Subject: Re: [mpls-tp] Scope of IETF MPLS-TP developments? [was: RE:[T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

From: "Xueqin WEI (Shuetsing WEI)" <[email-masked]>
Date: Fri, 27 Feb 2009 16:09:15 +0800

Maarten:

Is the second figure in you email means PW can be nested?  Just as you metioned in the second figure "PW lable stack entry head" and "PWE3 encapsulaiton"? I just want to confirm this with you.

My understand is PW lable only apear once as the client to LSP. Only LSP lable can be nested, not PW label. Am I right?

Sincerely Yours
Xueqin Wei (Shuetsing Wei)

Development & Planning Department,
Fiberhome Telecommunication Technologies Co.,Ltd.,
No.88 Youkeyuan Road,Hongshan Dist.,Wuhan,Hubei,P.R.China,430074
Email:  [email-masked]
2009-02-27  16:03:02

==================== Following is your email=====================
Subject:Re: [mpls-tp] Scope of IETF MPLS-TP developments? [was: RE:[T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]
Sent：2009-02-25 16:52:48
From:Maarten Vissers
To:'Malcolm Betts'; neil.2.harrison
CC to:ahmpls-tp; tsg15q12; mpls-tp

>Malcolm,
>
>> my understanding of the scope of work on MPLS-TP that has been agreed
>between
>> the ITU-T and the IETF is the definition of the MPLS-TP layer network.
>
>From a T-MPLS layer network perspective, the "MPLS-TP layer network"
>includes the MS-PW, LSP tunnel/path and LSP section layer network instances.
>The MS-PW layer is essentially a LSP service/channel layer as illustrated in
>the figure below, which operates "between the PWE3 encapsulation and the PW
>label stack entry header". I.e. MS-PW is a transport service layer LSP, or
>stated in an alternative manner "MS-PW = LSP".
>
>Is the "MPLS-TP layer network" to be used as a the transport service layer
>network for p2p and p2mp services, as indicated in the bottom part of the
>figure below?
>
>
>
> 
>Regards
>Maarten
>
>
>-----Original Message-----
>From: Malcolm Betts [mailto:[email-masked]]
>Sent: dinsdag 24 februari 2009 14:14
>To: Maarten Vissers; [email-masked]
>Cc: [email-masked]; [email-masked]; [email-masked]
>Subject: RE: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp]
>[T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]
>
>Maarten, my understanding of the scope of work on MPLS-TP that has been
>agreed between the ITU-T and the IETF is the definition of the MPLS-TP layer
>network.
>
>To address your other points - for consideration by Q12/15:
>
>If we (in SG 15) decide to advance work on a "top to bottom" definition of a
>packet transport network then that definition must be based on a stack of
>independent layer networks.  This approach allows us to minimize complexity
>(i.e. minimizes the interactions between layer networks) and therefore
>allows the network to continue to evolve.  This evolution involves the
>addition of new (transport) technologies to existing networks.  This
>includes the network support infrastructure (e.g. OSS).  Once a "new"
>technology has been deployed it becomes a part of the "existing" network.
>History has demonstrated that technologies have a finite life and will
>eventually be replaced.
>
>With that in mind I am advocating the definition of a set of (client/server)
>independent layer networks (e.g. MPLS-TP).  This is the approach that has
>been taken for a number of years by SG 15 when defining the transport
>network.  The application of a common approach to the definition of these
>layer networks (based on G.805 and G.800) allows us to recognize the aspects
>that are common from the perspective of network operation.  It is this
>approach that has allowed the TMForum to develop and deploy the MTNM
>interface (for SDH, ATM, OTN, Ethernet, ASON....) over the last 10 years.
>Good engineering practice indicates that we should, where appropriate, reuse
>the implementation of some functions in multiple technologies.  This reuse
>enable simplicity without incurring dependency.
>
>In the last study period work on a "packet transport network" was initiated
>in Q12 but was not advanced due to lack of interest and contributions. If we
>intend to revive this activity we should first agree on the network
>scenarios and business boundaries that we are attempting to address so that
>we can understand the scope of the work.
>
>Malcolm Betts
>Co chair ad hoc on MPLS-TP
>Phone: +1 613 763 7860 (ESN 393)
>email: [email-masked]
>
>-----Original Message-----
>From: Maarten Vissers [mailto:[email-masked]]
>Sent: Sunday, February 22, 2009 7:10 PM
>To: [email-masked]; Betts, Malcolm (CAR:X632)
>Cc: [email-masked]; [email-masked]
>Subject: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] [T15Q12]
>FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]
>
>Neil, Malcolm,
>
>I assume that you refer to the MPLS-TP LSP layer, which provides a transport
>path layer role in the packet transport network.
>
>Of all the layers in a packet transport network (transport service,
>transport path, section, phy media) the transport path layer is the least
>important layer (just a scalability measure). The reason is that the p2p
>(and optional p2mp) transport entities in this layer are domain bound, i.e.
>exist between nodes at the edge of an aggregation domain. Those p2p/p2mp
>transport path layer transport entities can be supported by every packet
>technology; e.g. Ethernet VLAN, MPLS-TP LSP and PBB-TE TESI; main difference
>is their label sizes: 12-bit, 20-bit, 108-bit. And the number of transport
>path layer trnasport entities is much smaller then the number of transport
>service layer transport entities.
>
>The most important layer is the transport service layer. The p2p, p2mp, rmp,
>mp2mp transport entities in this layer carry the customer services, may
>cross through different admin domains, may be protected and provide
>information to verify the SLAs.
>
>For me, MPLS-TP is as such not just the definition of **yet another**
>transport path instance; i.e. of a MPLS-TP LSP layer, MPLS-TP LSP
>characteristic information and MPLS-TP LSP OAM. MPLS-TP for me is the
>definition of a complete transport solution, including as well all the
>aspects of the transport service layer, section layer and physical media
>layer.
>
>To prevent that we continue to have discussions related to the envisaged
>scope of the MPLS-TP work in IETF, I would like to understand if the scope
>of this work is limited to either the definition of a MPLS-TP LSP layer that
>will be used as a transport path layer in the emerging packet transport
>network, or the definition of a packet transport network solution including
>a MPLS-TP LSP layer as transport service layer.
>
>Regards,
>Maarten
>
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: zaterdag 21 februari 2009 19:09
>To: [email-masked]; [email-masked];
>[email-masked]; [email-masked]
>Cc: [email-masked]; [email-masked]
>Subject: RE: [mpls-tp] [T15Q12]
>FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP
>
>Quite!
>
>regards, Neil
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Malcolm Betts
>> Sent: 17 February 2009 20:41
>> To: Maarten Vissers; Drake, John E; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [mpls-tp] [T15Q12]
>> FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP
>>
>> Maarten, if we have client/server independence with MPLS-TP why is it
>> necessary to burden MPLS-TP with the task of defining its client layer
>> network(s).
>>
>>
>> Malcolm Betts
>> Nortel Networks
>> Phone: +1 613 763 7860 (ESN 393)
>> email: [email-masked]
>>
>> -----Original Message-----
>> From: Maarten Vissers [mailto:[email-masked]]
>> Sent: Tuesday, February 17, 2009 2:12 PM
>> To: Betts, Malcolm (CAR:X632); 'Drake, John E'; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: RE: [mpls-tp] [T15Q12] FW:
>> LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP
>>
>> Malcolm,
>>
>> We do need to define the architecture of the MPLS-TP transport service
>> layer.
>>
>> As far as I understand MPLS-TP has the following two options for its
>> transport service layer:
>> 1) Ethernet VLAN (ETH) for all services
>> 2) Ethernet VLAN (ETH) for rmp and mp2mp services plus MPLS-TP MS-PW
>> for p2p and p2mp services.
>>
>> Regards,
>> Maarten
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Malcolm Betts
>> Sent: dinsdag 17 februari 2009 17:49
>> To: Drake, John E; [email-masked]
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison
>> onthecooperationbetweenIETFandITU-Ton MPLS-TP
>>
>> Agree, MPLS-TP should be payload agnostic.  We should define/identify
>> the set of supported client adaptations and the PW adaptation should
>> be included.
>>
>> My point is that we do not need to define/specify the PW architecture.
>>
>>
>> Malcolm Betts
>> Nortel Networks
>> Phone: +1 613 763 7860 (ESN 393)
>> email: [email-masked]
>>
>> -----Original Message-----
>> From: Drake, John E [mailto:[email-masked]]
>> Sent: Tuesday, February 17, 2009 11:21 AM
>> To: [email-masked]
>> Cc: Betts, Malcolm (CAR:X632); [email-masked];
>> [email-masked]
>> Subject: RE: [mpls-tp] [T15Q12] FW: Liaison on
>> thecooperationbetweenIETFandITU-Ton MPLS-TP
>>
>> *required*?  I would think MPLS TP should be payload agnostic.
>>
>> > -----Original Message-----
>> > From: Stewart Bryant [mailto:[email-masked]]
>> > Sent: Tuesday, February 17, 2009 8:14 AM
>> > To: Drake, John E
>> > Cc: Malcolm Betts; [email-masked]; [email-masked]
>> > Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on
>> > thecooperationbetweenIETFandITU-Ton MPLS-TP
>> >
>> > I disagree. MPLS-TP at least needs to call up PWs as the required
>> > adaptation mechanism.
>> >
>> > Stewart
>> >
>> >
>> >
>> > Drake, John E wrote:
>> > > Malcom,
>> > >
>> > > I agree that MPLS PWs are a reasonable payload for MPLS TP
>> > but they are not part of the definition of MPLS TP.
>> > >
>> > > Thanks,
>> > >
>> > > John
>> > > 
>> > >> -----Original Message-----
>> > >> From: Malcolm Betts [mailto:[email-masked]]
>> > >> Sent: Tuesday, February 17, 2009 7:20 AM
>> > >> To: [email-masked]
>> > >> Cc: [email-masked]
>> > >> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on
>> > >> thecooperationbetweenIETFandITU-T on MPLS-TP
>> > >>
>> > >> All, I think that we need to distinguish between what must
>> > be defined
>> > >> in the context of a "complete" network and what must be
>> > specified for
>> > >> the MPLS-TP layer network that provides co-ps "transport
>> > service" in
>> > >> the context of a "complete" network.
>> > >>
>> > >> I think the issue that Neil raise in his 3rd point is that
>> > if we have
>> > >> client server independence (as identified by Neil in point
>> > 1) then in
>> > >> the context of the MPLS-TP layer network what do we need
>> > to specify
>> > >> about the client or the server layer networks.
>> > >>
>> > >> I suggest that for the client we only need to define the
>> supported
>> > >> adaptations and the "transport service" offered by MPLS-TP.  i.e.
>> > >> definition of the PW layer should not be in scope for
>> the MPLS-TP
>> > >> RFCs or Recommendations.  I see good rational for reuse
>> of the PW
>> > >> mapping that are already defined and deployed.  We can
>> > debate if SG15
>> > >> should develop Recommendations describing PWs, (single or multi
>> > >> segment) but that is a separate issue.
>> > >>
>> > >> For the server layer, as discussed on the lists we should
>> > only define
>> > >> the transport service that must be provided in order for
>> > the MPLS-TP
>> > >> layer to be able to guarantee the service that it is
>> > offering to its
>> > >> client.
>> > >>
>> > >> I hope that this approach (reduction of scope) will allow
>> > us to focus
>> > >> on getting MPLS-TP defined.
>> > >>
>> > >> Malcolm Betts
>> > >> Nortel Networks
>> > >> Phone: +1 613 763 7860 (ESN 393)
>> > >> email: [email-masked]
>> > >>
>> > >> -----Original Message-----
>> > >> From: [email-masked]
>> > >> [mailto:[email-masked]] On Behalf Of Maarten Vissers
>> > >> Sent: Tuesday, February 17, 2009 1:45 AM
>> > >> To: [email-masked]; [email-masked]
>> > >> Cc: [email-masked]
>> > >> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the
>> > >> cooperationbetweenIETFandITU-T on MPLS-TP
>> > >>
>> > >> As per MPLS-TP requirements draft, MPLS-TP will need to have the
>> > >> following
>> > >> layers:
>> > >> 1) transport service layer
>> > >> 2) transport path layer
>> > >> 3) section layer
>> > >> 4) physical media layer.
>> > >>
>> > >> My understanding is that so far we were discussing to use the
>> > >> following layer technologies for those four layers:
>> > >> 1) ETH and optional MS-PW
>> > >> 2) Path LSP
>> > >> 3) Section LSP or ETH Section
>> > >> 4) 802.3, SDH, OTN.
>> > >>
>> > >> If we remove the MS-PW from the set above, does this imply
>> > that the
>> > >> transport service layer is provided by an ETH (i.e.
>> > >> Ethernet VLAN) layer for all services? I.e. following the
>> > case that I
>> > >> have found in some of the european networks today.
>> > >>
>> > >> Or, will the removal of the MS-PW imply that the p2p and p2mp
>> > >> services are supported by a new "Service LSP" layer?
>> > >>
>> > >> The deployment of a Service LSP layer (instead of a MS-PW
>> > >> layer) will not change the packet formats as far as I can see.
>> > >>
>> > >> Regards,
>> > >> Maarten
>> > >>
>> > >> -----Original Message-----
>> > >> From: [email-masked]
>> > >> [mailto:[email-masked]] On Behalf Of
>> > [email-masked]
>> > >> Sent: maandag 16 februari 2009 16:58
>> > >> To: [email-masked]; [email-masked]
>> > >> Cc: [email-masked]
>> > >> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the
>> > >> cooperationbetweenIETFandITU-T on MPLS-TP
>> > >>
>> > >> John is correct.  You to remember Liu that PWs only came about
>> > >> because of the way MPLS was originally specified.  For
>> MPLS-TP to
>> > >> assume a  transport role then (i) the conditions which
>> > gave rise to
>> > >> the need for PWs in MPLS have to be removed and (ii) we
>> > have to treat
>> > >> all clients equally/transparently.  Furthermore, and of
>> > even greater
>> > >> importance, is the fact that the MS-PWs that are now being
>> > considered
>> > >> in MPLS cannot have any place in MPLS-TP.  This is
>> because a MS-PW
>> > >> represents a co-ps mode layer network above MPLS, and clearly a
>> > >> transport network such as MPLS-TP should never require
>> > >> unnecessary layer networks to be created
>> above it. 
>> > >>
>> > >> regards, Neil
>> > >> PS - I am away on leave for a week now so will not be able
>> > to respond
>> > >> to any further questions until I get back.
>> > >>
>> > >>   
>> > >>> -----Original Message-----
>> > >>> From: [email-masked]
>> > >>> [mailto:[email-masked]] On Behalf Of Drake, John E
>> > >>> Sent: 16 February 2009 15:22
>> > >>> To: [email-masked]
>> > >>> Cc: [email-masked]
>> > >>> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation
>> > >>> betweenIETFandITU-T on MPLS-TP
>> > >>>
>> > >>> There are no PW headers in this proposal.
>> > >>>
>> > >>>     
>> > >>>> -----Original Message-----
>> > >>>> From: [email-masked] [mailto:[email-masked]]
>> > >>>> Sent: Sunday, February 15, 2009 6:55 PM
>> > >>>> To: Drake, John E
>> > >>>> Cc: [email-masked]
>> > >>>> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation
>> > >>>> between IETFandITU-T on MPLS-TP
>> > >>>>
>> > >>>>
>> > >>>> John:
>> > >>>>  I have a question of your solution. if adding PPP PID of the
>> > >>>> associated client payload as the bottom-most label,
>> > there are two
>> > >>>> different traffic that are both the same type i.e ETH,
>> > >>>>       
>> > >> needing to be
>> > >>   
>> > >>>> transported by MPLS-TP layer network. if using your
>> > solution, the
>> > >>>> two traffic must be encapsulated by the same PW label and
>> > >>>>       
>> > >> maybe be
>> > >>   
>> > >>>> tranported by the same MPLS-TP LSP. so how to identify the two
>> > >>>> different traffic in sink MEP of mpls-tp LSP?
>> > >>>> regards
>> > >>>> liu
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> "Drake, John E" <[email-masked]>
>> > >>>> 发件人:  [email-masked]
>> > >>>>
>> > >>>> 2009-02-16 03:48 收件人
>> > >>>> <[email-masked]>, <[email-masked]>,
>> > <[email-masked]>
>> > >>>> 抄送
>> > >>>> 主题
>> > >>>> Re: [mpls-tp] [T15Q12] FW: Liaison on the cooperation between
>> > >>>>        IETFand ITU-T on MPLS-TP
>> > >>>>
>> > >>>>      
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> Hi,
>> > >>>>
>> > >>>> Neil and I have been discussing how to address the
>> > >>>>       
>> > >> requirements he
>> > >>   
>> > >>>> lists in his e-mail, below, and we would like to propose the
>> > >>>> following.
>> > >>>>
>> > >>>> We would add the PPP PID of the associated client
>> payload as the
>> > >>>> bottom-most label, with the 'bottom of stack' bit set, in
>> > >>>>       
>> > >> the server
>> > >>   
>> > >>>> MPLS stack.  (We would also define a new PPP PID value
>> > >>>>       
>> > >> for dataplane
>> > >>   
>> > >>>> OAM
>> > >>>> payloads.)
>> > >>>>
>> > >>>> So, the 'bottom of stack' entry in the server MPLS stack
>> > >>>>       
>> > >>> would look as
>> > >>>     
>> > >>>> follows:
>> > >>>>
>> > >>>> -                 When carrying client payloads:
>> > >>>>
>> > >>>>     0                   1                   2        
>>          3
>> > >>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> > >>>>       
>> > >> 7 8 9 0 1
>> > >>   
>> > >>>>  
>> > >>>>       
>> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >>   
>> > >>>>    |0 0 0 0|       PPP client PID          |0 0 0|1|0 0 0
>> > >>>>       
>> > >> 0 0 0 0 1|
>> > >>   
>> > >>>>  
>> > >>>>       
>> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >>   
>> > >>>>                                              EXP  S      TTL
>> > >>>> -                 When carrying OAM payloads:
>> > >>>>
>> > >>>>     0                   1                   2        
>>          3
>> > >>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> > >>>>       
>> > >> 7 8 9 0 1
>> > >>   
>> > >>>>  
>> > >>>>       
>> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >>   
>> > >>>>    |0 0 0 0|       PPP OAM (TBD)           |0 0 0|1|0 0 0
>> > >>>>       
>> > >> 0 0 0 0 1|
>> > >>   
>> > >>>>  
>> > >>>>       
>> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >>   
>> > >>>>                                              EXP  S     TTL
>> > >>>>
>> > >>>> -                 When carrying inband control
>> > >>>> plane/management plane payloads:
>> > >>>>
>> > >>>>     0                   1                   2        
>>          3
>> > >>>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
>> > >>>>       
>> > >> 7 8 9 0 1
>> > >>   
>> > >>>>  
>> > >>>>       
>> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >>   
>> > >>>>    |0 0 0 0|       GAL                     |0 0 0|1|0 0 0
>> > >>>>       
>> > >> 0 0 0 0 1|
>> > >>   
>> > >>>>  
>> > >>>>       
>> > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> > >>   
>> > >>>>                                              EXP  S     TTL
>> > >>>>
>> > >>>>                 I.e., the GAL (label 13) is specifically
>> > reserved
>> > >>>> for carrying
>> > >>>> CP/MP protocols                  between logically adjacent
>> > >>>> MPLS-TP layer network
>> > >>>> nodes.  (The S bit is essentially                  'don't
>> > >>>> care' as it is the
>> > >>>> globally unique GAL that is the key identifier.)  The GAL   
>> > >>>>              is never
>> > >>>> associated with the DP and is never propagated beyond
>> 2 logically
>> > >>>> adjacent                  MPLS-TP layer network nodes.  The
>> > >>>> GAL is always
>> > >>>> immediately followed by the G-ACH                  and this
>> > >>>> identifies the specific
>> > >>>> CP or MP protocol/functions being carried in the            
>> > >>>>     payload.
>> > >>>>
>> > >>>> The server MPLS stack entries with S=0 have normal traffic
>> > >>>>       
>> > >>> forwarding
>> > >>>     
>> > >>>> semantics (including the normal use of EXP and TTL
>> > >>>>       
>> > >> fields) for label
>> > >>   
>> > >>>> values > 15.
>> > >>>>
>> > >>>> If a control plane is used to establish the server LSP,
>> > >>>>       
>> > >> there would
>> > >>   
>> > >>>> presumably be a capabilities exchange to ensure that both
>> > >>>>       
>> > >>> ends of that
>> > >>>     
>> > >>>> LSP will understand the significance of the botom-most
>> > >>>>       
>> > >> label in this
>> > >>   
>> > >>>> context.
>> > >>>>
>> > >>>> We think that this proposal is consistent with RFC 3032,
>> > >>>>       
>> > >>> which states:
>> > >>>     
>> > >>>> "2.2. Determining the Network Layer Protocol
>> > >>>>
>> > >>>>   When the last label is popped from a packet's label stack
>> > >>>>       
>> > >>> (resulting
>> > >>>     
>> > >>>>   in the stack being emptied), further processing of the
>> > packet is
>> > >>>>   based on the packet's network layer header.  The LSR
>> > >>>>       
>> > >>> which pops the
>> > >>>     
>> > >>>>   last label off the stack must therefore be able to
>> identify the
>> > >>>>   packet's network layer protocol.  However, the label
>> > >>>>       
>> > >>> stack does not
>> > >>>     
>> > >>>>   contain any field which explicitly identifies the
>> network layer
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> Rosen, et al.               Standards Track                 
>> > >>>>   [Page 5]
>> > >>>> > > > > >
>> > >>>> RFC 3032               MPLS Label Stack Encoding          
>> > >>>> January 2001
>> > >>>>
>> > >>>>
>> > >>>>   protocol.  This means that the identity of the network layer
>> > >>>> protocol
>> > >>>>   must be inferable from the value of the label which is
>> > >>>>       
>> > >> popped from
>> > >>   
>> > >>>>   the bottom of the stack, possibly along with the
>> > contents of the
>> > >>>>   network layer header itself.
>> > >>>>
>> > >>>>   Therefore, when the first label is pushed onto a
>> network layer
>> > >>>>   packet, either the label must be one which is used ONLY
>> > >>>>       
>> > >>> for packets
>> > >>>     
>> > >>>>   of a particular network layer, or the label must be one
>> > >>>>       
>> > >> which is
>> > >>   
>> > >>>> used
>> > >>>>   ONLY for a specified set of network layer protocols,
>> > >>>>       
>> > >> where packets
>> > >>   
>> > >>>> of
>> > >>>>   the specified network layers can be distinguished by
>> > >>>>       
>> > >> inspection of
>> > >>   
>> > >>>>   the network layer header.  Furthermore, whenever
>> that label is
>> > >>>>   replaced by another label value during a packet's
>> > >>>>       
>> > >> transit, the new
>> > >>   
>> > >>>>   value must also be one which meets the same
>> criteria.  If these
>> > >>>>   conditions are not met, the LSR which pops the last
>> label off a
>> > >>>>   packet will not be able to identify the packet's
>> network layer
>> > >>>>   protocol."
>> > >>>>
>> > >>>> Thanks,
>> > >>>>
>> > >>>> Neil and John
>> > >>>>
>> > >>>>       
>> > >>>>> -----Original Message-----
>> > >>>>> From: [email-masked] [mailto:[email-masked]]
>> > >>>>> Sent: Saturday, February 14, 2009 1:41 AM
>> > >>>>> To: [email-masked]; [email-masked];
>> > >>>>>         
>> > >> [email-masked]
>> > >>   
>> > >>>>> Subject: Re: [mpls-tp] [T15Q12] FW: Liaison on the
>> cooperation
>> > >>>>> between IETFand ITU-T on MPLS-TP
>> > >>>>>
>> > >>>>> Thanks Malcolm,
>> > >>>>>
>> > >>>>> Your mail has prompted me to list some key
>> requirements that I
>> > >>>>> believe are important for both ITU-T and IETF to
>> consider as we
>> > >>>>> develop the standards for MPLS-TP.  In no particular order:
>> > >>>>>
>> > >>>>>
>> > >>>>> 1                  Transparent client/server relationship:
>> > >>>>>
>> > >>>>> If MPLS-TP is to succeed in a transport role it will
>> essential
>> > >>>>> that it can provide a transparent client/server relationship
>> > >>>>> between different instances of MPLS-TP layer networks
>> > >>>>>         
>> > >> owned by the
>> > >>   
>> > >>>>> same or different parties, ie MPLS-TPoverMPLS-TP.
>> One way this
>> > >>>>> could be achieved is by the use of special label for
>> > >>>>>         
>> > >> this purpose
>> > >>   
>> > >>>>> only.  However, if we want a more general client/server
>> > >>>>>         
>> > >> solution
>> > >>   
>> > >>>>> (which I believe is the case) then we should consider how to
>> > >>>>> implement a generic adaptation function that provides a
>> > >>>>>         
>> > >> client PID
>> > >>   
>> > >>>>> capability.
>> > >>>>>
>> > >>>>> Aside=> Current co-cs generation transport networks
>> > >>>>>         
>> > >> (based on PDH,
>> > >>   
>> > >>>>> SDH and OTN) use GFP as the common/generic adaptation
>> > >>>>>         
>> > >> function for
>> > >>   
>> > >>>>> their clients.  GFP has a PID function (in the UPI
>> field) that
>> > >>>>> already identifies important SAN clients, and it also
>> > >>>>>         
>> > >> has values
>> > >>   
>> > >>>>> for Ethernet, IP and MPLS clients.  Since the ease of
>> > >>>>> migration/interworking of current and next generation
>> transport
>> > >>>>> networks is important for network operators, then the
>> > >>>>>         
>> > >> use of GFP
>> > >>   
>> > >>>>> in MPLS-TP should be given serious consideration.
>> > >>>>>
>> > >>>>>
>> > >>>>> 2                 MPLS-TP OAM:
>> > >>>>>
>> > >>>>> MPLS-TP OAM functions must be client layer network
>> agnostic and
>> > >>>>> appear as identical as possible to MPLS-TP traffic
>> units at the
>> > >>>>> MPLS-TP layer network under consideration.  From technical
>> > >>>>> considerations a TTL field is not required in any
>> > >>>>>         
>> > >> co-ps/co-cs mode
>> > >>   
>> > >>>>> layer network (the CP/MP can ensure there are no loops before
>> > >>>>> establishing a LSP) and thus the existing MPLS TTL
>> > >>>>>         
>> > >> field could be
>> > >>   
>> > >>>>> used for other important functions such as an OAM indicate
>> > >>>>> function (this would only require 1 bit, noting that
>> > >>>>>         
>> > >> the TTL field
>> > >>   
>> > >>>>> consumes 25% of a scarce resource in the MPLS-TP header).
>> > >>>>> However, if this is deemed not possible (for whatever
>> > >>>>>         
>> > >> reason, but
>> > >>   
>> > >>>>> which clearly cannot be technical) then some other
>> way must be
>> > >>>>> found to ensure this.
>> > >>>>>
>> > >>>>>
>> > >>>>> 3                 PWs and MPLS-TP:
>> > >>>>>
>> > >>>>> We must be very clear that PWs are a consequence of the
>> > >>>>>         
>> > >> way MPLS
>> > >>   
>> > >>>>> was originally specified;  in particular the different way in
>> > >>>>> which IP and all other clients were handled, and the
>> > >>>>>         
>> > >> consequences
>> > >>   
>> > >>>>> of LDP merging and ECMP load spreading.  For MPLS-TP to
>> > >>>>>         
>> > >> take on a
>> > >>   
>> > >>>>> transport role however, its design must be changed
>> such that it
>> > >>>>> treats all clients equally (ie point
>> > >>>>> 1 above) and merging behaviour is removed.
>> > >>>>>
>> > >>>>> We should also note that when PWs were only a 1-hop
>> > >>>>>         
>> > >> entity in MPLS
>> > >>   
>> > >>>>> they could be considered as an adaptation-like function.
>> > >>>>>  However, when PWs became multi-segment constructs (ie
>> > >>>>> MS-PWs) then they underwent a very significant change
>> > >>>>>         
>> > >> in behaviour
>> > >>   
>> > >>>>> and became a co-ps layer network in their own right
>> above MPLS.
>> > >>>>>
>> > >>>>> Now given MPLS-TP is supposed to be a transport
>> > >>>>>         
>> > >> network, then it
>> > >>   
>> > >>>>> would make no sense whatsoever for it to create a
>> further co-ps
>> > >>>>> mode (PW) layer network above it.  Indeed, this would be
>> > >>>>> completely at odds with the requirement for a generic
>> > >>>>>         
>> > >> transparent
>> > >>   
>> > >>>>> client/server relationship noted in 1 above.
>> > >>>>>
>> > >>>>> From purely technical considerations it is therefore
>> > >>>>>         
>> > >> quite clear
>> > >>   
>> > >>>>> that MPLS-TP has no need to have PWs.  However, they
>> > >>>>>         
>> > >> could be kept
>> > >>   
>> > >>>>> (at least in name) providing they reverted back to
>> > >>>>>         
>> > >> their original
>> > >>   
>> > >>>>> 1-hop adaptation-like functionality and did not
>> > >>>>>         
>> > >> generate a co-ps
>> > >>   
>> > >>>>> layer network above MPLS-TP.
>> > >>>>>
>> > >>>>> regards, Neil
>> > >>>>>
>> > >>>>>
>> > >>>>>         
>> > >>>>>> -----Original Message-----
>> > >>>>>> From: Malcolm Betts [mailto:[email-masked]]
>> > >>>>>> Sent: 12 February 2009 14:13
>> > >>>>>> To: [email-masked]
>> > >>>>>> Cc: [email-masked]; [email-masked];
>> > >>>>>> [email-masked]; [email-masked]
>> > >>>>>> Subject: [T15Q12] FW: Liaison on the cooperation
>> > >>>>>>           
>> > >>> between IETF and
>> > >>>     
>> > >>>>>> ITU-T on MPLS-TP
>> > >>>>>>
>> > >>>>>> All, attached is a liaison statement from the IETF
>> MEAD team.
>> > >>>>>>  The most
>> > >>>>>> critical items are listed below:
>> > >>>>>>
>> > >>>>>> "However, in order to foster communication between the two
>> > >>>>>>           
>> > >>>>> bodies, we
>> > >>>>>         
>> > >>>>>> believe that the following items need to be agreed on and or
>> > >>>>>> communicated from the ITU-T to the IETF:
>> > >>>>>> 1.                 First, we need to understand when we
>> > >>>>>>           
>> > >>>> have received all the
>> > >>>>       
>> > >>>>>> relevant MPLS-TP requirements from ITU-T, if this date is
>> > >>>>>>           
>> > >>>>> pressed to
>> > >>>>>         
>> > >>>>>> far into the future this will have an impact on the
>> > >>>>>>           
>> > >>>> target date for
>> > >>>>       
>> > >>>>>> the MPLS-TP RFCs.
>> > >>>>>> 2.                 Second, we need to have a clear
>> > >>>>>>           
>> > >>>> understanding of which documents
>> > >>>>       
>> > >>>>>> we need to have approved as RFCs for the SG15 meeting in
>> > >>>>>>           
>> > >>>>> October 2009.
>> > >>>>>         
>> > >>>>>> 3.                 Third, we see a need to further define
>> > >>>>>>           
>> > >>>> the process, regarding
>> > >>>>       
>> > >>>>>> ITU-T review of our Internet-Drafts as well as IETF
>> > >>>>>>           
>> > >>>> review of ITU-T
>> > >>>>       
>> > >>>>>> Draft Recommendations before they are published as RFCs
>> > >>>>>>           
>> > >>>> or Approved
>> > >>>>       
>> > >>>>>> Recommendations.
>> > >>>>>> 4.                 Fourth, we see that there is a need to
>> > >>>>>>           
>> > >>>> coordinate between our
>> > >>>>       
>> > >>>>>> two organizations so that T-MPLS related contributions to
>> > >>>>>>           
>> > >>>> the ITU-T
>> > >>>>       
>> > >>>>>> are not accepted into SG or Question meetings.
>> > >>>>>> 5.                 Finally, we need the OAM deployment
>> > >>>>>>           
>> > >>>> scenarios that we were
>> > >>>>       
>> > >>>>>> promised at the SG15 meeting in Geneva."
>> > >>>>>>
>> > >>>>>> The IETF have requested a complete response by March 31st.
>> > >>>>>>
>> > >>>>>> With respect to point 1:  I believe that the ITU has
>> > >>>>>>           
>> > >>>>> identified all of
>> > >>>>>         
>> > >>>>>> the current requirements and we are in the process of
>> > >>>>>>           
>> > >> providing
>> > >>   
>> > >>>>>> clarifications as the IETF drafts are developed.
>> > >>>>>>
>> > >>>>>> To respond to point 2, I request the editors of the
>> > >>>>>>           
>> > >>>> revised MPLS-TP
>> > >>>>       
>> > >>>>>> Recommendations to identify which drafts they plan to make
>> > >>>>>>           
>> > >>>>> normative
>> > >>>>>         
>> > >>>>>> references to.
>> > >>>>>>
>> > >>>>>> With respect to point 5:  I request that those interested
>> > >>>>>>           
>> > >>>>> in the work
>> > >>>>>         
>> > >>>>>> provide input as soon as possible so that we can
>> > >>>>>>           
>> > >>> deliver this as
>> > >>>     
>> > >>>>>> promised.
>> > >>>>>>
>> > >>>>>> For points 3 & 4 I will work with the SG 15 leadership team
>> > >>>>>>           
>> > >>>>> to develop
>> > >>>>>         
>> > >>>>>> a response.
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Malcolm Betts
>> > >>>>>> Co chair Ad Hoc on MPLS-TP
>> > >>>>>> Phone: +1 613 763 7860 (ESN 393)
>> > >>>>>> email: [email-masked]
>> > >>>>>>
>> > >>>>>> -----Original Message-----
>> > >>>>>> From: Loa Andersson [mailto:[email-masked]]
>> > >>>>>> Sent: Friday, February 06, 2009 11:52 AM
>> > >>>>>> To: Yoichi Maeda; Greg Jones; Ghani Abbas; Huub Van
>> > >>>>>>           
>> > >>>>> Helvoort; Betts,
>> > >>>>>         
>> > >>>>>> Malcolm (CAR:X632); Hing-Kam Lam; [email-masked];
>> > >>>>>>           
>> > >>>>> [email-masked]
>> > >>>>>         
>> > >>>>>> Cc: David Ward; Ross Callon; Mark Townsley; Jari Arkko;
>> > >>>>>>           
>> > >>>>> Scott Bradner;
>> > >>>>>         
>> > >>>>>> Russ Housley; Olaf Kolkman; IETF MEAD team
>> > >>>>>> Subject: Liaison on the cooperation between IETF and ITU-T
>> > >>>>>>           
>> > >>>>> on MPLS-TP
>> > >>>>>         
>> > >>>>>> All,
>> > >>>>>>
>> > >>>>>> please find a liaison on the cooperation between IETF and
>> > >>>>>>           
>> > >>>> ITU-T on
>> > >>>>       
>> > >>>>>> MPLS-TP included.
>> > >>>>>>
>> > >>>>>> /Loa
>> > >>>>>> --
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Loa Andersson
>> > >>>>>>
>> > >>>>>> Sr Strategy and Standards Manager
>> > >>>>>> Ericsson ///                          phone:  +46 8 632 77 14
>> > >>>>>>
>> > >>>>>>                                        email:
>> > >>>>>> [email-masked]
>> > >>>>>>                                              
>> > >>>>>> [email-masked]
>> > >>>>>>                                                [email-masked]
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>           
>> > >>>>> _______________________________________________
>> > >>>>> 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
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>>
>> > >>>> --------------------------------------------------------
>> > >>>> ZTE Information Security Notice: The information
>> > >>>>       
>> > >> contained in this
>> > >>   
>> > >>>> mail is solely property of the sender's organization.
>> > >>>> This mail communication is confidential. Recipients named
>> > >>>>       
>> > >> above are
>> > >>   
>> > >>>> obligated to maintain secrecy and are not permitted to
>> > >>>>       
>> > >> disclose the
>> > >>   
>> > >>>> contents of this communication to others.
>> > >>>> This email and any files transmitted with it are
>> > confidential and
>> > >>>> intended solely for the use of the individual or entity
>> > >>>>       
>> > >> to whom they
>> > >>   
>> > >>>> are addressed. If you have received this email in error please
>> > >>>> notify the originator of the message. Any views
>> > expressed in this
>> > >>>> message are those of the individual sender.
>> > >>>> This message has been scanned for viruses and Spam by ZTE
>> > >>>>       
>> > >> Anti-Spam
>> > >>   
>> > >>>> system.
>> > >>>>
>> > >>>>       
>> > >>> _______________________________________________
>> > >>> 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
>> > >>
>> > >> _______________________________________________
>> > >> 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
>> > >>
>> > >>   
>> > > _______________________________________________
>> > > 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
>>
>> _______________________________________________
>> 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: Maarten Vissers <[email-masked]>
Date: Fri, 27 Feb 2009 09:54:20 +0100

Xueqin,

Your understanding is correct.

Regards,
Maarten

-----Original Message-----
From: Xueqin WEI (Shuetsing WEI) [mailto:[email-masked]] 
Sent: vrijdag 27 februari 2009 9:09
To: Maarten Vissers
Cc: MPLS-TP; MPLS-TPSG15
Subject: Re: Re: [mpls-tp] Scope of IETF MPLS-TP developments? [was:
RE:[T15Q12] FW:LiaisononthecooperationbetweenIETFandITU-Ton MPLS-TP]

Maarten:

Is the second figure in you email means PW can be nested?  Just as you
metioned in the second figure "PW lable stack entry head" and "PWE3
encapsulaiton"? I just want to confirm this with you.

My understand is PW lable only apear once as the client to LSP. Only LSP
lable can be nested, not PW label. Am I right?

Sincerely Yours

Subject:Re: [mpls-tp] Scope of IETF MPLS-TP developments? [was: RE:[T15Q12]

>The MS-PW layer is essentially a LSP service/channel layer as 
>illustrated in the figure below, which operates "between the PWE3 
>encapsulation and the PW label stack entry header". I.e. MS-PW is a 
>transport service layer LSP, or stated in an alternative manner "MS-PW =
LSP".
>
>Is the "MPLS-TP layer network" to be used as a the transport service 
>layer network for p2p and p2mp services, as indicated in the bottom 
>part of the figure below?
>
>
>
> 
>Regards
>Maarten
>
>
>agreed between the ITU-T and the IETF is the definition of the MPLS-TP 
>layer network.
>
>If we (in SG 15) decide to advance work on a "top to bottom" definition 
>of a packet transport network then that definition must be based on a 
>stack of independent layer networks.  This approach allows us to 
>minimize complexity (i.e. minimizes the interactions between layer 
>networks) and therefore allows the network to continue to evolve.  This 
>evolution involves the addition of new (transport) technologies to 
>existing networks.  This includes the network support infrastructure (e.g.
OSS).  Once a "new"
>With that in mind I am advocating the definition of a set of 
>(client/server) independent layer networks (e.g. MPLS-TP).  This is the 
>approach that has been taken for a number of years by SG 15 when 
>defining the transport network.  The application of a common approach 
>to the definition of these layer networks (based on G.805 and G.800) 
>allows us to recognize the aspects that are common from the perspective 
>of network operation.  It is this approach that has allowed the TMForum 
>to develop and deploy the MTNM interface (for SDH, ATM, OTN, Ethernet,
ASON....) over the last 10 years.
>Good engineering practice indicates that we should, where appropriate, 
>reuse the implementation of some functions in multiple technologies.  
>This reuse enable simplicity without incurring dependency.
>
>In the last study period work on a "packet transport network" was 
>initiated in Q12 but was not advanced due to lack of interest and 
>contributions. If we intend to revive this activity we should first 
>agree on the network scenarios and business boundaries that we are 
>attempting to address so that we can understand the scope of the work.
>
>Malcolm Betts
>Subject: Scope of IETF MPLS-TP developments? [was: RE: [mpls-tp] 
>I assume that you refer to the MPLS-TP LSP layer, which provides a 
>transport path layer role in the packet transport network.
>
>transport path, section, phy media) the transport path layer is the 
>least important layer (just a scalability measure). The reason is that 
>the p2p (and optional p2mp) transport entities in this layer are domain
bound, i.e.
>exist between nodes at the edge of an aggregation domain. Those 
>p2p/p2mp transport path layer transport entities can be supported by 
>every packet technology; e.g. Ethernet VLAN, MPLS-TP LSP and PBB-TE 
>TESI; main difference is their label sizes: 12-bit, 20-bit, 108-bit. 
>And the number of transport path layer trnasport entities is much 
>smaller then the number of transport service layer transport entities.
>
>The most important layer is the transport service layer. The p2p, p2mp, 
>rmp, mp2mp transport entities in this layer carry the customer 
>services, may cross through different admin domains, may be protected 
>and provide information to verify the SLAs.
>
>aspects of the transport service layer, section layer and physical 
>media layer.
>
>To prevent that we continue to have discussions related to the 
>envisaged scope of the MPLS-TP work in IETF, I would like to understand 
>if the scope of this work is limited to either the definition of a 
>MPLS-TP LSP layer that will be used as a transport path layer in the 
>emerging packet transport network, or the definition of a packet 
>transport network solution including a MPLS-TP LSP layer as transport
service layer.
>> necessary to burden MPLS-TP with the task of defining its client 
>> layer network(s).
>>
>>
>> Malcolm Betts
>> Nortel Networks
>> We do need to define the architecture of the MPLS-TP transport 
>> service layer.
>>