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

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Wed, 10 Nov 2010 21:07:10 -0500

This Last Call has ended. Authors please address the comments.
Thanks,
Deborah

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
BRUNGARD, DEBORAH A (ATTLABS)
Sent: Tuesday, October 19, 2010 10:14 AM
To: CCAMP; MPLS-TP; PWE3; [email-masked]
Subject: [mpls] Last Call on
draft-ietf-ccamp-mpls-tp-cp-framework-03.txt

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: [email-masked] [mailto:[email-masked]] 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, [email-masked] 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
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp
_______________________________________________
mpls mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls

---

From: Lou Berger <[email-masked]>
Date: Mon, 22 Nov 2010 08:33:26 -0500

All,
	We have updated and posted rev -04 of this document.  The document has 
been updated as discussed on the list and as discussed below.

The authors believe all LC comments have been addressed.

Lou (and co-authors)
-----------------------------------

The following are proposed resolutions to the comments received in the
ITU-T Liaison:

Comment [M1]: Need to clarify that this applies to both LSP and
PW and that management plane configuration is always supported –
See comment M6 on v2.  Another solution for this comment would be
to delete the sentence.

Response: remove text requiring clarification
OLD Text:
Management plane functions such as manual configuration and the
initiation of LSP setup are out of scope of this document.
NEW Text:
Management plane functions are out of scope of this document.

Comment [M2]Extension may also be required for PWs (e.g. OAM
configuration) which may be outside the scope of GMPLS.
Proposed text change: Removed "GMPLS", add "and PW".
Response: Accept change

Comment [M3]Also need to consider upgrades in the context of PW
configuration
Proposed text change: strike "(G)MPLS enabled"
Response: Accept change

Comment [M4]: Similar text was proposed in the comments on v2
but was not included.
Proposed text change: Note that failure or restarting of the
control plane or a change in LSP ownership must not impact the
operation of any protection or OAM functions which were configured
by either the control plane or management plane.
Response: No comment was included in the earlier liaison. Text
was viewed as a statement, not proposed addition. While the
proposed text is not unreasonable, we are unable to add the text
in the proposed location as parallel text does not exist in
RFC5654.

Comment [M5]: See comment M42 on v2. Use of may implies that the CP
design must support extra traffic but activation is optional. RFC5654
Requirement, i.e., extra traffic is not required in MPLS-TP
Proposed text change: strike "may" add "is not required to"
Response: Please see RFC2119 for the usage of "may" in the IETF
context.  We believe the current text is consistent with both
common IETF usage of may and the text in RFC5654.

Comment [M6]: The current wording of 100 and 101 implies a
single control plane, in this case the requirements are
contradictory, add LSP/PW to clarify the scope of each
statement.
Proposed text change: Add "for LSPs", strike "for MPLS-TP LSPs",
add "for PWs" (leave for MPLS-TP PWs)
Response: Accepted.

Comment [M7]Between nodes or along the same path.
Proposed text change: strike "along", add "between"
Response: clarify text:
OLD Text:
along the same node pairs, but not necessarily the same links
NEW Text:
along the same nodal path, but not necessarily the same links
Comment [M8]typo
Response: Accepted.

On 11/10/2010 9:07 PM, BRUNGARD, DEBORAH A (ATTLABS) wrote:
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>