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 protected]] > Sent: Wednesday, December 13, 2017 8:33 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; [email protected]; [email protected] > Subject: Spencer Dawkins' No Objection on draft-ietf-spring-segment- > routing-13: (with COMMENT) > > 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. > [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 _______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
