Re-sending... From: DECRAENE Bruno IMT/OLN Sent: Thursday, April 02, 2015 3:00 PM To: 'Anil Kumar S N (VRP Network BL)' Cc: [email protected]; Alia Atlas; Robert Kebler; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Hi Anil, Please see inline [Bruno2] Thanks, Regards, Bruno From: Anil Kumar S N (VRP Network BL) [mailto:[email protected]] Sent: Thursday, April 02, 2015 1:52 PM To: DECRAENE Bruno IMT/OLN Cc: [email protected]; Alia Atlas; Robert Kebler; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; Kalyankumar Asangi; Rajeshmv; Veerendranatha Reddy Vallem; Chris Bowers Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt Hi Bruno, :) Lets finalize on the rephrased statement which need to be updated. Please see inline [Anil] Thanks & Regards Anil S N "Be liberal in what you accept, and conservative in what you send" - Jon Postel [...] 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 [Bruno2] As a side note, "Q-Node Label" is not required. (with previous label, you reach "Q". Then "Q" can directly reach the destination "D") Topology : P----Q (Cost 10) Q----Destination(Cost 10) P----Destination (Cost 100) [Bruno2] I understand the following topology 10 10 P ------ Q ------- D | | +--------------+ 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. [Anil] : Here P would send a packet to Q and as primary path to D is lost Q would return packet back to P till P learns link b/w Q and D is down. [Bruno2] Q sees the failure of QD for destination D. It will swap Node_SID (D) to Node_SID (P), Adj_SID PD, Node_SID (D). (In MPLS, with PHP, first and last SID may be encoded with no label) P will see, at the topo of the stack "Adj_SID PD" and hence will send the traffic to D. No loop. 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. [Anil] : I understand Loop here but Label stack increase can you help me to understand. [Bruno2] My mistake. Sorry. I meant all links have a metric of 10, except AD which has 100 Notation: Prefix --> Nominal Next-Hop => LFA Next-Hop On node A: C --> C => B, push Node_SID(D), Node_SID(C) On node B: D --> D => A, push Node_SID(C), Node_SID(D) If both links AC & BD fails, each PLR (A & B) push 1 additional label (respectively to D & C). Since C & D are never reached, label are never poped. So at each iteration in the loop, an additional label is pushed. Here primary path would be A->D->C [Cost 20] for A (LFA A->B->D->C), Primary path for B to would be B->D->C [Cost 20] (LFA B->A->D->C). On A->C link failure A chooses A->B->D->C, On B->D failure B chooses B->A->D->C. A would send packet to B and B would send packet to A. Here which label is inserted ? 10 A B +---------+ | \ | | \ | | \ | | \10 | 10 100 | \ | | \ | | \ | | \| +---------+ C 10 D 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) [Anil] : This Could be explicitly specified :) [Bruno2] Indeed, how each solution handles independent failure may be indicated. However, if space is limited in the draft, this is probably not the most important metric (IMHO) has this situation should rarely happen (assuming SRLG are known and the solution protects from SRLG) 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
