Deborah Brungard has entered the following ballot position for draft-ietf-ospf-te-link-attr-reuse-14: 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-te-link-attr-reuse/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This should be simple to resolve - the use of the SR-TE term is out-of-alignment with other drafts, spring and idr. Suggest: Segment Routing Traffic Engineering/s/Segment Routing Policy and SRTE/s/SR Policy. And this should be obvious, the abstract justifies the need for this document because routers assume RSVP-TE on a link based on an OSPF advertisement. But that's an implementation shortcut and needs to be noted as that. Sure, it was ok when everything was RSVP/RSVP-TE. But let's not make it a "BCP". This needs to be corrected to say "Some implementations..". I would suggest aligning this abstract with the ISIS draft and move this paragraph to later in the document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As Warren noted, the draft is very difficult to read. The specific problem (to me) is the ability to support advertisement of application specific values? And, to say, new applications MUST NOT make use of RSVP-TE LSA advertisements which is causing confusion for (some) implementations. It would help to make this more clearer and not muddy with implementation woes. I don't see any discussion on the dark bandwidth problem or the security problems identified in RFC8426? It would be helpful if the draft pointed to the RFC8426 solution. _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
