Hi Acee, LOL.. Might as well be 'link-on-break'.. :)
Anyways graceful-link-shutdown seems to be the most agreed upon. Thanks and regards, -Pushpasis On Tue, Jan 9, 2018 at 9:29 PM, Acee Lindem (acee) <a...@cisco.com> wrote: > Hi Pushpasis, Shraddha, et al, > > From: Pushpasis Sarkar <pushpasis.i...@gmail.com> > Date: Monday, January 8, 2018 at 12:22 PM > To: Bruno Decraene <bruno.decra...@orange.com> > Cc: Shraddha Hegde <shrad...@juniper.net>, Acee Lindem <a...@cisco.com>, > "Les Ginsberg (ginsberg)" <ginsb...@cisco.com>, "Ketan Talaulikar > (ketant)" <ket...@cisco.com>, "Joel M. Halpern" <j...@joelhalpern.com>, " > gen-...@ietf.org" <gen-...@ietf.org>, OSPF WG List <ospf@ietf.org>, " > i...@ietf.org" <i...@ietf.org>, "draft-ietf-ospf-link- > overload....@ietf.org" <draft-ietf-ospf-link-overload....@ietf.org> > Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11 > Resent-From: <alias-boun...@ietf.org> > Resent-To: Shraddha Hegde <shrad...@juniper.net>, Pushpasis Sarkar < > pushpasis.i...@gmail.com>, Hannes Gredler <han...@gredler.at>, < > mnand...@ebay.com>, Luay Jalil <luay.ja...@verizon.com>, Acee Lindem < > a...@cisco.com>, <a...@cisco.com>, Alvaro Retana <aretana.i...@gmail.com>, > Deborah Brungard <db3...@att.com>, Alia Atlas <akat...@gmail.com>, Acee > Lindem <a...@cisco.com> > Resent-Date: Monday, January 8, 2018 at 12:22 PM > > Hi Joel et al, > > +1 for 'graceful-link-shutdown'. > > > I think we are converging on this. I must admit that it is much better > than “link-overload”. Although Les raises a good point that this behavior > could be used for other use cases, subsequent discussions have indicated > that these could be handled differently. > > > Another possibility may be 'link-decommission'.. > > > This implies too much permanence. If you decommission something, you are > more or less retiring It which is not this use case. This is more of giving > the link a rest. Maybe we could use the there term “Link on Leave” or LOL > state ;^). > > Thanks, > Acee > > > Thanks and regards > -Pushpasis > > On Mon, Jan 8, 2018 at 7:09 PM, <bruno.decra...@orange.com> 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:a...@cisco.com <a...@cisco.com>] >> *Sent:* Friday, January 5, 2018 6:50 PM >> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Ketan Talaulikar >> (ketant) <ket...@cisco.com>; Joel Halpern <j...@joelhalpern.com>; >> gen-...@ietf.org >> *Cc:* ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload. >> a...@ietf.org >> *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)" <ginsb...@cisco.com> >> *Date: *Thursday, January 4, 2018 at 11:56 PM >> *To: *"Ketan Talaulikar (ketant)" <ket...@cisco.com>, Acee Lindem < >> a...@cisco.com>, "Joel M. Halpern" <j...@joelhalpern.com>, " >> gen-...@ietf.org" <gen-...@ietf.org> >> *Cc: *OSPF WG List <ospf@ietf.org>, "i...@ietf.org" <i...@ietf.org>, " >> draft-ietf-ospf-link-overload....@ietf.org" < >> draft-ietf-ospf-link-overload....@ietf.org> >> *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) <a...@cisco.com>; Les Ginsberg (ginsberg) < >> ginsb...@cisco.com>; Joel Halpern <j...@joelhalpern.com>; gen-...@ietf.org >> *Cc:* ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload. >> a...@ietf.org >> *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:ospf-boun...@ietf.org <ospf-boun...@ietf.org>] *On >> Behalf Of *Acee Lindem (acee) >> *Sent:* 05 January 2018 08:14 >> *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com>; Joel Halpern < >> j...@joelhalpern.com>; gen-...@ietf.org >> *Cc:* ospf@ietf.org; i...@ietf.org; draft-ietf-ospf-link-overload. >> a...@ietf.org >> *Subject:* Re: [OSPF] Genart last call review of >> draft-ietf-ospf-link-overload-11 >> >> >> >> Hi Les, >> >> >> >> *From: *"Les Ginsberg (ginsberg)" <ginsb...@cisco.com> >> *Date: *Thursday, January 4, 2018 at 9:26 PM >> *To: *Acee Lindem <a...@cisco.com>, "Joel M. Halpern" < >> j...@joelhalpern.com>, "gen-...@ietf.org" <gen-...@ietf.org> >> *Cc: *OSPF WG List <ospf@ietf.org>, "i...@ietf.org" <i...@ietf.org>, " >> draft-ietf-ospf-link-overload....@ietf.org" < >> 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://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/dr >> aft-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 >> >> > OSPF@ietf.org >> >> > 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. >> >> >
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
