Micro-loop Prevention by Introducing a Local Convergence Delay
draft-ietf-rtgwg-uloop-delay-09

[Ballot comment]
(Oops, sorry, I entered the bit about addressing my comments for the wrong draft. The following comments still apply.)

- General: Do I undertand correctly that this is a black-box implementation detail? I note that section 4 explicitly says that it is a local-only feature that does not require interoperability. If so, then standards track seems inappropriate. BCP or informational seems to make more sense. Since there are recommendations here, I think BCP is the right choice.  (I note Adam made a similar comment.)

-11: Do you expect this section to stay in the RFC? It is likely to become outdated rather quickly.

Editorial Comments:

- General: Please number the tables.

- sections 2 and 3 and their child sections have quite a few grammar errors. Please proofread it again. I mention a few specifics below, but doubt I caught everything.

- 2, first paragraph: " That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free."
I can't parse that sentence. Is it a run-on sentence, or are there missing words?
-- S / "can be work" / "can work"

-3: " may cause high damages for a network."
I suggest " may cause significant network damage".

-4, last paragraph: "This benefit comes at the expense of eliminating transient forwarding loops involving the local router. "
How is that an "expense"? Isn't it the whole point?

-5.3, first paragraph and paragraph before figure 4:
The MUST is stated twice. Please avoid redundant normative statements. Even if they agree now, they can cause maintenance issues down the road.

[Ballot comment]
(Oops, sorry, I entered the bit about addressing my comments for the wrong draft.)

- General: Do I undertand correctly that this is a black-box implementation detail? I note that section 4 explicitly says that it is a local-only feature that does not require interoperability. If so, then standards track seems inappropriate. BCP or informational seems to make more sense. Since there are recommendations here, I think BCP is the right choice.  (I note Adam made a similar comment.)

-11: Do you expect this section to stay in the RFC? It is likely to become outdated rather quickly.

Editorial Comments:

- General: Please number the tables.

- sections 2 and 3 and their child sections have quite a few grammar errors. Please proofread it again. I mention a few specifics below, but doubt I caught everything.

- 2, first paragraph: " That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free."
I can't parse that sentence. Is it a run-on sentence, or are there missing words?
-- S / "can be work" / "can work"

-3: " may cause high damages for a network."
I suggest " may cause significant network damage".

-4, last paragraph: "This benefit comes at the expense of eliminating transient forwarding loops involving the local router. "
How is that an "expense"? Isn't it the whole point?

-5.3, first paragraph and paragraph before figure 4:
The MUST is stated twice. Please avoid redundant normative statements. Even if they agree now, they can cause maintenance issues down the road.

[Ballot comment]
Substantive Comments:

- General: Do I undertand correctly that this is a black-box implementation detail? I note that section 4 explicitly says that it is a local-only feature that does not require interoperability. If so, then standards track seems inappropriate. BCP or informational seems to make more sense. Since there are recommendations here, I think BCP is the right choice.  (I note Adam made a similar comment.)

-11: Do you expect this section to stay in the RFC? It is likely to become outdated rather quickly.

Editorial Comments:

- General: Please number the tables.

- sections 2 and 3 and their child sections have quite a few grammar errors. Please proofread it again. I mention a few specifics below, but doubt I caught everything.

- 2, first paragraph: " That means that all non-D neighbors of S on the topology will send to S any traffic destined to D if a neighbor did not, then that neighbor would be loop-free."
I can't parse that sentence. Is it a run-on sentence, or are there missing words?
-- S / "can be work" / "can work"

-3: " may cause high damages for a network."
I suggest " may cause significant network damage".

-4, last paragraph: "This benefit comes at the expense of eliminating transient forwarding loops involving the local router. "
How is that an "expense"? Isn't it the whole point?

-5.3, first paragraph and paragraph before figure 4:
The MUST is stated twice. Please avoid redundant normative statements. Even if they agree now, they can cause maintenance issues down the road.

[Ballot comment]
Line 115
  Consider the case in Figure 1 where S does not have an LFA to protect
  its traffic to D.  That means that all non-D neighbors of S on the
You need to define LFA.


Line 118
  topology will send to S any traffic destined to D if a neighbor did
  not, then that neighbor would be loop-free.  Regardless of the
  advanced fast-reroute (FRR) technique used, when S converges to the
This is not a grammatical sentence.


Line 132
        S ------ B
            1
        Figure 1
What do the numbers in this box mean? I assume they are route metrics, but you need to say so.


Line 136
  When S-D fails, a transient forwarding loop may appear between S and
  B if S updates its forwarding entry to D before B.
Something seems to have gone badly wrong with this paragraph. Are these lines supposed to be in the previous paragraph.


Line 326
      unstable.  As an example, [I-D.ietf-rtgwg-backoff-algo] defines a
      standard SPF delay algorithm.
You need to define SPF here.


Line 338
  1.  The Up/Down event is notified to the IGP.
Usually, one would say that the IGP is notified of...


Line 552
          S

            Figure 7
Is this the same as the previous figure with T running CEAB?

[Ballot comment]
Section 1.  Introduction:
"That means that all non-D neighbors of S on the
  topology will send to S any traffic destined to D if a neighbor did
  not, then that neighbor would be loop-free."
-- I was unable to parse the above. I may just be overtired, but it feels like there are some missing words.


Nits:
" When S-D fails, a transient forwarding loop may appear between S and
  B if S updates its forwarding entry to D before B."
-- Perhaps "... entry to D before B does." or "... before B updates its forwarding entry"?

Section 2.1.  Fast reroute inefficiency
"On the  router C, the nexthop to D is the tunnel T thanks to the IGP  shortcut."
s/the//

"On C, the tail-end of the TE tunnel (router B) is no more on the shortest-path tree (SPT) to D, ..."
s/is no more on/is no longer on/
(related)
"... so C does not encapsulate anymore the traffic to D..."
s/does not encapsulate anymore/no longer encapsulates/

Section 3.  Overview of the solution
"This ordered convergence, is similar to the ordered FIB ..."
s/,/ (superfluous).

[Ballot comment]
This document doesn't really define any new on-the-wire protocol. Was publication as a BCP rather than a standards track document considered?

The Introduction contains the following text:

  That means that all non-D
  neighbors of S on the topology will send to S any traffic destined to
  D if a neighbor did not, then that neighbor would be loop-free.

I can't parse this sentence. Is there supposed to be a sentence break somewhere in there?

The introduction starts talking about post-failure events (e.g., "when S converges to the new topology") before mentioning a failure of the S-D link. This makes it very hard to follow. Would suggest mentioning the failure being considered before talking about the ensuing events.

Section 4 begins:

  This document defines a two-step convergence initiated by the router
  detecting a failure and advertising the topological changes in the
  IGP.  This introduces a delay between the convergence of the local
  router and the network wide convergence.

This reads backwards to me. With this technique, the network converges first, followed by an introduced delay, followed by router convergence. Right?

Further on in that section:

  This benefit comes at the
  expense of eliminating transient forwarding loops involving the local
  router.

I can't make sense of this. Eliminating transient forwarding loops is a good thing, right? Not an expense?

I agree with Alvaro that the lack of a recommended default for ULOOP_DELAY_DOWN_TIMER is an issue, especially as the values configured in the examples seem to change arbitrarily from 1 second to 2 seconds.

[Ballot discuss]
Section 5.1. (Definitions) refers to a couple of “existing IGP timers”.  I understand the concepts, but can you please reference the IGP documents where these timers are defined?  I quickly checked rfc2328 and couldn’t find a specific place that talked about LSP_GEN_TIMER (or LSA, of course!), or a similar concept.  SPF_DELAY seems to be introduced by I-D.ietf-rtgwg-backoff-algo.  Given that the rest of Section 5. (Specification) is built on these “existing IGP timers”, I think that the references should be Normative.

Note also that the description in Section 5.2. (Current IGP reactions) is described (in 5.3) as the “standard IP convergence” and carries a “MUST” associated with it.  It was mentioned (in 5.1) that the timers in question are “often associated with a damping mechanism”, which is not part of the base IGP specifications.

I’m putting this comment in as a DISCUSS given that understanding the definitions (and having then Normative references) is necessary for the implementation of the mechanism described.  I think it should be easy to resolve by just adding the appropriate references.

[Ballot comment]
(1) Where do the numbers in the “Route computation event time scale” table come from?  Please put a reference or at least some guidance to the origin of the information.  If it's just for informational purposes, then please say so.  BTW, please also put a number on the table.  [I have the same question for the tables in Section 9.]

(2) Section 5.4. (Local delay for link down) specifies that “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.”  When would ULOOP_DELAY_DOWN_TIMER not be applied?  Along the same lines, if there’s no delay mentioned in Step 5 of 5.3, when would the RIB/FIB not be updated immediately?  IOW, why are these “SHOULDs” not “MUSTs”?

(3) What should be the default setting for ULOOP_DELAY_DOWN_TIMER?  Section 9. (Examples) shows a couple of manually configured (?) scenarios, but no guidance is present in the document.  Please include guidance (maybe based on the local network convergence, or even a default that manufacturers can use) in the Deployment Considerations section.

(4) Section 11. (Existing implementations).  Please take a look at RFC7942.


Nits:

s/any traffic destined to D if a neighbor did not/any traffic destined to D; if a neighbor did not

s/can be work/can work

“IGP shortcut feature”: a reference would be nice

[Ballot comment]
Nit in section 9:
You should probably not talk about 'our' solution or mechanism in an RFC:
s/our/this/ or s/our X/the X described in this document/
This appears multiple times in section 9.

[Ballot comment]
Nit in section 9:
You should probably not talk about 'our' solution or mechanism in an RFC:
s/our/this/ or s/our X/the X described in this document/
This appear multiple times in sectio 9.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-rtgwg-uloop-delay-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-10-04):

From: The IESG
To: IETF-Announce
CC: chrisbowers.ietf@gmail.com, rtgwg@ietf.org, rtgwg-chairs@ietf.org, draft-ietf-rtgwg-uloop-delay@ietf.org, akatlas@gmail.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Micro-loop prevention by introducing a local convergence delay) to Proposed Standard


The IESG has received a request from the Routing Area Working Group WG
(rtgwg) to consider the following document: - 'Micro-loop prevention by
introducing a local convergence delay'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2017-10-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document describes a mechanism for link-state routing protocols
  to prevent local transient forwarding loops in case of link failure.
  This mechanism proposes a two-step convergence by introducing a delay
  between the convergence of the node adjacent to the topology change
  and the network wide convergence.

  As this mechanism delays the IGP convergence it may only be used for
  planned maintenance or when fast reroute protects the traffic between
  the link failure time and the IGP convergence.

  The proposed mechanism is limited to the link down event in order to
  keep the mechanism simple.

  Simulations using real network topologies have been performed and
  show that local loops are a significant portion (>50%) of the total
  forwarding loops.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-rtgwg-uloop-delay/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2565/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard is requested as indicated in the title page header.
This is the correct type of RFC since it describes it is useful to have
the particular behavior it describes implemented in a consistent manner
across different implementations. It is also consistent with the
previous decisions to publish as Proposed Standard RFCs related to LFA,
RLFA, and node-protecting LFA.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

Transient forwarding loops can occur among routers using hop-by-hop
forwarding. This document describes a mechanism for link-state routing protocols
to prevent local transient forwarding loops in case of link failure.
This mechanism proposes a two-steps convergence by introducing a
delay between the convergence of the router adjacent to the topology
change and the network wide convergence.

Working Group Summary

The final version of the document has strong consensus in the WG. Input
from the WG was incorporated in the document, which affected both the
scope and substance of the document.

Document Quality
 
  The document is of high quality.
 
  A Routing Area Directorate early review of draft-ietf-rtgwg-uloop-delay-01
  was done by Matthew Bocci.  It noted mainly grammatical problems, as well as a requesting a few
  technical clarifications.  draft-ietf-rtgwg-uloop-delay-03 addressed both the
  grammatical and technical clarifications from the review.
 
  As discussed in the document, the mechanism described has at least three implementation
  and has been deployed in live networks.

Personnel

  Document Shepherd: Chris Bowers
  Responsible Area Director: Alia Atlas

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document was thoroughly reviewed by the document shephard.  Some issues
were found and discussed on the list with the authors and have been addressed.
The Document Shepherd thinks the document is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

The Document Shepherd has no concerns in this respect.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

Not beyond the Routing Area Directorate review, which was already performed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

The Document Shepherd has no concerns in this respect.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

All authors have confirmed that they are only aware of the following disclosures:
https://datatracker.ietf.org/ipr/2565/

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

One IPR disclosure references this document, and it has been disclosed to the
working group by the authors.  There has not been active discussion of the
IPR diclosure.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The final version of the document has strong consensus from the WG.

Early versions of the draft included mechanisms to deal
with both link-down and link-up events.  The mechanism
to deal with the link-up case was later removed from the draft in
an effort to solidify consensus on the mechanism to deal with
the link-down case.

One issue that came up during the WG Last Call was the type of RFC being
requested. Stewart Bryant suggested that the RFC should be informational
since the behavior described is local to the PLR and therefore does not
introduce a requirement for multiple routers to co-operate. However,
several people pointed out or agreed with the observation the document
is not qualitatively different from the LFA, RLFA, and node-protecting
LFA RFCs which were all published as standards track. So publishing this
draft as standards track would be consistent with the decision made on
those drafts. Stewart indicated that this was not a sticking point and
would accept the consensus of the WG.


(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

All ID nits have been addressed as of draft-ietf-rtgwg-uloop-delay-06.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

No additional formal reviews are required based on the document content.

(13) Have all references within this document been identified as
either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

There are no normative references in an unclear state.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

There are no downward normative references.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

The publication of this document will not change the status of any
existing RFCs.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

There are no new IANA registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

No sections of the document are written in a formal language.