datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Liaison Statement: CCAMP working group last call on "MPLS-TP Control Plane Framework" (ref #040.01)

Submission Date: 2010-10-20
From: IETF CCAMP WG (Loa Andersson)
To: ITU-T SG15 Q9, Q10, Q12 and Q14 (greg.jones@itu.int)
Cc:yoichi.maeda@ntt-at.co.jp
greg.jones@itu.int
ghani.abbas@ericsson.com
hhelvoort@huawei.com
malcolm.betts@zte.com.cn
hklam@alcatel-lucent.com
tsbsg15@itu.int
ahmpls-tp@lists.itu.int
dward@juniper.net
adrian.farrel@huawei.com
rcallon@juniper.net
paf@cisco.com
stbryant@cisco.com
mpls@ietf.org
mpls-tp@ietf.org
swallow@cisco.com
lberger@labn.net
db3546@att.com
Response Contact: lberger@labn.net
db3546@att.com
Technical Contact: llberger@labn.net
db3546@att.com
Purpose: For comment
Deadline: 2010-11-09 Action Needed
Attachments: (none)
Body:
SG15, Q9, Q10, Q12 and Q14

We like to to inform you that the CCAMP working group just started a
two week
 working group last call on "MPLS-TP Control Plane Framework"
(draft-ietf-ccamp-mpls-tp-cp-framework-03.txt).

Please note that this wg last call is limited to verify that comments
raised during the previous working group last call and reviews have
been correctly addressed.

We would like to receive comments from the ITU-T by November 9th 2010.

The disposition on comments from the earlier working group last call
were dstributed to the mailing lists by mail:

http://www.ietf.org/mail-archive/web/ccamp/current/msg11587.html

and is also copied here:

"All,
   We've updated draft-ietf-ccamp-mpls-tp-cp-framework to address last
call comments.  There a number of changes so we do expect a second last
call on these changes.  The major changes are as follows:

-- Updated OAM Requirements section (2.3) to match current versions of
     [RFC5860] and [TP-OAM], and updated LSP/PW tables to match
-- Added Section 2.5, Identifier Requirement based on
[TP-IDENTIFIERS],
     and updated LSP/PW tables to match
-- Addressed Liaison comments as listed below
-- Addressed minor and editorial feedback
-- Revised Editors list

Lou (for document authors/editors)

Responses to Liaison LS218, "Comments on
draft-ietf-ccamp-mpls-tp-cp-framework-02" are as follows.  The authors
expect this list to be used as the basis for a future Liaison
response.
=========================================================================

  > [M1]Editorial: Add the boiler plate text on joint development

This has been done.

  > [M2]Editorial: Add a note to the RFC editor that this Informational
RFC
  > has been approved by the IETF consensus process.

This has been done.

  > [M3]Path computation is normally out of scope for standards

Although specific path computation algorithms are out of scope, the
Path Computation function itself is in scope; see for example RFC 4655,
"A Path Computation Element (PCE)-Based Architecture".

  > [M4]Data plane or control plane?

The referenced text has been deleted.

  > [M5]RFC5654 says "The control plane for MPLS-TP MUST fit within the
ASON
  > architecture", however, ASON CP and GMPLS don't include the control
for
  > PW and the protocols identified for the PW control plane do not
comply
  > with the ASON architecture.

New explanatory text on this topic has been added to the document.

  > [M6]Current text implies that a control plane is always used for
PWs.

The scope of this document is the control plane for MPLS-TP, and the
related mechanisms defined by IETF for this technology.  As such, we
believe the current phrasing is correct.

  > [M7]Add this text to the Abstract section as per comment M1.

This text has been added.

  > [M8]This draft identifies the protocols for the control plane

The existing text is correct because the MPLS-TP Framework and MPLS-TP
Survivability Framework do limit the scope of protocols.

  > [M9]RFC5654 says "The control plane for MPLS-TP MUST fit within the
ASON
  > architecture", however, ASON CP and GMPLS don't include the control
for
  > PW and the protocols identified for the PW control plane do not
comply
  > with the ASON architecture.

This is a duplicate comment; see [M5] above.

  > [M10]RFC5654 says "The control plane for MPLS-TP MUST fit within
the
  > ASON architecture", however, ASON CP and GMPLS don't include the
control
  > for PW and the protocols identified for the PW control plane do
not
  > comply with the ASON architecture.

This is a duplicate comment; see [M5] above.

  > [M11]PW recovery is for further study

The text in question has been removed.

  > [M12]TP-SURVIVE describes both protection and restoration

Agreed.

  > [M13]Not exactly identical. See section 3.2 of [TP-FWK]

We have aligned the text with Section 3.3 of RFC 5921.

  > [M14]A server layer must support traffic engineering.

We have aligned the text with Section 3.3 of RFC 5921.

  > [M15]How is traffic engineering supported as per [RFC5654,
requirement
  > 5]

We have removed "as-is" from the sentence "MPLS PWs are used as-is by
MPLS-TP...".

  > [M16]Draft-ietf-pwe3-ldp-aii-reachability extends LDP for the
MS-PW
  > routing.  So, LDP should also be added here.

As LDP is already referred to in this narrative sentence, we believe
the existing text is sufficient.

  > [M17]The currently defined control plane is for "general purpose"
LSPs
  > the MPLS-TP control plane is for transport applications.

GMPLS was defined to include, and has been applied to, transport
applications, and thus we believe the existing text is correct.

  > [M18]ASTN is in old term that is no longer user

Agreed; the reference to the term has been removed.

  > [M19]The requirements state: The MPLS-TP control plane design
should as
  > far as reasonably possible reuse existing MPLS standards

We agree.

  > [M20]Is the IETF precluded from adopting work already completed in
other
  > standards bodies?

This question is outside the scope of the specific text and this
document.

  > [M21]The current GMPLS control plane does not include PWs.

This is correct.  We have added "LSP-related" in order to avoid
misunderstanding.

  > [M22]A GMPLS control plane does not support merging

The text in question has been removed.

  > [M23]The control plane requirements are provided in Section 2 of
this
  > RFC.

The text has been clarified.

  > [M24]MPLS-TP LSPs do not cross the UNI as defined in the MPLS-TP
  > Framework

We do not see how this comment relates to the highlighted text.

  > [M25]Can the PW be between CEs, if so the T-LDP session should
extend to
  > the CEs

In the figure a CE PW would be carried over an LSP, so PW should not be
listed as a client signal type; we have made the correction.

  > [M26]This figure is correct however it is inconsistent with the UNI
and
  > NNI as defined in the recently published MPLS-TP framework.  Is it
  > intended to publish a Bis for the overall framework to correct
this
  > inconsistency?

This figure shows the control plane representation of the UNI and NNI,
not the internal node representation shown in the MPLS-TP Framework.

  > [M27]Where are the RSVP-TE sessions?

We have clarified the figure.

  > [M28]T-LDP for PW label assignment

Targeted LDP is a form of LDP.

  > [M29]Use of hierarchical LSP as SPME for OAM alters data plane
  > processing of particular LSP(s) to which the H-LSP been applied.
Such
  > effect should be described.

Discussions of data-plane processing are outside the scope of this
document.  This document covers the control plane of hierarchical LSPs,
of which SPMEs are special cases.

  > [M30]TP-SURVIVE describes both protection and restoration. 
Restoration
  > has the most impact on the control plane.

We have added "and restored" after "protected".

  > [M31]instantiation of the MIPs is optional.

We have accepted the change.

  > [M32]Comments on Figure 1 also apply to figure 2.

We have accepted the change.

  > [M33]Editorial

We have accepted the change.

  > [M34]Address separation must added to LDP if this is used for PWs

We have updated the text to clarify.

  > [M35]Reword to make the control plane implications clear e.g. The
  > control plane must make all nodes.

We agree and have updated the text accordingly.

  > [M36]Reword to make the control plane implications clear

We agree and have updated the text accordingly.

  > [M37]Reword to make the control plane implications clear

We agree and have updated the text accordingly.

  > [M38]Independence of the management plane is outside the scope of
this
  > draft.  Reword to make the control plane implications clear

We agree and have updated the text accordingly.

  > [M39]Independence of the management plane is outside the scope of
this
  > draft.  Reword to make the control plane implications clear

We agree and have updated the text accordingly.

  > [M40]Independence of the management plane is outside the scope of
this
  > draft.  Reword to make the control plane implications clear

We agree and have updated the text accordingly.

  > [M41]Is this really a control plane requirement? Clarification is
  > needed.

We have removed this item, as related requirements are already captured
in 14 and 15.

  > [M42]To be consistent with RFC5654 Requirement, i.e., extra traffic
is
  > not required in MPLS-TP.

We believe the existing text is preferable as it aligns with the use of
"MAY" in the referenced text of RFC 5654.

  > [M43]How does this support traffic engineering as per [RFC5654,
  > requirement 5] and the address separation requirements

LDP is the foundation for the pseudowire control plane.  Traffic
engineering support for PWs is discussed in Section 5.

  > [M44]Better describe in 108, 109 and 124

The existing text parallels the text in RFC 5860.

  > [M45]This is not a control plane requirement

This text has been rephrased to reflect the control plane requirement
and for improved alignment with RFC 5860.

  > [M46]Not a control plane function

This text has been rephrased to reflect the control plane requirement.

  > [M47]Not a control plane function

This text has been rephrased to reflect the control plane requirement.

  > [M48]Should be reliable to support restoration the functions
  > identified should be independent of the control plane.

The current text reuses the language of RFC 5860.

  > [M49]Repeat of 109

We are maintaining parallelism with the structure in RFC 5860.  The
text has been revised to better align with that document.

  > [M50]116-123 are all OAM functions that may be enabled by the
control
  > plane as per requirement 109

This is correct.  Also, we are maintaining parallelism with the
structure in RFC 5860. The text has been revised to better align with
that document.

  > [M51]Part of MEP/MIP configuration

The current text is constructed to be aligned with [TP-OAM].

  > [M52]How are SPMEs established for PWs (PW TCM).  How is this
  > coordinated with LSP SPMEs.

PW/LSP coordination is covered in Section 5.1.

  > [M53]Please clarify the use of the term "tunnel" in this context. 
The
  > MPLS-TP identifiers draft uses the term tunnel as a logical
relationship
  > between node and is used to name LSPs.

We have removed the text in question.

  > [M54]The relationship of management plane with respect to the
transport
  > plane should be out of scope of this document.

We agree.

  > [M55]Should define how the terms are used in the context of the
MPLS-TP
  > control plane.

We have revised the subsequent text accordingly.

  > [M56]Please clarify this: Is it on the same wavelength or in the
same
  > fiber on a different wavelength.

This depends on the technology / layer of switching being performed. At
the optical layer it may be a different wavelength, at the TP layer it
would be the same wavelength.

  > [M57]Most use an embedded communications channel but the selection
of
  > the route for control/management traffic is independent for the
  > "associated data traffic" and hence is, in effect, out-of-band
  > independent topology.

We have removed the sentence in question.

  > [M58]How is this different from Out-of-band in-fiber

The difference is that the control plane uses the same node pairs but
not the same links.

  > [M59]If it is in-fiber or aligned topology links are used, please
  > clarify what "alignment is not required" means in this context.

It means simply that the independent topology case is a superset of the
aligned topology case.

  > [M60]Addressing in the context of the MPLS-TP data plane is defined
in
  > the MPLS-TP identifiers draft

The text has been revised to better align with the TP identifier
document.

  > [M61]Does "family" mean Format? Please clarify

The term "address family", as in IPv4 or IPv6 address family, is
commonly used in RFCs and is used here in the same sense.

  > [M62]See the identifiers draft.

We agree with the reference.

  > [M63]Do you mean "The address space(s) of the control, management
and
  > data planes used ..."?

Yes, as well as the neighbor adjacencies in the respective planes.

  > [M64]RFC 4201 defines mechanism by which allocated label is valid
across
  > all component links of given Link Bundle. Is this Link Bundle
technique
  > as well applicable to MPLS-TP?

The question relates to label allocation policy in the data plane and
is therefore outside the scope of the control plane and this document.

  > [M65]Is this consistent with the Survivability framework?

We have revised the text to better align with that document.

  > [M66]Not a control plane function

This text now references the GMPLS definition of recovery, which
includes this list.

  > [M67]Where is this defined?

We have added references to [RFC4872] and [RFC4873].

  > [M68]Should include MIP configuration

We agree and have updated the text accordingly.

  > [M69]A routing sub section should be add here. It is essential for
  > MS-PW. Furthermore, the TE mechanism for MS-PW should be described

This is covered in the last part of Section 5.1 and Section 5.3.4.

  > [M70]Specification for PW QoS, TE parameters, explicit route
control and
  > OAM configuration (for MS-PW) should be provided

These topics are covered in the following subsections.

  > [M71]Is this binding only for dynamic PW and dynamic LSP?  What
will it
  > be if a dynamic PW is bound to a static LSP and the reverse?

We have updated the text to clarify.  Note that the case of configured
pseudowires is outside the scope of the control plane.

  > [M72]MS-PW recovery that is independent of LSP recovery should
  > considered.  This would allow recovery in the event of a PE node
  > failure.

As S-PEs and T-PEs are always co-located with LSP end points, we
believe that the described case accurately reflects the MPLS-TP data
plane."


Loa Andersson on behalf of
Deborah Brungard and Lou Berger


CCAMP Working Group co-chairs