Hi Rob, Thanks for your quick response and please check further inline below with KT2.
On Tue, Feb 15, 2022 at 9:05 PM Rob Wilton (rwilton) <rwil...@cisco.com> wrote: > Hi Ketan, > > > > Please see inline … > > > > *From:* Ketan Talaulikar <ketant.i...@gmail.com> > *Sent:* 15 February 2022 14:17 > *To:* Rob Wilton (rwilton) <rwil...@cisco.com> > *Cc:* The IESG <i...@ietf.org>; > draft-ietf-spring-segment-routing-pol...@ietf.org; spring-cha...@ietf.org; > SPRING WG <spring@ietf.org>; james.n.guich...@futurewei.com > *Subject:* Re: Robert Wilton's No Objection on > draft-ietf-spring-segment-routing-policy-16: (with COMMENT) > > > > 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. > > > > Looks good. > > > > > > > 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). > > > > Okay. It would be nice if the text in paragraph 2 and 4 could be more > closely aligned, but I don’t actually see an easy/clean way of doing this. > KT2> We'll work on this. > > > > > > 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). > > > > Okay. It was this paragraph that initially threw me (relative to the > list): > > > > o The preference, being the first tiebreaker, allows an operator to > > influence selection across paths thus allowing provisioning of > > multiple path options, e.g., CP1 is preferred and if it becomes > > invalid then fallback to CP2 and so on. Since preference works > > across protocol sources, it also enables (where necessary) > > selective override of the default Protocol-Origin preference, > > e.g., to prefer a path signaled via BGP SR Policy over what is > > configured. > > > > Perhaps this text shouldn’t refer to preference being a tie-breaker, and > perhaps it would be better to list it before the Protocol-Origin > paragraph? I.e., I couldn’t figure out why something lower in the list > would be able to override the Protocol-Origin, that is higher in the list. > KT2> Ack > > > > > > 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. > > > > Ah, okay. If you make this more explicit then doing it in the individual > types might be useful. Or even more explicit would be to list the types > that are relevant to SR-MPLS and those which are relevant to SRv6. But > I’ll leave this to your discretion. > KT2> We will go with the explicit text for type E & F to align with others. Thanks, Ketan > > > Thanks, > > Rob > > > > > > Thanks, > > Ketan > > > > > Regards, > Rob > > >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
