Hi Rob, Thanks for your review and your comments. Please check inline below for responses.
We will include these changes in the next update of the document. On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker < nore...@ietf.org> wrote: > 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. > KT> How about if we added the following sentence in the abstract and the introduction? Note that this document doesn't define SR Policy - that comes from RFC8402. SR Policy is an ordered list of segments (i.e. instructions) that represent a source-routed policy. > > 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"? > KT> Ack. > > 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. > KT> Yes, that is correct. The introduction does say that RFC8402 introduces the SR Policy construct (para 2) and that this document details it (para 4). > > 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). > KT> The motivation for the current text is that preference is the primary parameter (we can clarify this in the text) in determining the order of selection of active candidate path. The other parameters are coming from the identifiers of the candidate path and are hence called tie-breakers in the event of having the same preference (for any reason whatsoever). > > 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? > KT> These are only relevant/applicable for SR-MPLS. We can do - s/label/SR-MPLS label - to make this more explicit. Thanks, Ketan > > Regards, > Rob > > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
