Subject: [Lsr] Deborah Brungard's Discuss on draft-ietf-ospf-te-link-attr-reuse-14: (with DISCUSS and COMMENT)

From: Deborah Brungard via Datatracker <[email-masked]>
Date: Thu, 11 Jun 2020 05:35:43 -0700

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.