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

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