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

[Pushpasis Sarkar <[e-mail]>]

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) <[e-mail]> wrote:

> Hi Pushpasis, Shraddha, et al,
>
> From: Pushpasis Sarkar <[e-mail]>
> Date: Monday, January 8, 2018 at 12:22 PM
> To: Bruno Decraene <[e-mail]>
> Cc: Shraddha Hegde <[e-mail]>, Acee Lindem <[e-mail]>,
> "Les Ginsberg (ginsberg)" <[e-mail]>, "Ketan Talaulikar
> (ketant)" <[e-mail]>, "Joel M. Halpern" <[e-mail]>, "
> [e-mail]" <[e-mail]>, OSPF WG List <[e-mail]>, "
> [e-mail]" <[e-mail]>, "draft-ietf-ospf-link-
> [e-mail]" <[e-mail]>
> Subject: Re: Genart last call review of draft-ietf-ospf-link-overload-11
> Resent-From: <[e-mail]>
> Resent-To: Shraddha Hegde <[e-mail]>, Pushpasis Sarkar <
> [e-mail]>, Hannes Gredler <[e-mail]>, <
> [e-mail]>, Luay Jalil <[e-mail]>, Acee Lindem <
> [e-mail]>, <[e-mail]>, Alvaro Retana <[e-mail]>,
> Deborah Brungard <[e-mail]>, Alia Atlas <[e-mail]>, Acee
> Lindem <[e-mail]>
> 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, <[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]" <
>> [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]" <
>> [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/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
>>
>> > [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.
>>
>>
>