Amazing timing, I have two documents in the IESG telechat today for which I am the primary editor and another for which I am the document shepherd (the one in the subject line). Please be patient.
Thanks Acee From: Alia Atlas <akat...@gmail.com> Date: Thursday, January 25, 2018 at 10:26 AM To: Deborah Brungard <db3...@att.com> Cc: The IESG <i...@ietf.org>, OSPF WG List <ospf@ietf.org>, "draft-ietf-ospf-link-overl...@ietf.org" <draft-ietf-ospf-link-overl...@ietf.org>, Acee Lindem <a...@cisco.com>, "ospf-cha...@ietf.org" <ospf-cha...@ietf.org>, "TEAS WG (t...@ietf.org)" <t...@ietf.org> Subject: Re: Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT) Could a look at the changes in draft-ietf-ospf-link-overload-14 happen? Also, it would be good to get feedback from TEAS on this document and any concerns. Thanks, Alia On Tue, Jan 23, 2018 at 12:01 PM, Deborah Brungard <db3...@att.com<mailto:db3...@att.com>> wrote: Deborah Brungard has entered the following ballot position for draft-ietf-ospf-link-overload-13: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ospf-link-overload/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This document is defining a MAX-TE-METRIC of 0xfffffffe. But RFC5817 defined 0xffffffff to be used for graceful shutdown. I noted an email exchange between the author and Acee on this where Acee raised the question why RFC5817's value was not used. Shraddha replied "We can if we have the Working Group Consensus". There was no further discussion. This document was not shared with teas which is responsible for TE (or ccamp which was originally responsible for RFC5817). Either this value needs to be changed to RFC5817's value or this TE metric needs to be removed from this document until agreement with TEAS. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I found the title of section 7.2 "Controller Based Traffic Engineering Deployments" confusing as it only is describing a controller controlling a path. It is not "TE" in the IETF sense e.g. TE signaling. It would be much less confusing if say "Controller Based Deployments" and "satisfying the traffic engineering constraints"/s/"satisfying the constraints". Especially as for TE, procedures already do exist. I noted in the introduction you did reference RFC5817 MPLS Graceful Shutdown on the procedures when doing a graceful shutdown of a TE link.
_______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf
