Subject: [mpls-tp] last call comments on draft-ietf-mpls-tp-framework-11

From: Curtis Villamizar <[email-masked]>
Date: Fri, 09 Apr 2010 01:33:00 -0400

This document is quite clear IMHO.  There are a few things I would
like to see changed.  At least this time I didn't wait untial a day or
two before last call ended.

The first is the addition of some text that may stir a bit of debate.
It is an important point.  Packet networks have been very successful
for a reason and MPLS-TP can make MPLS more transport like but in
practice it can't remove the characteristics of today's packet
networks that make them so much more cost effective.  Packet networks
could at any time become hopelessly congested because they aggregate
traffic feeds whose maximum load is far in excess of the capacity in
the network core but they work quite well despite that lack of a hard
guarentee that traffic will be delivered.  Of course there is a
guarentee for the small minority of high priority traffic that needs
it and wants to pay extra for it.  The extreme predictability of
transport networks are also their failing and the paragraph simple
acknowledges that a tradeoff exists.  If we can spend the better part
of a page of the intro praising the predictability of transport
networks, we can also mention the tradeoff.

Second is a rearranged sentence along the lines of extract info first
then toss encaps containing that info rather than other way around.

There are two places where I changed PSC to RSC.  Hopefully we settled
on that.

In one place mesh topologies was missed, in another it was included.

I added this to recovery trigger since NE does this today.  For
example, SONET faults are passed up to MPLS over POS for a decade now.

+   o  May use information from a lower layer to detect network faults
+      in cases where a lower layer provides such information local to
+      a network element.

There are some minor wording changes.

Curtis

--- draft-ietf-mpls-tp-framework-11.txt	Fri Apr  2 19:28:00 2010
+++ draft-ietf-mpls-tp-framework-11.txt.modified	Thu Apr  8 19:36:35 2010
@@ -212,16 +212,22 @@
 
    1.  To enable MPLS to be deployed in a transport network and operated
        in a similar manner to existing transport technologies.
 
    2.  To enable MPLS to support packet transport services with a
        similar degree of predictability to that found in existing
        transport networks.
 
+   A tradeoff exists between predictability and cost effectiveness.
+   This tradeoff is discussed in a somewhat different context in
+   [RFC1633].  The cost effectiveness of guarenteed behaviour vs that
+   of predictive behaviour is well established.  MPLS-TP service with
+   very high predictability can be expected to coexist with and/or
+   carry services which trade predictability for cost effectiveness.

 Bocci, et al.            Expires October 4, 2010                [Page 4]
 
 Internet-Draft      MPLS Transport Profile Framework          April 2010

@@ -1033,18 +1039,18 @@
        added, if necessary, and the packet is transmitted over the
        transport path.
 
    In the second case, when a packet associated with a Transport Service
    Instance arrives over a transport path, the following steps occur:
 
    1.  The transport path encapsulation is disposed of.
 
-   2.  The transport service encapsulation is disposed of and the
-       Transport Service Instance and client flow identified.
+   2.  The Transport Service Instance and client flow are identified
+       and the transport service encapsulation is disposed of.
 
    3.  At this point, UNI processing begins.  A data-link encapsulation
        is associated with the packet for delivery to the CE based on the
        client flow.
 
    4.  Link-layer-specific postprocessing, if any, is performed.  Such
        postprocessing is outside the scope of MPLS-TP.
 
@@ -1645,17 +1651,17 @@
 
 3.6.  Generic Associated Channel (G-ACh)
 
    For correct operation of OAM mechanisms it is important that 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
-   Protection State Coordination (PSC) data.  This is achieved by
+   Recovery State Coordination (RSC) data.  This is achieved by
    carrying such packets in either:
 
    o  A generic control channel associated to the LSP, PW or section,
       with no IP encapsulation. e.g. in a similar manner to
       Bidirectional Forwarding Detection for Virtual Circuit
       Connectivity Verification (VCCV-BFD) with PW ACH encapsulation
       [I-D.ietf-pwe3-vccv-bfd]).
 
@@ -1835,17 +1841,17 @@
    Group (MEG) is a collection of one or more MEs that belongs to the
    same transport path and that are maintained and monitored as a group.
    The MEPs that form an ME limit the OAM responsibilities of an OAM
    flow to within the domain of a transport path or segment, in the
    specific layer network that is being monitored and managed.
 
    A MEG may also include a set of Maintenance Entity Group Intermediate
    Points (MIPs).  MEPs are capable of sourcing and sinking OAM flows,
-   while MIPs can both react to OAM flows received from within a MEG.
+   while MIPs primarily react to OAM flows received from within a MEG.

 Bocci, et al.            Expires October 4, 2010               [Page 33]
 
 Internet-Draft      MPLS Transport Profile Framework          April 2010

@@ -1928,17 +1934,17 @@
 
    b.  D has some other unspecified means of directing traffic back to
        U.
 
    The first option is referred to as an "in-band" return path, the
    second as an "out-of-band" return path.
 
    There are various possibilities for "out-of-band" return paths.  Such
-   a path may, for example, be based on ordinary IP routing.  In this
+   a path may, for example, may be based on ordinary IP routing.  In this
    case packets would be forwarded as usual to a destination IP address
    associated with U. In an MPLS-TP network that is also an IP/MPLS
    network, such a forwarding path may traverse the same physical links
    or logical transport paths used by MPLS-TP.  An out-of-band return
    path may also be indirect, via a distinct Data Communication Network
    (DCN) (provided, for example, by the method specified in [RFC5718]);
    or it may be via one or more other MPLS-TP LSPs.
 
@@ -2190,18 +2196,19 @@
    as part of the MPLS/PW paradigms, MPLS provides methods for local
    repair using back-up LSP tunnels ([RFC4090]), while pseudowire
    redundancy [I-D.ietf-pwe3-redundancy] supports scenarios where the
    protection for the PW cannot be fully provided by the underlying LSP
    (i.e. where the backup PW terminates on a different target PE node
    than the working PW in dual homing scenarios, or where protection of
    the S-PE is required).  Additionally, GMPLS provides a well known set
    of control plane driven protection and restoration mechanisms
-   [RFC4872].  MPLS-TP provides additional protection mechanisms that
-   are optimised for both linear topologies and ring topologies, and
+   [RFC4872].  MPLS-TP may provide additional protection mechanisms that
+   are optimised for linear topologies, ring topologies, or mesh
+   topologies, and
    that operate in the absence of a dynamic control plane.  These are
    specified in [I-D.ietf-mpls-tp-survive-fwk].
 
    Different protection schemes apply to different deployment topologies
    and operational considerations.  Such protection schemes may provide
    different levels of resiliency, for example:
 
    o  Two concurrent traffic paths (1+1).
@@ -2210,26 +2217,30 @@
       paths (1:1).
 
    o  one active path and a standby path the resources of which are
       shared by one or more other active paths (shared protection).
 
    The applicability of any given scheme to meet specific requirements
    is outside the scope of this document.
 
-   The characteristics of MPLS-TP resiliency mechanisms are as follows:
+   The characteristics of MPLS-TP recovery mechanisms are as follows:
 
    o  Optimised for linear, ring or meshed topologies.
 
    o  Use OAM mechanisms to detect and localise network faults or
       service degenerations.
 
+   o  May use information from a lower layer to detect network faults
+      in cases where a lower layer provides such information local to
+      a network element.
+
    o  Include protection mechanisms to coordinate and trigger protection
       switching actions in the absence of a dynamic control plane.  This
-      is known as a Protection State Coordination (PSC) mechanism.
+      is known as a Recovery State Coordination (RSC) mechanism.
 
    o  MPLS-TP recovery schemes are applicable to all levels in the
       MPLS-TP domain (i.e. section, LSP and PW), providing segment and
       end-to-end recovery.
 
    o  MPLS-TP recovery mechanisms support the coordination of protection
       switching at multiple levels to prevent race conditions occurring
       between a client and its server layer.