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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- As Warren noted, the draft is very difficult to read. This doesn't parse: "As soon as the router that is an RSVP-TE head-end sees the link attribute being advertised for that link, it assumes RSVP-TE is enabled on that link, even though it is not. If such RSVP-TE head-end router tries to setup an RSVP-TE path via that link it will result in the path setup failure." It seems there is the assumption the link is congruent with the signaling (maybe some implementations do but not per spec). Maybe this is needed by some implementations, but the draft seems to make it a "general problem". But I don't think this is really the intention of the draft - even section 4.1 says duplication would be only in "rare cases". 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
