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

[<[e-mail]>]

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 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...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.

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
> > 
> > 
> > 
>