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 protected] wrote: > 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. > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
