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
