On Wed, Oct 11, 2017 at 5:07 AM, <[email protected]> wrote:
Stephane: Hi! ... > ---------------------------------------------------------------------- > 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. > > [SLI] ISIS does have the minimumLSPGenerationInterval defined in the ISO > specification. I will add it. For OSPF, I do not see the equivalent in the > base spec. I will check with Acee if he knows some references or if it's > purely local features that have been implemented. > This is the definition from 10589: minimumLSPGenerationInterval – This is the minimum time interval between generation of Link State PDUs. A source Intermediate system shall wait at least this long before re-generating one of its own Link State PDUs. That is not the same as LSP_GEN_TIMER. I get the impression that the only place where that documents it might be I-D.ietf-rtgwg-backoff-algo. > 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. > > [SLI] I agree with your point. I think that the "standard" word is badly > used it and "regular" may be more appropriate. > The behavior defined in 5.2 cannot be defined as a standard, as it clearly > depends on the implementation and additional timers may be involved. > My proposal is to: > - change the word "standard" to "regular" in section 5.3 > - change the title of Section 5.2 to "Regular IGP reaction" to accommodate > the change in 5.3 > - In 5.2, modify slightly the text as follows: > " Upon a change of the status of an adjacency/link, the regular IGP > convergence > behavior of the router advertising the event involves the following > main steps: " > > It's important to keep the "MUST" in section 5.3, as applying the delay > timer to complex outages is dangerous and may lead to side effects. > Yes, the changes are fine. The MUST being there is needed (I agree) -- that is what makes the reference needed to be Normative. > > > > > 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. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > ... > (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? > [SLI] The text states " If the > condition of a single local link-down event has been met ". The > "otherwise" is linked to this statement. This means that the FIB/RIB SHOULD > be updated immediately when this condition is not met. > Sorry, that question was for the first "SHOULD": In "update of the RIB and the FIB SHOULD be delayed for ULOOP_DELAY_DOWN_TIMER msecs", when would you not delay? Why is that not a "MUST"? > (2)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”? > [SLI] Do you refer to 5.2 (and not 5.3) as there is no Step 5 in 5.3. In > 5.2, the RIB/FIB are updated immediately after the SPF computation. > Yes, 5.2. Right, 5.2 says that the RIB/FIB are updated immediately, but the text in 5.4 only says that it "SHOULD" -- why is that not a "MUST"? Are there cases when it wouldn't? Thanks! Alvaro.
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
