[mpls] Last Call on draft-ietf-ccamp-mpls-tp-cp-framework-03.txt

["BRUNGARD, DEBORAH A (ATTLABS)" <[e-mail]>]

Thanks authors.

This begins a second Last Call. The Last Call ends on Nov. 9th.

Please send comments (limited to updates) to the ccamp and pwe3 lists.

Thanks,
CCAMP Co-Chairs, PWE3 Co-Chairs, MPLS Co-Chairs



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Lou Berger
Sent: Friday, October 15, 2010 3:19 PM
To: CCAMP; MPLS-TP; PWE3
Subject: Re: [mpls-tp] [CCAMP] I-D
Action:draft-ietf-ccamp-mpls-tp-cp-framework-03.txt (resend)

[This is a resend to include the CCAMP, MPLS-TP, and PWE3 lists]

On 10/15/2010 3:00 PM, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Common Control and Measurement Plane
Working Group of the IETF.
>
>
> 	Title           : MPLS-TP Control Plane Framework
> 	Author(s)       : L. Andersson, et al.
> 	Filename        : draft-ietf-ccamp-mpls-tp-cp-framework-03.txt
> 	Pages           : 54
> 	Date            : 2010-10-15
...
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framewor
k-03.txt
...

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.

_______________________________________________
mpls-tp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mpls-tp