Acee - From: Acee Lindem (acee) Sent: Thursday, January 04, 2018 6:44 PM To: Les Ginsberg (ginsberg) <[email protected]>; Joel Halpern <[email protected]>; [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11
Hi Les, From: "Les Ginsberg (ginsberg)" <[email protected]<mailto:[email protected]>> Date: Thursday, January 4, 2018 at 9:26 PM To: Acee Lindem <[email protected]<mailto:[email protected]>>, "Joel M. Halpern" <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Cc: OSPF WG List <[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: Genart last call review of draft-ietf-ospf-link-overload-11 > >Minor issues: > > I understand the WG likes using the term "overload" for a link > >being taken > > out of service. I think people will learn what we mean. I do wish > >we had > > not chosen to misuse the words in this fashion. This is much more a > > graceful-link-close indication (or clsoe-pending indication) than > >it is an > > overload indication. > > I agree with this comment but I wasn’t sure we’d reach consensus on a > better alternative. However, after some though and consideration of current > OSPF router terminology, I’d propose we use the term “Pending-Shutdown”. > Does anyone not agree that this is a more appropriate moniker for the TLV > and state? > [Les:] I agree with Joel's comment. The use of the term "overload" is unfortunate. But "pending-shutdown" isn’t appealing to me because - at least in most use cases - you aren't actually going to shutdown the link. What you are going to do is make a link the "link of last resort". This seems a better choice. That is not the use case - you are going to take the link down. It is not going to be the "link of last resort”, it is the currently the “link of last resort” and will imminently be taken down. [Les:] https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11#section-2 <snip> 2. Motivation … 4. Allow the link to be used as last resort link to prevent traffic disruption when alternate paths are not available. <end snip> This is the real value of the protocol extension. If the intention was to take the link out of service the extension would not be worth much as the behavioral difference between (normal metric->max metric->down) vs (normal metric->down) is very small. This is also consistent with my recollection of the service providers motivation when the early versions of isis-reverse-metric were presented. The question was asked “why don’t you simply take the link down?” and the response was “We don’t want to take the link down – we want it to be the link of last resort so that if all else fails we can still use the link to get to the node.” (As an aside, if the idea was to more gracefully redirect traffic away from the link in preparation for taking the link down you would need to use a metric offset as the isis-reverse-metric draft does. Then you could direct traffic away from the link in incremental steps. I don’t mean to suggest this will be a common use case of reverse-metric – but it would at least be useful if the intent was to take the link down in a short while). Les The suggestion from Shraddha that this term was borrowed from IS-IS isn't accurate. "overload" in IS-IS has a very different meaning - it indicates a node either has an incomplete LSDB or (a la RFC 3277<https://datatracker.ietf.org/doc/rfc3277/> )an incomplete forwarding plane. The only use of "link overload" in IS-IS occurs in https://tools.ietf.org/html/draft-ietf-isis-reverse-metric-07#section-3.6 and this was added recently to support the (very useful) TE use case which was defined in https://tools.ietf.org/html/draft-ietf-ospf-link-overload-11 . When this was done the term "link-overload" was cut and pasted from the OSPF draft. I think this should also be changed in the IS-IS draft. Agreed. Thanks, Acee Les > Thanks, > Acee > > > > > > > > _______________________________________________ > OSPF mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
