Segment Routing Policy Architecture
draft-ietf-spring-segment-routing-policy-22
Yes
(Martin Vigoureux)
No Objection
Abstain
Note: This ballot was opened for revision 16 and is now closed.
Alvaro Retana (was Discuss) No Objection
Comment
(2022-03-11 for -20)
[Thanks for addressing my DISCUSS!]
Erik Kline No Objection
Comment
(2022-02-10 for -16)
[S1; nit] * The sentence starting with "While" appears to be sentence fragment. perhaps just: ". While" -> ", while" [S2.1; nit] * s/null address/unspecified address/ * s/comprising of/comprising/ (though see UTF-8 comment below) [S2.1, 2.6; comment] * It seems unnecessarily restrictive to require names be in ASCII. How about RFC 5198/UTF-8? If these names are purely for human consumption anyway, I wonder if isn't best to allow the humans to name things in their native language(s)... (I'm not sure if BCP 18 applies here.) [S4; question] * For each of the uses of "IPv4 Prefix" and "IPv6 Global Prefix" should there be an additional "Unicast" qualifier before "Prefix"? If multicast prefixes are acceptable or understand (somehow) to be out of scope, then no worries. [S8; nit] * s/of where come/of which some/?
Francesca Palombini No Objection
Comment
(2022-02-15 for -16)
Thank you for the work on this document. Many thanks to Cullen Jennings for his review: https://mailarchive.ietf.org/arch/msg/art/beMjluUNRnbT8PWBIQ35pATPVBg/, which I understand will be addressed in the next revision of the draft. Francesca
Murray Kucherawy No Objection
Comment
(2022-02-16 for -17)
Thanks to Cullen Jennings for his ARTART review. I'm hardly an expert on the technologies described here, but most of the SHOULDs I ran into left me wondering why they aren't MUSTs. There's no obvious (to me) implementation guidance present about when one might legitimately do something other than what the SHOULD says. Should Section 2.1 stipulate that symbolic names, if used, should be unique? Thanks for the attention to detail in Section 12.
Robert Wilton No Objection
Comment
(2022-02-15 for -16)
Hi, Thanks for this document, I have a few minor suggestions that may improve the readability of this document. Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy. Possibly the abstract would be more readable if it gave a brief description of what an SR Policy is. Segment Routing (SR) [RFC8402] allows a headend node to steer a packet flow along any path. The headend is a node where the instructions for source routing (i.e. segments) are instantiated into the packet and hence becomes the starting node for a specific segment routing path. Intermediate per-path states are eliminated thanks to source routing. Would "written" be better than "instantiated"? The headend node is said to steer a flow into a Segment Routing Policy (SR Policy). [RFC8402] introduces the SR Policy construct and provides an overview of how it is leveraged for Segment Routing use- cases. I was slightly confuses as where SR policy is actually defined. My interpretation is that the base definition is in RFC8402, but that definition is being explained in more detail in this document. Is that correct? If so, possibly adding a sentence here to make that clear may be helpful. 2.9. Active Candidate Path I found the description of the path selection to be somewhat confusing. I would suggest this might be clearer if it just gave the full list of path selection, rather than treating the preference as a special case and listing the rest of tie-breakers. E.g., 1. Higher value of preference is selected. 2. Higher value of Protocol-Origin is selected. 3. If specified by configuration, prefer the existing installed path. 4. Lower value of originator is selected. 5. Finally, the higher value of discriminator is selected. The paragraphs above this list would need to be changed slightly, but the paragraphs below would then be easier to read/understand (at least to me). 4. Segment Types Based on the desired dataplane, either the MPLS label stack or the SRv6 Segment Routing Header [RFC8754] is built from the Segment-List. A couple of the types, i.e., the IPv4 related E and F, don't obviously appear to be either MPLS or SRv6. Hence does the first sentence need to be expanded to cover these types? Regards, Rob
Roman Danyliw (was Discuss) No Objection
Comment
(2022-03-20 for -21)
Thank you for addressing my DISCUSS and most of my COMMENT feedback.
Zaheduzzaman Sarker No Objection
Comment
(2022-02-16 for -17)
Thanks for the efforts on this specification. This might be due to my lack of expertise on SR policy but it is not clear to me how to resolve policy conflicts where preferences and priority are same for policies. It would be nice if you point me information I am missing as I could not resolve it by reading this specification. This might be that the scenario I am having in mind never occurs.
Éric Vyncke No Objection
Comment
(2022-02-17 for -17)
Thank you for the work put into this document. I am afraid that, due to lack of available time, I only quickly reviewed this document and I will rely on the INT directorate review. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Jim Guichard for the shepherd's write-up including the section about the WG consensus and discussion. Thanks also to Carlos Bernardos for the INT directorate review dated 13th of March. I have also seen that authors are in an email discussion with Carlos and I appreciate that Carlos was acknowledged in the acknowledgment section. See <https://datatracker.ietf.org/doc/review-ietf-spring-segment-routing-policy-16-intdir-telechat-bernardos-2022-02-13/>. I hope that this helps to improve the document, Regards, -éric Generic comment: this document uses the term "headend", which is not used in other SRv6-related documents. Not really important though. ## Abstract Mostly cosmetic, but the abstract would benefit from being more concise and straight to the point. ## Section 2.1 Please use "::" rather than "::0" to respect RFC 5952. Also for section 8.8.1 I also share the concern of other AD for an ASCII-only symbolic name. ## Section 2.3 Why are the values 10, 20, and 30 only RECOMMENDED in a standard track document and are not a MUST ? If this is about distance, then let's be clear and name this value as "distance" or "origin-precedence". ## Section 2.13 Rather than using 1.1.1.1 or 2.2.2.2 please use the documentation addresses for IPv4 / IPv6. Same reasoning for using the example ASN. # NITS Probably a topic beaten to death but isn't "ISIS" spelled "IS-IS" ? Usually, "i.e." is always followed by a ","
John Scudder (was Discuss) Abstain
Comment
(2022-03-22)
Thanks for resolving my discuss concern #4 and working with me on the other three. I'm choosing to abstain because I'm not happy with the outcome of #2 and especially #3; however I won't stand in the way of the document's advancement for these reasons. ---previous discuss, for posterity: 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? 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/ 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. 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. 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…) ---comments: 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?
(Martin Vigoureux; former steering group member) Yes
Yes
(for -16)
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
No Objection
(2022-03-19 for -21)
Thank you for addressing my Discuss (and most of my Comment) points!