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

[Lou Berger <[e-mail]>]

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:
> This Last Call has ended. Authors please address the comments.
> Thanks,
> Deborah
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> BRUNGARD, DEBORAH A (ATTLABS)
> Sent: Tuesday, October 19, 2010 10:14 AM
> To: CCAMP; MPLS-TP; PWE3; [e-mail]
> 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: [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
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls
> _______________________________________________
> CCAMP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>