Subject: [mpls-tp] Some comments on draft-umansky-mpls-tp-ring-protection-switching-02.txt

From: Stewart Bryant <[email-masked]>
Date: Mon, 22 Feb 2010 13:38:38 +0000

Some comments on

         draft-umansky-mpls-tp-ring-protection-switching-02.txt

Please clarify whether intersecting rings are in or out of scope. You do 
not discuss them so I assume that they are out of scope, but please say 
so in the main text.

I cannot see a mechanism for node/link diagnosis discussed. Does the 
mechanism diagnose, or does the operator have to chose? I the failure 
type is diagnosed, please explain how.

It is very easy in routing and FRR to mistakenly use the use information 
that is not available to a node in describing a solution. A general 
comment on all of the cases that you describe is that you need to make 
sure that you describe the case where the failure is completely isolated 
from the ring ingress or the ring egress. That forces the case to be 
described in such a way that information is deduced only by the messages 
and not by adjacency to the failure, which in turn surfaces more of the 
corner cases.

1.  Introduction

   MPLS shared protection ring can be viewed as equivalent to SDH MS
   shared protection ring architecture [G.841]

SB> Above sentence does not read correctly.

   The protection ring consists of two counter-rotating rings,
SD> The protected ring?
   transmitting in opposite directions relative to each other. Both
   rings carry working and protection traffic.

3.  Ring protection schemes

3.1.  Wrapping

   The Wrapping technique implies that the node detecting a failure
   sends out an APS request to the (opposite to the failure) node
   adjacent to the failure.
SB> Is this the only recipient of the msg?

   The APS request is transmitted over the APS
   communication protocol, as defined in [OAM framework]. When a node
   detects a failure or receives an APS request through APS protocol
   addressed to this node, the traffic of all working LSPs/tunnels
   transmitted towards the failed span is switched to the protection
   LSPs/tunnels in the opposite direction (away from the failure).

SB> Are these protection LSPs preconfigured, or are they constructed
in response to the failure. The text implies preconstruction, but on the 
last call I think that you said that the were dynamically constructed.

   This traffic travels around the ring to the other node (adjacent to the
   failure) where it is switched back onto the working LSPs/tunnels. The
   nodes that performed the protection switching revert back to the
   normal traffic flow when the failure or APS request is cleared.

SB> ... and what happens to the protection LSPs?

   For each normal or working MPLS-TP LSP/tunnel, the protection
   LSP/tunnel MUST be established in the opposite direction though all
   nodes in the ring. Labels assigned for the protection LSPs/tunnels
   MUST be associated with the labels assigned for working LSPs/tunnels
   to allow proper traffic switching between the working and protection
   LSPs/tunnels.

SB> This is a bit confusing because you make no distinction between the
SB> the LSP and the instantiation of the LSP in the FIB. When we spoke
SB> about this last time this turned out to be quite important.

3.1.2  P-t-p LSP example

                            +---+    [P1]     +---+

                            | F |-------------| A | <- LSP 1

                            +---+             +---+

                             /                   \

                        [P2]/                 [W1]\[P6]

                           /                       \

                        +---+                     +---+

                        | E |                     | B |

                        +---+                     +---+

                           \                       /

                        [P3]\                 [W2]/[P5]

                             \                   /

                            +---+    [W3]     +---+

                  LSP 1 <-- | D |-------------| C |

                            +---+    [P4]     +---+

      Figure 1: Labels allocation example for p-t-p LSP protection with

                          wrapping protection switching

   Working and protection labels association:
   [W1]<->[P6]
   [W2]<->[P5]
   [W3]<->[P4]

SB> You need to clarify that the reason that these associations are 
needed is because B and C might need to repair, and hence need to 
understand the association where as F and E don't need to do that.

3.1.2.1  Link failure example

                            +---+    [P1]     +---+

                            | F |-------------| A | <- LSP 1

                            +---+             +---+

                             /                   \

                        [P2]/                 [W1]\[P6]

                           /                       \

                        +---+                     +---+

                        | E |                     | B |

                        +---+                     +---+

                           \                       /

                        [P3]\                     X

                             \                   /

                            +---+    [W3]     +---+

                  LSP 1 <-- | D |-------------| C |

                            +---+    [P4]     +---+

             Figure 2: Wrapping protection switching operation

                     for p-t-p LSP in case of link failure

   When the failure occurs between the nodes B and C, these nodes
   send APS request to each other around the ring.

SB> Are these the only recipient of the APS? If so you need to explain 
the case where node C fails.
SB> Is this a single phase action or is it a co-ordinated action.

   Node B switches the
   traffic of LSP 1 from working label [W1] to the protection label [P6]
   in the opposite direction (CCW). This traffic travels around the ring
   to the node C where it is switched from protection label [P4] to the
   working label [W3] and sent to the node D where it is dropped from
   the ring.

SB> A lot of the corner cases only come out when you have a bigger ring 
and failure no adjacent to an end node.

SB> Will C map P4 to W3 all the time or only when it notices a failure?

   Traffic flow and labels use when the link failure occurs:

   A[W1]->B[P6]->A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D

SB> when A-B fails the path is
   A[P1]->F[P2]->E[P3]->D[P4]->C[P5]......

SB> So you need to talk about how C (which is not adjacent to the 
failure knew to use P5 not W3.

3.1.2.2.  Node failure example

SB> Is this a network configuration mode or a diagnosed mode?

                            +---+    [P1]     +---+

                            | F |-------------| A | <- LSP 1

                            +---+             +---+

                             /                   \

                        [P2]/                     X

                           /                       \

                        +---+                     +---+

                        | E |                     | B |

                        +---+                     +---+

                           \                       /

                        [P3]\                     X

                             \                   /

                            +---+    [W3]     +---+

                  LSP 1 <-- | D |-------------| C |

                            +---+    [P4]     +---+

             Figure 3: Wrapping protection switching operation

                     for p-t-p LSP in case of node failure

   When node B fails or becomes isolated because of two failed links,
   nodes A and C send APS request to each other around the ring.

SB> How do they know this has happened?

   Traffic flow and labels use when the node B failure occurs:

   A[P1]->F[P2]->E[P3]->D[P4]->C[W3]->D

SB> When node C fails this is
   A[W1]->B[P6]->A[P1]->F[P2]->E[P3]->D

SB> D know what to do because it is adjacent to the failure... but if it 
was not adjacent the failure what would it have done?

3.1.3.  P-t-mp LSP example
3.1.3.1  Link failure example
3.1.3.2.  Node failure example

SB> I think that similar considerations apply in each or the above cases.

3.2.  Steering

   The Steering technique implies that the node detecting a failure
   sends an APS request to the node adjacent to the failure (away from
   the failure). The APS request is processed by all intermediate nodes
   in the ring.

SB> It is not clear how this happens with the APS msg that you define 
later. Are you proposing to use router alert to do this? If so have you 
considered that such pkts have no defined forwarding time? Alternatively 
are you proposing to send a multicast APS?

All nodes in the ring MUST analyze which LSPs are
   affected by the failure or APS request. This analysis is based on the
   ring node maps configured at each node in the ring and LSP maps
   provided at each source node (that adds traffic onto the ring) and
   sink node (that drops the traffic from the ring). For each affected
   LSP the source node and the sink node switches the traffic from
   working LSPs/tunnels to the protection LSPs/tunnels and restore
   normal traffic flow when the failure or APS request is cleared.

SB> I think that you say it later, but here would be a good place to not 
that the generation and distribution of the ring maps is out of scope. 
You also need to comment on the verification of the ring maps.

3.2.1  Steering protection scheme applicability

   Steering protection scheme provides for recovery of p-t-p and p-t-mp
   LSPs in case of single or multiple failures in the ring. The
   protection mechanism different for p-t-p and p-t-mp LSPs in terms of
   nodes behavior and data path. Signaled APS protocol messages are the
   same. Steering mechanism introduces less latency comparing to
   wrapping during protection switching in the ring but it requires more
   complex configuration. It also may affect the protection time because
   of more complex operation of switching nodes.

SB> Do you want to comment on the time to initiate the protection 
mechanism in each case. For example will the APS propagation time be the 
same? What about the action time at the nodes?

3.2.2  P-t-p LSP example

Needs text

3.2.2.1.  Link failure example

                            +---+    [P1]     +---+

                            | F |-------------| A | <- LSP 1

                            +---+             +---+

                             /                   \

                        [P2]/                     \

                           /                       \

                        +---+                     +---+

                        | E |                     | B |

                        +---+                     +---+

                           \                       /

                        [P3]\                     X

                             \                   /

                            +---+             +---+

                  LSP 1 <-- | D |-------------| C |

                            +---+             +---+

             Figure 8: Steering protection switching operation

                     for p-t-p LSP in case of link failure

   When the failure occurs between the nodes B and C, these nodes send
   APS request to each other around the ring. Nodes A and D analyze
   these requests and determine that LSP 1 is affected by the failure.

SB> If B send a msg to C, you need to explain why B and C are looking at 
it. Surely B and C actually send a msg to all other nodes in the ring?

3.2.2.2.  Node failure example

   When node B fails or becomes isolated because of two failed links,
   nodes A and C send APS request to each other around the ring. Nodes A
   and D analyze these requests and determine that LSP 1 is affected by
   the failure.

SB> As above.

3.2.3  P-t-mp LSP example

SB> Needs text in the next rev

3.2.3.2.  Node failure example

4.  MRPS characteristics
SB> MPRS not yet defined

4.2.  Operation types

SB> This looks like a requirements section, shouldn't it be in a 
requirements draft?

4.3.1  Bandwidth sharing

SB> This looks like a requirements section, shouldn't it be in a 
requirements draft?

4.3.3  Point-to-point and point-to-multipoint traffic
SB> This looks like a requirements section, shouldn't it be in a 
requirements draft?

5.  APS protocol

SB> Why is this section written in the style of a requirements document 
and not in the style of a protocol definition document?

   The MRPS protection operation MUST be controlled with the help of
   the APS protocol.
SB> What does "with the help of" mean?, and surely you mean "is 
controlled by" rather thna "MUST be controlled by"

   The APS processes in the each of the individual
   nodes that form the ring SHOULD communicate using MPLS-TP Section OAM
   APS PDUs.
SB> You need to explain how this happens on the long path.

   The APS protocol MUST carry the ring status information and APS
   requests, both automatic and externally initiated commands, between
   the ring nodes.

   The maximum number of nodes on the ring supported by the APS
   protocol is 127.

SB> Which is more than can actually be used in a real deployment, since 
a pathalogical failure will use all the TTL

The node ID SHOULD be independent of the order in

SB> Or even MAY be independent?

   which the nodes appear on the ring.

   Each node SHOULD have a ring map containing information about the
SB> Surely MUST?
   sequence of the nodes around the ring.

   A destination node is a node that is adjacent to a node that
   identified a failed span. When a node that is not the destination
   node receives an APS request

SB> How does it get it?

   Note that in the case of a bidirectional failure such as a cable cut,
   two nodes detect the failure and send each other an APS request in
   opposite directions.

SB> It is usually the other case that is more interesting.

   MUST drop its protection switches.

SB> You use the term switches a number of times without really defining 
it. Please can you define the term.

   MRPS mechanism SHOULD support multiple protection switches in the
   ring, resulting the ring being segmented into two or more separate
   segments. This may happen when several APS requests of the same
   priority exist in the ring due to multiple failures or external
   switch commands.

SB> I think that you mean multiple concurrent mgt actions and/or 
failures. However I don't think that you describe these cases and since 
they are likely to have very interesting pathology, I think that you 
need to provide some examples to demonstrate to the reader that the 
protocol operates correctly.

   Proper operation of the MRPS mechanism relies on all nodes having
   knowledge of the state of the ring (nodes and spans) so that nodes do
   not preempt existing APS request unless they have a higher-priority
   APS request.

SB> In that case you really need to talk about how you ensure that all 
nodes have the same information before they take action, or talk about 
behaviour in the desynchronised state and demosntrate that this is benign.

5.1.  Transmission and acceptance of APS requests

   protocol messages SHOULD be 3.3 ms.

SB> .. and not for example 3.142ms? Why does this need to be specified 
to the nearest 300us?

5.2.  APS PDU structure

   Figure 5 depicts the format of an APS packet that is sent on the
   G-ACh. The Channel Type field is set to indicate that the message is
   an APS message. The ACH MUST NOT include the ACH TLV Header
   [RFC 5586] meaning that no ACH TLVs can be included in the message.

SB> You need talk about how the PDU is encapsulated in the LSP, since 
you seem to be suggesting that in in some cases it is delivered end to 
end and in some cases hop by hop.

  Valid destination node ID values are 1-127.

SB> Why not 0 to 127?

5.3.2.  Switching state

SB> I do not think that you have actually defined what switching state 
is in this document.

   The following switches MUST be allowed to coexist:

    - LP with LP

    - FS with FS

    - SF with SF

    - FS with SF

SB> I do not understand what you are describing here. Are you for 
example saying that a number of nodes on the ring can concurrently be in 
this state?

   When multiple MS APS requests over different spans exist at the same
   time, no switch SHOULD be executed and existing switches MUST be
   dropped. The nodes MUST signal, anyway, the MS APS request code.

SB> Again I do not understand this.

    - At the tail end:

    - At the head end:

SB> Have you defined these terms?

8.  Security Considerations

   This document does not by itself raise any particular security
   considerations.

SB> From experience I would suggest that this is unlikely to pass the 
security directorate review. Please can I suggest that the authors 
conduct security review using the pointers described in 
http://www.ietf.org/tao.html#security-considerations

Appendix A:  Ring protection requirements compliance

   Ring protection requirements are specified in the [RFC5654] paragraph
   2.5.6. This section summarizes the coverage of these requirements by
   MRPS mechanism.

SB> This is an analysis against requirements, but is not written in a 
way that makes it suitable for publication. Is the intent to remove this 
in a future version of the document?

   Optimization criteria:

   a.  There is only one APS OAM session per ring.

   b.  Only two network elements, which are adjacent to addressed span
       or node are involved in protection switching event.

SB> Please see my earlier question on the change in next hop needed. 
Also don't you say that every node in the ring needs to look at the APS 
msg under some circumstances?

  e.  MRPS mechanism does not affect control plane.

SB> So how do the ring maps get generated when you are working in a CP 
environment?

   93  Current version of this draft describes protection mechanism
       operating in the single ring domain. Multiple rings interworking
       is for further study.

SB> You need to make this clear in the main text.

   96  Irrelevant for this draft.

SB> Maybe you should hint at what is irrelevant?

   97  MRSP mechanism operates at the MPLS-TP section layer and does
       not depend on number of LSPs passing addressed section/span.

SB> No, but the number of LSP that need to be controlled and installed is.

   98 A.  Configuration of protection LPS is proportional to the number
          of working LSPs. Operation of protection switching is
          independent of number of working/protection path.

SB> Well, I think that you need to be careful here. I consider the 
number of LSPs that need to be reconfigured as part of the solution 
because it influences scaling.

   98 B.  Configuration of protection LPS is proportional to the number
          of nodes in the ring. Operation of protection switching is
          independent of number of nodes.

SB> Is it? Don't some of those APS msgs go hop by hop? Is the config 
soley prop to #nodes, don't you need a  protect LSP per LSP with a 
different label at each node?

   98 C.  Configuration and operation of MRPS is done per ring and is
          independent of number or rings interconnects.

SB> Hm, so we turn it on on one node and the others discover it's on - I 
must have missed that part of the protocol.

   100  Recovery technique of MRPS relies on standard MPLS label
        swapping operation. Protection algorithm relies on well
        established MS-SPRing/BLSR mechanism.

SB> It's not very well established in the IETF. I think that you need to 
say a little more.

- Stewart