Hi Bruno,
Understood , Thanks a lot.
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
From: rtgwg [mailto:[email protected]] On Behalf Of
[email protected]
Sent: 02 April 2015 21:06
To: [email protected]
Subject: FW: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
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]<mailto:[email protected]>; Alia Atlas;
Robert Kebler;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[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]<mailto:[email protected]>; Alia Atlas;
Robert Kebler;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>;
[email protected]<mailto:[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
