Re-sending as my previous email was apparently too big. ( "too big to fail" does not work for email ;-) )
From: DECRAENE Bruno IMT/OLN Sent: Thursday, April 02, 2015 12:24 PM To: 'Anil Kumar S N (VRP Network BL)' Hi Anil, Please see inline [Bruno] From: Anil Kumar S N (VRP Network BL) [mailto:[email protected]] Sent: Thursday, April 02, 2015 10:53 AM Hi Bruno,Chris, Lets not talk about number of labels. With respect to TI LFA, In our implementation we have extended number labels much more than two, [Bruno] Good job. - For link protection only, in network with symmetric link cost, up to 2 labels may be required for. Never more than 2. - For others cases, in particular node and/or SRLG protection, more than 2 labels may be required. In theory, there is no limit. In practice, there is a limit. In our networks, the max found was 4 labels. So it's good to be able to push more than 2 labels to enforce the FRR detour. Ex: when there is no PQ node also when there no adjacency b/w any P and Q node pair. We find a shortest path from P & Q form; a label stack that will be pushed. In case L3 VPN PE label stack could become much more. This consumes more computation. Best effort label for a destination is Destination Label , SR FRR label for the same destination is [P Node -> Label stack to reach Q Node -> Destination label]. [Bruno] I would propose OLD: using an MPLS label stack with two labels NEW: by pushing up to two additional labels There is a possibility of Looping in TI-LFA; We can expect in case of multiple simultanious failure: [Bruno] You are right. In case of independent/non FRR planned failures, the first PLR can't avoid all failures since those failures were expected to not planned/expected to occur at the same time. The second PLR will try to protect the second failure. In good cases, the two protections are complementary and will achieve "de facto" protection. In bad cases, forwarding loop will occur. In theory, the handling of the second independent failure, is a (difficult) choice, between dropping or trying to repair. In theory TI-LFA could do both, but as of today, it tries the second protection This is not specific to TI-LFA. FRR assumes _local_ protection (hence local knowledge) of a _pre_computed_ (hence pre-planned) failure. I have been told ARC could handle multiple consecutive FRR (through some localize notification mechanism) but I don't have the details. Consider the case where packet is been forwarded towards destination from a source on backup FRR path with TI LFA backup path Statck as below : P Node Lable P-Node to Q-Node Adj lable Q-Node Lable Destination Lable Topology : P----Q (Cost 10) Q----Destination(Cost 10) P----Destination (Cost 100) Faliure happens on the only link b/w Q-Node towards destination; Reachability to destination with SPF calculation or with FRR falls back towards P-Node (Q's TI LFA calculation). [Bruno] In this specific case, I don't see a loop. Q, acting as the second PLR (in a row), has computed that node "P" is its P node and node "D" is its Q node. P is reached via a node-SID (possibly implicit label) which is not affected by the first failure. Q is reached by a Adj-sid, which is not affected by the first failure. So there could be a loop. [Bruno] I could not find one in this example, but I agree that we could find examples with loops. e.g. the following topology A - B | \ | C - D Where all links have a metric of 10, except AC which has 100. For the traffic from A to C, if both AC and BD links fails at the same time (and were not identified as SRLG), there will be a loop between A and B. (and funnily (is it? ;-) ) as packets are looped, the label stack seems to increase to "infinity" as additional P nodes (alternatively C and D) are used. So I still feel there is a tradeoff. [Bruno] There are many tradeoff ;-). But this one is about handling a second independent failure. Not about increase coverage of a protected resource (link/node/SRLG/any) Thanks Regards /Bruno Thanks & Regards Anil S N "Be liberal in what you accept, and conservative in what you send" - Jon Postel _________________________________________________________________________________________________________________________ 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, 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, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
