Subject: [mpls-tp] Working Group last call on draft-ietf-mpls-tp-framework-10

From: Loa Andersson <[email-masked]>
Date: Thu, 04 Feb 2010 16:04:08 +0100

Working Group,

this is to start a two week MPLS working group last call on

draft-ietf-mpls-tp-framework-10

This working group last call ends eob January 19th.

Please send comments to the [email-masked] mailing list.

We would like request that special attention is focused on
section 3.5 - 3.15 since it is our impression that these
sections has been less well reviewed than the rest of the
document, this is not to say that the earlier sections does
not need review.

Loa and George

MPLS WG co-chairs

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Loa Andersson <[email-masked]>
Date: Thu, 04 Feb 2010 18:08:53 +0100

All,

as has been pointed out be several observant working
group members, I meant February 19th as the day when
the wg last call ends.

/Loa

--

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 5 Feb 2010 15:59:39 -0800

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

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Feb 2010 21:49:37 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Rahul Aggarwal
Sent: zaterdag 6 februari 2010 1:00
To: Loa Andersson
Cc: [email-masked]; [email-masked]
Subject: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10

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

<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

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

          packets. To support this case the MPLS-TP server layer network
uses

<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

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

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

PW1-segment1 and PW1-segment2 are segments of the same MS-PW, while
PW2-segment1 and PW2-segment2 are segments of another MS-PW

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

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

rahul

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

---

From: <[email-masked]>
Date: Tue, 9 Feb 2010 21:25:26 -0000

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 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 09 February 2010 20:50
> To: 'Rahul Aggarwal'; 'Loa Andersson'
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rahul Aggarwal
> <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"
> 
> <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.
> - 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
> 
> <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> 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
> 
> Given draft-fbb is not a WG draft, I don't think we should 
> add a reference to it here.
> 
> 
> <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.
> 
>       Edge 1   |                                              
> |  Edge 2
> <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.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Note: H(ighlighted) indicates the part of the protocol stack 
> we are considering in this document.
> 
> 
> 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 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."
>

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Feb 2010 08:58:52 -0500

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

---

From: <[email-masked]>
Date: Wed, 10 Feb 2010 14:14:01 -0000

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	

> From: Lou Berger [mailto:[email-masked]] 
> Sent: 10 February 2010 13:59
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> (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
> 
> > 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 
> > 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).
> > 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 
> transport entity 
> >> within either the transport service layer network, or the 
> transport 
> >> path layer network, or the section layer network.
> >>
> >> Regards,
> >> Maarten
> >>
> >> Here are my LC comments on 
> draft-ietf-mpls-tp-framework-10, prefixed 
> >> by
> >> <RA>:
> >>
> >>
> >> 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"
> >>
> >> 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
> >>
> provided by a 
> >> service interface. The following are the service 
> interfaces supported 
> >> by
> >> MPLS-TP:
> >>
> >> received over the service interface. This PW in turn is a 
> client of 
> >> the MPLS-TP server layer.
> support this 
> >> case a MPLS-TP PE participates in the service interface signaling."
> >>
> >> 3. 1.4.  Applicability
> >>
> >>    therefore applicable in any packet transport network 
> context.  It 
> >> is
> >>    1.  MPLS-TP provided by a network that only supports 
> MPLS-TP LSPs 
> >> and
> >>        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
> >>        profile and those that do not, exist between the 
> PEs), acting 
> >> as
> >>        profile.  For MPLS traffic, the MPLS-TP server 
> layer network 
> >> uses
> making an 
> >> 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 
> >>    "3.  MPLS-TP as a server layer for client layer traffic 
> of IP or 
> >> MPLS
> >>    o  The control and management planes of any client 
> network layer 
> >> that
> >>       addressing and other information (e.g. topology) to 
> be hidden 
> >> from
> >>    These characteristics imply that a packet transport 
> service does 
> >> not
> value and is 
> >> Given draft-fbb is not a WG draft, I don't think we should add a 
> >> reference to it here.
> >>
> >>
> architecture 
> >>    the MPLS-TP architecture.  The use of MS-PWs may be 
> motivated by, 
> >> for
> >> the "service PEs" are. Or whether PE1 is actually both the 
> MPLS-TP PE 
> >> and the service PE.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>        |              |          ^                   |     
>         |
> >>        |           TE LSP        |                TE LSP   
>         |
> >>        |                      P-router                     
>         |
> >>        |                                                   
>         |
> >>    The corresponding MPLS-TP protocol stacks including PWs 
> are shown 
> >> in
> >> <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.
> >>
> >>
> >>    in [RFC3031] and [RFC3032].  The network layer 
> protocols supported 
> >> by
> >>    encoded packets with an MPLS label stack (the client 
> MPLS stack), 
> >> may
> >>         Edge 1   |             TE           TE             
> >> 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."
> >>
> >>    Channel (Section 3.6).  Forwarding based on IP 
> addresses for user 
> >> or
> >>    alert mechanisms that enable an MPLS LSR to identify 
> and process 
> >> MPLS
> >>    that enable an MPLS LSR to identify and process MPLS 
> OAM packets 
> >> when
> >>    These mechanisms are the default mechanisms for 
> identifying MPLS 
> >> OAM

---

From: Lou Berger <[email-masked]>
Date: Wed, 10 Feb 2010 09:38:35 -0500

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.

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

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

---

From: <[email-masked]>
Date: Wed, 10 Feb 2010 15:21:25 -0000

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

> Sent: 10 February 2010 14:39
> 	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.
> 
> 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.)
> 
> > sublayering and (self) layering is almost unforgivable IMO.  This 
> > should have been a top priority requirement of this work.
> > 
> > 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
> > Stewart's original ID on this client/server issue)...less to 
> > configure, less to go wrong, less cost.
> > 
> 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	
> > 
> >> (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
> >>
> >>>>    3.  MPLS-TP as a server layer for client layer 
> traffic of IP or 
> >>>> MPLS
> >>>>        PW switching [RFC5659] or LSP stitching [RFC5150] 
> at the PE 
> >>>> that
> >>>>    One objective of MPLS-TP is to enable MPLS networks 
> to provide 
> >>>> packet
> >>>>       guaranteed not to fall below the agreed level 
> regardless of 
> >>>> other
> >>>>       client activity.
> >>>>
> >>>>    provide a packet transport service, and their use is 
> consistent 
> >>>> with
> >>>>
> >>>>
> >>>>
> >>>>             |          |      transport service       |  
> >>>>             |          |                              |  
> >>>>             |          V    V                    V    V  
> >>>>             |  |                      |                  
> >>>>          | V     V                        V    V         
>  V    V |
> >>>>    (IPLS), pseudowires must be used to carry the client 
> service.  
> >>>> VPWS,
> >>>>    document uses the term Network Layer in the same 
> sense as it is 
> >>>> used
> >>>>    across the MPLS-TP network to the corresponding PE 
> node on the 
> >>>> right,
> >>>>    encoding defined for that access link type.  It 
> should be noted 
> >>>> that
> >>>>               |          |                            |  
> >>>>               |          V    V                  V    V  
> >>>>               |  |       Edge    |     |     |   Edge    
> >>>>    necessary to discriminate between user data payloads 
> and other 
> >>>> types
> >>>>    MPLS-TP must be able to operate in environments where 
> IP is not 
> >>>> used

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 10 Feb 2010 23:45:12 +0100

Neil,

As I have been describing on this mailinglist some time ago, it is
technically possible to use a reserved label to mark MEG levels. This would
allow us to identify layer boundaries from sublayer boundaries. There was no
support for it... This implies that the data plane packet format will not be
descriptive. It seems that the operator and vendor communities don't need a
descriptive packet format. Let's accept that verdict and focus our effort on
the remaining open issues; e.g. on more explicit descriptions of the
functionality in the transport service layer, the transport path layer and
the section layer. 

Interoperability in an MPLS-TP network will only be simple when we specify
unambiguously an MPLS-TP NNI format (i.e. a MPLS-TP Transport Module (MTM-n)
network node interface specification), in analogy to the STM-N and OTM-n
network node interface specifications in G.707 and G.709.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: dinsdag 9 februari 2010 22:25
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] LC comments on draft-ietf-mpls-tp-framework-10

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 

> 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 
> 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"
> 
> described in section 3.4. Furhter it is needed to clarify what is the 
> received over the service interface. This PW in turn is a client of 
> - Or the service interface may be a MPLS LSP or a PW. To support this 
> signaling" where the service interface provided by MPLS-TP is a MPLS 
> text seems to imply and in that case the MPLS-TP PE would participate 
> the "service PEs" are. Or whether PE1 is actually both the MPLS-TP PE 
> and the service PE.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> <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 
> identifying MPLS OAM