Re: [mpls] [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10

[<[e-mail]>]

Just one comment Lou:

We are at a watershed opportunity...just how many co-ps mode
technologies do you think the industry has stomach for (ie can afford)
if we screw-up and waste this one?  But if what you say holds sway, then
I think it a little disingenuous to claim MPLS-TP is a 'transport
network'...it's just another spin of MPLS as-is.

regards, Neil
 

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]] 
> Sent: 10 February 2010 14:39
> To: Harrison,N,Neil,DKQ7 R
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10
> 
> Neil,
> 	See below for in-line response.  Also just to be be 
> clear, as much as I'm in favor of it, at this point I don't 
> see a change in forwarding behavior being agreed to by all 
> the parties.  Although, perhaps I'm wrong.
> 
> On 2/10/2010 9:14 AM, [e-mail] wrote:
> > Thanks Lou,
> > 
> > Just to be really clear here:
> > 
> > -	standards must look to the future...they should not be hampered
> > by poor/wrong arch decisions made in the past
> > 
> 
> MPLS-TP is a bit unusual as it is being defined as a profile 
> of an existing technology, so we don't have a chance for a 
> clean slate design.
>  In particular, the requirement for the TP data plane to be 
> equal to the MPLS data plane means that there is very limited 
> change possible.  (See the first few requirements of RFC 5654.)
> 
> > -	MPLS-TP is supposed to addressing a transport network role.....a
> > transport network does not require the sublayering 
> behaviour of MPLS 
> > (nor PWs, nor TTL...) but not being able to clearly differentiate 
> > sublayering and (self) layering is almost unforgivable IMO.  This 
> > should have been a top priority requirement of this work.
> > 
> > -	the S bit is a non-issue in what I have proposed.  One can have
> > multiple S bits (ie set in the reserved label header plus 
> at true end 
> > of
> > stack) or just the single S bit at the end of the stack.  
> In fact what 
> > I originally proposed was the latter to be in-keeping with the 
> > original MPLS premise of just a single occurrence of the S bit...
> 
> I don't think this premise is correct.  RFC3032 states that 
> the S-bit indicates that a network layer packet immediately 
> follows the LSE, but neither 3032 nor 3031 define what a 
> "network layer" packet can be.  If we look at RFC3209 we see 
> that a "network layer", as indicated by the L3PID, can be 
> anything represented by a Standard Ethertype value which 
> includes MPLS (0x8847 for unicast and 0x8848 for multicast).  
> I think together, this shows that the original definition of 
> MPLS allowed another Label stack to be in the "network layer 
> packet", i.e., to have one label stack (with s=1) follow 
> another label stack with (s=1).
> 
> Now this said, current practice precludes an MPLS stack to be 
> carried after an LSE with S=1.  Oh well.
> 
> > so we could keep
> > sublayering whilst introducing very efficient layering.
> > 
> > -	you can recurse the idea as many times as is necessary.
> > 
> > 
> > The reserved label idea also has many operational advantages, eg:
> > 
> > - 	no need to run a degenerate 1-hop Ethernet/PW network (as per
> > Stewart's original ID on this client/server issue)...less to 
> > configure, less to go wrong, less cost.
> > 
> > -	one can use any technology to connect MPLS client and server
> > layer nodes at each end.
> > 
> > -	the label does not cause a lack of consistent characteristic
> > information in the DP as it has a globally well-known semantic.
> > 
> 
> I think your reserved label approach is valid from a 
> technical approach, but is unlikely to be accepted by most 
> from the perspective of meeting the MPLS compatibility 
> requirements of RFC 5654.
> 
> Lou
> 
> > regards, Neil	
> > 
> >> -----Original Message-----
> >> From: Lou Berger [mailto:[e-mail]]
> >> Sent: 10 February 2010 13:59
> >> To: Harrison,N,Neil,DKQ7 R
> >> Cc: [e-mail]; [e-mail]; [e-mail]; 
> >> [e-mail]; [e-mail]
> >> Subject: Re: [mpls-tp] LC comments on 
> draft-ietf-mpls-tp-framework-10
> >>
> >> Neil,
> >> 	I have to say I agree 100% with your comments.  
> >> Particularly that:
> >>
> >> (a) that there "should" be "an unambiguous way of identifying when 
> >> one sublayer stack of LSPs ends" -- personally I think the 
> S-bit is 
> >> perfect for this purpose, and
> >>
> >> (b) more importantly, that we're limited (as you say,
> >> "clinging") to current MPLS practices.
> >>
> >> It is really (b), the current usage of the MPLS label 
> stack, that has 
> >> driven me to pragmatically accept that (a) is not 
> achievable in the 
> >> current MPLS-TP efforts.
> >>
> >> Lou
> >>
> >> On 2/9/2010 4:25 PM, [e-mail] wrote:
> >>> Maarten,  Please let us not confuse folks with terms like
> >> 'transport
> >>> entity'....we all know that MPLS-TP will only be using proper 
> >>> connections because we want to *deterministically and
> >> simply* manage
> >>> resource.
> >>>
> >>> However, you are absolutely right to pick-up on the point
> >> that an LSP
> >>> is *not necessarily* a layer network.  AFAIK we now have 
> no way of 
> >>> telling from looking at the DP whether a suite of nested LSPs is 
> >>> sublayered or layered...seems one can mix up sublayering 
> and proper 
> >>> client/server layering of LSPs at will.
> >>>
> >>> This is not great architectural design practice IMO but
> >> this seems to
> >>> be happening because we cannot easily satisfy the real transport 
> >>> requirement whilst clinging on to some old MPLS behaviours.
> >>>
> >>> Some while ago I suggested (at least to Stewart) that if
> >> folks want to
> >>> keep sublayering in MPLS-TP, then we should have an
> >> unambiguous way of
> >>> identifying when one sublayer stack of LSPs ends (say a
> >> client layer
> >>> MPLS-TP network belonging to party X) and a different
> >> sublayer stack
> >>> of LSPs begins (say a server layer MPLS-TP network
> >> belonging to party Y).
> >>> I suggested we should allocate a globally well-known
> >> functional label
> >>> from the 0-15 set for this important client/server case.  
> We could 
> >>> also use the same reserved label in MPLS.  Note this is 
> consistent 
> >>> with respecting consistent CI as the label is globally well-known.
> >>>
> >>> I still think this idea should be given serious
> >> consideration due to
> >>> the importance (to operators) of being able to have a quite clear 
> >>> client/server relationship in MPLS-TP between different operating 
> >>> parties.
> >>>
> >>> regards, Neil
> >>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Maarten Vissers
> >>>> Sent: 09 February 2010 20:50
> >>>> To: 'Rahul Aggarwal'; 'Loa Andersson'
> >>>> Cc: [e-mail]; [e-mail]
> >>>> Subject: Re: [mpls-tp] LC comments on
> >> draft-ietf-mpls-tp-framework-10
> >>>>
> >>>> Rahul,
> >>>>
> >>>> The MPLS-TP LSP is not a layer network. The LSP is a
> >> transport entity
> >>>> within either the transport service layer network, or the
> >> transport
> >>>> path layer network, or the section layer network.
> >>>>
> >>>> Regards,
> >>>> Maarten
> >>>>
> >>>> -----Original Message-----
> >>>> From: [e-mail]
> >>>> [mailto:[e-mail]] On Behalf Of Rahul Aggarwal
> >>>> Sent: zaterdag 6 februari 2010 1:00
> >>>> To: Loa Andersson
> >>>> Cc: [e-mail]; [e-mail]
> >>>> Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10
> >>>>
> >>>>
> >>>> Here are my LC comments on
> >> draft-ietf-mpls-tp-framework-10, prefixed
> >>>> by
> >>>> <RA>:
> >>>>
> >>>>
> >>>> 1. 1.3.4.  MPLS-TP Label Switched Path
> >>>>
> >>>>    An MPLS-TP Label Switched Path (MPLS-TP LSP) is an LSP
> >> that uses a
> >>>>    subset of the capabilities of an MPLS LSP in order to meet the
> >>>>    requirements of an MPLS transport network as set out in
> >> [RFC5654].
> >>>>    The characteristics of an MPLS-TP LSP are primarily that it:
> >>>>
> >>>> <RA> I would suggest adding: "A MPLS-TP LSP is the lowest server 
> >>>> layer provided by MPLS-TP. The client layers of a MPLS-TP
> >> LSP maybe
> >>>> IP, MPLS or PWs. The client layers of a MPLS-TP LSP are
> >> described in
> >>>> detail in section 3.4"
> >>>>
> >>>> This is to make the client server relationship in 
> MPLS-TP clearer.
> >>>>
> >>>> 2. 1.3.10.  Additional Definitions and Terminology
> >>>>
> >>>>    Detailed definitions and additional terminology may 
> be found in
> >>>>    [RFC5654].
> >>>>
> >>>> <RA> I would suggest a section on "Service Interface". 
> This is to 
> >>>> clarify the applicability of the use of MPLS-TP LSPs and PWs as 
> >>>> described in section 3.4. Furhter it is needed to clarify
> >> what is the
> >>>> interface exposed by MPLS-TP to the client network.
> >>>>
> >>>> "Service Interface
> >>>>
> >>>> The transport service provided by MPLS-TP is said to be
> >> provided by a
> >>>> service interface. The following are the service
> >> interfaces supported
> >>>> by
> >>>> MPLS-TP:
> >>>>
> >>>> - The service interface may a layer 2 interface that 
> carries only 
> >>>> network layer clients. MPLS-TP LSPs are both necessary and
> >> sufficient
> >>>> to support this service interface as described in section 3.4.3
> >>>>
> >>>> - Or the service interface may be a layer 2 interface 
> that carries 
> >>>> both network layer and non-network layer clients. To 
> support this 
> >>>> service interface, a PW is required to adapt the client traffic 
> >>>> received over the service interface. This PW in turn is a
> >> client of
> >>>> the MPLS-TP server layer.
> >>>> This is described in section 3.4.2.
> >>>>
> >>>> - Or the service interface may be a MPLS LSP or a PW. To
> >> support this
> >>>> case a MPLS-TP PE participates in the service interface 
> signaling."
> >>>>
> >>>> 3. 1.4.  Applicability
> >>>>
> >>>>    MPLS-TP can be used to construct packet transport
> >> networks and is
> >>>>    therefore applicable in any packet transport network
> >> context.  It
> >>>> is
> >>>>    also applicable to subsets of a packet network where
> >> the transport
> >>>>    network operational model is deemed attractive.  The
> >> following are
> >>>>    examples of MPLS-TP applicability models:
> >>>>
> >>>>    1.  MPLS-TP provided by a network that only supports
> >> MPLS-TP LSPs
> >>>> and
> >>>>        PWs (i.e.  Only MPLS-TP LSPs and PWs exist between
> >> the PEs or
> >>>>        LSRs), acting as a server for other layer 1, layer
> >> 2 and layer
> >>>> 3
> >>>>        networks (Figure 1).
> >>>>
> >>>>    2.  MPLS-TP provided by a network that also supports
> >> non-MPLS-TP
> >>>> LSPs
> >>>>        and PWs (i.e. both LSPs and PWs that conform to the
> >> transport
> >>>>        profile and those that do not, exist between the
> >> PEs), acting
> >>>> as
> >>>>        a server for other layer 1, layer 2 and layer 3 networks
> >>>>        (Figure 2).
> >>>>
> >>>>    3.  MPLS-TP as a server layer for client layer 
> traffic of IP or 
> >>>> MPLS
> >>>>        networks which do not use functions of the MPLS transport
> >>>>        profile.  For MPLS traffic, the MPLS-TP server
> >> layer network
> >>>> uses
> >>>>        PW switching [RFC5659] or LSP stitching [RFC5150] 
> at the PE 
> >>>> that
> >>>>        terminates the MPLS-TP server layer (Figure 3).
> >>>>
> >>>>
> >>>> <RA> I think figure 3 and case 3 as written currently are
> >> making an
> >>>> assumption that a MPLS-TP PE participates in the "service
> >> interface
> >>>> signaling" where the service interface provided by MPLS-TP
> >> is a MPLS
> >>>> LSP or a PW. This is a NNI model. Perhaps we need two 
> sub-cases of 
> >>>> case 3.
> >>>> One is a UNI model where the MPLS network just sees a 
> P2P or P2MP 
> >>>> link, which is provided by the MPLS-TP network. In this case 
> >>>> mechanisms of section
> >>>> 3.4.3 are sufficient. The second case is the one which 
> the current 
> >>>> text seems to imply and in that case the MPLS-TP PE would
> >> participate
> >>>> in the MPLS signaling. In this case the MPLS-TP PE may use LSP 
> >>>> hierarchy or LSP stitching to support the MPLS-LSP as a service 
> >>>> interface and may use PW stitching to support PW as a service 
> >>>> interface.
> >>>>
> >>>> <RA> So I would propose to replace example number 3 above with:
> >>>>
> >>>>    "3.  MPLS-TP as a server layer for client layer traffic
> >> of IP or
> >>>> MPLS
> >>>>        networks which do not use functions of the MPLS transport
> >>>>        profile. Here are two examples of applicability
> >> models of this:
> >>>>
> >>>>        a) The client IP or MPLS network is provided a
> >> layer 2 P2P or
> >>>>           P2MP link by the MPLS-TP network. In other words
> >> the service
> >>>>           interface is a layer 2 inteface that carries
> >> only IP or MPLS
> >>>>           packets. To support this case the MPLS-TP server layer 
> >>>> network uses
> >>>>           the mechanisms of section 3.4.3 to carry IP or
> >> MPLS client l
> >>>>           layer traffic over MPLS-TP LSPs"
> >>>>
> >>>>        b) The client IP or MPLS network is provided a LSP
> >> or a PW as a
> >>>>           service interface by the MPLS-TP network. In this case
> >>>>           the MPLS-TP PE would participate in the client MPLS 
> >>>> signaling.
> >>>>           In this case the MPLS-TP PE may use LSP 
> hierarchy or LSP
> >>>>           stitching to support the MPLS-LSP as a service
> >> interface and
> >>>>           may use PW stitching to support PW as a 
> service interface
> >>>>           (Figure 3)"
> >>>>
> >>>> 4. 3.1 Packet Transport Services
> >>>>
> >>>>    One objective of MPLS-TP is to enable MPLS networks 
> to provide 
> >>>> packet
> >>>>    transport services with a similar degree of
> >> predictability to that
> >>>>    found in existing transport networks.  Such packet transport 
> >>>> services
> >>>>    inherit a number of characteristics, defined in [RFC5654]:
> >>>>
> >>>>    o  In an environment where an MPLS-TP layer network is
> >> supporting a
> >>>>       client layer network, and the MPLS-TP layer network
> >> is supported
> >>>>       by a server layer network then operation of the 
> MPLS-TP layer
> >>>>       network must be possible without any dependencies on
> >> either the
> >>>>       server or client layer network.
> >>>>
> >>>>    o  The service provided by the MPLS-TP network to the 
> client is
> >>>>       guaranteed not to fall below the agreed level 
> regardless of 
> >>>> other
> >>>>       client activity.
> >>>>
> >>>>    o  The control and management planes of any client
> >> network layer
> >>>> that
> >>>>       uses the service is isolated from the control and 
> management
> >>>>       planes of the MPLS-TP layer network, where the 
> client network
> >>>>       layer is considered to be the native service of the MPLS-TP
> >>>>       network.
> >>>>
> >>>>    o  Where a client network makes use of an MPLS-TP server that
> >>>>       provides a packet transport service, the level of
> >> co-ordination
> >>>>       required between the client and server layer
> >> networks is minimal
> >>>>       (preferably no co-ordination will be required).
> >>>>
> >>>>    o  The complete set of packets generated by a client
> >>>> MPLS(-TP) layer
> >>>>       network using the packet transport service, which 
> may contain
> >>>>       packets that are not MPLS packets (e.g.  IP or CLNS
> >> packets used
> >>>>       by the control/management plane of the client 
> MPLS(-TP) layer
> >>>>
> >>>>
> >>>>
> >>>> Bocci, et al.            Expires August 8, 2010               
> >>>>  [Page 12]
> >>>>
> >>>> Internet-Draft      MPLS Transport Profile Framework       
> >>>> February 2010
> >>>>
> >>>>
> >>>>       network), are transported by the MPLS-TP server
> >> layer network.
> >>>>
> >>>>    o  The packet transport service enables the MPLS-TP
> >> layer network
> >>>>       addressing and other information (e.g. topology) to
> >> be hidden
> >>>> from
> >>>>       any client layer networks using that service, and 
> vice-versa.
> >>>>
> >>>>    These characteristics imply that a packet transport
> >> service does
> >>>> not
> >>>>    support a connectionless packet-switched forwarding
> >> mode.  However,
> >>>>    this does not preclude it carrying client traffic
> >> associated with a
> >>>>    connectionless service.
> >>>>
> >>>>    Such packet transport services are very similar to
> >> Layer 2 Virtual
> >>>>    Private Networks as defined by the IETF.
> >>>>
> >>>> <RA> The last sentence should be deleted. It doesn't add
> >> value and is
> >>>> in potential conflict with section 3.4.3.
> >>>>
> >>>>
> >>>> 5. 3.3.  Architecture
> >>>>
> >>>>    MPLS-TP comprises the following architectural elements:
> >>>>
> >>>>    o  A standard MPLS data plane [RFC3031] as profiled in
> >>>>       [I-D.fbb-mpls-tp-data-plane].
> >>>>
> >>>> <RA> Standard MPLS data plane also includes RFC 5331 and 
> RFC 5332.
> >>>> Given draft-fbb is not a WG draft, I don't think we should add a 
> >>>> reference to it here.
> >>>>
> >>>>
> >>>> 6. 3.4.2.  Pseudowire Adaptation
> >>>>
> >>>>    The architecture for an MPLS-TP network that provides
> >> PW emulated
> >>>>    services is based on the MPLS [RFC3031] and 
> pseudowire [RFC3985]
> >>>>    architectures.
> >>>>
> >>>> <RA> I think instead of "PW emulated services", the 
> section should 
> >>>> start with the service interface that requires PWs.
> >>>> Something like:
> >>>>
> >>>> "If the MPLS-TP network provides a layer 2 interface, 
> that carries 
> >>>> both network layer and non-network layer traffic, as a service 
> >>>> interface then a PW is required to support the service interface.
> >>>> The PW is a client of the MPLS-TP LSP server layer. The
> >> architecture
> >>>> of a MPLS-TP network that uses such PWs is is based on the MPLS 
> >>>> [RFC3031] and pseudowire [RFC3985] architectures."
> >>>>
> >>>> <RA> The above is to make it very clear the applicability of
> >>>> 3.4.2 as compared to 3.4.3.
> >>>>
> >>>>   Multi-segment pseudowires may optionally be used to
> >>>>    provide a packet transport service, and their use is 
> consistent 
> >>>> with
> >>>>
> >>>>
> >>>>
> >>>> Bocci, et al.            Expires August 8, 2010               
> >>>>  [Page 18]
> >>>>
> >>>> Internet-Draft      MPLS Transport Profile Framework       
> >>>> February 2010
> >>>>
> >>>>
> >>>>    the MPLS-TP architecture.  The use of MS-PWs may be
> >> motivated by,
> >>>> for
> >>>>    example, the requirements specified in [RFC5254].  If 
> MS-PWs are
> >>>>    used, then the MS-PW architecture [RFC5659] also applies.
> >>>>
> >>>>    Figure 6 shows the architecture for an MPLS-TP network using
> >>>> single-
> >>>>    segment PWs.
> >>>>
> >>>>             |<--------------- Emulated Service 
> ----------------->|
> >>>>             |                                            
>         |
> >>>>             |          |<-------- Pseudowire -------->|  
>         |
> >>>>             |          |      encapsulated, packet    |  
>         |
> >>>>             |          |      transport service       |  
>         |
> >>>>             |          |                              |  
>         |
> >>>>             |          |    |<------ LSP ------->|    |  
>         |
> >>>>             |          V    V                    V    V  
>         |
> >>>>             V    AC    +----+      +-----+       +----+  
>    AC   V
> >>>>       +-----+    |     | PE1|=======\   /========| PE2|     | 
> >>>>    +-----+
> >>>>       |     |----------|.......PW1.| \ / 
> >>>> |............|----------|     |
> >>>>       | CE1 |    |     |    |      |  X  |       |    |     | 
> >>>>    | CE2 |
> >>>>       |     |----------|.......PW2.| / \ 
> >>>> |............|----------|     |
> >>>>       +-----+  ^ |     |    |=======/   \========|    |     | 
> >>>> ^  +-----+
> >>>>             ^  |       +----+      +-----+       +----+  
>      |  ^
> >>>>             |  |   Provider Edge 1    ^     Provider 
> Edge 2   |  |
> >>>>             |  |                      |                  
>      |  |
> >>>>      Customer  |                  P Router                    
> >>>> | Customer
> >>>>       Edge 1   |                                              
> >>>> |  Edge 2
> >>>>                |                                              |
> >>>>                |                                              |
> >>>>          Native service                                 
> >> Native service
> >>>>
> >>>>
> >>>>             Figure 6: MPLS-TP Architecture (Single Segment PW)
> >>>>
> >>>>    Figure 7 shows the architecture for an MPLS-TP network
> >> when multi-
> >>>>    segment pseudowires are used.  Note that as in the SS-PW case,
> >>>>    P-routers may also exist.
> >>>>
> >>>> <RA> This figure needs to clarify where the MPLS-TP PEs
> >> are and where
> >>>> the "service PEs" are. Or whether PE1 is actually both the
> >> MPLS-TP PE
> >>>> and the service PE.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Bocci, et al.            Expires August 8, 2010               
> >>>>  [Page 19]
> >>>>
> >>>> Internet-Draft      MPLS Transport Profile Framework       
> >>>> February 2010
> >>>>
> >>>>
> >>>>            |<----------- Pseudowire encapsulated ------------->|
> >>>>            |             packet transport service              |
> >>>>            |                                                   |
> >>>>            |                                                   |
> >>>>            |                                                   |
> >>>>         AC |     |<-------- LSP1 -------->|    
> |<--LSP2-->|    | AC
> >>>>          | V     V                        V    V         
>  V    V |
> >>>>          | +----+              +-----+    +----+         
>  +----+ |
> >>>>    +---+ | |TPE1|===============\   
> >>>> /=====|SPE1|==========|TPE2| | +---+
> >>>>    |   |---|......PW1-Seg1.... | \ / | 
> >>>> ......X...PW1-Seg2......|---|   |
> >>>>    |CE1| | |    |              |  X  |    |    |          |   
> >>>>  | | |CE2|
> >>>>    |   |---|......PW2-Seg1.... | / \ | 
> >>>> ......X...PW2-Seg2......|---|   |
> >>>>    +---+ | |    |===============/   \=====|    |==========|   
> >>>>  | | +---+
> >>>>        ^   +----+     ^        +-----+    +----+     ^    
> >> +----+   ^
> >>>>        |              |          ^                   |     
> >>         |
> >>>>        |           TE LSP        |                TE LSP   
> >>         |
> >>>>        |                      P-router                     
> >>         |
> >>>>        |                                                   
> >>         |
> >>>>        |<-------------------- Emulated Service
> >> ------------------->|
> >>>>
> >>>> PW1-segment1 and PW1-segment2 are segments of the same 
> MS-PW, while
> >>>> PW2-segment1 and PW2-segment2 are segments of another MS-PW
> >>>>
> >>>>
> >>>>              Figure 7: MPLS-TP Architecture (Multi-Segment PW)
> >>>>
> >>>>    The corresponding MPLS-TP protocol stacks including PWs
> >> are shown
> >>>> in
> >>>>    Figure 8.  In this figure the Transport Service Layer
> >> [RFC5654] is
> >>>>    identified by the PW demultiplexer (Demux) label and
> >> the Transport
> >>>>    Path Layer [RFC5654] is identified by the LSP Demux Label.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Bocci, et al.            Expires August 8, 2010               
> >>>>  [Page 20]
> >>>>
> >>>> Internet-Draft      MPLS Transport Profile Framework       
> >>>> February 2010
> >>>>
> >>>>
> >>>>  +-------------------+     /===================\   
> >>>> /===================\
> >>>>  |  Client Layer     |     H     OAM PDU       H   H     OAM 
> >>>> PDU       H
> >>>>  /===================\     H-------------------H   
> >>>> H-------------------H
> >>>>  H     PW Encap      H     H      GACh         H   H      
> >>>> GACh         H
> >>>>  H-------------------H     H-------------------H   
> >>>> H-------------------H
> >>>>  H   PW Demux (S=1)  H     H PW Demux (S=1)    H   H    GAL 
> >>>> (S=1)      H
> >>>>  H-------------------H     H-------------------H   
> >>>> H-------------------H
> >>>>  H     LSP Demux(s)  H     H  LSP Demux(s)     H   H  LSP 
> >>>> Demux(s)     H
> >>>>  \===================/     \===================/   
> >>>> \===================/
> >>>>  |    Server Layer   |     |   Server Layer    |   |   Server 
> >>>> Layer    |
> >>>>  +-------------------+     +-------------------+   
> >>>> +-------------------+
> >>>>
> >>>>      User Traffic                 PW OAM                  LSP OAM
> >>>>
> >>>> Note: H(ighlighted) indicates the part of the protocol
> >> stack we are
> >>>> considering in this document.
> >>>>
> >>>>
> >>>>              Figure 8: MPLS-TP Layer Network using Pseudowires
> >>>>
> >>>>    PWs and their associated labels may be configured or
> >> signaled.  See
> >>>>    Section 3.11 for additional details related to
> >> configured service
> >>>>    types.  See Section 3.9 for additional details related
> >> to signaled
> >>>>    service types.
> >>>>
> >>>> 7. 3.4.2.1.  Pseudowire Based Services
> >>>>
> >>>>    When providing a Virtual Private Wire Service (VPWS) , Virtual
> >>>>    Private Local Area Network Service (VPLS), Virtual Private 
> >>>> Multicast
> >>>>    Service (VPMS) or Internet Protocol Local Area Network Service
> >>>>    (IPLS), pseudowires must be used to carry the client 
> service.  
> >>>> VPWS,
> >>>>    VLPS, and IPLS are described in [RFC4664].  VPMS is 
> described in
> >>>>    [I-D.ietf-l2vpn-vpms-frmwk-requirements].
> >>>>
> >>>> <RA> This section should be deleted. From a MPLS-TP network view 
> >>>> point the service interface, that requires PWs,  is a
> >> point-to-point
> >>>> layer 2 interface that carries both network layer and 
> non-network 
> >>>> layer traffic. This is orthogonal to the service which is being 
> >>>> delivered to the end user. Hence this section doesn't 
> belong here.
> >>>>
> >>>>
> >>>> 8. 3.4.3.  Network Layer Adaptation
> >>>>
> >>>>    MPLS-TP LSPs can be used to transport network layer
> >> clients.  This
> >>>>    document uses the term Network Layer in the same 
> sense as it is 
> >>>> used
> >>>>    in [RFC3031] and [RFC3032].  The network layer
> >> protocols supported
> >>>> by
> >>>>    [RFC3031] and [RFC3032] can be transported between service
> >>>>    interfaces.  Examples are shown in Figure 5 above.  
> Support for
> >>>>    network layer clients follows the MPLS architecture for
> >> support of
> >>>>    network layer protocols as specified in [RFC3031] and 
> [RFC3032].
> >>>>
> >>>>    With network layer adaptation, the MPLS-TP domain
> >> provides either a
> >>>>    uni-directional or bidirectional point-to-point
> >> connection between
> >>>>    two PEs in order to deliver a packet transport service
> >> to attached
> >>>>    customer edge (CE) nodes.  For example, a CE may be an
> >> IP, MPLS or
> >>>>
> >>>>
> >>>>
> >>>> Bocci, et al.            Expires August 8, 2010               
> >>>>  [Page 21]
> >>>>
> >>>> Internet-Draft      MPLS Transport Profile Framework       
> >>>> February 2010
> >>>>
> >>>>
> >>>>    MPLS-TP node.  As shown in Figure 9, there is an
> >> attachment circuit
> >>>>    between the CE node on the left and its corresponding
> >> provider edge
> >>>>    (PE) node which provides the service interface, a
> >> bidirectional LSP
> >>>>    across the MPLS-TP network to the corresponding PE 
> node on the 
> >>>> right,
> >>>>    and an attachment circuit between that PE node and the 
> >>>> corresponding
> >>>>    CE node for this service.
> >>>>
> >>>>    The attachment circuits may be heterogeneous (e.g., any
> >> combination
> >>>>    of SDH, PPP, Frame Relay, etc.) and network layer
> >> protocol payloads
> >>>>    arrive at the service interface encapsulated in the
> >> Layer1/Layer2
> >>>>    encoding defined for that access link type.  It 
> should be noted 
> >>>> that
> >>>>    the set of network layer protocols includes MPLS and 
> hence MPLS
> >>>>    encoded packets with an MPLS label stack (the client
> >> MPLS stack),
> >>>> may
> >>>>    appear at the service interface.
> >>>>
> >>>>               |<------------- Client Network Layer 
> ------------->|
> >>>>               |                                          
>         |
> >>>>               |          |<---- Pkt Xport Service --->|  
>         |
> >>>>               |          |                            |  
>         |
> >>>>               |          |    |<-- PSN Tunnel -->|    |  
>         |
> >>>>               |          V    V                  V    V  
>         |
> >>>>               V     AC   +----+      +---+       +----+  
>   AC    V
> >>>>         +-----+     |    |PE1 |      |   |       |PE2 |    |  
> >>>>    +-----+
> >>>>         |     |     |LSP |    |      |   |       |    |    |  
> >>>>    |     |
> >>>>         | CE1 |----------|    |========X=========|    
> >>>> |----------| CE2 |
> >>>>         |     |  ^  |IP  |    |  ^   |   |   ^   |    |    |  
> >>>> ^  |     |
> >>>>         +-----+  |  |    |    |  |   |   |   |   |    |    |  
> >>>> |  +-----+
> >>>>               ^  |       +----+  |   +---+   |   +----+  
>   |  |  ^
> >>>>               |  |      Provider |     ^     |  Provider 
>      |  |
> >>>>               |  |       Edge    |     |     |   Edge    
>      |  |
> >>>>         Customer |        1      | P-router  |    2           
> >>>> | Customer
> >>>>         Edge 1   |             TE           TE             
> >>    | Edge 2
> >>>>                  |             LSP          LSP               |
> >>>>                  |                                            |
> >>>>            Native service                               
> >> Native service
> >>>>
> >>>>
> >>>>          Figure 9: MPLS-TP Architecture for Network Layer Clients
> >>>>
> >>>> <RA> PE1 and PE2 should be specifically labeled as MPLS-TP PEs.
> >>>>
> >>>>    At the ingress service interface the client packets are
> >> received .
> >>>>    The PE pushes one or more labels onto the client
> >> packets which are
> >>>>    then label switched over the transport network.  
> >>>> Correspondingly the
> >>>>    egress PE pops any labels added by the MPLS-TP networks and 
> >>>> transmits
> >>>>    the packet for delivery to the attached CE via the
> >> egress service
> >>>>    interface.
> >>>>
> >>>> 9. 3.6.  Generic Associated Channel (G-ACh)
> >>>>
> >>>>    For correct operation of the OAM it is important that the OAM 
> >>>> packets
> >>>>    fate-share with the data packets.  In addition in 
> MPLS-TP it is
> >>>>    necessary to discriminate between user data payloads 
> and other 
> >>>> types
> >>>>    of payload.  For example, a packet may be associated with a 
> >>>> Signaling
> >>>>    Communication Channel (SCC), or a channel used for Automatic
> >>>>    Protection Switching (APS) data.  This is achieved by
> >> carrying such
> >>>>    packets on a generic control channel associated to the
> >> LSP, PW or
> >>>>    section.
> >>>>
> >>>> <RA> Suggest replacing the last sentence with:
> >>>>
> >>>> "This is achieved by either carrying such packets in an IP 
> >>>> encapsulation that provides the necessary discrimination, or by 
> >>>> carrying such packets on a generic control channel
> >> associated to the
> >>>> LSP, PW or section. Rest of this section describes the latter 
> >>>> mechanism."
> >>>>
> >>>> <RA> Also please see related comment in section 3.7.
> >>>>
> >>>>
> >>>> 10. 3.7.  Operations, Administration and Maintenance (OAM)
> >>>>
> >>>>    MPLS-TP must be able to operate in environments where 
> IP is not 
> >>>> used
> >>>>    in the forwarding plane.  Therefore, the default
> >> mechanism for OAM
> >>>>    demultiplexing in MPLS-TP LSPs and PWs is the Generic 
> Associated
> >>>>    Channel (Section 3.6).  Forwarding based on IP
> >> addresses for user
> >>>> or
> >>>>    OAM packets is not required for MPLS-TP.
> >>>>
> >>>>    [RFC4379] and BFD for MPLS LSPs [I-D.ietf-bfd-mpls] 
> have defined
> >>>>    alert mechanisms that enable an MPLS LSR to identify
> >> and process
> >>>> MPLS
> >>>>    OAM packets when the OAM packets are encapsulated in an
> >> IP header.
> >>>>    These alert mechanisms are based on TTL expiration
> >> and/or use an IP
> >>>>    destination address in the range 127/8 for IPv4 and
> >> that same range
> >>>>    embedded as IPv4 mapped IPv6 addresses for IPv6 [RFC4379]. 
> >>>>  When the
> >>>>    OAM packets are encapsulated in an IP header, these
> >> mechanisms are
> >>>>    the default mechanisms for MPLS networks in general for
> >> identifying
> >>>>    MPLS OAM packets.  MPLS-TP must be able to operate in an 
> >>>> environments
> >>>>    where IP forwarding is not supported, and thus the
> >> G-ACh/GAL is the
> >>>>    default mechanism to demultiplex OAM packets in MPLS-TP.
> >>>>
> >>>> <RA> The last sentence is in conflict with the following
> >> from section
> >>>> 4.1 of RFC 5586:
> >>>>
> >>>> "RFC 4379 [RFC4379] and BFD-MPLS [BFD-MPLS] define alert 
> mechanisms
> >>>>    that enable an MPLS LSR to identify and process MPLS
> >> OAM packets
> >>>> when
> >>>>    these are encapsulated in an IP header.  These alert
> >> mechanisms are
> >>>>    based, for example, on Time To Live (TTL) expiration
> >> and/or on the
> >>>>    use of an IP destination address in the range of
> >>>> 127.0.0.0/8 or 0:0:
> >>>>    0:0:0:FFFF:127.0.0.0/104 for IPv4 and IPv6, respectively.
> >>>>
> >>>>    These mechanisms are the default mechanisms for
> >> identifying MPLS
> >>>> OAM
> >>>>    packets when encapsulated in an IP header although 
> the mechanism
> >>>>    defined in this document MAY also be used."
> >>>>
> >>>> <RA> Hence the last sentence of the above paragraph must
> >> be removed.
> >>>>
> >>>>
> >>>> rahul
> >>>>
> >>>> _______________________________________________
> >>>> mpls-tp mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>
> >>>> _______________________________________________
> >>>> mpls-tp mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>>
> >>> _______________________________________________
> >>> mpls-tp mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>>
> >>>
> >>>
> >>
> > 
> > 
> > 
>