Hi John, Thanks for your review and please check inline below for responses.
On Wed, Feb 16, 2022 at 10:29 PM John Scudder via Datatracker < nore...@ietf.org> wrote: > John Scudder has entered the following ballot position for > draft-ietf-spring-segment-routing-policy-17: 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/blog/handling-iesg-ballot-positions/ > for more information about how to handle 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-policy/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I’ve done an initial review of this document and have several concerns I’d > like > to discuss. I apologize for not also providing a full review as comments in > this ballot, I judged it more important to begin the discussion about these > points timely, than to provide all comments in a single message. > > 1. The shepherd writeup indicates that “Standard Track is requested and > indicated in the title page header. This is appropriate for a > specification of > packet steering into an SR policy needing interoperability between the > ingress/source of the policy instantiation and the egress/destination of > the > policy termination.” > > I realize it’s unusual to ask to discuss a shepherd writeup rather than the > spec itself, but I think this one rises to the level. My concern is that > this > description (needing interoperability between the ingress and the egress) > doesn’t comport with my understanding of the Segment Routing architecture. > Surely, one of the key value propositions of SR is that it’s stateless > everywhere other than the headend? Indeed, that’s stated in the abstract. > SR > doesn’t require the egress to even understand that it IS an egress of a SR > Policy, it just does what the headers tell it to, right? > > If that's so, then the rationale given for the requested track must be > wrong. > :-( And that in turn leads me to ask, whether the track really is right. It > seems to me that in most respects this is more an Informational document > than a > standards track one. That’s not a value judgement in any respect, just a > statement of fact — for the most part, it doesn’t seem as though the > information found in this document is needed in order to interoperate with > another system. (Section 8.8 is an exception, I discuss that separately.) > > Anyway, not to get too far ahead of myself, let’s start by working on this > question: is the shepherd writeup correct in saying that interoperability > between headend and tailend is required? If so, can someone please > characterize > the nature of that interoperability, and put it in the context of SR’s > stateless nature? > KT> I see that Jim (doc shepherd) has clarified. The document aims to standardize the SR Policy constructs and related behaviors. It provides the basis then for protocol extensions (e.g. PCEP and BGP) and the YANG model to follow by a normative reference to it. > > 2. It seems to me an unusual practice for this document to be defining > semantics and even reserving values in a field allocated by a different > document, by a different WG. I’m referring here to the so-called > “‘Color-Only’ > bits” discussed in Section 8.8. > > - I would be more comfortable if the work were all done in one place, to > the > extent possible. > > - Given the fact this document is reaching in to a registry normally > managed by > IDR, was there any discussion with the IDR group? I don't see any evidence > of a > courtesy notification of the last call when I look at the IDR mailing list > archive. > > I’ve also emailed the IDR list about this in connection with > draft-ietf-idr-segment-routing-te-policy, see > https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/ KT> Thanks. I will work on addressing them as a co-author of that IDR document. > > > Relating this back to my previous question, it’s evident that if this > document > is going to define semantics for the Color Extended Community Flags, then > that > makes it Standards Track because there is an interoperability factor to > take > into account (that's been imported from IDR). A more ideal solution would > be to > take care of that in the IDR document rather than putting it in this > “architecture” document, though. Surely, this kind of detail is > implementation, > not architecture? Indeed, Ketan said in his reply to Matthew Bocci's RTG > review, "Given that this is an architecture document, it describes the > architecture and not really the protocol mechanisms"... but this section > seems > to be an exception to that aspiration. > KT> The resolution of BGP service routes over the underlying forwarding constructs may be seen by some as more of a "system" or "forwarding" aspect than a BGP protocol aspect. This is in the architecture because operators who have deployed SR Policies expected the same consistent resolution behavior across headed routers from different vendors. > > 3. Related to the above, at least one of the references listed as > informational > clearly has to be normative with the document as it stands. > draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for > example its use in §2.4 seems like it may rise to the "normative" level, > §2.5 > almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake > because this document defines semantics for a field that isn’t even > allocated > until and unless draft-ietf-idr-segment-routing-te-policy is published. > KT> It is the other way round. The SPRING document specifies the information model and the constructs of the SR Policy. The IDR document is primarily about signaling of the SR Policy from a controller to the headend using the new SR Policy SAFI (73) - as such it does refer normatively to the SPRING SR Policy. > > 4. In §2.1 you talk about the signaling of symbolic names for candidate > paths. > Although you are careful to say that such symbolic names are only used for > presentation purposes, it seems to me they still could be considered a new > potential source of vulnerability, since a string that has no > sanity-checking > whatsoever applied by the protocol can display literally anything to an > operator viewing it. Shouldn’t this be addressed in your Security > Considerations? (For an example of a related Security Considerations, see > RFC > 9003. It’s probably not the best example, but it’s the one I had at my > fingertips…) > KT> RFC9003 uses UTF-8 while this document uses printable ASCII. As such, I am not aware of security issues around printable ASCII - please do point me to any references. Also note that this document does not specify protocol encodings where some extra verbiage is normally required (e.g. that it is signaled without NULL, handling truncation/overruns, etc.). > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > As noted in my DISCUSS, these comments are unfinished but I thought I’d > give > you what I have. > > 1. I see that Cullen Jennings referred to this in his ART review, but I’d > like > to talk about it a little more: why have you chosen to restrict symbolic > names > to ASCII? UTF-8 is the more usual choice in this context; indeed > implementations may have to go to extra effort to scrub their input to > insure > that only ASCII is present. BCP 18 doesn’t require you to internationalize > your > strings, of course, it gives you two options, of which you have (sort of, > you > don't have the "US-") followed the latter: > > This document does not mandate a policy on name internationalization, > but requires that all protocols describe whether names are > internationalized or US-ASCII. > > But in 2022 the choice to restrict symbolic names to ASCII seems unusual > enough > to invite the question. > > If you do stick with ASCII as currently written, might you add text > mandating > that implementations scrub their input to prevent non-ASCII characters from > being accepted? > KT> As discussed in the WG, we are sticking to printable ASCII. When the encoding is specified to be printable ASCII, it is expected that implementations valid that. Thanks, Ketan
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
