[Pals] Shepherds review of draft-ietf-pals-endpoint-fast-protection-02

[Stewart Bryant <[e-mail]>]

Hi All,

Sorry this has taken a long time, but I took over as shepherd a few 
weeks ago and have done the customary review of this draft.

There are no fundamental issues with the text, but there are a lot of 
must-fix issues that we need to address before we can take this forward.

Please see below for details.

Regards

- Stewart

Firstly I ran id-nits and got a lot of output.I am not sure what is 
going on with the references because I-D nits
is flagging a lot of them up. I think that it is because it cannot 
findthem in square brackets in the text. Annoying as it is we need to 
fix them rather than having lots of people work through the nits list.


   == Unused Reference: 'RFC3985' is defined on line 1280, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC5659' is defined on line 1285, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC5036' is defined on line 1301, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC2205' is defined on line 1310, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC3209' is defined on line 1315, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC3031' is defined on line 1345, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC2328' is defined on line 1350, but no explicit
      reference was found in the text

   == Unused Reference: 'RFC5920' is defined on line 1375, but no explicit
      reference was found in the text

These definately need to be fixed if we can.

   ** Downref: Normative reference to an Informational RFC: RFC 3985

RFC3985 can be safely moved to info.

   ** Downref: Normative reference to an Informational RFC: RFC 5659
RFC5659 can be safely moved to info.

   ** Downref: Normative reference to an Informational RFC: RFC 5714
RFC5714 can be safely moved to info.


      Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--).

      Run idnits with the --verbose option for more detailed information 
about
      the items above
-----------------


1.  Introduction



    In order to protect the layer-2 service against network failures, it
SB> PWs can carry other than L2, so it think this should be "the PW service"

---------------

   The bypass path has the property that it can
    guide traffic around the failure, while remaining unaffected by the
    topology changes resulting from the failure.  When the failure
    occurs, the router can invoke the bypass path to achieve fast
SB> which router is "the router"
    restoration for the service.

    Today, fast protection against ingress AC failure and ingress (T-)PE
    failure can be achievable by using a multi-homed CE and redundant
  SB> nit s/achievable/achieved/

    ACs, such as multi-chassis link aggregation group (MC-LAG).  Fast
    protection against failure of intermediate router of transport tunnel
SB> nit should be "against the failure of an intermediate"

    can be achievable through RSVP fast-reroute [RFC4090] or IP/LDP fast-
SB> s/achievable/achieved/

    reroute [RFC5714, RFC5286].  However, there is a lack of equivalent
SB> "of an equivalent"

    mechanism against egress AC failure, egress (T-)PE failure, and S-PE
SB> Maybe you should say:
"However, there is no equivalent mechanism that can be used against
an egress AC failure, an egress (T-)PE failure, or an S-PE failure."

    failure.  For these failures, service restoration has to rely on
    global repair or control plane repair.  Global repair normally
    involves ingress CE or ingress (T-)PE switching traffic to another
SB> "involves the ingress CE or the ingress"

SB> You cannot say "another fully function path" since the first one
SB< failed and thus was not functioning.
SB> I would say "to an alternative path"
    fully functional path, based on remote failure detection via PW
    status notification, end-to-end OAM, etc.

    The mechanism is applicable to LDP signaled PWs.  It is relevant to
    networks with redundant PWs and multi-homed CEs.  It is designed on
    the basis of MPLS upstream label assignment and context-specific
    label switching [RFC5331].  Fast protection refers to its ability to
    restore traffic in the order of tens of milliseconds. Compared with
    global repair and control plane repair, this mechanism can provide
    faster service restoration.  However, it is intended to complement
    those mechanisms, rather than replacing them in any fashion.

SB> d/in any fashion/


============


3.1.  Single-Segment PW

                   |<-------------- PW1 --------------->|

               - PE1 -------------- P1 ---------------- PE2 -
              / \
/                                                \
CE1                                                  CE2
\                                                /
              \ /
               - PE3 -------------- P2 ---------------- PE4 -

                   |<-------------- PW2 --------------->|

                                  Figure 1


    In Figure 1, the IP/MPLS network consists of PE and P routers.  It
    provides an emulation of a layer-2 service between CE1 and CE2.  Each
SB> It may or may not be L2. Why not say "it provides a PW service between
CE1 and CE2?

==============


    Note that an egress endpoint failure of the traffic of a given
    direction may be detected by the egress CE as an ingress endpoint
    failure for the traffic of the reverse direction, except when the
    failure is on a link of the primary egress PE within the PSN, or when
    the traffic of the reverse direction takes a different active path.

SB> The text above needs clarification - it is not immediately obvious
SB> what you mean.

    If the CE can detect the failure, it may protect the traffic of the
    reverse direction by switching it to the backup path. However, this
    is categorized as ingress endpoint failure protection, and hence is
    not handled by this mechanism.

SB> This is presumably "the mechanism described in this document"

    Figure 2 shows another possible scenario, where CE1 is single-homed
    to PE1, while CE2 remains multi-homed to PE2 and PE4. From the
    perspective of egress endpoint protection for the traffic going from
    CE1 to CE2 over PW1, this scenario is not much different than
    Figure 1.

SB> Do you mean "not much different", in which case you need to explain
SB> the difference, or (as I suspect is the case) do you mean is the same?

================



4.1.  Applicability

    The mechanism is applicable to LDP signaled PWs in an environment
    where an egress CE is multi-homed to a primary PE and a backup PE and
    there exists a backup PW, as described in Section 3. The procedure
    for S-PE node protection is applicable when there exists a backup
    S-PE on the backup PW.

    The mechanism assumes IP/MPLS transport tunnels.  In a network where
    transport tunnels may provide ECMP to primary PEs, care should be
    taken to prevent misordered packet delivery during local repair.
    Imagine a scenario where the transport tunnel of a PW traverses a
    router with ECMP to a primary PE, and the ECMP include a direct link
    to the primary PE.  Normally the router will attempt to forward PW
    packets in a load balance fashion over the ECMP, including this link.
    In this document, when the link fails, the router will treat the
    event as an egress PE failure, and reroute the portion of traffic on
    the link towards a backup PE.  Meanwhile, the rest of the traffic
    will remain on the other ECMP branches to the primary PE.  This will
    create a situation where the egress CE receives traffic from both the
    primary PE and the backup PE, which is undesirable if the PW or flows
    within the PW are sensitive to packet misordering. Therefore, the
    mechanism assumes that Control Word (CW) SHOULD be used for PWs and
    flow labels [RFC6391] SHOULD be used for flows within a PW, whenever
    applicable.

SB> Unless you are saying use the sequence number in the PW (which
SB> is hardly deployed at all) some form of misordering is inevitable,
SB> since the path/queue lengths in the old and the new path (in both
SB> repair and restore) will be different. The mechanisms that you
SB> cite prevent misorder during normal operation, but not during
SB> a transient.

==============


4.2.  Local Repair and Protector

    The fast protection ability of the mechanism comes from local repair
    performed by routers upstream adjacent to failures. Each of these
    routers is referred to as a "point of local repair" (PLR).  A PLR
    MUST be able to detect a failure by using a rapid mechanism, such as
    physical layer failure detection, Bidirectional Failure Detection
    (BFD) [RFC5880], etc.  In anticipation of the failure, the PLR MUST
    also pre-establish a bypass tunnel to a "protector", and pre-install
    a bypass route in the data plane.  The bypass tunnel MUST have the
SB> I know what you mean, but unfortunately unanticipated SRLGs
SB> are a problem. I think you mean "to be sure protection will work
SB> ...." However a word about unexpected SRLG is probably warranted.








4.3.  Context Identifier

    A protector may protect multiple primary PEs.  The protector MUST
    maintain a separate label space for each primary PE. Likewise, the
    PWs terminated on a primary PE may be protected by multiple
    protectors, each for a subset of the PWs.  In any case, a given PW
    MUST be associated with one and only one pair of {primary PE,
    protector}.

    This document introduces the notion of "context identifier" to
    facilitate protection establishment.  A context identifier is an
    IPv4/v6 address assigned to an ordered pair of {primary PE,
    protector}. The address MUST be globally unique, or unique in the
    address space of the network where the primary PE and the protector
    reside.


SB> Maybe we will get to it, but there can of course be many protectors
SB> depending on the available ECMP paths between the x-PEs, and
SB> all of them need to be included in this mechanism and assigned
SB> one of these context addresses.
SB>


SB> Can you get a PLR to PLR loop?


SB> A section that you will need to include, or at least provide text on
SB> is manageability.


================

    o  A context identifier indicates the primary PE's label space on the
       protector.  The protector may protect PWs for multiple primary
       PEs.  For each primary PE, it MUST maintain a separate label space
       to store the PW labels assigned by that primary PE. It associates
       a PW label with a label space via the context identifier of the
       {primary PE, protector}, as below.

       In addition to the normal LDP PW signaling, the primary PE MUST
       have a targeted LDP session with the protector, and advertise PW
       labels to the protector via LDP Label Mapping messages
       (Section 6).  The primary PE MUST attach the context identifier to
       each message.  Upon receiving the message, the protector MUST
       install the advertised PW label in the label space identified by
       the context identifier.

       When a PLR sets up or resolves a bypass tunnel to the protector,
       it MUST use the context identifier rather than a private IP
       address of the protector as destination.  The protector MUST use
       the bypass tunnel, either the MPLS tunnel label or IP tunnel
       destination address, as the pointer to the corresponding label
       space.  The protector MUST forwards PW packets received on the
       bypass tunnel based on label lookup in that label space.

SB> Some label diagrams could be really helpful, and it would be useful
SB> to go carefully through the text in this section and edit it for
SB> readability. I found it quite difficult.

===================



4.4.1.  Co-located Protector

    In this model, the protector is a backup PE that is directly
    connected to the target CE via a backup AC, or it is a backup S-PE on
    a backup PW.  That is, the protector is co-located with the backup
    (S-)PE.  Examples of this model have been shown in Figure 4, Figure 5
    and Figure 6 in Section 4.2.

    In egress AC protection and egress PE node protection, when a
    protector receives traffic from the PLR, it forwards the traffic to
    the CE via the backup AC.  This is shown in Figure 7, where PE2 is
    the PLR for egress AC failure, P3 is the PLR for PE2 failure, and PE4
    (the backup PE) is the protector.

                  |<-------------- PW1 --------------->|

              - PE1 -------------- P1 ------- P3 ----- PE2 ----
             /                               PLR \ PLR     \
            /                                     \ |       \
         CE1                                 bypass\ |bypass  CE2
            \                                       \ |       /
             \                                       \ |      /
              - PE3 -------------- P2 ---------------- PE4 ----
protector

                  |<-------------- PW2 --------------->|

                                  Figure 7

    In S-PE node protection, when a protector receives traffic from the
    PLR, it forwards the traffic over the next segment of the backup PW.
    The T-PE of the backup PW in turn forwards the traffic to the CE via
    a backup AC.  This is shown in Figure 8, where P4 is the PLR for SPE1
    failure, and SPE2 (the backup S-PE) is the protector for SPE1.



SB> I really would like to know what the label stacks look like.


==============




4.4.2.  Centralized Protector

    In this model, the protector is a dedicated P router or PE router
    that serves the role.  In egress AC protection and egress PE node
    protection, the protector may or may not be a backup PE with a direct
    connection to the target CE.  In S-PE node protection, the protector
    may or may not be a backup S-PE on the backup PW.

    In egress AC protection and egress PE node protection, when the
    protector receives traffic from the PLR, if the protector has a
    direct connection (i.e. backup AC) to the CE, it forwards the traffic
    to the CE via the backup AC, which is similar to Figure 7.
    Otherwise, it forwards the traffic to a backup PE, which then
    forwards the traffic to the CE via a backup AC.  This is shown in
    Figure 9, where the protector receives traffic from P3 (the PLR for
    egress PE failure) or PE2 (the PLR for egress AC failure) and
    forwards the traffic to PE4 (the backup PE).  The protector may be
    protecting other PWs and other primary PEs as well, which is not
    shown in this figure for clarity.


SB> The above seems a bit fluffy in terms of who does what to the stack


=================


4.6.  Bypass Tunnel

    A PLR may protect multiple PWs associated with one or multiple pairs
    of {primary PE, protector}. The PLR MUST establish a bypass tunnel to
    each protector for each context identifier associated with that
    protector.  The destination of the bypass tunnel MUST be the context



Yimin Shen, et al.        Expires July 30, 2016                [Page 18]

Internet-Draft     PW Endpoint Fast Failure Protection January 2016


    identifier (Section 4.3.1).  Since the PLR is a transit router of the
    transport tunnel, it SHOULD derive the context identifier from the
    destination of the transport tunnel.

    For examples, in Figure 7 and Figure 9, a bypass tunnel is
    established from PE2 (PLR for egress AC failure) to the protector,
    and another bypass tunnel is established from P3 (PLR for egress node
    failure) to the protector.  In Figure 8 and Figure 10, a bypass
    tunnel is established from P4 (PLR for S-PE failure) to the
    protector.

    In local repair, a PLR reroutes traffic to the protector through a
    bypass tunnel, with PW label intact in the packets. This normally
    involves pushing a label to the label stack, if the bypass tunnel is
    an MPLS tunnel, or pushing an IP header to the packets, if the bypass

SB> There are some assumptions about the IP protection path.
SB> Do we need to consider the IP case at all in practice?

    tunnel is an IP tunnel.  Upon receipt of the packets, the protector
    forwards them based on the PW label.  Specifically, the protector
    uses the bypass tunnel as a context to determine the primary PE's
    label space.  If the bypass tunnel is an MPLS tunnel, the protector
    should have assigned a non-reserved label to the bypass tunnel, and
    hence this label can serve as the context.  If the bypass tunnel is
    an IP tunnel, the context identifier should be the destination
    address of IP header.

    To be useful for local repair, a bypass tunnel MUST have the property
    that it is not affected by any topology changes caused by the
    failure.  It should remain effective during local repair, until the
    traffic is moved to another fully functional path, i.e. either the
    same PW over a fully functional transport tunnel, or another fully
    functional PW.

SB> To avoid repair loops you need to not repair repairs - this
SB> should be explicitly stated.

===============

4.7.1.  Examples of Co-located Protector



    e In Figure 8, SPE2 is a co-located protector that protects PW1
SB> Typo in line above(I think)
    against S-PE failure.  It maintains a label space for SPE1, which is
    identified by the context identifier of {SPE1, SPE2}. It learns
    SEG1's label from SPE1, and installs a forwarding entry in the label
    space.  The nexthop of the forwarding entry indicates a label swap to
    SEG4's label.


==============

9.  Acknowledgements


    Thanks to Nischal Sheth and Bhupesh Kothari for their contribution.
    Thanks to John E Drake, Andrew G Malis, Alexander Vainshtein, Steward
SB>Please s/Steward/Stewart/
    Bryant, and Mach Chen for valuable comments that helped shape this
    document and improve its clarity.

==========================
==========================