Hi Chris,
Thanks for the review. I'm updating the document to reflect your proposals.
Couple of comments:
- s/"otherwise the standard IP convergence MUST be used."/ "otherwise
the standard IP convergence MUST used". It does not sound good to me but may be
because of an English grammar issue on my side. Could you confirm the change ?
- Regarding your main comment on section 1 and 2.1, I do not agree
about your statement on RSVP-FRR. First there are multiple deployment styles of
RSVP FRR:
o LDP tunneling
o RSVP with no strict ERO
o RSVP with CSPF at head end (strict ERO)
Your statement is true only for the third case where an RSVP tunnel between S
and D exists with its path computed by S => no uloop in that case for sure. But
as soon as you rely on distributed convergence, you will fall into a loop even
if you use RSVP-FRR. I will precise in the text that we are in an LDP scenario
for example. Here is a text proposal:
"In the Figure 2, we consider an IP/LDP routed network. An RSVP-TE tunnel T,
provisioned on C and terminating on B, is used to protect the traffic against
C-B link failure (IGP shortcut is activated on C)."
"The issue described here is completely independent of the fast-reroute
mechanism involved (TE FRR, LFA/rLFA, MRT ...) when the primary path is an hop
by hop defined path."
For the LFA case, yes, there are some cases where there is no loop, but it is
topology dependent. I'm not sure that we need to give such precision as if the
LFA is on the postconvergence path, this means that the postconvergence is
loopfree, so there will be no local microloop in any case.
- Regarding your comment on section 4.4, here is my new text proposal
to fit your comment:
"Upon an adjacency/link down event, this document introduces a change
in step 5 (<xref target="description-current"/>) in order to delay the local
convergence compared to the
network wide convergence. The new step 5 is described below:"
5. Upon SPF_DELAY timer expiration, the SPF is computed. If the
condition of a single local link-down event has been met and if the new
convergence did not trigger a stop of the ULOOP_DELAY_DOWN_TIMER , then an
update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER
msecs. Otherwise, the RIB and FIB SHOULD be updated immediately.
If a new convergence occurs while ULOOP_DELAY_DOWN_TIMER is running,
ULOOP_DELAY_DOWN_TIMER is stopped and the RIB/FIB SHOULD be updated as part of
the new convergence event."
Brgds,
Stephane
From: Chris Bowers [mailto:[email protected]]
Sent: Tuesday, August 08, 2017 03:01
To: LITKOWSKI Stephane OBS/OINIS; [email protected]
Cc: [email protected]
Subject: shepherd feedback and idnits on draft-ietf-rtgwg-uloop-delay-05.txt
Authors,
I'm in the process of doing the Shepherd write-up for
draft-ietf-rtgwg-uloop-delay-05.txt.
In reading the latest version of the document, I wrote down some feedback.
A diff can be found at:
https://github.com/cbowers/outgoing-feedback-on-ietf-drafts-2017/commit/70f3fc5b2c89dc65f813b992921d685049a4a4bd
http://bit.ly/2vJqoq2
Most of the feedback is related to clarifying language and typos. However there
are few comments that I think are more substantive so I am
reproducing them below since they should probably discussed on the list.
===========
[CB] I find the examples presented in section 1 and section 2.1 to
be confusing. The conclusion drawn in the last paragraph of section
2.1 does not seem to follow from these examples.
Section 1 (figure 1) shows an example of micro-loops occuring when shortest
path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR.
Section 2.1 (figure 2) also shows an example of micro-loops occuring when
shortest path forwarding is used and the metrics are such that LFA and rLFA
produce no backup paths from the PLR. However, in this example,
a one-hop RSVP tunnel is provisioned to provide link protection for one of
the links. However, even with this one-hop RSVP tunnel the example
demonstrates that micro-loops can occur.
The last paragraph asserts that:
"The issue described here is completely independent of the fast-
reroute mechanism involved (TE FRR, LFA/rLFA, MRT ...)."
There are two problems with this assertion.
Problem 1) I don't think that the assertion is correct for RSVP TE-FRR in
general.
For classical RSVP TE-FRR, there would be an RSVP-signaled LSP from S to D.
Before the failure of the link C-B, this LSP would follow the path
S-E-C-B-A-D. Immediately after the failure of link C-B, the LSP would
follow the path S-E-C-E-A-B-A-D using the bypass LSP at C. Once S is
made aware of the failure. S will resignal the LSP to take the path S-E-A-D.
At no time would looping occur.
I assume that it wasn't the initial intention to claim that RSVP TE-FRR suffers
from
micro-looping, but the text currently reads that way. The assertion of the last
paragraph should be qualified to talk about how microloops will still affect
traffic
forwarded hop-by-hop over links protected with one-hop RSVP-signaled LSPs.
Problem 2) The assertion may be correct for LFA/rLFA and MRT, but it has not
been demonstrated with the examples provided. I think it may instead be
the case that the assertion nay not be true for local LFA in some circumstances.
In particular, if traffic to a given destination can be protected for a given
failure by the PLR using a local LFA that is the same as the post convergence
path, then that traffic will not be subject to microloops.
Perhaps the overall intention of the example in figure 2 using
links protected with one-hop RSVP-signaled LSPs was to say that no
matter how much flexibility you give yourself in building a backup path
from the PLR, if the PLR stops using the backup path before other routers
stop sending traffic to the PLR, then you can still have forwarding loops.
However, I think the complexity and detail of the example using one-hop
RSVP-signaled LSPs ends up confusing the matter.
The text should either work more systematically through examples to
substantiate the assertion, or the assertion should be scaled back.
Regardless, the assertion needs to be clarified with respect to RSVP-TE FRR.
======
Section 4.4
[CB] It would be good to write out exactly what the modified version of step 5
looks like so there is no confusion. Something like:
5. Upon SPF_DELAY timer expiration, the SPF is computed. If the condition
of a single local link-down event have been met, then an update of the
RIB and the FIB is scheduled in ULOOP_DELAY_DOWN_TIMER msecs. Otherwise,
the RIB and FIB update is scheduled immediately.
=========
Such a delay
SHOULD only be introduced if all the LSDB modifications processed are
only reporting a single local link down event (Section 4.3). If a
subsequent LSP/LSA is received/updated and a new SPF computation is
triggered before the expiration of ULOOP_DELAY_DOWN_TIMER, then the
same evaluation SHOULD be performed.
=========
[CB] What should one do if the evaluation of a subsequent LSP/LSA fails
at this point? Do you go ahead and update the FIB with the forwarding
entries that you were waiting to do? Or do you do a new SPF with the
new information? Or is it up to the implementation?
=========
I also ran the idnits check which show the following issues.
Can you get rid of the unused references and move RFC 5715 from Normative to
informational so that idnits will run clean?
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-rtgwg-uloop-delay-05.txt
Thanks,
Chris
_________________________________________________________________________________________________________________________
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
