Subject: RE: [mpls] RE: Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 9 Nov 2006 20:06:47 +0100

Hi Venu, 

> -----Message d'origine-----
> De : HEMIGE Venu [mailto:[email-masked]] 
> Envoyé : jeudi 9 novembre 2006 19:29
> À : LE ROUX Jean-Louis RD-CORE-LAN; Kireeti Kompella
> Cc : [email-masked]
> Objet : RE: [mpls] RE: Comments on 
> draft-leroux-mpls-p2mp-te-bypass-00.txt
> 
> 
> Hi John-Louis,
> 
> Please see comments inline: 
> 
> > -----Original Message-----
> > From: LE ROUX Jean-Louis RD-CORE-LAN
> > [mailto:[email-masked]]
> > Sent: Thursday, November 09, 2006 10:12 AM
> > To: HEMIGE Venu; Kireeti Kompella
> > Cc: [email-masked]
> > Subject: RE: [mpls] RE: Comments on
> > draft-leroux-mpls-p2mp-te-bypass-00.txt
> > 
> > Hi Venu
> > 
> > Think about the protection of a branch node with N downstream LSRs.
> > If you rely on P2P Bypass tunnels, you end up with N times 
> the traffic 
> > on shared bypass links during failure...
> > I can show you operational network topologies where N = 50, and you 
> > would end up with 50 times the traffic on shared links. For 
> the sake 
> > of illustration, to protect a 2G TV traffic, you would need 100G 
> > capacity to backup the traffic!
> > no comments...
> > 
> 
> Agreed.
> 
> > The situation is not the same with link protection, as you 
> can rely on 
> > a single P2P Bypass, and there is no traffic replication at all.
> >
> 
> Let's say a branch node R1 has two downstream LSR1 R2 and R3 
> on a P2MP tree. To protect the link between R1 and R2, the 
> p2p bypass tunnel may go through R3. In the event of the 
> R1-R2 link failure, traffic from R1 to R2 will be forwarded 
> via the bypass tunnel. But since R3 is also a downstream LSR 
> to R1, traffic is forwarded normally on R1-R3 also. So there 
> are two copies of the multicast traffic on R1-R3. 

OK, I get your point. 

> Now, I 
> agree that the situation is not as bad as that for node 
> protection - there will be atmost two copies. But that is 
> still an issue, isnt it? 

Yes it is.

>Your draft would solve this issue if 
> you apply it to P2MP link protection as well. 

Yes, it would solve this issue. A P2MP Bypass may indeed be used to protect a link downstream to a branch LSR. In case of failure, the traffic would be tunneled within the P2MP Bypass towards all downstream LSRs, and there would be only a single copy of the traffic on a downstream link.

Thanks a lot for highlighting this point, IMO this significantly reinforces the needs for P2MP Bypass tunnels.

Best Regards,

JL

> 
> Regards,
> -Venu
> 
> > 
> > > -----Message d'origine-----
> > > De : HEMIGE Venu [mailto:[email-masked]] Envoyé 
> : jeudi 9 
> > > novembre 2006 17:57 À : Kireeti Kompella; LE ROUX Jean-Louis 
> > > RD-CORE-LAN Cc : [email-masked] Objet : RE: [mpls] RE: Comments on 
> > > draft-leroux-mpls-p2mp-te-bypass-00.txt
> > > 
> > > 
> > > Hi Jean-Louis,
> > > 
> > > I agree with Kireeti that node protection is several degrees more 
> > > complex, definitely in the case of P2MP LSPs. However, I 
> am not so 
> > > sure of the efficiency of even link protection for P2MP 
> LSP traffic. 
> > > The bypass tunnel for a protected link may be established over 
> > > another link or set of links behind which there are leaves of the 
> > > P2MP LSP. So when the protected link fails, there would be two 
> > > copies of the traffic forwarded over such links. Isn't 
> that also a 
> > > concern very similar to what you are trying to solve in 
> this draft 
> > > for node protection?
> > > 
> > > Regards,
> > > -Venu
> > > 
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: Kireeti Kompella [mailto:[email-masked]]
> > > > Sent: Wednesday, November 08, 2006 11:56 AM
> > > > To: LE ROUX Jean-Louis RD-CORE-LAN
> > > > Cc: [email-masked]
> > > > Subject: Re: [mpls] RE: Comments on 
> > > > draft-leroux-mpls-p2mp-te-bypass-00.txt
> > > > 
> > > > Hi Jean-Louis,
> > > > 
> > > > To re-iterate my comment in the WG, in general, node 
> protection, 
> > > > whether for p2p or p2mp LSPs, is an order of magnitude less
> > > scalable
> > > > than link protection.
> > > > 
> > > > I think we should step back at this point, and request SPs
> > > and others
> > > > deploying MPLS networks to share with the WG: 
> frequencies of link 
> > > > failures, node software failures (node recovers), node failures 
> > > > (requires manual intervention), and battery explosions, to
> > > give us a
> > > > sense of the importance of continuing the work on node 
> protection.
> > > > 
> > > > I realize that some of these figures may be sensitive, but even 
> > > > normalized numbers may be useful.
> > > > 
> > > > Kireeti.
> > > > -------
> > > > 
> > > > _______________________________________________
> > > > mpls mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/mpls
> > > > 
> > > 
> > 
> 

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

---

From: "HEMIGE Venu" <[email-masked]>
Date: Thu, 9 Nov 2006 19:02:23 -0600

Hi John-Louis,

<...deleted...>

> > protection - there will be atmost two copies. But that is 

I was afraid so too.

> Yes, it would solve this issue. A P2MP Bypass may indeed be 
> used to protect a link downstream to a branch LSR. In case of 
> failure, the traffic would be tunneled within the P2MP Bypass 
> towards all downstream LSRs, and there would be only a single 
> copy of the traffic on a downstream link.
> 

I think it can still be very tricky to achieve "single-copy" FRR even if we use P2MP bypass tunnels (for either node or link protection). In the above example, let's say R2, R3 and R4 are downstream of R1. And assume that R5 and R6 are downstream to R2 and are part of the P2MP tree. So the P2MP bypass tunnel would need to have {R5, R6} as the leaves of the P2MP bypass tunnel. In addition, since the bypass tunnel goes through R3, R3 will also have to be part of the bypass tunnel. So bypass tunnel will have {R3, R5, R6} as leaves. Only then, can we guarantee a single-copy FRR. When the R1-R2 link is functional, R1 has to switch the P2MP traffic to {R2, R3, R4}. When the R1-R2 link fails or when the node R2 fails, R1 needs to forward traffic to {Tunnel protecting R2, R4}. Note that R3 also needs to be removed from the OIF-list. This can be tricky both in the control plane and data plane, but I suppose it can be done.

Another worrisome part is the following: In the unicast case, we protect a link and can tunnel any unicast traffic for that link onto the bypass tunnel. So it is O(1) processing when a link fails. But in the multicast case, we will need to make sure that all P2MP trees that will be forwarding traffic on the P2MP bypass tunnel do not also forward traffic to R3. So the FRR may not be as responsive as it is for unicast.

The above logic would work if the double-copy happens on links connected to R1. But if the douple-copy happens because of some remote link in the P2MP tree also being a branch of the tree, then I am not sure how that can be solved - even with P2MP bypass tunnels. i.e. if the bypass P2MP tree has to go through R1-Rx-Ry-Rz and the branch Ry-Rz is also a part of the P2MP tree, then I am not sure how we can ensure single-copy there.

> Thanks a lot for highlighting this point, IMO this 
> significantly reinforces the needs for P2MP Bypass tunnels.
>

I agree that for both link and node protection, P2MP bypass is probably the right option. So if single-copy FRR is an absolute requirement, then I agree that P2MP Bypass tunnels will be needed. But the complexity is very high in my opinion.

Regards,
-Venu