Re: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-segment-routing-policy-17: (with DISCUSS and COMMENT)

[Ketan Talaulikar <[e-mail]>]

Hi Ben,

Thanks for your time and your response. Please check inline below with KT3.

We've also posted an update with changes to address your comments:
https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-21


On Sun, Mar 20, 2022 at 12:54 AM Benjamin Kaduk <[e-mail]> wrote:

> Hi Ketan,
>
> My apologies for the slow reply, there are quite a few things for me to
> wrap up before my term as AD ends.  As you put it in your graceful note
> off-list, we are very close.
>
> More inline...
>
> On Sat, Mar 05, 2022 at 04:06:53PM +0530, Ketan Talaulikar wrote:
> > Hi Ben,
> >
> > Thanks for your response and please check inline below with KT2
> >
> > We've also just posted another update to address some of your comments
> and
> > those from other ADs.
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-19
> >
> > On Fri, Feb 25, 2022 at 7:32 AM Benjamin Kaduk <[e-mail]> wrote:
> >
> > > Hi Ketan,
> > >
> > > Thanks for the replies here and the updates in the -18.
> > > I think there are still some open topics, though; more inline.
> > >
> > > On Thu, Feb 17, 2022 at 09:21:04PM +0530, Ketan Talaulikar wrote:
> > > > Hi Ben,
> > > >
> > > > Thanks for your detailed review and your comments/inputs. Please
> check
> > > > inline for responses.
> > > >
> > > >
> > > > On Thu, Feb 17, 2022 at 11:46 AM Benjamin Kaduk via Datatracker <
> > > > [e-mail]> wrote:
> > > >
> > > > > Benjamin Kaduk has entered the following ballot position for
> > > > > draft-ietf-spring-segment-routing-policy-17: Discuss
> > > > >
> > > > > 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/
> > > > >
> > > > >
> > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > DISCUSS:
> > > > >
> ----------------------------------------------------------------------
> > > > >
> > > > > (1) I may just be misunderstanding things, but I'd like to pull on
> a
> > > thread
> > > > > in §8.4 a bit more.  We say that the headend H learns a BGP route
> that
> > > has
> > > > > a
> > > > > VPN label V, but then the following procedures seem to say that we
> > > install
> > > > > a
> > > > > route on the appropriate SR Policy P and that when we receive a
> packet
> > > that
> > > > > matches the route in question, push a label stack including the VPN
> > > label,
> > > > > and send the resulting packet out.
> > > >
> > > >
> > > > KT> Note that we are sending the packet to the selected BGP NH (i.e.
> > > egress
> > > > PE) that advertised the route. The SR Policy is enabling the packets
> to
> > > > traverse a path that is different from (perhaps) the best-effort IGP
> > > > routing.
> > > >
> > > >
> > > > > Nowhere do we say to check the VPN
> > > > > status of the incoming packet,
> > > >
> > > >
> > > > KT> That is the ingress part of the forwarding entry which maps the
> > > > incoming traffic over a customer interface to their specific VPN
> context
> > > > and then performs a lookup in their VPN specific table. This all is
> > > > unchanged.
> > > >
> > > >
> > > > > so this seems like it would open a hole in
> > > > > the VPN by allowing "arbitrary" incoming traffic (not marked as
> > > specific to
> > > > > V) to enter that VPN.  Is the label V filling some other role than
> > > > > identifying a specific VPN of many VPNs that could run along the
> route
> > > R/r?
> > > > > (This is the only instance of the phrase "VPN label" in the
> document,
> > > and
> > > > > no
> > > > > reference is given, so I'm relying heavily on instinct to
> ascertain the
> > > > > intent here.)
> > > > >
> > > >
> > > > KT> I hope my responses clarified that the only thing that is changed
> > > here
> > > > by the steering over the SR Policy is the path taken through the
> network
> > > to
> > > > get to the egress PE. Rest is as today. And yes, of course, we have
> the
> > > > ability to indicate the need for such steering via the matching Color
> > > > Extended community to the BGP route.
> > >
> > > Yes, these help clarify that the part we're focusing on in this
> document is
> > > conceptually "after" the determination of the incoming VPN, and so
> there
> > > isn't any new processing needed for it.  Thanks for the explanation.
> >
> >
> > > >
> > > > >
> > > > > (2) The security considerations says that this document does not
> > > define any
> > > > > new protocol extensions and (accordingly) does not introduce any
> > > further
> > > > > security considerations.  The first part of this seems false, not
> least
> > > > > since we define the meaning of the "CO" bits in the Color Extended
> > > > > Community.  I'm pretty sure that makes the second part also false,
> and
> > > we
> > > > > need to discuss the security considerations relating to imposing SR
> > > > > Policies
> > > > > based only on color and not next-hop.  Alvaro has also noted
> additional
> > > > > aspects where security considerations are missing.
> > > > >
> > > >
> > > > KT> Ack. We will add text in the security consideration sections for
> the
> > > CO
> > > > steering modes.
> > >
> > > What about the SR-DB concept and other new concepts that Alvaro
> identified?
> > > Aren't there security and manageability considerations there as well?
> > >
> >
> > KT2> We've just added text for the endpoint uniqueness and steering
> > aspects. The SRDB is internal to the computation node and the information
> > within it is derived from existing routing protocols and their
> extensions -
> > we are not adding anything new to it. Do let me know, however, if you
> feel
> > we are missing something.
>
> I see that Alvaro has cleared his Discuss, so I am willing to consider this
> topic closed.  I did not think very hard about whether there is anything
> missing, so accordingly I don't have anything to propose adding.
>
> >
> > > >
> > > > >
> > > > > (3) The Discriminator as defined in §2.5 does not seem wide enough
> to
> > > be
> > > > > able to provide the needed properties.  Some later clarification in
> > > §2.6
> > > > > implies that the definition in §2.5 is incomplete and the width is
> > > actually
> > > > > appropriate, but in either case §2.5 seems inadequate in its
> current
> > > form.
> > > > > (Details in the COMMENT.)
> > > > >
> > > >
> > > > KT> 32 bit is wide enough and please see further response below.
> > >
> > > I think I'm still failing to understand exactly why; more below.
> > >
> > > > >
> > > > > (4) Section 2.11 contains the statement, "A valid SR Policy is
> > > instantiated
> > > > > in the forwarding plane."
> > > > >
> > > > > Is this a statement of fact (i.e., a consequence of the definition
> of
> > > > > "valid") or a mandate for something (e.g., the headend) to take
> action
> > > to
> > > > > make it so?  Given that the point of SR is to be stateless on nodes
> > > other
> > > > > than the headend, I suspect the former, but if we are relying on
> the
> > > > > headend
> > > > > (or some other entity) to take action to ensure this is the case,
> that
> > > > > needs
> > > > > to be a clearly stated normative requirement.
> > > > >
> > > >
> > > > KT> The validity of a candidate path and as an extension, the SR
> Policy
> > > is
> > > > discussed in Sec 5. Sec 2.11 describes how a valid SR Policy and its
> > > > constructs are instantiated in the forwarding plane.
> > >
> > > Would it make sense to say something like "In order to be considered
> valid,
> > > an SR policy needs to be instantiated in the forwarding plane (Section
> 5)"?
> > >
> >
> > KT2> The SR Policy may be valid, but could not be instantiated into the
> > forwarding due to a resource issue. We are simply stating here that
> > generally only a valid SR Policy is instantiated in the forwarding plane.
> > We don't have the "only" here since we have use-cases as in section 8.2
> > where we do have to instantiate a "drop" entry in the forwarding for an
> > invalid SR Policy.
>
> Thanks for helping me understand the scenarios here.  A few more
> alternative proposals:
> "A valid SR policy is instantiated in the forwarding plane by the headend."
> "A valid SR policy is generally instantiated in the forwarding plane."
> "Generally, only valid SR policies are instantiated in the forwarding
> plane."
>
> Feel free to use any of those, a modified version thereof, or leave it
> unchanged (though I would prefer to make some form of clarification, I do
> not plan to ask my successor to take up this as a Discuss point when my
> term ends in a few days).
>

KT3> Ack - we've incorporated this change.


> >
> > >
> > > >
> > > > >
> > > > > (5) Section 8.4 uses the phrase "any AFI/SAFI of LISP [RFC6830]."
> > > > > There's nothing in the IANA registry for SAFI
> > > > > (
> https://www.iana.org/assignments/safi-namespace/safi-namespace.xhtml)
> > > > > about
> > > > > LISP, and RFC 6830 doesn't talk about SAFI.  What is this
> referring to?
> > > > >
> > > >
> > > > KT> Ack - there is no SAFI in LISP and the reference was meant to be
> for
> > > > routing of both IPv4 and IPv6 packets with LISP. Will fix this.
> > >
> > > The new text is still a bit terse/opaque for me to be confident that I
> > > understand properly, but I will drop the discuss point as I think I
> see how
> > > it works.
> >
> >
> > > >
> > > > >
> > > > >
> > > > >
> ----------------------------------------------------------------------
> > > > > COMMENT:
> > > > >
> ----------------------------------------------------------------------
> > > > >
> > > > > There's a lot of this document that feels like just some
> informational
> > > > > discussion of "here are some things that many people do", "here are
> > > some
> > > > > possible things you can do with SR", etc..  There are also a small
> > > handful
> > > > > of places in the document that look to actually be specifying
> parts of
> > > > > protocol behavior (I suspect that John has already identified them
> in
> > > his
> > > > > enumeration), and the overall impression ends up being a bit
> jumbled,
> > > > > like there are a bunch of topics stuck together without an
> overarching
> > > > > theme.
> > > > > I think the overall content would be more valuable if divided into
> a
> > > tight
> > > > > "protocol specification" portion that could stay at proposed
> standard,
> > > plus
> > > > > an informational "architecture details" document that contains the
> > > > > in-depth exposition that didn't make it into 8402.
> > > > >
> > > > > This draft would benefit greatly from a terminology section.  I
> note
> > > in the
> > > > > section-by-section comments several places where a term is first
> used
> > > > > without sufficient background/definition, leaving the matter at
> hand
> > > > > underspecified for the reader.
> > > > >
> > > > > Section 2
> > > > >
> > > > >    An SR Policy is a framework that enables the instantiation of an
> > > > >    ordered list of segments on a node for implementing a source
> routing
> > > > >
> > > > > Really, an SR policy is a *framework*?  I thought an SR policy was
> a
> > > > > specific instantiation of a list of segments, or at least that's
> what
> > > I'm
> > > > > getting from RFC 8402.  Perhaps we should say that the general
> concept
> > > of
> > > > > SR
> > > > > Policy provides a framework?
> > > > >
> > > >
> > > > KT> Ack. Will rephrase.
> > > >
> > > >
> > > > >
> > > > > Section 2.1
> > > > >
> > > > >    An SR Policy MUST be identified through the tuple <headend,
> color,
> > > > >    endpoint>.  In the context of a specific headend, an SR policy
> MUST
> > > > >    be identified by the <color, endpoint> tuple.
> > > > >
> > > > > These two MUSTs appear to be in (nominal) conflict.  Maybe start
> the
> > > first
> > > > > one with "absent further context" or "absent the context of a known
> > > headend
> > > > > node"?
> > > > >
> > > >
> > > > KT> It is not "absence of context" but "within the context of a
> specific
> > > > headend".
> > > >
> > > >
> > > > >
> > > > >    The headend is the node where the policy is
> > > instantiated/implemented.
> > > > >    The headend is specified as an IPv4 or IPv6 address and is
> expected
> > > > >    to be unique in the domain.
> > > > >
> > > > > This is the first instance of the word "domain" in this document.
> I
> > > > > suggest
> > > > > using the introduction to introduce what is meant by the word,
> even if
> > > just
> > > > > by reference to RFC 8402.
> > > > >
> > > >
> > > > KT> Ack. It should be SR Domain.
> > > >
> > > >
> > > > >
> > > > >    An implementation MAY allow the assignment of a symbolic name
> > > > >    comprising printable ASCII [RFC0020] characters (i.e.  0x20 to
> 0x7E)
> > > > >    to an SR Policy to serve as a user-friendly attribute for
> debugging
> > > > >    and troubleshooting purposes.  [...]
> > > > >
> > > > > I agree with the other ADs that limiting to US-ASCII is not
> actually
> > > > > user-friendly for many users, and that the likelihood of some
> > > > > implementations not properly enforcing such a limitation to be
> high.
> > > > > (Likewise for the other places where symbolic names are admitted.)
> > > > >
> > > >
> > > > KT> Please see the response to the other reviews on this point.
> > >
> > > I don't find them compelling, but this is just the COMMENT section so
> > > you're not obligated to persuade me.
> > >
> > > >
> > > > >
> > > > > Section 2.2
> > > > >
> > > > >    A dynamic candidate path expresses an optimization objective
> and a
> > > > >    set of constraints.  [...]
> > > > >
> > > > > Down in §5.2 when we discuss validation procedures for dynamic
> > > candidate
> > > > > paths, we say that the optimization problem is solved "for either
> the
> > > > > SR-MPLS or the SRv6 data-plane as specified".  Does the data plane
> > > need to
> > > > > be specified as part of the dynamic candidate path itself?
> > > > >
> > > >
> > > > KT> Yes.
> > >
> > > Should we say that here, e.g., "a dynamic candidate path expresses an
> > > optimization objective and a set of constraints within a specified data
> > > plane"?
> > >
> >
> > KT2> Ack. Have clarified this in the text.
> >
> >
> > >
> > > >
> > > > >
> > > > > Section 2.3
> > > > >
> > > > >    in Section 2.9.  The table below specifies the RECOMMENDED
> default
> > > > >    values of Protocol-Origin:
> > > > >
> > > > > I feel like it would be useful to provide some justification for
> why
> > > the
> > > > > recommended default behavior prefers BGP SR configuration over
> PCEP,
> > > even
> > > > > if
> > > > > that justification is just "we need to have a clear ordering and
> this
> > > one
> > > > > is
> > > > > arbitrary".
> > > > >
> > > >
> > > > KT> Ack. Will clarify that.
> > > >
> > > >
> > > > >
> > > > > Section 2.4
> > > > >
> > > > >    o  Node Address : represented as a 128-bit value.  IPv4
> addresses
> > > > >       MUST be encoded in the lowest 32 bits, and the high-order
> bits
> > > > >       MUST be set to zero.
> > > > >
> > > > >    Its application in the candidate path selection is described in
> > > > >    Section 2.9.
> > > > >
> > > > > The tie-breaker procedure for path selection described in §2.9
> seems to
> > > > > always prefer IPv4 originators over IPv6 ones (by virtue of
> preferring
> > > the
> > > > > smaller value).  I guess if we wanted to change that to prefer
> IPv6 we
> > > have
> > > > > the option of fc00::/7 (unique-local) or fe80::/10 (link-scoped
> > > unicast)
> > > > > from BCP 153, but it's a bit hard to justify either of those as
> > > appropriate
> > > > > on technical grounds, and since this is just a tie-breaker and the
> > > > > Preference is explicitly preferred, it seems like this is probably
> > > "good
> > > > > enough" as-is.
> > > > >
> > > >
> > > > KT> Ack. As clarified in a recent text update in v17, preference is
> the
> > > key
> > > > parameter really.
> > > >
> > > >
> > > > >
> > > > > Section 2.5
> > > > >
> > > > >    The Discriminator is a 32-bit value associated with a candidate
> path
> > > > >    that uniquely identifies it within the context of an SR Policy
> from
> > > a
> > > > >    specific Protocol-Origin as specified below:
> > > > >
> > > > > What are the constraints that underlie the 32-bit requirement here?
> > > > > It looks like some of the scenarios are going to involve
> uncoordinated
> > > > > (random) assignment of these discriminator values (e.g., with the
> BGP
> > > > > distribution mechanism, when coming from different BGP peers), and
> the
> > > > > birthday-bound collision probability is not negligible for this few
> > > bits.
> > > > > That, in turn, calls into question the "uniquely identifies"
> property
> > > being
> > > > > claimed.  Or is there some other property that means that only
> > > > > discriminators from a single issuer will ever need to be compared
> with
> > > each
> > > > > other (making the allocation "coordinated"), such as being
> additionally
> > > > > associated with the originator?
> > > > > If my initial analysis was incorrect and these are indeed
> allocated in
> > > a
> > > > > "coordinated" fashion, would it be typical/expected for the
> allocation
> > > to
> > > > > occur by incrementing a local counter on the originator?  In some
> > > > > situations
> > > > > such allocation by counter can have security considerations, which
> > > > > draft-gont-numeric-ids-sec-considerations attempts to cover.
> > > > >
> > > >
> > > > KT> The discriminator is scoped to a particular originating node for
> the
> > > > candidate path and as such, there is no requirement for coordination
> > > across
> > > > sources/nodes. Therefore, 32-bit is more than sufficient.
> > >
> > > When you say "originating node", does that refer to the SR headend, or
> the
> > > (BGP) originator of the BGP route containing the SR Policy NLRI?
> > >
> >
> > KT2> The BGP originator as you've correctly understood below.
> >
> >
> > >
> > > I assume the latter, and agree that *within the context of BGP*, the
> > > discriminator is scoped to the originating BGP node.  But the
> description
> > > we give in §2.5 of this document does not say anything about making
> use of
> > > such information.  As far as I know, the BGP originator information is
> lost
> > > when the BGP distinguisher is converted into the SR Policy candidate
> path
> > > discriminator data model.
> >
> >
> > KT2> The BGP originator information is not lost. We have clarified this
> in
> > the text below in sec 2.5 itself:
> >
> >    o  When signaling is via BGP SR Policy, the BGP process receiving the
> >       route provides the distinguisher (refer to Section 2.1 of
> >       [I-D.ietf-idr-segment-routing-te-policy
> > <
> https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-18#ref-I-D.ietf-idr-segment-routing-te-policy
> >])
> > as the discriminator.
>
> I think this is trying to cover too much subtlety to be accessible to all
> readers.  Thanks for the pointer to
> draft-filsfils-spring-sr-policy-considerations below, that seems to help
> clarify that the intent is that collisions on BGP distinguisher are
> expected to be resolved within the BGP layer using BGP best-path selection,
> so that only a single candidate path is received by the SR layer from BGP
> for a given distinguisher/discriminator, even if the BGP agent on the SR
> node receives multiple routes that could be candidate paths prior to the
> BGP bestpath selection.
>

KT3> This is standard BGP operations given the NLRI design and the
referenced sec 2.1 of draft-ietf-idr-segment-routing-te-policy touches upon
the use of different discriminators when the CP for the same SR Policy
needs to be sent to the SR layer from BGP layer.


>
> It seems that there are a number of ways that we could modify this document
> to clarify; let me list a couple (but these are not intended to be
> exhaustive):
>
> - in this chunk of text, add another sentence like "Note that BGP best path
>   selection is applied before the route is supplied as a candidate path, so
>   only a single candidate path will be seen for a given discriminator."
>
> - In the preface at the top of §2.5 before the list of per-Protocol-Origin
>   discussions, add a note that "each Protocol-Origin is expected to apply
>   any processing needed to ensure that only a single candidate path is
>   supplied with a given Discriminiator value"
>

KT3> Ack - we have incorporated the 1st text above.


>
> >
> >
> > > And we don't say anything about how candidate
> > > paths for a given SR Policy can only be originated from a single BGP
> node,
> > > so I have to account somehow for the possibility that two BGP nodes are
> > > independently announcing candidate paths for the same SR Policy, and
> thus
> > > might collide in their assignment of distinguisher.
> >
> >
> > KT2> You are correct. This can and does indeed happen today in
> deployments
> > for redundancy and other reasons.
> >
> >
> > > Whereas BGP can
> > > resolve that collision via the BP origination information, I don't see
> how
> > > that would be done in the SR data model.  Does that help you understand
> > > what part I am missing?
> > >
> >
> > KT2> We did have some text in this document in the early days to explain
> > these scenarios but it was moved out to an individual draft. Sec 2.9 has
> a
> > pointer to this informative draft. Please check
> >
> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-sr-policy-considerations-08#section-4
> > and if they clarify.
>
> (As indicated above, they do clarify, but that draft is not referenced here
> and is not a normative reference, so I must insist on further changes to
> this document.)
>

KT3> The draft-filsfils-spring-sr-policy-considerations is providing only
the illustrations and the normative behavior is covered in this document
(i.e., the tiebreaker rules) while the BGP protocol behavior is defined in
draft-ietf-idr-segment-routing-te-policy document. Please note that the
initial versions of this draft did have those illustrations in them but
were moved out to a separate document as part of the WG process.


>
> >
> > >
> > >
> > > >
> > > > >
> > > > > Section 2.8
> > > > >
> > > > >    A candidate path is usable when it is valid.  A common path
> validity
> > > > >    criterion is the validity of any of its constituent
> Segment-Lists.
> > > > >    The validation rules are specified in Section 5.
> > > > >
> > > > > This document claims to target Proposed Standard status; are we
> really
> > > > > content to say only that this is "a common" criterion?  Even when
> we
> > > also
> > > > > go
> > > > > on to flat-out state "the validation rules are specified [below]"?
> > > > >
> > > >
> > > > KT> We will change this to introduce the word RECOMMENDED. There are
> > > > deployments where an operator might need a local policy to declare
> the
> > > > candidate path invalid when the number of valid SLs drops below a
> certain
> > > > threshold (for b/w or load-balancing considerations).
> > > >
> > > >
> > > > >
> > > > > Section 2.9
> > > > >
> > > > >    The candidate path selection process operates primarily on the
> > > > >    candidate path Preference.  A candidate path is selected when
> it is
> > > > >    valid and it has the highest preference value among all the
> > > candidate
> > > > >    paths of the SR Policy.
> > > > >
> > > > > Should this be "among all the valid candidate paths"?  A path
> that's
> > > > > invalid
> > > > > is still invalid, even if it has the highest preference value.
> > > > >
> > > >
> > > > KT> Ack - will clarify this.
> > > >
> > > >
> > > > >
> > > > >    2.  If specified by configuration, prefer the existing installed
> > > > >        path.
> > > > >
> > > > > Does "if specified by configuration" refer to the act of applying
> this
> > > rule
> > > > > at all, or that the existing installed path was one specified by
> > > > > configuration?
> > > > >
> > > >
> > > > KT> The existing installed path. The rationale was that in some
> > > deployment
> > > > designs an operator may not want to disturb/churn an active and
> > > > valid/working path that has been installed in the forwarding.
> > > >
> > > >
> > > > >
> > > > > Section 2.11
> > > > >
> > > > >    The fraction of the flows associated with a given Segment-List
> is w/
> > > > >    Sw, where w is the weight of the Segment-List and Sw is the sum
> of
> > > > >    the weights of the Segment-Lists of the selected path of the SR
> > > > >    Policy.
> > > > >
> > > > > Thank you for stating this clearly!
> > > > >
> > > > > Section 3
> > > > >
> > > > >    o  TE Link Attributes (such as TE metric, Shared Risk Link
> Groups,
> > > > >       attribute-flag, extended admin group) [RFC5305] [RFC3630].
> > > > >
> > > > > Is RFC 5329 applicable here as well?
> > > > >
> > > >
> > > > KT> Yes, will add that. Thanks.
> > >
> > > (It looks like a second 3630 reference got added in the -18, not 5329;
> I'll
> > > mention that in my updated ballot remarks as well.)
> > >
> >
> > KT2> Ooops :-( .. now fixed for real
> >
> >
> > >
> > > >
> > > > >
> > > > > Section 4
> > > > >
> > > > >    Type E: IPv4 Prefix with Local Interface ID:
> > > > >          This type allows identification of Adjacency SID or BGP
> Peer
> > > > >          Adjacency SID (as defined in [RFC8402]) SR-MPLS label for
> > > > >          point-to-point links including IP unnumbered links.  The
> > > > >          headend is required to resolve the specified IPv4 Prefix
> > > > >          Address to the Node originating it and then use the Local
> > > > >          Interface ID to identify the point-to-point link whose
> > > > >          adjacency is being referred to.  The Local Interface ID
> link
> > > > >          descriptor follows semantics as specified in [RFC7752].
> This
> > > > >
> > > > > The phrase "local interface ID" does not appear in RFC 7752 (and
> even
> > > > > "local
> > > > > interface" appears just once"; please use terminology actually
> present
> > > in
> > > > > the referred-to document to clarify what is being referenced.
> > > > >
> > > >
> > > > KT> This one is a bit complicated since RFC7752 (sec 3.2.2) in turn
> > > > references RFC5307 which in turn RFC4202. We use RFC7752 since it
> covers
> > > > and explains the use of the various link descriptors that we use for
> > > > various segment types.
> > > >
> > > >
> > > > >
> > > > > Section 4.1
> > > > >
> > > > >    When steering unlabeled IPv6 BGP destination traffic using an SR
> > > > >    policy composed of Segment-List(s) based on IPv4 SIDs, the
> Explicit
> > > > >    Null Label Policy is processed as specified in
> > > > >    [I-D.ietf-idr-segment-routing-te-policy]) Section 2.4.4.  When
> an
> > > > >
> > > > > It looks like this is §2.4.5, not 2.4.4, in the referenced
> document.
> > > > >
> > > >
> > > > KT> Ack. Will fix.
> > > >
> > > >
> > > > >
> > > > > Section 5.1
> > > > >
> > > > >    The computation/logic that leads to the choice of the
> Segment-List
> > > is
> > > > >    external to the SR Policy headend.  The SR Policy headend does
> not
> > > > >    compute the Segment-List.  The SR Policy headend only confirms
> its
> > > > >    validity.
> > > > >
> > > > > Does the headend actually have to confirm validity?  Is it okay to
> just
> > > > > trust the controller and blindly use what is provided?
> > > > >
> > > >
> > > > KT> At least the first segment needs to be validated from a
> resolvability
> > > > perspective. The subsequent segments depend on how (i.e., using what
> > > > segment types) the controller has signalled the path to the headend.
> If
> > > it
> > > > is indicated by just referring to a Prefix (e.g. loopback) of a node,
> > > then
> > > > the headend will need to resolve and as such validate. While if
> specified
> > > > as a label, then no resolution is required.
> > >
> > > Hmm.  So maybe we could say "the SR Policy headend only confirms the
> > > validity of any segments that it needs to resolve as part of packet
> > > processing"?  Or does that not actually convey the needed information?
> > >
> >
> > KT2> IMHO, the term used in the draft "path resolution to the SID" is
> more
> > informative and cleared (at least to someone working on the programming
> of
> > forwarding entries) than "packet processing".
>
> Okay, I am happy to defer to your domain expertise.
>
> >
> > >
> > > >
> > > > >
> > > > > Section 6.2
> > > > >
> > > > >    When the active candidate path has a specified BSID, the SR
> Policy
> > > > >    uses that BSID if this value (label in MPLS, IPv6 address in
> SRv6)
> > > is
> > > > >    available (i.e., not associated with any other usage: e.g. to
> > > another
> > > > >    MPLS client, to another SRv6 client, to another SID, to another
> SR
> > > > >    Policy, outside the range of SRv6 Locators).
> > > > >
> > > > > I don't think I understand what is meant by "client" here (for
> "another
> > > > > client").  This sentence is the only place where the word "client"
> > > appears
> > > > > in this document...
> > > > >
> > > >
> > > > KT> The term is "MPLS client" or "SRv6 client". MPLS clients can be
> IS-IS
> > > > enabled with SR-MPLS, LDP, RSVP-TE or BGP-LU that allocate label
> from a
> > > > "label manager" within the router.
> > >
> > > I think this explanation actually makes me more concerned about the way
> > > this is written than I previously was.  It seems to imply that we are
> > > trying to describe both that there is an MPLS vs SRv6 data-plane in
> use and
> > > that the node in question is a client of some unspecified protocol
> that can
> > > allocate SIDs/MPLS labels, which could be as varied as an IGP or a
> > > dedicated path computation protocol.  Furthermore, not all of these
> > > possible protocols would intrinsically provide for arbitrary headend
> nodes
> > > to even know if the label/SID in question has already been allocated to
> > > another "client"!
> >
> >
> > > Is the determination of availability to be made by the controller or
> by the
> > > headend?
> >
> >
> > KT2> This is local on the headend.
> >
> >
> > > I think we should state that clearly, since (given the above
> > > discussion) it seems like it is the controller that is best place to
> > > actually make the determination, but the phrasing "the SR Policy uses"
> > > implies (at least to me) that the determination is made on the headend,
> > > since it is the headend that actually instantiates the policy.
> > >
> >
> > KT2> The controller can (and does in some of the deployments that I am
> > aware of) keep track of the usage of the Labels in the SRGB and SRLB
> (refer
> > RFC8402). The same goes for SRv6 SIDs from under the SRv6 Locator. In
> > deployments where controllers do drive the whole SR Policy provisioning,
> > they do keep track. However, this is not mandatory in general. The
> headend
> > is taking care of the actual programming into the forwarding and doesn't
> > have any option but to handle these conditions.
>
> Okay.  I might consider coalescing "to another MPLS client, to another SRv6
> client" down to "to another node in the SR domain" since it's not worth
> adding enough detail to fully clarify "MPLS client" and "SRv6 client", but
> it's up to you.
>

KT3> We have edited the text to expand a bit on what is meant by "client"
here.


>
> >
> > >
> > > >
> > > > >
> > > > >    Optionally, instead of only checking that the BSID of the active
> > > path
> > > > >    is available, a headend MAY check that it is available within a
> > > given
> > > > >    SID range i.e., Segment Routing Local Block (SRLB) as specified
> in
> > > > >    [RFC8402].
> > > > >
> > > > > Is the only allowed range to check the SRLB?  If not, I think we
> need
> > > to
> > > > > s/i.e./e.g./.
> > > > >
> > > >
> > > > KT> Yes, SRLB is the one to check/allocate from for such usage.
> > >
> > > Okay.  I suspect we want s/a given/the given/ then, but am not 100%
> sure.
> > >
> >
> > KT2> Ack. Fixed.
> >
> >
> > > >
> > > > >
> > > > >    When the specified BSID is not available (optionally is not in
> the
> > > > >    SRLB), an alert message MUST be generated.
> > > > >
> > > > > This is the first time (of only two) the word "alert" appears in
> this
> > > > > document, and there is no prior expalanation of what entity might
> be
> > > > > receiving alerts generated by a headend.  Please clarify.
> > > > >
> > > >
> > > > KT> Alert mechanism could be one or more of syslog, Netconf
> > > notification, a
> > > > telemetry mechanism, etc..
> > >
> > > I think the clarification is best placed in the document itself, e.g.,
> in a
> > > glossary/terminology section as I suggested in my high-level comments.
> > >
> >
> > KT2> We have clarified inline.
> >
> >
> > >
> > > >
> > > > >
> > > > >    Assuming that at time t the BSID of the SR Policy is B1, if at
> time
> > > > >    t+dt a different candidate path becomes active and this new
> active
> > > > >    path does not have a specified BSID or its BSID is specified
> but is
> > > > >    not available (e.g. it is in use by something else), then the SR
> > > > >    Policy MAY keep the previous BSID B1.
> > > > >
> > > > > Is there a strict bound on or other guidance for what values of dt
> are
> > > > > allowable for this purpose?
> > > >
> > > >
> > > > KT> None
> > > >
> > > >
> > > > >   Is the intent that there be an atomic
> > > > > transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2?
> > > > >
> > > >
> > > > KT> There is no atomicity requirement. A switch from one active CP to
> > > > another will vary depending on the cause of the switch - e.g. if it
> is
> > > due
> > > > to a failure or because a more preferred path came up.
> > > >
> > > >
> > > > >
> > > > >    The association of an SR Policy with a BSID thus MAY change
> over the
> > > > >    life of the SR Policy (e.g., upon active path change).  Hence,
> the
> > > > >    BSID SHOULD NOT be used as an identification of an SR Policy.
> > > > >
> > > > > Is there any guidance available on how long to wait with a given
> BSID
> > > value
> > > > > unused before binding it to a new SR Policy?
> > > > >
> > > >
> > > > KT> None. These depend on the implementation and scenarios like
> resource
> > > > availability e.g., a BSID might get re-used sooner if the system is
> > > running
> > > > short of labels.
> > > >
> > > >
> > > > >
> > > > > Section 6.2.3
> > > > >
> > > > >    An implementation MAY support the configuration of the
> Specified-
> > > > >    BSID-only restrictive behavior on the headend for all SR
> Policies or
> > > > >    individual SR Policies.  Further, this restrictive behavior MAY
> also
> > > > >    be signaled on a per SR Policy basis to the headend.
> > > > >
> > > > > Elsewhere in the document we discuss specific potential signaling
> > > > > mechanisms/protocols, but here we say nothing.  Is that vagueness
> > > > > intentional?
> > > > >
> > > >
> > > > KT> Since this isn't a protocol specification the mechanism is not
> > > > described here. However, you can look at
> > > >
> > >
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.2
> > > > and that document refers back to this specification.
> > >
> > > Okay, but if this document isn't a protocol specification and that's
> > > grounds to not describe mechanism in it, then there are quite a few
> other
> > > places in the document that should also not describe mechanism, if we
> want
> > > to be applying the rule consistently.
> > >
> >
> > KT2> There may be very high-level references to some mechanisms in
> addition
> > to the informative pointer to the specific protocol spec. This was done
> to
> > improve readability.
> >
> >
> > >
> > > >
> > > > >
> > > > > Section 6.3
> > > > >
> > > > >    A valid SR Policy installs a BSID-keyed entry in the forwarding
> > > plane
> > > > >    with the action of steering the packets matching this entry to
> the
> > > > >    selected path of the SR Policy.
> > > > >
> > > > > I don't think this is stated properly.  An SR Policy is the list of
> > > > > segments; it isn't the entity that's installing entries in the
> > > forwarding
> > > > > plane.  Some other entity is installing an entry in the forwarding
> > > plane to
> > > > > realize the SR Policy in question, and we should make our writing
> > > reflect
> > > > > that.
> > > > >
> > > >
> > > > KT> Ack. s/installs/results in the installation of
> > > >
> > > >
> > > > >
> > > > > Section 6.4
> > > > >
> > > > >    An implementation MAY choose to associate a Binding SID with any
> > > type
> > > > >    of interface (e.g. a layer 3 termination of an Optical Circuit)
> or a
> > > > >    tunnel (e.g.  IP tunnel, GRE tunnel, IP/UDP tunnel, MPLS RSVP-TE
> > > > >    tunnel, etc).  This enables the use of other non-SR enabled
> > > > >
> > > > > Should we have some discussion that contrasts this scenario
> against the
> > > > > End.X behavior from RFC 8986 (for the "interface" case)?
> > > > >
> > > >
> > > > KT> What this document says is that a BSID may be also associated to
> > > direct
> > > > over these other types of interfaces/tunnels. We can look at them as
> > > having
> > > > no other segment being imposed but just redirecting to an interface.
> In
> > > > that sense, it is somewhat similar to End.X in SRv6 (or Adjacency
> SID in
> > > > SR-MPLS). However, those tend to be associated with protocol
> > > adjacencies. I
> > > > am not sure that I've followed your point though and please do let me
> > > know
> > > > if I've not.
> > >
> > > What you write here indicates to me that you got my point.  My
> proposal was
> > > for a sentence something like "this behavior is analogous to the End.X
> > > behavior defined in [RFC8986] in that the SID is removed, no new SIDs
> > > applied, and the packet is directed across a particular interface, but
> it
> > > conceptually fits better as a Binding SID since the SID is bound to a
> > > specific (logical or physical) interface and End.X is typically used
> with
> > > protocol adjacencies rather than interfaces".  But that's just a
> > > suggestion, and if you think it doesn't make sense or doesn't add much
> > > value, please ignore it.
> > >
> > > >
> > > > >
> > > > > Section 7
> > > > >
> > > > >    The SR Policy State is maintained on the headend to represent
> the
> > > > >    state of the policy and its candidate paths.  [...]
> > > > >
> > > > > I confess I don't really understand why we need to have the
> current,
> > > > > minimal, description of SR Policy State in this document.  What
> would
> > > be
> > > > > lost if we deferred its discussion entirely until there is a more
> > > > > comprehensive discussion available?
> > > > >
> > > >
> > > > KT> We will add an informational pointer to the SR Policy YANG model.
> > > What
> > > > this document calls out is the requirement for reporting the
> operational
> > > > state and provides pointers to other specs where this is being worked
> > > out.
> > > >
> > > >
> > > > >
> > > > >    The SR Policy state can be reported by the headend node via
> BGP-LS
> > > > >    [I-D.ietf-idr-te-lsp-distribution] or PCEP [RFC8231] and
> > > > >    [I-D.ietf-pce-binding-label-sid].
> > > > >
> > > > > The functionality of draft-ietf-pce-binding-label-sid seems much
> more
> > > > > limited than that of draft-ietf-idr-te-lsp-distribution; in
> > > particular, the
> > > > > former does not seem to actually report SR Policy state to the
> headed
> > > at
> > > > > all; rather, it only concerns itself with BSID association to path,
> > > with no
> > > > > information about "active", "not preferred", etc.
> > > > >
> > > >
> > > > KT> The PCEP work might be spread out over different documents but
> we do
> > > > need to cover these requirements. That is one of the objectives of
> having
> > > > this document coordinate work across protocol WGs.
> > >
> > > It still feels like we're claiming something here that isn't true --
> "can
> > > be reported via ... PCEP and [I-D.ietf-pce-binding-label-sid]".  It
> seems
> > > like we are really trying to say "... via extensions to PCEP [some of
> which
> > > don't exist yet in a form that we're willing to reference]".
> > >
> >
> > KT2> This document, like some others in SPRING, does provide informative
> > references (perhaps still in the WG doc stage) for better readability and
> > clarity.
> >
> >
> > > >
> > > > >
> > > > > Section 8.3
> > > > >
> > > > >    If the SR Policy P is invalid, the BSID B is not in the
> forwarding
> > > > >    plane and hence the packet K is dropped by H.
> > > > >
> > > > > We literally just in the previous section talked about a scenario
> > > where the
> > > > > BSDI is kept in the forwarding plane (but with the action to drop,
> so
> > > the
> > > > > overall outcome is not changed from what this text describes).
> > > > > Nonetheless,
> > > > > it's inaccurate to state that "the BSID B is not in the forwarding
> > > plane"
> > > > > here.
> > > > >
> > > >
> > > > KT> There is a difference between the drop being referred to in 8.2
> and
> > > > 8.3. What we have in 8.2 is like a route pointing to null where we
> may
> > > > advertise and get packets but will drop it with normal counters
> > > associated
> > > > with that specific entry. While 8.3 is like we are dropping because
> we
> > > have
> > > > no route (ideally we shouldn't have got the packet) and we increment
> a
> > > > generic lookup failed counter. The use-cases for both are different.
> > >
> > > I (think I) understand that the mechanisms are different and both have
> use
> > > cases.  I just don't think that the specific combination of words used
> here
> > > makes a true statement.  There are probably a number of ways to make a
> > > slight
> > > adjustment and come up with a true statement, such as starting it with
> a
> > > caveat as in "When Drop-Upon-Invalid behavior is not in use, for an
> invalid
> > > SR Policy P, its BSID B is not in the forwarding plane and hence the
> packet
> > > K is dropped by H".
> > >
> >
> > KT2> Thanks for that suggestion. We've incorporated it.
> >
> >
> > >
> > > >
> > > > >
> > > > > Section 8.4.1
> > > > >
> > > > >    When a BGP route has multiple Color Extended communities each
> with a
> > > > >    valid SR Policy, the BGP process installs the route on the SR
> Policy
> > > > >    giving preference to the color with the highest numerical value.
> > > > >
> > > > > Do we want to say anything about this being an arbitrary tiebreaker
> > > (rather
> > > > > than an intentional preference), or is that thought to be
> implicitly
> > > clear?
> > > > >
> > > >
> > > > KT> It is an intentional preference.
> > >
> > > Peeking forward to §8.8.2, is this also referring to the BGP color
> rather
> > > than the SR Policy color?  If so, please specifically qualify the word
> > > "color" as being the BGP one.
> > >
> > > If not, then I strongly suggest that the introduction of color in §2.1
> > > state that the numerical value of the color is used as a preference
> > > mechanism in addition to indicating intent or objective (with the
> > > implication or explicit statement that assignment of color values must
> be
> > > performed in a manner that is compatible with the operator's
> > > preference/policy).
> > >
> >
> > KT2> This document needs to refer to the "BGP color" as the "Color
> Extended
> > Community". Thanks for catching that. This is not done in a few places
> and
> > we've fixed that.
>
> Many thanks for those fixes, it is a big help.
>
>
> >
> > >
> > > >
> > > > >
> > > > > Section 8.5
> > > > >
> > > > >    In this section, independent of the a-priori existence of any
> > > > >    explicit candidate path of the SR policy (C, N), it is to be
> noted
> > > > >    that the BGP process at headend node H triggers the
> instantiation of
> > > > >    a dynamic candidate path for the SR policy (C, N) as soon as:
> > > > >
> > > > > I strongly suggest providing a more explicit framework of what the
> > > > > assumptions and preconditions are for the mechanism described in
> this
> > > > > section.  My intuition says that it's a fairly optional thing that
> > > would
> > > > > need to be specifically configured, but trying to wrap that
> sentiment
> > > into
> > > > > the long bullet point involving "a local policy" seems like a very
> > > > > confusing
> > > > > way to express the desired behavior.
> > > > >
> > > >
> > > > KT> It is actually a matter of local policy with perhaps some
> template
> > > and
> > > > configuration to drive this. I believe this should get covered in
> the SR
> > > > Policy YANG model at some point in time.
> > > >
> > > >
> > > > >
> > > > > Section 8.6
> > > > >
> > > > >    o  is configured to instantiate an array of paths to N where the
> > > > >       entry 0 is the IGP path to N, color C1 is the first entry and
> > > > >       Color C2 is the second entry.  The index into the array is
> called
> > > > >       a Forwarding Class (FC).  The index can have values 0 to 7.
> > > > >
> > > > > Why are the only allowed values 0 to 7?  Where does this
> restriction
> > > arise
> > > > > from?  It is because of some protocol element?
> > > > >
> > > >
> > > > KT> There is text further in the section to indicated that these
> > > > ranges/values are implementation-specific. Historically, the 8 values
> > > have
> > > > come from the MPLS EXP bits.
> > >
> > > If the ranges/values are implementation-specific, then don't give a
> > > specific range here stated as if it is a universal limitation!  I would
> > > either drop the sentence entirely or say something like "when the
> index is
> > > conveyed using the MPLS EXP bits, only indices 0 to 7 are usable".
> > >
> >
> > KT2> Ack. Have clarified.
> >
> >
> > >
> > > >
> > > > >
> > > > >    If the local configuration does not specify any explicit
> forwarding
> > > > >    information for an entry of the array, then this entry is filled
> > > with
> > > > >    the same information as entry 0 (i.e. the IGP shortest path).
> > > > >
> > > > >    If the SR Policy mapped to an entry of the array becomes
> invalid,
> > > > >    then this entry is filled with the same information as entry 0.
> > > When
> > > > >    all the array entries have the same information as entry0, the
> > > > >    forwarding entry for N is updated to bypass the array and point
> > > > >    directly to its outgoing interface and next-hop.
> > > > >
> > > > > I can't tell how much of this is supposed to be protocol
> specification
> > > and
> > > > > how much an illustrative example.  Is A(0) always the IGP shortest
> > > path?
> > > > > Are these protocol requirements to fall back to the IGP shortest
> path
> > > when
> > > > > an entry is otherwise unpopulated or the associated SR Policy
> becomes
> > > > > invalid?
> > > > >
> > > >
> > > > KT> The specifics are for illustration purposes. Most of these are
> policy
> > > > knobs/options.
> > >
> > > Please add a note at the top of the section that "this section
> provides an
> > > example of how a headend might apply per-flow steering in practice".
> > >
> >
> > KT2> Ack. Added.
> >
> >
> > >
> > > >
> > > > >
> > > > > Section 8.8.2
> > > > >
> > > > >    The steering preference is first based on the highest color
> value
> > > and
> > > > >    then CO-dependent for the color.  [...]
> > > > >
> > > > > This seems to contradict what I assumed earlier about the "highest
> > > color"
> > > > > rule being a tiebreaker, e.g., the word "preference" is used
> here.  Is
> > > it
> > > > > actually intended to be a deliberately configured
> priority/preference
> > > > > scheme?  If so, that would seem to require some wide-ranging
> reworking
> > > > > throughout the document.
> > > > >
> > > >
> > > > KT> There is the color that is in the identification of an SR Policy
> -
> > > > (color, endpoint). This does not get into any tiebreaker or selection
> > > > logic. All that (sec 2.9) is about the selection of a candidate path
> > > within
> > > > an SR Policy. Then there is the color value signaled via the Color
> > > Extended
> > > > community on the BGP routes and here, we have the preference for
> higher
> > > > color when the route is advertised with multiple colors tagged to it.
> > >
> > > I think you should clarify that this section refers to the BGP Color,
> then
> > > -- previously in the document it has been the SR Policy color value
> and an
> > > unqualified reference to "color value" seems like it refers to the
> concept
> > > defined in this document, absent other qualifiers.
> > >
> >
> > KT2> Ack. Fixed references as mentioned in a previous comment.
> >
> >
> > >
> > > >
> > > > >
> > > > > Section 9.3
> > > > >
> > > > >    the most appropriate alternative for the active candidate
> path.  A
> > > > >    fast re-route mechanism MAY then be used to trigger sub 50msec
> > > > >    switchover from the active to the backup candidate path in the
> > > > >    forwarding plane.  Mechanisms like Bidirectional Forwarding
> > > Detection
> > > > >    (BFD) MAY be used for fast detection of such failures.
> > > > >
> > > > > Why is the specific 50msec value important here?  Is there some
> other
> > > > > requirement that imposes it?
> > > > >
> > > >
> > > > KT> This comes from "typical" expectations from fast-reroute
> mechanisms.
> > >
> > > I'd consider '''to trigger "fast" (sub 50msec) switchover''', then, but
> > > it's not very important.
> > >
> > > >
> > > > >
> > > > > Section 10
> > > > >
> > > > > I think we also want to mention the security considerations of
> several
> > > more
> > > > > documents, including (but not limited to)
> > > > > draft-ietf-idr-segment-routing-te-policy and RFCs 8660, 8754, and
> 8986.
> > > > >
> > > >
> > > > KT> Ack on the three RFCs, but convinced about the
> > > > draft-ietf-idr-segment-routing-te-policy since that depends on this
> and
> > > not
> > > > the other way around.
> > >
> > > I think this relates to John's Discuss point and whether this document
> > > specifies the protocol behavior of the two bits in the context of the
> > > extension defined in draft-ietf-idr-segment-routing-te-policy.  You
> need to
> > > understand draft-ietf-idr-segment-routing-te-policy in order to
> understand
> > > the security considerations relating to the protocol behavior
> controlled by
> > > those two bits, and IMO the protocol behavior specified by those two
> bits
> > > is solely the responsibility of this document, so this document must
> > > incorporate the security considerations of
> > > draft-ietf-idr-segment-routing-te-policy in order to fully document the
> > > security considerations of the concepts and protocol elements that this
> > > document defines.
> > >
> >
> > KT2> I am working with John to address his comments.
>
> Okay, the changes from -18 to -20 are looking promising, but I will let
> John decide when it's done.
>

KT3> Our discussion with John is ongoing and seems like might take more
time. Would you be clearing your DISCUSS assuming the updates address your
concerns?

Thanks,
Ketan


>
> Thanks for all these replies and updates; I didn't respond to them
> individally but they are all appreciated.
>
> -Ben
>
> >
> >
> > >
> > > Thanks for this, and all the other parts I didn't specifically reply
> to.
> > >
> > > I will attempt to update my ballot position in the datatracker to
> remove
> > > the parts that are fully addressed (though I will probably
> inadvertently
> > > leave in something I shouldn't have).
> > >
> > > -Ben
> > >
> > > >
> > > > >
> > > > > Section 15.2
> > > > >
> > > > > I agree with John that draft-ietf-idr-segment-routing-te-policy
> must be
> > > > > classified as a normative reference.
> > > > >
> > > > > It also seems that RFC 7752 should be classified as normative, as
> we
> > > > > incorporate its definition for the semantics of several of the
> segment
> > > type
> > > > > descriptions.
> > > > >
> > > >
> > > > KT> Ack
> > > >
> > > >
> > > > >
> > > > >
> > > > > NITS
> > > > >
> > > > > Section 1
> > > > >
> > > > >    Segment Routing Policy (SR Policy) [RFC8402] is an ordered list
> of
> > > > >    segments (i.e. instructions) that represent a source-routed
> policy.
> > > > >
> > > > > /Segment/A Segment/
> > > > >
> > > >
> > > > KT> Ack
> > > >
> > > >
> > > > >
> > > > >    The headend node is said to steer a flow into a SR Policy.  The
> > > > >    packets steered into an SR Policy carry an ordered list of
> segments
> > > > >    associated with that SR Policy.  [...]
> > > > >
> > > > > In a certain sense this can be read as saying that the packets that
> > > "carry
> > > > > an ordered list of segments" are the ones prior to being steered
> into
> > > an SR
> > > > > policy, which would make this statement not true.  Perhaps we want
> to
> > > say
> > > > > "after being steered into an SR Policy, packets carry an ordered
> list
> > > ..."?
> > > > > (I also went back and forth with myself about whether "packets ...
> > > carry"
> > > > > implies in the payload or not.  I settled on "not" but make this
> note
> > > just
> > > > > in case I am missing an aspect of that question.)
> > > > >
> > > >
> > > > KT> Ack. Will rephrase.
> > > >
> > > >
> > > > >
> > > > > Section 2
> > > > >
> > > > >    An SR Policy is a framework that enables the instantiation of an
> > > > >    ordered list of segments on a node for implementing a source
> routing
> > > > >
> > > > > It's easy to read this as saying that all of the segments in the
> list
> > > > > instantiated on the single node in question, which I assume is not
> the
> > > > > intent.  Probably the easiest way to aid readability here is to
> split
> > > the
> > > > > sentence up into multiple smaller sentences that are easier to
> parse.
> > > > >
> > > >
> > > > KT> Will rephrase.
> > > >
> > > >
> > > > >
> > > > > Section 2.2
> > > > >
> > > > >    A dynamic candidate path expresses an optimization objective
> and a
> > > > >    set of constraints.  The headend (potentially with the help of a
> > > PCE)
> > > > >    computes the solution Segment-List (or set of Segment-Lists)
> that
> > > > >    solves the optimization problem.
> > > > >
> > > > > I'd suggest computes the solution/computes a solution/ for
> genericity.
> > > > >
> > > >
> > > > KT> Ack.
> > > >
> > > >
> > > > > A stateful PCE might end up computing a path that is not the
> optimal
> > > one
> > > > > for
> > > > > this specific optimization problem, due to a desire to cooperate
> with
> > > other
> > > > > paths in the network, and the "Min-Metric with margin and maximum
> > > number of
> > > > > SIDs" objective in draft-filsfils-spring-sr-policy-considerations
> > > doesn't
> > > > > even have a guaranteed unique best solution.
> > > > >
> > > > > Section 2.5
> > > > >
> > > > >    When provisioning is via configuration, this is an
> implementation's
> > > > >    configuration model-specific unique identifier for a candidate
> path.
> > > > >    The default value is 0.
> > > > >
> > > > > I'm having a lot of trouble parsing this.  Did we perhaps mean to
> > > hyphenate
> > > > > as "configuration-model-specific"?
> > > > >
> > > >
> > > > KT> Ack
> > > >
> > > >
> > > > >
> > > > > Section 2.13
> > > > >
> > > > >    The SR Policy POL1 is identified by the tuple <headend, color,
> > > > >    endpoint>.  It has two candidate paths CP1 and CP2.  Each is
> > > > >    identified by a tuple <protocol-origin, originator,
> discriminator>.
> > > > >
> > > > > I suggest (for the last sentence) "identified within the scope of
> POL1"
> > > > >
> > > >
> > > > KT> Ack
> > > >
> > > >
> > > > >
> > > > >    forwarding instantiation of SR policy POL1.  Traffic steered on
> POL1
> > > > >    is flow-based hashed on Segment-List <SID11...SID1i> with a
> ratio
> > > > >    W1/(W1+W2).
> > > > >
> > > > > If I read "ratio" I would instinctively think of the ratio of
> (traffic
> > > on
> > > > > segment list 1)/(traffic on segment list 2), as opposed to the
> > > proportion
> > > > > of
> > > > > all traffic, that would be measured as the indicated W1/(W1+W2).
> > > > >
> > > >
> > > > KT> Ack. s/ratio/proportion
> > > >
> > > >
> > > > >
> > > > > Section 3
> > > > >
> > > > >    The attached domain topology may be learned via IGP, BGP-LS or
> > > > >    NETCONF.
> > > > >
> > > > >    A non-attached (remote) domain topology may be learned via
> BGP-LS or
> > > > >    NETCONF.
> > > > >
> > > > > I think these are both probably not exhaustive lists, so "e.g." or
> > > similar
> > > > > may be appropriate.
> > > > >
> > > >
> > > > KT> Ack.
> > > >
> > > >
> > > > >
> > > > > Section 4
> > > > >
> > > > >    Type C: IPv4 Prefix with optional SR Algorithm:
> > > > >          The headend is required to resolve the specified IPv4
> Prefix
> > > > >          Address to the SR-MPLS label corresponding to a Prefix SID
> > > > >          segment (as defined in [RFC8402]).  The SR algorithm
> (refer to
> > > > >          Section 3.1.1 of [RFC8402]) to be used MAY also be
> provided.
> > > > >
> > > > >    Type D: IPv6 Global Prefix with optional SR Algorithm for
> SR-MPLS:
> > > > >          In this case, the headend is required to resolve the
> specified
> > > > >          IPv6 Global Prefix Address to the SR-MPLS label
> corresponding
> > > > >          to its Prefix SID segment (as defined in [RFC8402]).  The
> SR
> > > > >          Algorithm (refer to Section 3.1.1 of [RFC8402]) to be
> used MAY
> > > > >
> > > > > These are effectively just the IPv4 and IPv6 incarnations of the
> same
> > > > > underlying procedure, right?  Can't we minimize the diff between
> the
> > > > > paragraphs further?
> > > > >
> > > >
> > > > KT> Ack
> > > >
> > > >
> > > > >
> > > > > Section 5.1
> > > > >
> > > > >    Additionally, a Segment-List MAY be declared invalid when:
> > > > >
> > > > > We probably want another word here ("both"?), to specify how the
> two
> > > > > conditions are combined.
> > > > >
> > > >
> > > > KT> Ack - will rephrase.
> > > >
> > > >
> > > > >
> > > > > Section 5.2
> > > > >
> > > > >    When the local computation is not possible (e.g., a policy's
> > > tail-end
> > > > >    is outside the topology known to the headend) or not desired,
> the
> > > > >    headend MAY send path computation request to a PCE supporting
> PCEP
> > > > >    extension specified in [RFC8664].
> > > > >
> > > > > missing article ("the PCEP extension").  I forget if it should be
> > > > > "extensions" plural.
> > > > >
> > > >
> > > > KT> Ack
> > > >
> > > >
> > > > >
> > > > > Section 8.7
> > > > >
> > > > >    Finally, headend H MAY be configured with a local routing policy
> > > > >    which overrides any BGP/IGP path and steer a specified packet
> on an
> > > > >
> > > > > singular/plural mismatch -- s/steer/steers/
> > > > >
> > > >
> > > > KT> Ack.
> > > >
> > > > Thanks,
> > > > Ketan
> > >
> > >
>