Robert Wilton has entered the following ballot position for draft-ietf-spring-segment-routing-policy-16: 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/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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
