Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

[Ahmed Bashandy <[e-mail]>]

The basic idea behind any (IP)FRR mechanism is to have the repairing
node per-calculate the repair path and be directly connected to the
failure point. This allows the repairing node can make quick and small
local modification to the FIB so that traffic gets re-routed over the
per-calculated repair path within a guaranteed recovery period

This draft, just like all (IP)FRR drafts (including those that protect
multicast traffic), addresses the case of the repairing node being
adjacent  to failing network element. Detecting a remote failure is
really beyond the scope

Thanks

Ahmed


On 3/27/2012 10:55 AM, [e-mail] wrote:
> I totally agree with your point as if the P router is not directly connected to the protected PE, the solution doesn't bring any improvement compared to PIC Edge.
> The solution as a value for a repairing P connnected to the PE and so detecting the failure immediately.
> If the repairing P is remote to the failure, we are no more in a FRR case ... And I think this should be prevented ...
>
> -----Message d'origine-----
> De : Jeff Tantsura [mailto:[e-mail]] 
> Envoyé : mardi 27 mars 2012 10:44
> À : LITKOWSKI Stephane DTF/DERX
> Cc : Ilya Varlashkin; IETF MPLS
> Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation
>
> Hi,
>
> The switchover AFTER the failure has been detected in both cases is:
> Prefix independent - ie no RIB->FIB interactions Sub 100ms for reasonable number of primary/backup pairs
>
> So the real issue here is reliable and fast failure notification!
>
> As for this draft - if the repairing P router is not directly connected to the primary PE it is subject to the same limitations and would initiate switchover on either multihop BFD down or IGP convergence.
> Even though it is presumably closer to the failure than ingress PE and could react faster IMHO the complexity introduced is rather significant compared to the gain.
>
> Regards,
> Jeff
>
> On Mar 27, 2012, at 10:21 AM, "[e-mail]" <[e-mail]> wrote:
>
>> Ilya,
>>
>> The best current available mechanism is BGP PIC Edge that relay on IGP convergence to detect that remote PE is no longer reachable : PIC Edge result mainly depends on how fast your IGP is converging (sub sec or more).
>>
>> Ahmed solution is an FRR solution so doesn't rely on convergence. As soon as a P router detects that the link to the protected PE fails, it will switch (using pre-programmed backup NHLFE), so there you are in FRR numbers ... 50msec - 100msec depending of implementation ...
>>
>> Clearly the solution is today complex, and I hope it could be a bit 
>> simplified :)
>>
>> Regards,
>>
>> Stephane
>>
>>
>> -----Message d'origine-----
>> De : [e-mail] [mailto:[e-mail]] De la part 
>> de Ilya Varlashkin Envoyé : mardi 27 mars 2012 10:08 À : IETF MPLS 
>> Objet : [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation
>>
>> Ahmed, Kamran,
>>
>> as first expressed at the mic during MPLS session, I'd like to ask you for a clarification of the motivation behind the draft. You say that this draft will provide faster switch-over/fail-over time compare to anything already existing today. Do you have some numbers for comparison?
>>
>> /iLya
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
>>
>> ______________________________________________________________________
>> ___________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
>> exploites ou copies sans autorisation. Si vous avez recu ce message 
>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or 
>> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>> _______________________________________________
>> mpls mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> mpls mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls