More specifically, as Deborah pointed out, in RFC 5817 Section 4.1, it says "Specifically, the node where graceful shutdown of a link is desired originates the TE LSA or IS- IS-LSP containing a Link TLV for the link under graceful shutdown with the Traffic Engineering metric set to 0xffffffff, 0 as unreserved bandwidth. "
and draft-ietf-ospf-link-overload-14 conflicts with that by using 0xfffffffe instead. Regards, Alia On Thu, Jan 25, 2018 at 10:26 AM, Alia Atlas <akat...@gmail.com> wrote: > 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> 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
