The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [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:jeanlouis.leroux@orange-ftgroup.com] > Sent: Thursday, November 09, 2006 10:12 AM > To: HEMIGE Venu; Kireeti Kompella > Cc: mpls@ietf.org > 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. 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? Your draft would solve this issue if you apply it to P2MP link protection as well. But the complexity would be the same as that for node protection. 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
|
|