[spring] Spencer Dawkins' No Objection on draft-ietf-spring-segment-routing-13: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-spring-segment-routing-13: No Objection

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-spring-segment-routing/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm not surprised to see additional security alarm bells going off for the SRv6
variant - this is quite similar to the additional congestion awareness alarm
bells that went off when we were evaluating MPLS (which is usually pretty well
contained) over UDP (which can get around the Internet with a lot less effort
than MPLS without UDP). That's an opportunity to rethink the impact of changes
to an underlying technology.

Which leads me to the point I should be making as a TSV AD. I'm not seeing any
obvious mechanism that would tell you that you've managed to set up your
segment routing so that some paths will undergo persistent congestion. You
might consider whether it's worth recommending that people doing segment
routing take a look at https://datatracker.ietf.org/doc/rfc8084/ and decide how
much, if anything, would be useful to say about that.
https://tools.ietf.org/html/rfc7510#section-5 is an early example of the kind
of thing I'm talking about.