Subject: [spring] Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 15 Feb 2022 04:22:37 -0800

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

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 15 Feb 2022 19:46:50 +0530

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.

> https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/

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.

> Would "written" be better than "instantiated"?

KT> Ack.

> 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).

> 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).

> to be either MPLS or SRv6.  Hence does the first sentence need to be

KT> These are only relevant/applicable for SR-MPLS. We can do -
s/label/SR-MPLS label - to make this more explicit.

Thanks,
Ketan

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 15 Feb 2022 15:35:15 +0000

Hi Ketan,

Please see inline …

From: Ketan Talaulikar <[email-masked]>
Sent: 15 February 2022 14:17
To: Rob Wilton (rwilton) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; SPRING WG <[email-masked]>; [email-masked]
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.

On Tue, Feb 15, 2022 at 5:52 PM Robert Wilton via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Robert Wilton has entered the following ballot position for
draft-ietf-spring-segment-routing-policy-16: No Objection

Hi,

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.

KT> Ack.

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.

E.g.,

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.

4.  Segment 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.

Thanks,
Rob

Thanks,
Ketan

Regards,
Rob

---

From: Ketan Talaulikar <[email-masked]>
Date: Tue, 15 Feb 2022 21:25:58 +0530

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) <[email-masked]>
wrote:

> Hi Ketan,
>
>
>
> Please see inline …
>
>
>
> *From:* Ketan Talaulikar <[email-masked]>
> *Sent:* 15 February 2022 14:17
> *To:* Rob Wilton (rwilton) <[email-masked]>
> *Cc:* The IESG <[email-masked]>;
> [email-masked]; [email-masked];
> SPRING WG <[email-masked]>; [email-masked]
> *Subject:* Re: Robert Wilton's No Objection on
> draft-ietf-spring-segment-routing-policy-16: (with COMMENT)
>
>
>
> Hi Rob,
>
>
>
> 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.

> 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

> 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

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Tue, 15 Feb 2022 16:11:19 +0000

Hi Ketan,

All sounds good.

Thanks,
Rob

Sent: 15 February 2022 15:56

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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

Please see inline …

From: Ketan Talaulikar <[email-masked]<mailto:[email-masked]>>
Sent: 15 February 2022 14:17
To: Rob Wilton (rwilton) <[email-masked]<mailto:[email-masked]>>
Cc: The IESG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: Robert Wilton's No Objection on draft-ietf-spring-segment-routing-policy-16: (with COMMENT)

Hi Rob,

Hi,

Looks good.

KT> Ack.

KT2> We'll work on this.

E.g.,

KT2> Ack

4.  Segment Types

Thanks,
Ketan

Thanks,
Rob

Thanks,
Ketan

Regards,
Rob

---

From: Ketan Talaulikar <[email-masked]>
Date: Wed, 16 Feb 2022 16:56:16 +0530

Thanks Rob and we have just posted an updated version of the document :
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-17

On Tue, Feb 15, 2022 at 9:41 PM Rob Wilton (rwilton) <[email-masked]>
wrote:

> *Sent:* 15 February 2022 15:56