The MPLS WG Archive

["LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ftgroup.com>]

Hi Venu, 

> -----Message d'origine-----
> De : HEMIGE Venu [mailto:Venu.Hemige@alcatel.com] 
> Envoyé : vendredi 10 novembre 2006 02:02
> À : LE ROUX Jean-Louis RD-CORE-LAN; Kireeti Kompella
> Cc : mpls@ietf.org
> Objet : RE: [mpls] RE: Comments on 
> draft-leroux-mpls-p2mp-te-bypass-00.txt
> 
> Hi John-Louis,
> 
> <...deleted...>
> 
> > > 
> > > > 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.
> 
> I was afraid so too.
> 
> > 
> > >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.
> > 
> 
> 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.

This is a local implementation issue. You may prepare all backup outputs in advance and rely on a clever mechanism (that I won't describe here) to avoid any impact on the recovery time.

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

Note that in enough redundant topologies such situation is very unlikely to happen.

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

Yes it is a strong requirement.

>then I agree that P2MP Bypass tunnels 
> will be needed. But the complexity is very high in my opinion.

You should mitigate a bit...This is for sure more complex but definitely not highly complex IMO.
Anyway, hierarchy and upstream label assignement will also be needed for other applications (e.g. MVPN Aggregation)...

Best Regards,

JL

> 
> Regards,
> -Venu
> 
> > 
> > > 
> > > Regards,
> > > -Venu
> > > 
> > > > 
> > > > > -----Message d'origine-----
> > > > > De : HEMIGE Venu [mailto:Venu.Hemige@alcatel.com] Envoyé
> > > : jeudi 9
> > > > > novembre 2006 17:57 À : Kireeti Kompella; LE ROUX Jean-Louis 
> > > > > RD-CORE-LAN Cc : mpls@ietf.org 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:kireeti@juniper.net]
> > > > > > Sent: Wednesday, November 08, 2006 11:56 AM
> > > > > > To: LE ROUX Jean-Louis RD-CORE-LAN
> > > > > > Cc: mpls@ietf.org
> > > > > > 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
> > > > > > mpls@lists.ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/mpls
> > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls