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

From: Spencer Dawkins <[email-masked]>
Date: Wed, 13 Dec 2017 20:33:26 -0800

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.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 20 Dec 2017 23:43:52 +0000

Spencer -

Thanx for the review.
V14 has been published and it attempts to address the Security concerns raised by you and others.
Look forward to your feedback.

Inline.

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Wednesday, December 13, 2017 8:33 PM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: Spencer Dawkins' No Objection on draft-ietf-spring-segment-
> routing-13: (with COMMENT)
> 
> 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.)
> 
> 
> 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.
 [Les:] Clarification that new congestion avoidance requirements are not introduced by SR has been added to the draft. The use of techniques (such as RFC 8084) may be applicable and this is also mentioned.

   Les

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 20 Dec 2017 23:20:30 -0600

Hi, Les,

On Wed, Dec 20, 2017 at 5:43 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> Look forward to your feedback.

Looks exactly the way I hoped it would. Thanks much!

Spencer

> email
>  [Les:] Clarification that new congestion avoidance requirements are not
> introduced by SR has been added to the draft. The use of techniques (such
> as RFC 8084) may be applicable and this is also mentioned.
>
>    Les
>
>