Hi Les, From: "Les Ginsberg (ginsberg)" <ginsb...@cisco.com<mailto:ginsb...@cisco.com>> Date: Thursday, January 4, 2018 at 9:26 PM To: Acee Lindem <a...@cisco.com<mailto:a...@cisco.com>>, "Joel M. Halpern" <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>, "gen-...@ietf.org<mailto:gen-...@ietf.org>" <gen-...@ietf.org<mailto:gen-...@ietf.org>> Cc: OSPF WG List <ospf@ietf.org<mailto:ospf@ietf.org>>, "i...@ietf.org<mailto:i...@ietf.org>" <i...@ietf.org<mailto:i...@ietf.org>>, "draft-ietf-ospf-link-overload....@ietf.org<mailto:draft-ietf-ospf-link-overload....@ietf.org>" <draft-ietf-ospf-link-overload....@ietf.org<mailto:draft-ietf-ospf-link-overload....@ietf.org>> 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. 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 > OSPF@ietf.org<mailto:OSPF@ietf.org> > https://www.ietf.org/mailman/listinfo/ospf
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
