Subject: [mpls] Comments on draft-ietf-mpls-tp-ring-protection

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Wed, 22 Aug 2012 20:04:49 +0000

I apologize if these are coming in later than you'd like; I saw Loa's IP query and realized I hadn't commented on this draft in a while.

Two quick typographical comments:

i) section 2.1, 'LSP arounf the failed' should be 'LSP around the failed'
ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C-D-E-F, as per the text immediately following.

One comment on link vs node protection.  There are few places, e.g. section 2.4, which say that providing both link and node protection are difficult.  I do not believe this to be true.  I am familiar with two implementations that are easily able to do this today.  The algorithm is simple; if the thing you're protecting ends on the next-hop, use link protection.  Otherwise use node.  I agree that with a statically configured network it becomes the responsibility of the NMS to make sure this is done right, but it's a simple thing to do.

Also, it looks like the draft makes two assumptions, which I've spelled out below.  Can you confirm or deny?

i) 
It looks like your protection mechanisms all assume that when traffic enters the ring, it either goes CW or CCW.  In other words, take your Figure 6.  The protected LSP is A->B->[C]->[D]->E->[F].  This implies that you do not allow mcast traffic to enter at A and branch both right and left.  In other words, the following p2mp is not allowed:

A
 ->[F]->E->[D]
 ->E-[C]

Is that correct?  

ii)
Does the draft assume that I can have a W LSP in two directions?  For a four-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C?  This won't apply in all cases but it may be desirable to load-balance traffic in both directions across the ring.  This has implications on the wrapping protection methods.

I'd also like to very much see a scale analysis of the five protection mechanisms discussed in the draft.  I started work on one but realized I needed to clear up my questions about your assumptions.  I think the p2mp mechanisms may have serious scale challenges, but I want to make sure I get the assumptions right before discussing the scale.  Once I understand the assumptions better, I'll send out my thoughts on scale.

thanks!

eric

---

From: Gregory Mirsky <[email-masked]>
Date: Wed, 22 Aug 2012 17:46:24 -0400

Hi Eric,
putting down my $.02:
I think that applicability of load-balancing techniques in MPSL-TP, including Link Bundle and/or Composite Links, have yet to be clarified.
As for p2mp LSP ring protection, I think that SPME(s) can be used to protect sub-LSP(s). (At least until we finish with application of multi-point BFD for unidirectional p2p and p2mp LSPs in MPLS-TP).

        Regards,
                Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric Osborne (eosborne)
Sent: Wednesday, August 22, 2012 1:05 PM
To: [email-masked]; [email-masked]
Subject: [mpls] Comments on draft-ietf-mpls-tp-ring-protection

i)

A
 ->[F]->E->[D]
 ->E-[C]

Is that correct?

ii)

thanks!

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

---

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 23 Aug 2012 09:11:31 +0300

Eric, hi

Thank you for your comments - see my answers below inline.

On Wed, Aug 22, 2012 at 11:04 PM, Eric Osborne (eosborne) <
[email-masked]> wrote:

> I apologize if these are coming in later than you'd like; I saw Loa's IP
> query and realized I hadn't commented on this draft in a while.
>
yw>> thank you for pointing this out

> ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go
> A-B-C-D-E-F, as per the text immediately following.
>
yw>> This was actually sent to us during the Vancouver meeting, and will be
corrected in the next version.  I just figured that we should first go to
WGLC and address all comments rather than delay the LC by publishing a new
version.

>
>
> One comment on link vs node protection.  There are few places, e.g.
> section 2.4, which say that providing both link and node protection are
> difficult.  I do not believe this to be true.  I am familiar with two
> implementations that are easily able to do this today.  The algorithm is
> simple; if the thing you're protecting ends on the next-hop, use link
> protection.  Otherwise use node.  I agree that with a statically configured
> network it becomes the responsibility of the NMS to make sure this is done
> right, but it's a simple thing to do.
>
yw>> Yes, you are correct and previous versions of the draft actually
included such a solution.  However, there were many comments from different
members that when we use such a scheme that the traffic is no longer using
the same path in both directions and the protection path is
"non-deterministic" which is bothersome to many transport service
providers. We found that trying to address these comments complicated
issues and therefore we suggest that the SP decide a-priori for each
working path whether they want to apply link or node protection.

> It looks like your protection mechanisms all assume that when traffic
> enters the ring, it either goes CW or CCW.  In other words, take your
> Figure 6.  The protected LSP is A->B->[C]->[D]->E->[F].  This implies that
> you do not allow mcast traffic to enter at A and branch both right and
> left.  In other words, the following p2mp is not allowed:
>
> A
>  ->[F]->E->[D]
>  ->E-[C]
>
> Is that correct?
>
yw>> not 100% correct.  There is a general transport industry assumption
that all working traffic will (most probably for historical, i.e. SDH,
reasons) always traverse a ring in only one direction, however, you should
note that the protection that is described in section 3.2 of the document
actually could split the traffic to go in both directions for p2mp traffic.
 In addition, see my comment to your next comment.

>
>
>
> ii)
> Does the draft assume that I can have a W LSP in two directions?  For a
> four-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C?  This won't
> apply in all cases but it may be desirable to load-balance traffic in both
> directions across the ring.  This has implications on the wrapping
> protection methods.
>
yw> Yes, the draft assumes protection per LSP that traverses the ring,
therefore you could setup protection for two LSPs one that goes A-B-C and
additional protection for the working LSP that traverses A-D-C

>
>
> I'd also like to very much see a scale analysis of the five protection
> mechanisms discussed in the draft.  I started work on one but realized I
> needed to clear up my questions about your assumptions.  I think the p2mp
> mechanisms may have serious scale challenges, but I want to make sure I get
> the assumptions right before discussing the scale.  Once I understand the
> assumptions better, I'll send out my thoughts on scale.
>
> thanks!
>
>
>
>
>
> eric

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 23 Aug 2012 11:22:06 +0000

Hi Greg-

  Inline...

> From: Gregory Mirsky [mailto:[email-masked]]
> Sent: Wednesday, August 22, 2012 5:46 PM
> To: Eric Osborne (eosborne); [email-masked]; draft-ietf-mpls-tp-ring-
> [email-masked]
> Subject: RE: Comments on draft-ietf-mpls-tp-ring-protection
> 
> Hi Eric,
> putting down my $.02:
> I think that applicability of load-balancing techniques in MPSL-TP, including
> Link Bundle and/or Composite Links, have yet to be clarified.

I wasn't talking about link-layer balancing or about load balancing of p2p traffic.  I was talking about a p2mp LSP which can enter the ring and send traffic both CW and CCW.

eric

> As for p2mp LSP ring protection, I think that SPME(s) can be used to protect
> sub-LSP(s). (At least until we finish with application of multi-point BFD for
> unidirectional p2p and p2mp LSPs in MPLS-TP).
> 
>         Regards,
>                 Greg
> 
> From: [email-masked] [mailto:[email-masked] <mailto:mpls-
> [email-masked]> ] On Behalf Of Eric Osborne (eosborne)
> I apologize if these are coming in later than you'd like; I saw Loa's IP query
> and realized I hadn't commented on this draft in a while.
> 
> ii) Figure 1, the wrapped data path goes A-B-C-D-E but should go A-B-C-D-E-
> F, as per the text immediately following.
> 
> 
> One comment on link vs node protection.  There are few places, e.g. section
> 2.4, which say that providing both link and node protection are difficult.  I do
> not believe this to be true.  I am familiar with two implementations that are
> easily able to do this today.  The algorithm is simple; if the thing you're
> protecting ends on the next-hop, use link protection.  Otherwise use node.  I
> agree that with a statically configured network it becomes the responsibility
> of the NMS to make sure this is done right, but it's a simple thing to do.
> 
> It looks like your protection mechanisms all assume that when traffic enters
> the ring, it either goes CW or CCW.  In other words, take your Figure 6.  The
> protected LSP is A->B->[C]->[D]->E->[F].  This implies that you do not allow
> mcast traffic to enter at A and branch both right and left.  In other words, the
> following p2mp is not allowed:
> 
> A
> ->[F]->E->[D]
> ->E-[C]
> 
> Is that correct?
> 
> 
> 
> ii)
> Does the draft assume that I can have a W LSP in two directions?  For a four-
> node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C?  This won't
> directions across the ring.  This has implications on the wrapping protection
> methods.
> 
> 
> <https://www.ietf.org/mailman/listinfo/mpls>
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Thu, 23 Aug 2012 20:06:38 +0000

Hi Yaacov-

  Inline with EO#.

...

> yw>> Yes, you are correct and previous versions of the draft actually included
> such a solution.  However, there were many comments from different
> the same path in both directions and the protection path is "non-
> deterministic" which is bothersome to many transport service providers. 

EO#  I either don't get it or don't agree.  In a ring, you can go CW or CCW.  If the normal traffic goes CW, both the link and node protection tunnels must follow the CCW path.  There is only one way to go; that's what people seem to like about rings.  How is taking the exact same path non-deterministic?

> We
> found that trying to address these comments complicated issues and
> therefore we suggest that the SP decide a-priori for each working path
> whether they want to apply link or node protection.

EO#  Depending on how you set up the "node protection" LSP, you may or may not find that link protection is mandatory.

Consider a 5-node ring, A-B-C-D-E-A.  
If B protects against the failure of link BC, it will have a protect LSP of B-A-E-D-C.
If B protects against the failure of node C, it will have a protect LSP of B-A-E-D.
This works just fine if there are no LSPs which cross link BC and which egress the ring at C.  
But if there's an LSP A-B-C which egresses the ring at C, B *cannot* use the node protection tunnel for traffic which egresses at C. 

It gets hairier with p2mp.
Consider the same ring, with two p2mp LSPs, A-B-[C]-[D]-E and A-B-[C]-[D]-[E].
With traditional node protection (that is, a p2p tunnel which delivers traffic to the NNHOP which then merges and continues downstream), B's LSP protecting against the failure of C would be B-A-E-D.  This, too, leaves you unprotected if link  BC fails but C is reachable via D.

You could build both a link and a node protection tunnel, i.e.  B-A-E-D-C and B-A-E-D.

One might instead be tempted to optimize and protect against both link and node with a single tunnel, e.g. B-A-E-[D]-[C].  This gets trickier, though, since C needs to see a different label in this case than it would have received were it still directly connected to B.  It's not intractable, but if some people's heads explode in the presence of both link and node protection I'm not sure they'll be able to handle this optimization.

> enters the ring, it either goes CW or CCW.  In other words, take your Figure 6.
> The protected LSP is A->B->[C]->[D]->E->[F].  This implies that you do not
> allow mcast traffic to enter at A and branch both right and left.  In other
> words, the following p2mp is not allowed:
> 
> 	A
> 	 ->[F]->E->[D]
> 	 ->E-[C]
> 
> 	Is that correct?
> 
> 
> that all working traffic will (most probably for historical, i.e. SDH, reasons)
> always traverse a ring in only one direction, however, you should note that
> the protection that is described in section 3.2 of the document actually could
> split the traffic to go in both directions for p2mp traffic.  In addition, see my
> comment to your next comment.
> 

EO#  OK, so I'm assuming the p2mp LSP I've described above is legal.  It certainly would be if we had an arbitrary IP/MPLS topology.

> 
> 
> 
> 	ii)
> 	Does the draft assume that I can have a W LSP in two directions?  For
> a four-node ring A-B-C-D-A, can I have both W:A-B-C and W:A-D-C?  This
> won't apply in all cases but it may be desirable to load-balance traffic in both

EO#  I think you answered my question, but I realized I phrased it poorly and would like to rephrase.  Rather than "a W LSP in two directions" I should have said "two W LSPs with the same ingress/egress pair, taking two different directions".  But it looks you figured out this is what I was asking, and so you answered it.

> assumptions better, I'll send out my thoughts on scale.

EO#  As promised, here's my stab at scale for the five methods.

p2p wrapping: this is just FRR.  The draft claims that the scale of link+node is 2N, but I think that's incorrect.  It seems to only consider traffic in one direction.  It's true that if all my traffic flows CW that I only need protection tunnels to flow CCW.  This is where you get 2N for link+node.  But if I have primary traffic which flows both CW and CCW, you now need 2N for *each* of link and node protection.  In other words, to protect against the failure of link BC, node B needs a B->C protection LSP and node C needs a C->B protection LSP.

p2p steering: You need a protect SPME for each node pair on the ring.  So the upper limit on the number of protect LSPs is N^2.

p2mp Wrapping: just like p2p wrapping; in effect, wrapping is ignorant of the type of traffic that it is protecting.  Note that this precludes the idea of a combination link+node protection LSP, as that would be multicast-specific.

p2mp ROM-Wrapping: If I've understood it properly, I think this scales very poorly.  This is because the ROM-Wrapping protection LSP mirrors the tree which it protects, and thus things scale by a combination of the number of protected p2mp LSPs and the number of nodes on the ring.  Consider the ring A-B-C-D-E-A.  There is one mcast tree on this ring: A-B-[C]-[D]-E.  To protect against the failure of link BC, node B needs a ROM-Wrapping LSP B-A-E-[D]-[C].    Similarly, nodes A, C, D and E all need a ROM-Wrapping LSP which mirrors the protected tree A-B-[C]-[D]-E but in the reverse direction, in order to protect against the failure of their outgoing link/next-hop node.

Add one more mcast tree to the ring: A-B-[C]-D-[E].  To protect this tree against the failure of link BC, node B needs another ROM-Wrapping LSP: B-A-[E]-D-[C].  And as above, every other node needs one of these as well.  I think this may be what you meant by " ROM-Wrapping is an LSP based protection mechanism, as opposed to the SPME based protection mechanisms".  But I think that sentence glosses over the scale limitations here.  The number of possible mcast trees in a ring is huge.  If you assume mcast traffic can only go CW, you have N*[2^(n-1)] possible mcast trees which may need protection.  Allowing split mcast trees (e.g.  A: ->[F]->E->[D] and A->E-[C] as in my earlier question) only makes this worse.  I'm tempted to say it increases the potential number of primary mcast trees by something like (N-1)!, which gets pretty big pretty quickly.

For each of these primary LSPs, you need a protection LSP with the reverse topology on every node.  I believe this would be a serious concern for any service provider of any real scale.  A 16-node ring (the traditional ITU maximum but by no means impossible in an IP/MPLS network) could have in excess of a half-million protection LSPs on it. A 17-node ring would require more LSPs than are possible with today's technology.

Again, this is the maximum number of LSPs, and not everyone deploys the maximum, but I believe it is imperative that operators clearly understand the cost of an approach like this before deploying it.  And I have to ask - is the cost of ROM-Wrapping worth the benefit?

p2mp steering: I'm not clear why the draft requires that this be 1+1.  I think it would be cleaner to allow either 1+1 or 1:1, as the operator desires, regardless of protection type.  
I think the scale here is OK, but it depends very much on exactly how you apply context labels.  If you have only two contexts - CW and CCW - then you should be OK.  But if you allow split LSPs as described earlier, you need far more sophistication.  It seems like you either need a context label per possible tree or you need a lot more knowledge in the context table at each hop.  Can you explain how p2mp steering would work in the presence of split p2mp LSPs?

thanks!

eric