Re: [OSPF] Deborah Brungard's Discuss on draft-ietf-ospf-link-overload-13: (with DISCUSS and COMMENT)

[Alia Atlas <[e-mail]>]

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 <[e-mail]> 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.
>
>
>