The MPLS WG Archive

[Peter Tomsu <ptomsu@cisco.com>]

Well, if topologies are redundant enough, lot of issues will go away

Peter


On 10.11.2006 11:27 Uhr, "LE ROUX Jean-Louis RD-CORE-LAN"
<jeanlouis.leroux@orange-ftgroup.com> wrote:

> 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





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