Subject: Re: [mpls-tp] Response to ITU-T Liaison on draft-mpls-tp-requirements-00 (TD54-PLEN)

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 03 Jan 2009 11:36:32 +0000

Colleagues,

draft-mpls-tp-requirements-02 should now be on the IETF internet draft
servers for download here:

  The only differences between this version and the one I attached to a
previous message are the date & IPR text.

My apologies

On 22/12/2008 15:35, "Benjamin Niven-Jenkins"
<[email-masked]> wrote:

> Colleagues,
> 
> I have addressed the comments in the ITU-T SG15 liaison (TD54) and have
> posted a revised version of draft-mpls-tp-requirements (-02) which I have
> also attached. I had to manually post the draft as I can't find a xml2rfc
> version with the new boilerplate so it may take a while for the draft to
> appear for download.
> 
> ITU-T folks should note that I have already updated the draft in version -01
> to reflect comments made by an ad hoc review group during the Geneva meeting
> (lead by Adrian Farrel) which included amongst other changes a complete
> rewrite of the Recovery & Survivability section. It is therefore difficult
> to reconcile your comments on that section with the new section.  I have
> therefore only made limited edits to that section and would appreciate if
> you could review the new section to ensure it accurately encompasses your
> requirements.
> 
> Below are my personal responses to specific issues or questions raised in
> the liaison.
> 
> Ben
> 
> 
> 1) Liasion: "Note: we consider MPLS-TP as being composed by both MPLS LSP
> and PW layer networks (i.e. is the relationship between PW and MPLS-TP the
> same as between PW and MPLS, is there a potential need for PW extensions
> and/or profiling to support transport requirements). Is our understanding
> correct?
> 
> ITU-T Q12/15 will provide some deployment scenario by <TBD> in order to
> assist the resolution of this comment.
> 
> Note for Q12/15: Define the TBD above."
> 
> BN: Noted. I believe the relationship between PW & MPLS-TP to be the same as
> for PW & MPLS. As a result of comparing the requirements to existing
> solutions there may be a need to enhance or modify the PW specs. That is the
> job of the PWE3 WG and out of scope of the requirements document.
> 
> 
> 2) Liaison: " Note: Definition of Section should be aligned with the
> description below:"
> 
> BN: I have changed the definition to the following which I believe better
> aligns.
> 
> " Section: A section is a server layer (which may be MPLS-TP or a different
> technology) which provides for encapsulation and OAM of a MPLS-TP transport
> path client layer. A section layer may provide for aggregation of multiple
> MPLS-TP clients."
> 
> 
> 3) Liaison: " Note: Align the definition of Segment above with the
> definition of LSP Segment in RFC 4397:"
> 
> BN: I believe they were already aligned although the wording was somewhat
> different.  I have changed the definition of segment to the following which
> hopefully make it clearer.
> 
> " Segment: A segment is a single resource or a set of cross-connected
> resources that constitutes part of a path. A segment may be a single link
> (hop) within a path, a series of adjacent links (hops) within a path, or the
> entire end-to-end-path."
> 
> 
> 4) Liaison: " It is also our understanding that a PW segment is equivalent
> to a link connection within the PW layer network."
> 
> BN: Correct.
> 
> 
> 5) Liaison: " Note: the text ³The combination of a PW (Single Segment or
> Multi-Segment) and LSP corresponds to an MPLS-TP transport path² requires
> some clarification."
> 
> BN: Following other feedback I have already changed the text to " A
> Transport path corresponds to an MPLS-TP LSP or to an MPLS-TP LSP and its
> associated PW or PWs (Single Segment or Multi-Segment)."
> 
> 
> 6) Liaison: " Note 1: We are not sure that the description above matches
> with our original description reported hereafter. If necessary we can supply
> some text together with some deployment scenarios on this extent. ..."
> 
> BN: Please look 3 paragraphs down in that section and you will find a
> slightly modified version of your original description already there.
> 
> 
> 7) Liaison: " Note 2: we understood that within the IETF context aggregation
> and merging are different concepts:
> -    merging when different LSPs are forwarded with the same outgoing label.
> When this label is popped, the client signal (e.g. IP) carried by the merged
> LSPs gets exposed
> -    aggregation when different LSPs are multiplexed together into another
> LSP. When the label is popped, each individual original LSP gets exposed and
> can be identified.
> Is our understanding correct?"
> 
> BN: Yes.
> 
> 
> 8) Liaison: " Note 3: we need to clarify that the services offered to the
> clients can be point-to-point, point-to-multipoint or
> multipoint-to-multipoint services but the actual transport paths can be
> point-to-point or point-to-multipoint."
> 
> BN: This is already covered to some extent by the definition of transport
> path layer and transport service layer but I added the following sentence to
> section 1.2 to make it clear.
> 
> " Although the connectivity of the client of the transport path layer may be
> point-to-point, point-to-multipoint or multipoint-to-multipoint, the
> transport path layer itself only provides point-to-point or
> point-to-multipoint transport paths which are used to carry the client. "
> 
> 
> 9) Liaison: Suggested insertion of "only" in "MPLS-TP MUST support only a
> connection-oriented packet switching paradigm with traffic engineering
> capabilities that allow deterministic control of the use of network
> resources."
> 
> BN: Following other feedback I have already changed the wording of this
> requirement to the following which I believe also addresses what you were
> trying to achieve:
> 
> " MPLS-TP MUST be a connection-oriented packet switching model with traffic
> engineering capabilities that allow deterministic control of the use of
> network resources."
> 
> 
> 10) The liaison suggested changing " A solution MUST be provided to support
> dynamic provisioning of MPLS-TP transport paths via a control plane." to
> "The MPLS-TP specification MUST include a solution to support a control
> plane for dynamic provisioning of MPLS-TP transport paths. This control
> plane is OPTIONAL to be implemented or enabled."
> 
> BN: Following other feedback the following paragraph was added to the
> Introduction " Although both static and dynamic configuration of MPLS-TP
> transport paths (including Operations, Administration and Maintenance (OAM)
> and protection capabilities) is required by this document, it MUST be
> possible for operators to be able to completely operate (including OAM and
> protection capabilities) an MPLS-TP network in the absence of any control
> plane protocols for dynamic configuration." I believe this addresses the
> same concern as your proposed change.
> 
> 
> 11) Liaison: " Question: why was the term ³section² instead of ³Link² used
> in requirement 23? In our understanding the requirement 23 is applicable to
> Link."
> 
> BN: I have used link instead.
> 
> 
> 12) Liaison: " Note: it would be worth adding a note to the paragraph above
> stating that a label push/pop can be used also for other purposes other than
> aggregation/de-aggregation."
> 
> BN: Following other feedback the paragraph you refer to has been removed.
> 
> 
> 13) Liaison suggests changing SHOULD to MUST in "MPLS-TP SHOULD support
> mechanisms which ensure the integrity of the transported customer's service
> traffic."
> 
> BN: Done, however there is some debate as to what is meant by integrity in
> this context. Clarification from ITU-T experts would be appreciated.
> 
>  
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sat, 03 Jan 2009 11:39:29 +0000

Colleagues,

http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-requirements-02.txt

  The only differences between this version and the one I attached to a
previous message before Christmas are the date & IPR text.

My apologies for the delay this was primarily due to me not reading the
instructions for xml2rfc & the new IETF Trust boilerplate properly.

Ben