Re: [Gen-art] Genart last call review of draft-ietf-ospf-link-overload-11

[Pushpasis Sarkar <[e-mail]>]

Hi Joel et al,

+1 for 'graceful-link-shutdown'. Another possibility may be
'link-decommission'..

Thanks and regards
-Pushpasis

On Mon, Jan 8, 2018 at 7:09 PM, <[e-mail]> wrote:

>
>
>
>
> *From:* Shraddha Hegde
>
> How about “graceful-link-shutdown” ?
>
>
>
> Looks good to me.
>
> Also, FYI, for BGP sessions, in the GROW WG we used the term “Graceful BGP session shutdown” and named the BGP community “GRACEFUL_SHUTDOWN” so this would align on the terminology.
>
> https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-13
>
>
>
> Best regards,
>
> --Bruno
>
>
>
>
>
> Rgds
>
> Shraddha
>
>
>
>
>
>
>
> *From:* Acee Lindem (acee) [mailto:[e-mail] <[e-mail]>]
> *Sent:* Friday, January 5, 2018 6:50 PM
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Ketan Talaulikar
> (ketant) <[e-mail]>; Joel Halpern <[e-mail]>;
> [e-mail]
> *Cc:* [e-mail]; [e-mail]; draft-ietf-ospf-link-overload.
> [e-mail]
> *Subject:* Re: Genart last call review of draft-ietf-ospf-link-overload-11
>
>
>
> It is not in “maintenance" mode yet as it is still being used. However, it
> is better than “overload”. “pending-maintenance” is a bit long which is why
> I suggested “pending-shutdown” since “shutdown” is term that vendors have
> used for eons to described an interface that is not in service.
>
> Thanks,
>
> Acee
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <[e-mail]>
> *Date: *Thursday, January 4, 2018 at 11:56 PM
> *To: *"Ketan Talaulikar (ketant)" <[e-mail]>, Acee Lindem <
> [e-mail]>, "Joel M. Halpern" <[e-mail]>, "
> [e-mail]" <[e-mail]>
> *Cc: *OSPF WG List <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <draft-ietf-ospf-link-
> [e-mail]>
> *Subject: *RE: Genart last call review of draft-ietf-ospf-link-overload-11
>
>
>
> Ketan –
>
>
>
> “maintenance” I could live with.
>
>
>
> “GIR” seems to not be generic enough.
>
>
>
>    Les
>
>
>
>
>
> *From:* Ketan Talaulikar (ketant)
> *Sent:* Thursday, January 04, 2018 8:09 PM
> *To:* Acee Lindem (acee) <[e-mail]>; Les Ginsberg (ginsberg) <
> [e-mail]>; Joel Halpern <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; draft-ietf-ospf-link-overload.
> [e-mail]
> *Subject:* RE: Genart last call review of draft-ietf-ospf-link-overload-11
>
>
>
> Hello,
>
>
>
> May I suggest something more generic like “Maintenance Mode” or “Graceful
> Insertion/Removal (GIR) Mode” which could be defined so as to cover the
> multiple scenarios in question (e.g. pending shutdown, down for repairs,
> last resort due to poor link quality, etc.).
>
>
>
> Thanks,
>
> Ketan
>
>
>
> *From:* OSPF [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Acee Lindem (acee)
> *Sent:* 05 January 2018 08:14
> *To:* Les Ginsberg (ginsberg) <[e-mail]>; Joel Halpern <
> [e-mail]>; [e-mail]
> *Cc:* [e-mail]; [e-mail]; draft-ietf-ospf-link-overload.
> [e-mail]
> *Subject:* Re: [OSPF] Genart last call review of
> draft-ietf-ospf-link-overload-11
>
>
>
> Hi Les,
>
>
>
> *From: *"Les Ginsberg (ginsberg)" <[e-mail]>
> *Date: *Thursday, January 4, 2018 at 9:26 PM
> *To: *Acee Lindem <[e-mail]>, "Joel M. Halpern" <[e-mail]>,
> "[e-mail]" <[e-mail]>
> *Cc: *OSPF WG List <[e-mail]>, "[e-mail]" <[e-mail]>, "
> [e-mail]" <draft-ietf-ospf-link-
> [e-mail]>
> *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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc3277_&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=769ndBiWrwubwBNccNtOnDuHr1yMD-W10WuEarCDNgI&e=>
> )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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Disis-2Dreverse-2Dmetric-2D07-23section-2D3.6&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=r_8muG61-ePlkCbqf7qIcHUPHGtjWf_JOH1UXH7lp8U&e=>
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dospf-2Dlink-2Doverload-2D11&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=umZHmgXp6i4i0PAyZbsDS0iorBurDZsFIyvaVVXEHb0&e=>
> . 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
>
> > [e-mail]
>
> > https://www.ietf.org/mailman/listinfo/ospf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ospf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=NyjLsr7JA7mvpCJa0YmPdVKcmMXJ31bpbBaNqzCNrng&m=7GM8zN1-Ff2au_agmHAkiNYK2R5Aji-EjpyT8gmgRYU&s=N51dsQzqzgGoBY61VJtqkgGHlrNjgZT_-9g8G_pcOyE&e=>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>