> >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. 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. 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
