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

From: [email-masked]
Date: Thu, 20 Sep 2012 15:18:20 +0800

hi, all
i agree on what Eric said in this email.
for p2mp ROM Wrapping, it is very poorly for scales. in my mind , i 
discussed the problem in the past.
in addtion, for p2mp steering , i completely agree with Eric's opinions. 
it should allow either 1+1 or 1:1 
in the protection mechanism. after all, 1+1 may waste more bandwidth 
resource than 1:1 in my mind.
so i think that the authors of this draft should consider adding 1:1 
mechanism in p2mp steering section.

best regards
liu 

"Eric Osborne (eosborne)" <[email-masked]> 
发件人:  [email-masked]
2012-08-24 04:06

收件人
Yaacov Weingarten <[email-masked]>
抄送
"[email-masked]" <[email-masked]>, 
"[email-masked]" 
<[email-masked]>
主题
Re: [mpls] Comments on draft-ietf-mpls-tp-ring-protection

Hi Yaacov-

  Inlin with EO#.

...

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

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.

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

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

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.

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

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

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

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