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

From: <[email-masked]>
Date: Tue, 27 Mar 2012 11:04:55 +0200

As said to you offline, I would be interrested with discussing about your testing, achieving tns of msec with convergence is something I don't really see in a real world (otherwise why should we implement TE FRR or LFA ??).

Regarding the paradigm of giving VPN info on P, yes I agree with your point, that is something to care about.
Globally the solution proposed, gives a per CE view at P router (not really per VPN) and I have some scaling concerns about it.

Today I'm not pushing this kind of solution as clearly it has some issues and brings concerns , I'm just interrested looking at it and see what could be the improvement that we could provide to some premium customers.
The improvement exists, but it must be clearly measured against scaling concern, interop with current FRR mechanism ...

As we are more discussing about the solution, rather than the LDP evolutions, I propose to move the discussion to IDR mailing list ...

-----Message d'origine-----
De : Ilya Varlashkin [mailto:[email-masked]] 
Envoyé : mardi 27 mars 2012 10:55
À : LITKOWSKI Stephane DTF/DERX; 'IETF MPLS'
Objet : RE: ahRE: [mpls] draft-bashandy-mpls-ldp-bgp-frr-00 motivation

> -----Original Message-----
> 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).
>

I've been recently measuring convergence on not very fast RP and found that even for 10 000 nodes it's less than 900ms. Clearly 10K nodes is unlikely to be seen in many networks if in any at all. And for real-world sized nets convergence is like few tens of ms - not really to worry about.
 
> 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 ...
> 

If _P_ node needs to do fail-over to backup PE depending on VPN (L3VPN, PWE, L2VPN etc) then _P_ node needs to have VPN-level knowledge, and that contradicts with original idea of P nodes (they shouldn't care what's inside, only how to get to the edge independent of "payload").

> Clearly the solution is today complex, and I hope it could be a bit
simplified :)

Because of previous statement I see proposed solution as complication rather than simplification, and because of above mentioned IGP convergence times the gain seems to be too little when balanced against complexity.
 
/iLya

_________________________________________________________________________________________________________________________

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.

---

From: <[email-masked]>
Date: Wed, 28 Mar 2012 14:09:53 +0200

[Moving to IDR list ...]

Yes, when we are aware about FRR technics, it's clear but there is some lines in the doc, that could lead to understand that every P may install a repair ...

If you are using LDP or ISIS (and especially ISIS which use flooding of LSP) to advertise the (NHi,rNHi) or (Nhi,rNHi,Li,Push), every P router will receive the info (could not be the case with LDP ..., but it's not welle detailled that your LDP TLV must not be propagated upstream). I don't see something in the drafts (ISIS or BGP drafts) preventing remote P to install a backup entry ...

Based on Step 4 at §2.4 of the BGP draft, any P has a route to the BGP nexthop, and so is able to compute alternate path ...

How do you prevent it to happen ?

-----Message d'origine-----
De : Ahmed Bashandy [mailto:[email-masked]] 
Envoyé : mercredi 28 mars 2012 12:17
À : LITKOWSKI Stephane DTF/DERX
Cc : Jeff Tantsura; IETF MPLS
Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

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, [email-masked] 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 ...
>
> De : Jeff Tantsura [mailto:[email-masked]]
> 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, "[email-masked]" <[email-masked]> 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 ...
>>
>> Regards,
>> Stephane
>> De : [email-masked] [mailto:[email-masked]] 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
>> [email-masked]
>> 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.
>> _______________________________________________
>> mpls mailing list
>> [email-masked]
>> 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.
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 28 Mar 2012 12:35:18 -0400

Ahmed,

BGP PIC Edge is not the only existing solution.
Look at "5.1.8.4.1.  Anycast BGP applied to ABR node failure"
in http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-01

That looks much simpler. How is yours better than this?

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 28, 2012 5:10 AM
To: Ahmed Bashandy
Cc: [email-masked]
Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

[Moving to IDR list ...]

-----Message d'origine-----
De : Ahmed Bashandy [mailto:[email-masked]] 
Envoyé : mercredi 28 mars 2012 12:17
À : LITKOWSKI Stephane DTF/DERX
Cc : Jeff Tantsura; IETF MPLS
Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

Thanks

Ahmed

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 07:46:33 +0200

Jakob,

BGP Anycast and Ahmed's solution sound very similar.

BGP Anycast :
 - Protector PE definition seems manual as far as I know
 - LFA used as protection mechanism on P thanks to Anycast feature (same virtual loopback used on primary and repair PE) => 100% coverage not guaranteed
 - Still need to advertise virtual loopbacks in ISIS and LDP 
 - Requires also usage of repair label draft to prevent loops
 - Possibly requires a small change in the way to advertise LDP FEC for virtual loopbacks (depending on current vendor implementation) => no PHP required but most vendors are doing PHP by default.
 - One core state per VPN protected
 - Possibly suboptimal routing when using centralized protector PEs.

BGP-edge-node-frr : 
 - Protector PE definition is automatic (no configuration), and chosen by primary PE and his per CE.
 - New extension used to signal protection decision to P router
 - New loopbacks advertised in ISIS and LDP.
 - Basically more optimal routing (BGP anycast can achieve the same but it requires a lot of configuration of many different PEs)
 - One core state per CE protected (per VPN possible but may cause loop)

Correct me if I missed something.

Regards,

Stephane

-----Message d'origine-----
De : Jakob Heitz [mailto:[email-masked]] 
Envoyé : mercredi 28 mars 2012 18:35
À : Ahmed Bashandy
Cc : [email-masked]; LITKOWSKI Stephane DTF/DERX
Objet : RE: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

Ahmed,

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 28, 2012 5:10 AM
To: Ahmed Bashandy
Cc: [email-masked]
Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

[Moving to IDR list ...]

-----Message d'origine-----
De : Ahmed Bashandy [mailto:[email-masked]] Envoyé : mercredi 28 mars 2012 12:17 À : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura; IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

Thanks

Ahmed

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.

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 29 Mar 2012 03:28:55 -0400

> - Protector PE definition seems manual as far as I know

Not if the protecting PE is the protector.

> - LFA used as protection mechanism on P thanks to Anycast feature (same virtual loopback used on primary and repair PE) => 100% coverage not guaranteed

If no LFA, then it's IGP convergence. Same with Ahmed's draft.

> - Requires also usage of repair label draft to prevent loops

What loops?

> - One core state per VPN protected

The only core state is the alternate path to the anycast.

---

From: <[email-masked]>
Date: Thu, 29 Mar 2012 09:53:56 +0200

Inline comments ... 

-----Message d'origine-----
De : Jakob Heitz [mailto:[email-masked]] 
Envoyé : jeudi 29 mars 2012 09:29
À : LITKOWSKI Stephane DTF/DERX
Cc : Ahmed Bashandy; [email-masked]
Objet : Re: [Idr] [mpls] RE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation vs BGP anycast

[SLI] Here it is more implementation dependent ... But based on the only implementation I know, you always still to configure the protector.

> - LFA used as protection mechanism on P thanks to Anycast feature 
> (same virtual loopback used on primary and repair PE) => 100% coverage 
> not guaranteed

[SLI] Ahmed draft doesn't require any LFA. And doesn't care about loop free path (labels are changed on another LSP using another target FEC is used). The only case where there is no protection is when the protector is reachable through the primary egress PE (cascaded PE case ...)

What loops?

[SLI] Sorry my mistake, no loop here as Primary egress is down (I was confused compared to PE-CE link protection case)

[SLI] Yes but there is one anycast per VPN ...

I'm not pushing one or other solution today, both have pros and cons ...

> - Basically more optimal routing (BGP anycast can achieve the same but 
> it requires a lot of configuration of many different PEs)
> De : Jakob Heitz [mailto:[email-masked]] Envoyé : mercredi 
> 28 mars 2012 18:35 À : Ahmed Bashandy Cc : [email-masked]; LITKOWSKI 
> Stephane DTF/DERX Objet : RE: [Idr] [mpls] ahRE: 
> draft-bashandy-mpls-ldp-bgp-frr-00 motivation
> 
> Ahmed,
> 
> De : Ahmed Bashandy [mailto:[email-masked]] Envoyé : mercredi 28 
> mars 2012 12:17 À : LITKOWSKI Stephane DTF/DERX Cc : Jeff Tantsura; 
> IETF MPLS Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 
> motivation
> 
> 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
> 
> 
>>> ____________________________________________________________________
>>> _ _ ___________________________________________________
>>> 
>>> 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.
>>>

---

From: "Ahmed Bashandy (bashandy)" <[email-masked]>
Date: Thu, 29 Mar 2012 05:53:57 -0700

Thanks for pointing that out to me. I'll read the draft and get back to you soon

Thanks

Ahmed

-----Original Message-----
From: Jakob Heitz [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 6:35 PM
To: Ahmed Bashandy (bashandy)
Cc: [email-masked]; [email-masked]
Subject: RE: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

Ahmed,

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, March 28, 2012 5:10 AM
To: Ahmed Bashandy
Cc: [email-masked]
Subject: Re: [Idr] [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

[Moving to IDR list ...]

-----Message d'origine-----
De : Ahmed Bashandy [mailto:[email-masked]] 
Envoyé : mercredi 28 mars 2012 12:17
À : LITKOWSKI Stephane DTF/DERX
Cc : Jeff Tantsura; IETF MPLS
Objet : Re: [mpls] ahRE: draft-bashandy-mpls-ldp-bgp-frr-00 motivation

Thanks

Ahmed