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 protected]> 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
>> implementation detail rather than a protocol modification
>
> [SLI] Yes the problem comes even with LFA or rLFA.
>
>
> [Anton]
>
> > 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.
>
> [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
>
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
