Hi Ketan, All sounds good.
Thanks, Rob From: Ketan Talaulikar <ketant.i...@gmail.com> Sent: 15 February 2022 15:56 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 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<mailto:rwil...@cisco.com>> wrote: Hi Ketan, Please see inline … From: Ketan Talaulikar <ketant.i...@gmail.com<mailto:ketant.i...@gmail.com>> Sent: 15 February 2022 14:17 To: Rob Wilton (rwilton) <rwil...@cisco.com<mailto:rwil...@cisco.com>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-spring-segment-routing-pol...@ietf.org<mailto:draft-ietf-spring-segment-routing-pol...@ietf.org>; spring-cha...@ietf.org<mailto:spring-cha...@ietf.org>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; james.n.guich...@futurewei.com<mailto: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<mailto: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
