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, 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:
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).
So there could be a loop.
So I still feel there is a tradeoff.
Thanks & Regards
Anil S N
"Be liberal in what you accept, and conservative in what you send" - Jon Postel
From: [email protected] [mailto:[email protected]]
Sent: 02 April 2015 15:43
To: Chris Bowers
Cc: [email protected]; Anil Kumar S N (VRP Network BL); Alia Atlas;
Robert Kebler; [email protected]; [email protected];
[email protected]; [email protected]; [email protected]
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Chris,
Please see inline. [Bruno]
From: Chris Bowers [mailto:[email protected]]
Sent: Wednesday, April 01, 2015 6:43 PM
To: DECRAENE Bruno IMT/OLN; Anil Kumar S N (VRP Network BL); 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]>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Bruno,
Here is proposed text to address your comments. Tell me if this works.
With respect to the sentence: "The trade-off of looping traffic to improve
coverage is still made." I had assumed that Anil was referring to the scenario
where an SRLG produces correlated link failures such that two nodes have
different opinions about what the "new" topology is.
[Bruno] On my side, I had assumed that it was related to the "downstream"
condition of (R)LFA.
I haven't seen a specific topology that will produce looping for TI-LFA, but I
also haven't seen a proof that TI-LFA avoids this type of looping.
[Bruno] A priori, I see 2 aspects
- At least in theory, TI-LFA should be able to get 100% coverage for any
considered planned failure (link, node, SRLG, any arbitrary set of "single
link" failures). Hence I don't think there is a need to "improve coverage", not
to mention "trade-off looping traffic"
- Any FRR solution assumes a specific failure that it wants to protect from. In
reality, the failure may be more extensive than planned. A question is what
happens in this case. e.g. traffic is dropped, traffic may be FRR multiple time
(by multiple PLR) to provide "de facto protection" in the good cases at the
risk of creating loops in the bad cases, traffic may be FRR multiple time with
no risk of loops (a priori though some in-band knowledge of the previous
failure). Eventually, one may further distinguish the path from the PLR to the
"Merge point" (first Q node) and the path from the "Merge point" to the
destination.
Perhaps Anil has some insight into this topic since he proposed the text in
question. For the moment, I have removed that sentence until we get
clarification.
[Bruno] ok, thanks.
<t hangText="TI-LFA: ">Topology Independent Loop-free
Alternate Fast Re-route (TI-LFA) <xref
target="I-D.francois-spring-segment-routing-ti-lfa"/> aims to
provide link and node protection of node and adjacency
segments within the Segment Routing (SR) framework. It
guarantees complete coverage. The TI-LFA computation for
link-protection is fairly straightforward, while the
computation for node-protection is more complex. For
link-protection with symmetric link costs, TI-LFA can provide
complete coverage using an MPLS label stack with two labels.
[Bruno] I would propose
OLD: using an MPLS label stack with two labels
NEW: by pushing up to two additional labels
Motivation:
- it's not _always_ 2 labels (could be 0 or 1)
- these are _additional_ labels, in addition to the size of the received stacks
(or more importantly, "generated" stack for PE. pushing 2 labels looks
relatively easy for a PLR but if the PLR is a L3 VPN PE using entropy label, it
may have to push up tp of 6 labels (TI-LFA (2), remote PE, EL (2), VPN)
For node protection on arbitrary topologies, the label stack
size can grow significantly based on repair path. Note that
TI-LFA requires shortest path forwarding based on SR
Node-SIDs, as opposed to LDP labels, in order to construct
label stacks for backups paths without relying on a large
number of targeted LDP sessions to learn remote FEC-label
bindings. It also requires the use of Adj-SIDs to achieve
100% coverage.
[Bruno] Looks good.
Thanks Chris.
Bruno
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]
Sent: Wednesday, April 01, 2015 3:12 AM
To: Chris Bowers; Anil Kumar S N (VRP Network BL); 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]>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Hi Chris,
Thanks for the addition.
Please see inline some comments. [Bruno]
Thanks,
Regards,
Bruno
From: rtgwg [mailto:[email protected]] On Behalf Of Chris Bowers
Sent: Wednesday, April 01, 2015 3:10 AM
To: Anil Kumar S N (VRP Network BL); 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]>
Subject: RE: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Anil,
Thanks for your input and proposed text. I added the text below (which is a
slightly modified version of your proposed text) to the most recent version
which is being maintained at:
https://github.com/cbowers/draft-ietf-rtgwg-mrt-frr-architecture
Tell me if you are OK with the final sentence that I added as well, or you can
propose some other wording.
Thanks,
Chris
TI-LFA: Topology Independent Loop-free Alternate Fast Re-route
(TI-LFA) [I-D.francois-spring-segment-routing-ti-lfa] aims to
provide link and node protection of node and adjacency segments
within the Segment Routing (SR) framework. It has improved
coverage over LFA and Remote LFA for link and node protection and
also guarantees complete coverage.
[Bruno] The last sentence could probably be shortened by only keeping the last
part. "It guarantees complete coverage"
The trade-off of looping
traffic to improve coverage is still made.
[Bruno] I'm not sure to see what you mean. Contrary to LFA & RLFA, I don't
think TI-LFA makes such tradeoff.
The computation
required is quite high with added complexity.
[Bruno] As in the RLFA description you have made the distinction between link
and node protection, it would be fair to do the same for TI-LFA. (Link
protection computation is much easier)
TI-LFA is supported
only for the MPLS data plane due to the requirement for the PLR to
impose an MPLS label stack on link failure. On certain topologies
the label stack size can grow significantly based on repair path.
[Bruno] I agree for node failure. For link failure, this is more debatable as
compared to RLFA it may require at most 1 additional label. (assuming symmetric
link costs)
Note that TI-LFA requires shortest path forwarding based on SR
Node-SIDs, as opposed to LDP labels, in order to construct label
stacks for backups paths without relying on a large number of
targeted LDP sessions to learn remote FEC-label bindings.
[Bruno] It also requires Adj-SID (in order to provide 100% coverage).
From: Anil Kumar S N (VRP Network BL) [mailto:[email protected]]
Sent: Saturday, March 28, 2015 8:10 AM
To: Alia Atlas; Robert Kebler; Chris Bowers;
[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]>
Subject: draft-ietf-rtgwg-mrt-frr-architecture-05.txt
Hi Authors,
In "comparison of IP/LDP FRR Methods" section of the document , I feel
we should add comparison with TI-LFA
(draft-francois-spring-segment-routing-ti-lfa-01) where TI-LFA approach
achieves guaranteed coverage against link or node failure, in any IGP network,
relying on the flexibility of SR. This will give readers better picture and
enables them with more information so that they can choose MRT if they feel it
suites their requirement better; compared to IT-LFA...
Changes :
1. Introduction :
Other existing or proposed solutions are partial solutions or have
significant issues, as described below.
Summary Comparison of IP/LDP FRR Methods
+---------+-------------+-------------+-----------------------------+
| Method | Coverage | Alternate | Computation (in SPFs) |
| | | Looping? | |
+---------+-------------+-------------+-----------------------------+
| MRT-FRR | 100% | None | less than 3 |
| | Link/Node | | |
| | | | |
| LFA | Partial | Possible | per neighbor |
| | Link/Node | | |
| | | | |
| Remote | Partial | Possible | per neighbor (link) or |
| LFA | Link/Node | | neighbor's neighbor (node) |
| | | | |
| Not-Via | 100% | None | per link and node |
| | Link/Node | | |
| | | | |
| TI-LFA | 100% | Possible | per neighbor (link) or |
| | Link/Node | | neighbor's neighbor (node) |
| | | | |
+---------+-------------+-------------+-----------------------------+
Table 1
TI-LFA: Topology Independent Loop-free Alternate Fast
Re-route (TI-LFA), aimed at providing link and node protection of
node and adjacency segments within the Segment Routing (SR)
framework [draft-francois-spring-segment-routing-ti-lfa-01].
Has improved coverage over LFAs and Remote LFA for link and node
protection and also guarantees complete coverage. The trade-off
of looping traffic to improve coverage is still made.
The computation required is quite high with added complexity.
TI-LFA is supported only MPLS data plane with a requirement to
carry additional MPLS label stack on the link failure; on certain
topologies stack size can grow significantly based repair path.
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.
_________________________________________________________________________________________________________________________
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
