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 protected]] Envoyé : mercredi 18 janvier 2012 17:06 À : LITKOWSKI Stephane DTF/DERX Cc : Ahmed Bashandy; [email protected]; [email protected] 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 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 > _________________________________________________________________________________________________________________________ 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
