Re: [OSPF] 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.

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