Subject: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link

From: <[email-masked]>
Date: Tue, 17 Jan 2012 17:35:45 +0100

Hi all,
 
I made some simulation based on real topologies on LFA and remote LFA.
I saw some issues related to topologies and I wanted to have some
feedback on it.
 
We focus on P-P link failures.
In some ring topologies between Ps (which doesn't work very well with
LFA),  alternate Ps are not eligible for LFAs (for some destinations)
but some PEs are eligible providing link protection for the P-P link
failure.
 
We tried to apply remote LFA algorithm for non LFA eligible
destinations, and sometimes we have the same thing  : PEs are used as
best rLFA because there is no eligible P.
 
PE are sometimes meshed with low BW link (compared to core links). So if
P core link fails, traffic will be switched on PE link (during
protection time) and so will potentially (high probability) make the
link congestionned.
 
>From P point of view : traffic is protected, even if some traffic is
dropped due to congestion(CoS should prioritize traffic), it's better
than dropping all.
 
>From PE point of view : some destinations of the PE where maybe not
using the P-P link that fails. But due to congestion of the link, they
become impacted. So impact for the PE is maybe greater than not having
LFA on the core (we are talking about few seconds of impact -> time for
the P to converge).
 
Note : it's not a one to one mapping of traffic between the P-P link
that fails and the P-PE link used as LFA. It will depend on how many
destinations are using this PE as LFA (and quantity of traffic per
destination). But we could clearly expect congestion as PE links are
sized only for their usage.
 
Do you think this is a real concern ?
If yes, is there already a proposal/solution to deal this issue ?
    - like using TE informations (ISIS subTLV) to take account BW, and
so basically not protecting a link by a lower BW link
    - preventing some links to be used as LFA

Thanks for your feedback
 
---
Stephane

_________________________________________________________________________________________________________________________

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 authorization.
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 shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: Anton Smirnov <[email-masked]>
Date: Tue, 17 Jan 2012 18:30:50 +0100

Hi Stephane,
    if link which you want to exclude is local to the calculating router 
then implementation is trivial and doesn't need any signaling.
    If link is not local then this is very similar to more general 
problem of non-local SRLG. It was discussed but computation is 
relatively complex and still needs investigation.

Anton

On 01/17/2012 05:35 PM, [email-masked] wrote:
> LFA), alternate Ps are not eligible for LFAs (for some destinations) but
> some PEs are eligible providing link protection for the P-P link failure.
> - like using TE informations (ISIS subTLV) to take account BW, and so
> basically not protecting a link by a lower BW link
> _______________________________________________
> rtgwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg

---

From: Ahmed Bashandy <[email-masked]>
Date: Tue, 17 Jan 2012 19:54:21 +0200

If I understand the concern correctly, the issue is that the PE is used
as a remote LFA even though the PE is not connected to links with enough
bandwidth.

A quick solution is to configure the protecting/repairing routers to
only consider certain routers as rLFAs. Admin tags or routing policy can
be used to achieve this goal. I believe this would be an internal
implementation detail rather than a protocol modification

Thanks

Ahmed

On 1/17/2012 6:35 PM, [email-masked] wrote:
> LFA),  alternate Ps are not eligible for LFAs (for some
> destinations) but some PEs are eligible providing link protection for
> the P-P link failure.
>  
> PE are sometimes meshed with low BW link (compared to core links). So
> if P core link fails, traffic will be switched on PE link (during
> LFA on the core (we are talking about few seconds of impact -> time
> for the P to converge).
>

---

From: <[email-masked]>
Date: Wed, 18 Jan 2012 10:25:10 +0100

[Ahmed]
> If I understand the concern correctly, the issue is that the PE is
used as a remote LFA even though the PE is not connected to links with  
> enough bandwidth.
only consider certain routers as rLFAs. Admin tags or routing policy
>can  be used to achieve this goal. I believe this would be an internal
 
[SLI] Yes the problem comes even with LFA or rLFA. 

[Anton] 

 >If link is not local then this is very similar to more general problem
of non-local SRLG. It was discussed but computation is relatively
complex and still needs investigation.

 [SLI] I'm talking about only local links, so I agree that it should be
quite "easy" to implement, but I'm not aware of such implementation
today. Maybe it can be dealed with local SRLG but will be hard to
operate as SRLG database will require manual configuration/maintenance.
 
Don't you think this concern should be highlighted somewhere (even if no
modification required) to make people aware of this ?
 
Best Regards 
 
Stephane

---

From: Alia Atlas <[email-masked]>
Date: Wed, 18 Jan 2012 11:06:29 -0500

Stephane,

For local links, it makes sense to have the ability to
administratively allow/disallow their use as an alternate.  This is
what I implemented when at Avici. If you read RFC5286, step 3 in the
example algorithm in Sec 3.6 says
"   3.   If H_h.link is administratively allowed to be used as an
        alternate, "

Some of the feedback from the LFA Applicability draft is that we
really should have a document that talks about management as well as
MIBs.  Would you be interested in working on that?

Alia

On Wed, Jan 18, 2012 at 4:25 AM,  <[email-masked]> wrote:
>
> [Ahmed]
>> If I understand the concern correctly, the issue is that the PE is used as
>> a remote LFA even though the PE is not connected to links with
>> enough bandwidth.
>> A quick solution is to configure the protecting/repairing routers to only
>> consider certain routers as rLFAs. Admin tags or routing policy  >can  be
>> used to achieve this goal. I believe this would be an internal
>  > if link which you want to exclude is local to the calculating router then
> implementation is trivial and doesn't need any signaling.
>
>  >If link is not local then this is very similar to more general problem of
> non-local SRLG. It was discussed but computation is relatively complex and
> still needs investigation.
>
> quite "easy" to implement, but I'm not aware of such implementation today.
> Maybe it can be dealed with local SRLG but will be hard to operate as SRLG
> database will require manual configuration/maintenance.
>
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> As emails may be altered, France Telecom - Orange shall not be liable if
> this message was modified, changed or falsified.
> Thank you.
>
>

---

From: <[email-masked]>
Date: Thu, 19 Jan 2012 15:45:27 +0100

Hi Alia,

Thanks for your feedback.
Yes, some work is needed on management part.
Some global items to address are already proposed in RFC 5714 section 6 (Management considerations).
The main issue I can see is are we ready for that now ? Or should we wait for LFA deployment start in SP networks to have a better feedback on needs. I don't know where are other SPs regarding LFA deployment. If the work is too theorical, it may not fit the SP needs and so will never be implemented or used.
We internally have already few ideas on what is needed as LFA is deployed in some areas.
Does someone already started this work ?

Thanks

Stephane

-----Message d'origine-----
De : Alia Atlas [mailto:[email-masked]] 
Envoyé : mercredi 18 janvier 2012 17:06
À : LITKOWSKI Stephane DTF/DERX
Cc : Ahmed Bashandy; [email-masked]; [email-masked]
Objet : Re: draft-shand-remote-lfa-00 / RFC 5286 / draft-ietf-rtgwg-lfa-applicability => using low BW link as LFA to protect high BW link

Stephane,

For local links, it makes sense to have the ability to administratively allow/disallow their use as an alternate.  This is what I implemented when at Avici. If you read RFC5286, step 3 in the example algorithm in Sec 3.6 says
"   3.   If H_h.link is administratively allowed to be used as an
        alternate, "

Some of the feedback from the LFA Applicability draft is that we really should have a document that talks about management as well as MIBs.  Would you be interested in working on that?

Alia

On Wed, Jan 18, 2012 at 4:25 AM,  <[email-masked]> wrote:
>>>can  be  used to achieve this goal. I believe this would be an 
>>internal  implementation detail rather than a protocol modification
>
>  > if link which you want to exclude is local to the calculating 
> router then implementation is trivial and doesn't need any signaling.
>
>  >If link is not local then this is very similar to more general 
>  [SLI] I'm talking about only local links, so I agree that it should 
> be quite "easy" to implement, but I'm not aware of such implementation today.
> Maybe it can be dealed with local SRLG but will be hard to operate as 
> SRLG database will require manual configuration/maintenance.
>
> Don't you think this concern should be highlighted somewhere (even if 
> no modification required) to make people aware of this ?
>
> Best Regards
>
> Stephane
>
>
> ______________________________________________________________________
> ___________________________________________________
>
> 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 authorization.
> As emails may be altered, France Telecom - Orange shall not be liable 
> if this message was modified, changed or falsified.
> Thank you.
>
>