Skip to main content

Segment Routing Policy Architecture
draft-ietf-spring-segment-routing-policy-22

Revision differences

Document history

Date Rev. By Action
2024-01-26
22 Gunter Van de Velde Request closed, assignment withdrawn: Nagendra Nainar Last Call OPSDIR review
2024-01-26
22 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2022-07-21
22 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-06-17
22 (System) RFC Editor state changed to AUTH48
2022-05-24
22 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-05-19
22 Andrew Alston Shepherding AD changed to Andrew Alston
2022-04-04
22 Carlos Jesús Bernardos Request closed, assignment withdrawn: Zhen Cao Telechat INTDIR review
2022-04-04
22 Carlos Jesús Bernardos Closed request for Telechat review by INTDIR with state 'Overtaken by Events'
2022-04-01
22 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-04-01
22 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-04-01
22 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-03-31
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-03-24
22 (System) RFC Editor state changed to EDIT
2022-03-24
22 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-03-24
22 (System) Announcement was received by RFC Editor
2022-03-24
22 (System) IANA Action state changed to In Progress
2022-03-23
22 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2022-03-23
22 Amy Vezza IESG has approved the document
2022-03-23
22 Amy Vezza Closed "Approve" ballot
2022-03-23
22 Amy Vezza Ballot writeup was changed
2022-03-23
22 (System) Removed all action holders (IESG state changed)
2022-03-23
22 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2022-03-23
22 Martin Vigoureux Ballot approval text was generated
2022-03-22
22 John Scudder
[Ballot comment]
Thanks for resolving my discuss concern #4 and working with me on the other three. I'm choosing to abstain because I'm not happy …
[Ballot comment]
Thanks for resolving my discuss concern #4 and working with me on the other three. I'm choosing to abstain because I'm not happy with the outcome of #2 and especially #3; however I won't stand in the way of the document's advancement for these reasons.

---previous discuss, for posterity:

I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don't see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.

I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)

---comments:

As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I’d like to talk about it a little more: why have you chosen to restrict symbolic names to ASCII? UTF-8 is the more usual choice in this context; indeed implementations may have to go to extra effort to scrub their input to insure that only ASCII is present. BCP 18 doesn’t require you to internationalize your strings, of course, it gives you two options, of which you have (sort of, you don't have the "US-") followed the latter:

  This document does not mandate a policy on name internationalization,
  but requires that all protocols describe whether names are
  internationalized or US-ASCII.

But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough to invite the question.

If you do stick with ASCII as currently written, might you add text mandating that implementations scrub their input to prevent non-ASCII characters from being accepted?
2022-03-22
22 John Scudder [Ballot Position Update] Position for John Scudder has been changed to Abstain from Discuss
2022-03-22
22 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-22.txt
2022-03-22
22 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-03-22
22 Ketan Talaulikar Uploaded new revision
2022-03-20
21 Roman Danyliw [Ballot comment]
Thank you for addressing my DISCUSS and most of my COMMENT feedback.
2022-03-20
21 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2022-03-19
21 Benjamin Kaduk [Ballot comment]
Thank you for addressing my Discuss (and most of my Comment) points!
2022-03-19
21 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2022-03-19
21 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-21.txt
2022-03-19
21 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-03-19
21 Ketan Talaulikar Uploaded new revision
2022-03-11
20 Alvaro Retana [Ballot comment]
[Thanks for addressing my DISCUSS!]
2022-03-11
20 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2022-03-06
20 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-20.txt
2022-03-06
20 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-03-06
20 Ketan Talaulikar Uploaded new revision
2022-03-05
19 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-19.txt
2022-03-05
19 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-03-05
19 Ketan Talaulikar Uploaded new revision
2022-02-24
18 Benjamin Kaduk
[Ballot discuss]
[removing topics that are addressed; the below are (verbatim) copies from
my ballot on the -17, for topics that remain open]

(3) The …
[Ballot discuss]
[removing topics that are addressed; the below are (verbatim) copies from
my ballot on the -17, for topics that remain open]

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

(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.
2022-02-24
18 Benjamin Kaduk
[Ballot comment]
Section 3

the third bullet point has doubled [RFC3630] reference, I think the intent
was to add a 5329 reference instead …
[Ballot comment]
Section 3

the third bullet point has doubled [RFC3630] reference, I think the intent
was to add a 5329 reference instead of the duplicate 3630.


What appears below is a copy of my ballot comments on the -17 with some
portions removed.  I removed the portions that I believe are addressed in
the -18, but did not attempt to update the description/commentary for the
parts that remain (even though the email thread from my previous ballot
position has clarified aspects of many of them).

=======================================================================

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

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

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?

Section 2.3

  Note that the above order is to satisfy the need for having a clear
  ordering and implementations MAY allow modifications of these default
  values assigned to protocols on the headend along similar lines as a
  routing administrative distance.  [...]

Thanks for adding the text here per my previous comment.
I'd humbly offer for consideration an alternative
NEW:
% Note that the above order is constructed so that there is a clear
% ordering across different Protocol-Origin values, but the particular
% order chosen is not critical to the operation of the protocol.
% Implementations MAY allow modifications of these default values assigned
% to protocols on the headend along similar lines as a routing
% administrative distance. 

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.

Section 2.9

  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?

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?

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

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

  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.

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?

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

Section 7

  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.

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.

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?

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?

  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?

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.

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?

Section 15.2

I agree with John that draft-ietf-idr-segment-routing-te-policy must be
classified as a normative reference.
2022-02-24
18 Benjamin Kaduk Ballot comment and discuss text updated for Benjamin Kaduk
2022-02-17
18 (System) Changed action holders to Martin Vigoureux (IESG state changed)
2022-02-17
18 (System) Sub state has been changed to AD Followup from Revised ID Needed
2022-02-17
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-02-17
18 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-18.txt
2022-02-17
18 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-02-17
18 Ketan Talaulikar Uploaded new revision
2022-02-17
17 (System) Changed action holders to Clarence Filsfils, Martin Vigoureux, Dan Voyer, Paul Mattes, Alex Bogdanov, Ketan Talaulikar (IESG state changed)
2022-02-17
17 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2022-02-17
17 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I am afraid that, due to lack of available time, I only quickly reviewed …
[Ballot comment]
Thank you for the work put into this document. I am afraid that, due to lack of available time, I only quickly reviewed this document and I will rely on the INT directorate review.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits.

Special thanks to Jim Guichard for the shepherd's write-up including the section about the WG consensus and discussion.

Thanks also to Carlos Bernardos for the INT directorate review dated 13th of March. I have also seen that authors are in an email discussion with Carlos and I appreciate that Carlos was acknowledged in the acknowledgment section.
See .

I hope that this helps to improve the document,

Regards,

-éric

Generic comment: this document uses the term "headend", which is not used in other SRv6-related documents. Not really important though.

## Abstract

Mostly cosmetic, but the abstract would benefit from being more concise and straight to the point.

## Section 2.1

Please use "::" rather than "::0" to respect RFC 5952. Also for section 8.8.1

I also share the concern of other AD for an ASCII-only symbolic name.

## Section 2.3

Why are the values 10, 20, and 30 only RECOMMENDED in a standard track document and are not a MUST ? If this is about distance, then let's be clear and name this value as "distance" or "origin-precedence".


## Section 2.13

Rather than using 1.1.1.1 or 2.2.2.2 please use the documentation addresses for IPv4 / IPv6. Same reasoning for using the example ASN.

# NITS 

Probably a topic beaten to death but isn't "ISIS" spelled "IS-IS" ?

Usually, "i.e." is always followed by a ","
2022-02-17
17 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2022-02-16
17 Murray Kucherawy
[Ballot comment]
Thanks to Cullen Jennings for his ARTART review.

I'm hardly an expert on the technologies described here, but most of the SHOULDs I …
[Ballot comment]
Thanks to Cullen Jennings for his ARTART review.

I'm hardly an expert on the technologies described here, but most of the SHOULDs I ran into left me wondering why they aren't MUSTs.  There's no obvious (to me) implementation guidance present about when one might legitimately do something other than what the SHOULD says.

Should Section 2.1 stipulate that symbolic names, if used, should be unique?

Thanks for the attention to detail in Section 12.
2022-02-16
17 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2022-02-16
17 Benjamin Kaduk
[Ballot comment]
[updated to add another note on the security considerations]

There's a lot of this document that feels like just some informational
discussion of …
[Ballot comment]
[updated to add another note on the security considerations]

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?

Section 2.1

  An SR Policy MUST be identified through the tuple .  In the context of a specific headend, an SR policy MUST
  be identified by the  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"?

  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.

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

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?

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

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.

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.

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]"?

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.

  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?

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?

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.

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.

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?

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

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

  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.

  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?  Is the intent that there be an atomic
transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2?

  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?

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?

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.

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

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?

  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.

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.

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?

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.

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?

  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?

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.

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?

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.

It seems that having a centralized "SR DB" would present an attractive target
that (if compromised) would allow an attacker to construct very damaging
attacks on the SR domain.  Accordingly, we should say that the realization
(if any) of the SR DB needs to be strongly protected at rest (and if transit, if
it is ever conveyed around).

There are probably also some things to say about risk due to reuse of BSID
for different SR Policies.

The techniques described in section 8 for steering traffic into SR Policy
seem to have some considerations about the risks incurred by misdirected
traffic (e.g., due to misconfiguration).
There is perhaps also risk of misuse for per-flow steering, though it is
hard to say much that is not vague on this topic.  ("A single user's flows
might get redirected to a node where illegal traffic inspection, e.g., that
violates BCP 188, is performed" is an obvious bugbear, but not always the
strongest argument to make.)

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.


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/

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

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.

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.
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"?

Section 2.13

  The SR Policy POL1 is identified by the tuple .  It has two candidate paths CP1 and CP2.  Each is
  identified by a tuple .

I suggest (for the last sentence) "identified within the scope of POL1"

  forwarding instantiation of SR policy POL1.  Traffic steered on POL1
  is flow-based hashed on Segment-List  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).

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.

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?

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.

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.

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/
2022-02-16
17 Benjamin Kaduk Ballot comment text updated for Benjamin Kaduk
2022-02-16
17 Benjamin Kaduk
[Ballot 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 …
[Ballot 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.  Nowhere do we say to check the VPN
status of the incoming packet, 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.)

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

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

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

(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?
2022-02-16
17 Benjamin Kaduk
[Ballot 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 …
[Ballot 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?

Section 2.1

  An SR Policy MUST be identified through the tuple .  In the context of a specific headend, an SR policy MUST
  be identified by the  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"?

  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.

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

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?

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

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.

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.

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]"?

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.

  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?

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?

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.

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.

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?

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

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

  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.

  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?  Is the intent that there be an atomic
transition from BSID=B1;active-path=P1 to BSID=B1;active-path=P2?

  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?

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?

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.

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

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?

  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.

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.

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?

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.

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?

  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?

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.

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?

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.

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.


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/

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

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.

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.
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"?

Section 2.13

  The SR Policy POL1 is identified by the tuple .  It has two candidate paths CP1 and CP2.  Each is
  identified by a tuple .

I suggest (for the last sentence) "identified within the scope of POL1"

  forwarding instantiation of SR policy POL1.  Traffic steered on POL1
  is flow-based hashed on Segment-List  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).

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.

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?

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.

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.

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/
2022-02-16
17 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2022-02-16
17 Roman Danyliw
[Ballot discuss]
There appear to be a few places where additional pointers or specification is needed to ensure interoperability.

** Section 2.5
  When signaling …
[Ballot discuss]
There appear to be a few places where additional pointers or specification is needed to ensure interoperability.

** Section 2.5
  When signaling is via PCEP, the method to uniquely signal an
  individual candidate path along with its discriminator is described
  in [I-D.ietf-pce-segment-routing-policy-cp]. 

Where is the explanation of discriminator in this reference?  “Discriminator” appears in Sections 3.1, 3.2, 4.1.2, and 5.2.2.  In the first three section it is simply named but not explained.  In the last section, it isn’t explained beyond being defined as 32-bits.

** Section 2.6. 
  Candidate paths MAY also be assigned or signaled with a symbolic name
  comprising printable ASCII [RFC0020] [RFC5234] characters

How these candidate paths names are signaled isn’t defined.  I believe it is per Section 5.2.3 of draft-ietf-pce-segment-routing-policy-cp and Section 2.4.7 of draft-ietf-idr-segment-routing-te-policy.

** Section 2.7.  How is the candidate path preference signaled?  Is that draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1 and https://datatracker.ietf.org/doc/html/draft-ietf-idr-segment-routing-te-policy-14#section-2.4.1?
2022-02-16
17 Roman Danyliw
[Ballot comment]
I support John Scudder and Alvaro Retana's DISCUSS positions.

** Section 2.1.
  The color is an unsigned non-zero 32-bit numerical value that …
[Ballot comment]
I support John Scudder and Alvaro Retana's DISCUSS positions.

** Section 2.1.
  The color is an unsigned non-zero 32-bit numerical value that
  associates the SR Policy with an intent or objective (e.g.  low-
  latency).

Should “numeric value” be “integer”?

** Section 2.1
  The SR Policy name
  MAY also be signaled along with a candidate path of the SR Policy
  (refer to Section 2.2). 

-- It would be helpful to explicitly state either here or in Section 2.2 that Section 2.4.8 of [I-D.ietf-idr-segment-routing-te-policy] and Section 5.2.1 of  [I-D.ietf-pce-segment-routing-policy-cp] apply for the guidance on how this naming is signaled. Section 2.2 doesn’t discuss signaling the name.

-- Both of these document need to be normative reference since there is dependency on them for interoperable behavior.

** Section 2.2. Typo. s/heirarchical/hierarchical/

** Section 2.3.  It would be helpful if the precise mechanism to signal the Protocol-Origin was cited. 

-- I believe it is Section 5.2.2 of [I-D.ietf-pce-segment-routing-policy-cp]

-- I didn’t find any reference to a “Protocol Origin” or this section in [I-D.ietf-idr-segment-routing-te-policy].

** Section 2.4. 
  When signaling is via BGP SR Policy, the ASN and Node Address are
  provided by BGP (refer to [I-D.ietf-idr-segment-routing-te-policy])
  on the headend.

[I-D.ietf-idr-segment-routing-te-policy] needs to be a normative reference (as stated before due to the text in Section 2.1)

** Section 2.5.    Per “When provisioning is via configuration, this is an implementation's configuration model-specific unique identifier for a candidate path”, what is a “configuration model-model-specific unique identifier?  What scope of the uniqueness?

** Section 2.13.  This section says “the information model is the following”, but I don’t follow where that information model (IM) is per the definition in RFC3444.  The text here appears be an example with hard-coded parameter values.

** Section 4. 
  Based on the desired dataplane, either the MPLS label stack or the
  SRv6 Segment Routing Header [RFC8754] is built from the Segment- 
    List.

Do SRv6 SRH and MPLS label stacks support all the segment types enumerated here?  For example, does Type E and F, IPv4 segments, work with a SRv6 SRH?

** Section 4.
  When the algorithm is not specified for the SID types above which
  optionally allow for it, the headend SHOULD use the Strict Shortest
  Path algorithm if available; otherwise, it SHOULD use the default
  Shortest Path algorithm.  The specification of the algorithm enables
  the use of the IGP Flex Algorithm [I-D.ietf-lsr-flex-algo] specific
  SIDs in SR Policy.

Does this imply that [I-D.ietf-lsr-flex-algo] should be a normative reference?

** Section 10.  Given that this document has a dependency on [I-D.ietf-idr-segment-routing-te-policy] and [I-D.ietf-pce-segment-routing-policy-cp] to concrete implement SR Policy, their security considerations should apply.
2022-02-16
17 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2022-02-16
17 Alvaro Retana
[Ballot discuss]
(1) This specification should formally Update rfc8402.

What is the relationship between this document and rfc8402?  If this document
details the …
[Ballot discuss]
(1) This specification should formally Update rfc8402.

What is the relationship between this document and rfc8402?  If this document
details the concept introduced in rfc8402, why isn't there a formal Update
relationship?

Even the initial definition of SR Policy in this document (§2) doesn't match
what rfc8402 says.  This document defines it as "a framework that enables the
instantiation of an ordered list of segments", while rfc8402 states it is "an
ordered list of segments."  In §2.2, this document uses the term
"segment-list" for that.

Besides the general topic of clarifying and updating what an SR Policy is, this
document also includes other items that were not present in rfc8402; the list
includes:

  §2.1: "SR Policy MUST be identified through the tuple ."  There's not even a mention of "color" in rfc8402.

  §2.1: "The headend is specified as an IPv4 or IPv6 address and is expected
  to be unique in the domain."  Neither the mechanism to identify a node nor
  the expectation is present in rfc8402.

  §2.1: "The endpoint is specified as an IPv4 or IPv6 address and is expected
  to be unique in the domain."  Same as above.


The SR Database is a new element not in the base architecture.  The text in §3
says that "use of the SR-DB for computation and validation of SR Policies is
outside the scope of this document", but it is then mentioned and used in
§5.1/§5.2.


Accordingly, the added details require additional Security and Manageability
considerations.


I couldn't find a related discussion in the archive.  If I missed it, please
point me in the right direction.



(2) §5.1:

  Types A or B MUST be used for the SIDs for which the reachability
  cannot be verified.  Note that the first SID MUST always be reachable
  regardless of its type.

These two requirements and the text in the description of these types ("...does
not require the headend to perform SID resolution.") results in a
contradiction: Types A and B are not to be resolved, but if they are the first
SID then they MUST.  If it's not a contradiction, then Types A and B would not
be allowed to be the first SID, which is not correct because the most
straightforward mechanism to define a path is to list SR-MPLS Labels or SRv6
SIDs.
2022-02-16
17 Alvaro Retana
[Ballot comment]
(0) I support John's DISCUSS.


(1) Is the specification of a headend/endpoint mandatory?  IOW, should the text
in §2.1 about the headend/endpoint being …
[Ballot comment]
(0) I support John's DISCUSS.


(1) Is the specification of a headend/endpoint mandatory?  IOW, should the text
in §2.1 about the headend/endpoint being identified by a unique IPv4 or IPv6
address be normative?


(2) §2.1: "An implementation MAY allow the assignment of a symbolic name
comprising of printable ASCII [RFC0020] [RFC5234] characters"

Why are you normatively limiting the name to be represented in ASCII?  Please
internationalize it - use UTF-8.

§2.6 also has similar text.


(3) §2.1: "Such symbolic names MAY identify an SR Policy when the naming scheme
ensures uniqueness."  In this case, the "MAY" is just stating a fact. 
s/MAY/may


(4) §2.1: "An SR Policy MAY have multiple names...in the scenario where the
headend receives different SR Policy names"  Describing multiple names as the
case where multiple names are received is not helpful.


(5) §2.2: "the endpoints of the constituent SR Policies and the parent SR Policy
MUST be identical"  To avoid confusion, by "endpoints" you mean "headend and
endpoint", right?


(6) §2.3:

  A headend MAY be informed about a candidate path for an SR Policy
    by various means including...

It seems like the "MAY" is only stating a fact -- if so, then s/MAY/may


(7) §2.4: "When signaling is via PCEP...the AS number SHOULD be set to 0 by
default when not available or known."

When is it ok for the ASN to not be set to 0 (when not available or known)? 
If that possibility exists, the PCE can use any value (including the real
number or a random one).  What issues exist with uncoordinated (or rogue) PCEs
using potentially arbitrary ASNs?

Why is this action recommended and not required?


(8) This paragraph in §2.5 seems to be missing something"

  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:

"below" where?  I guess you may mean "below in §2.6 (Identification of a
Candidate Path)", but that section says that the "tuple
uniquely identifies a candidate
path" and not just the discriminator as above.

Also, the ":" leads to some text about the default and specific protocols.
Given that this document intends to provide an architecture, I would expect
general consideration about the discriminator, and not pointers to how it can
be signaled or, much less, the process in BGP.  In general, I would expect the
architecture to not rely on solution documents to explain how pieces of the
architecture are derived.


(9) Given the description, it seems possible for a PCE (for example) to
advertise multiple candidate paths with the same Preference, Originator, and
Discriminator.  If that occurs, what is the result of the selection in §2.9?
Would this situation result in multiple active candidate paths?


(10) §2.11: "Only the active candidate path SHOULD be used for forwarding
traffic that is being steered onto that policy."  When is it ok to use
non-active paths?  Why is this action recommended and not required?


(11) §2.12: Several of the "MAY" statements in this section express a fact, not
a normative statement:  s/MAY/may

The operator MAY set this field...
An SR Policy MAY comprise multiple...


(12) §4:

  When the algorithm is not specified for the SID types above which
  optionally allow for it, the headend SHOULD use the Strict Shortest
  Path algorithm if available; otherwise, it SHOULD use the default
  Shortest Path algorithm.

In this sentence, you're recommending both algorithms.  When should one or the
other be used?  There are no qualifiers that lead to the "otherwise" statement.


(13) §4: What is the purpose of enumerating the types of segment-descriptors?
Should the type be indicated when the Segment-List is signaled?  I assume the
answer is yes, but I didn't see that specified anywhere.


(14) §5.1: "The headend detects a mismatch between the SID value and its
context provided for SIDs of type C-through-K"  What does having a mismatch
mean?  Please be specific.


(15) §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].

This action (ask the PCE) is a solution, not an architectural description.  Are
there other external mechanisms that can find a "solution Segment-List"?  It
seems to me that one such mechanism would be in the form of a configured
Segment-List.  If that is correct, please generalize the normative statement
above -- where using PCEP can be an example.


(16) §7: Which are valid states?  Active is one, the text mentions an
"administrative state", what else?  Interoperability is a good reason to
specify the states and not assume that implementations might do the right thing.


(17) §7: "The SR Policy state MUST also reflect the reason when a policy and/or
its candidate path is not active due to validation errors or not being
preferred."

Given that this is a requirement, please provide a list of reasons.  The need
for interoperability (by using rfc2119 language) can only be achieved if the
reasons are standardized.


(18) In general, the text contains a mixture of normative language (rfc2119)
and descriptions that make the contents inconsistent and confusing.  For
example, my interpretation of "an SR Policy and its BSID are removed from the
forwarding plane" (from §8.1) is that it is an absolute requirement.  However,
§8.2 presents the optional "Drop-Upon-Invalid behavior" which then indicates
that there can be cases where my interpretation was not correct.

The point here is that the text in a Standards Track document should not be up
for interpretation.

There are too many cases in the text to list that would have benefitted from
using Normative Language -- I mentioned a couple above.  Ideally, the authors
would make one more pass for clarity.  However, I will probably end up
ABSTAINing because of it.

This point was also raised in the rtg-dir review, which is why I'm not
including it as part of a DISCUSS.
2022-02-16
17 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2022-02-16
17 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-02-16
17 Zaheduzzaman Sarker
[Ballot comment]
Thanks for the efforts on this specification.

This might be due to my lack of expertise on SR policy but it is not …
[Ballot comment]
Thanks for the efforts on this specification.

This might be due to my lack of expertise on SR policy but it is not clear to me how to resolve policy conflicts where preferences and priority are same for policies. It would be nice if you point me information I am missing as I could not resolve it by reading this specification. This might be that the scenario I am having in mind never occurs.
2022-02-16
17 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2022-02-16
17 John Scudder
[Ballot comment]
As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have.

1. I see that Cullen …
[Ballot comment]
As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I’d like to talk about it a little more: why have you chosen to restrict symbolic names to ASCII? UTF-8 is the more usual choice in this context; indeed implementations may have to go to extra effort to scrub their input to insure that only ASCII is present. BCP 18 doesn’t require you to internationalize your strings, of course, it gives you two options, of which you have (sort of, you don't have the "US-") followed the latter:

  This document does not mandate a policy on name internationalization,
  but requires that all protocols describe whether names are
  internationalized or US-ASCII.

But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough to invite the question.

If you do stick with ASCII as currently written, might you add text mandating that implementations scrub their input to prevent non-ASCII characters from being accepted?
2022-02-16
17 John Scudder Ballot comment text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don't see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.

I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don't see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.


- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?

If that's so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.


- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?

And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.


- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?



If that’s so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.


- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?



If that’s so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?



If that’s so, then the rationale given for the requested track must be wrong.And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?



If that’s so, then the rationale given for the requested track must be wrong. And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder Ballot discuss text updated for John Scudder
2022-02-16
17 John Scudder
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a …
[Ballot discuss]
I’ve done an initial review of this document and have several concerns I’d like to discuss. I apologize for not also providing a full review as comments in this ballot, I judged it more important to begin the discussion about these points timely, than to provide all comments in a single message.

1. The shepherd writeup indicates that “Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy instantiation and the egress/destination of the policy termination.”



I realize it’s unusual to ask to discuss a shepherd writeup rather than the spec itself, but I think this one rises to the level. My concern is that this description (needing interoperability between the ingress and the egress) doesn’t comport with my understanding of the Segment Routing architecture. Surely, one of the key value propositions of SR is that it’s stateless everywhere other than the headend? Indeed, that’s stated in the abstract. SR doesn’t require the egress to even understand that it IS an egress of a SR Policy, it just does what the headers tell it to, right?



If that’s so, then the rationale given for the requested track must be wrong. :-( And that in turn leads me to ask, whether the track really is right. It seems to me that in most respects this is more an Informational document than a standards track one. That’s not a value judgement in any respect, just a statement of fact — for the most part, it doesn’t seem as though the information found in this document is needed in order to interoperate with another system. (Section 8.8 is an exception, I discuss that separately.)



Anyway, not to get too far ahead of myself, let’s start by working on this question: is the shepherd writeup correct in saying that interoperability between headend and tailend is required? If so, can someone please characterize the nature of that interoperability, and put it in the context of SR’s stateless nature?

2. It seems to me an unusual practice for this document to be defining semantics and even reserving values in a field allocated by a different document, by a different WG. I’m referring here to the so-called “‘Color-Only’ bits” discussed in Section 8.8. 



- I would be more comfortable if the work were all done in one place, to the extent possible.

- Given the fact this document is reaching in to a registry normally managed by IDR, was there any discussion with the IDR group? I don’t see any evidence of a courtesy notification of the last call when I look at the IDR mailing list archive.



I’ve also emailed the IDR list about this in connection with draft-ietf-idr-segment-routing-te-policy, see https://mailarchive.ietf.org/arch/msg/idr/yCcZdStmTR-FLUYGHTsLLBv5aWo/



Relating this back to my previous question, it’s evident that if this document is going to define semantics for the Color Extended Community Flags, then that makes it Standards Track because there is an interoperability factor to take into account (that's been imported from IDR). A more ideal solution would be to take care of that in the IDR document rather than putting it in this “architecture” document, though. Surely, this kind of detail is implementation, not architecture?
 Indeed, Ketan said in his reply to Matthew Bocci's RTG review, "Given that this is an architecture document, it describes the architecture and not really the protocol mechanisms"... but this section seems to be an exception to that aspiration.

3. Related to the above, at least one of the references listed as informational clearly has to be normative with the document as it stands. draft-ietf-idr-segment-routing-te-policy is the one I’m thinking of, for example its use in §2.4 seems like it may rise to the "normative" level, §2.5 almost surely does, §4.1 surely does, and §8.8.1 is the icing on the cake because this document defines semantics for a field that isn’t even allocated until and unless draft-ietf-idr-segment-routing-te-policy is published.


4. In §2.1 you talk about the signaling of symbolic names for candidate paths. Although you are careful to say that such symbolic names are only used for presentation purposes, it seems to me they still could be considered a new potential source of vulnerability, since a string that has no sanity-checking whatsoever applied by the protocol can display literally anything to an operator viewing it. Shouldn’t this be addressed in your Security Considerations? (For an example of a related Security Considerations, see RFC 9003. It’s probably not the best example, but it’s the one I had at my fingertips…)
2022-02-16
17 John Scudder
[Ballot comment]
As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have.

1. I see that Cullen …
[Ballot comment]
As noted in my DISCUSS, these comments are unfinished but I thought I’d give you what I have.

1. I see that Cullen Jennings referred to this in his ART review, but I’d like to talk about it a little more: why have you chosen to restrict symbolic names to ASCII? UTF-8 is the more usual choice in this context; indeed implementations may have to go to extra effort to scrub their input to insure that only ASCII is present. BCP 18 doesn’t require you to internationalize your strings, of course, it gives you two options, of which you have (sort of, you don't have the "US-") followed the latter:

  This document does not mandate a policy on name internationalization,
  but requires that all protocols describe whether names are
  internationalized or US-ASCII.

But in 2022 the choice to restrict symbolic names to ASCII seems unusual enough to invite comment.

If you do stick with ASCII as currently written, might you add text mandating that implementations scrub their input to prevent non-ASCII characters from being accepted?
2022-02-16
17 John Scudder [Ballot Position Update] New position, Discuss, has been recorded for John Scudder
2022-02-16
17 Jim Guichard
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

  Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the policy source / controller of the
  policy instantiation and the traffic head end as the destination of the policy termination.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Segment Routing [RFC8402] 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.

Working Group Summary:

This document is a foundation for segment routing policy concepts and steering techniques into an SR policy. It has been largely reviewed, commented on and supported by the working group.

Document Quality:

The document is well written with many examples of policy concepts and steering techniques.

Personnel:

The Document Shepherd is James N Guichard.
The Responsible Area Director is Martin Vigoureux.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed before and after the WGLC.  Numerous comments and suggested textual improvements sent and were addressed by the document editor.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns as the document has been widely reviewed by the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Each author and contributor has replied to the IPR call on the mailing list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Two IPR disclosure have been filed by the same vendor. No WG discussion on this IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

This document has been largely reviewed and received large support, both from vendors and network operators. It has multiple implementations and deployments.

The specification has several implementations for many years. The following are the links to the whitepapers released publicly by EANTC:

https://eantc.de/fileadmin/eantc/downloads/events/2017-2020/MPLS2018/EANTC-MPLSSDNNFV2018-WhitePaper-final.pdf
https://eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf
https://eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf

Note that these whitepapers do not explicitly reference the draft. Rather, they reference BGP-SRTE, PCEP or Netconf based mechanisms for provisioning/signaling of SR Policies.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Idnits has been run and any errors have been corrected.
Internet-Drafts Checklist done.
Shepherd has reviewed the draft and made comments. Those have been addressed by the editor.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, Yang model, media type or URI type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. All normative references are active RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations are consistent with the body of the document. No additional comments or concerns.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document contains a "Guidance for Designated Experts" section.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document has no sections written in formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not define a YANG module but makes reference to I-D.ietf-spring-sr-policy-yang section-11 as part of the manageability considerations.

2022-02-16
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-02-16
17 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-17.txt
2022-02-16
17 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-02-16
17 Ketan Talaulikar Uploaded new revision
2022-02-15
16 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Many thanks to Cullen Jennings for his review: https://mailarchive.ietf.org/arch/msg/art/beMjluUNRnbT8PWBIQ35pATPVBg/, which I understand will be …
[Ballot comment]
Thank you for the work on this document.

Many thanks to Cullen Jennings for his review: https://mailarchive.ietf.org/arch/msg/art/beMjluUNRnbT8PWBIQ35pATPVBg/, which I understand will be addressed in the next revision of the draft.

Francesca
2022-02-15
16 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2022-02-15
16 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document, I have a few minor suggestions that may improve the readability of this document.

  Segment Routing (SR) …
[Ballot 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
2022-02-15
16 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2022-02-13
16 Carlos Jesús Bernardos Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Bernardos. Sent review to list.
2022-02-10
16 Erik Kline
[Ballot comment]
[S1; nit]

* The sentence starting with "While" appears to be sentence fragment.

  perhaps just: ".  While" -> ", while"

[S2.1; nit] …
[Ballot comment]
[S1; nit]

* The sentence starting with "While" appears to be sentence fragment.

  perhaps just: ".  While" -> ", while"

[S2.1; nit]

* s/null address/unspecified address/

* s/comprising of/comprising/  (though see UTF-8 comment below)

[S2.1, 2.6; comment]

* It seems unnecessarily restrictive to require names be in ASCII.  How
  about RFC 5198/UTF-8?  If these names are purely for human consumption
  anyway, I wonder if isn't best to allow the humans to name things in
  their native language(s)... (I'm not sure if BCP 18 applies here.)

[S4; question]

* For each of the uses of "IPv4 Prefix" and "IPv6 Global Prefix" should
  there be an additional "Unicast" qualifier before "Prefix"?  If multicast
  prefixes are acceptable or understand (somehow) to be out of scope, then
  no worries.

[S8; nit]

* s/of where come/of which some/?
2022-02-10
16 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2022-02-06
16 Cullen Jennings Request for Last Call review by ARTART Completed: Ready. Reviewer: Cullen Jennings. Sent review to list.
2022-02-03
16 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2022-02-03
16 Bernie Volz Request for Telechat review by INTDIR is assigned to Zhen Cao
2022-02-03
16 Bernie Volz Request for Telechat review by INTDIR is assigned to Zhen Cao
2022-02-03
16 Bernie Volz Request for Telechat review by INTDIR is assigned to Carlos Bernardos
2022-02-03
16 Bernie Volz Request for Telechat review by INTDIR is assigned to Carlos Bernardos
2022-02-03
16 Éric Vyncke Requested Telechat review by INTDIR
2022-02-01
16 Éric Vyncke Requested Telechat review by INTDIR
2022-01-31
16 Cindy Morgan Placed on agenda for telechat - 2022-02-17
2022-01-31
16 Martin Vigoureux Ballot has been issued
2022-01-31
16 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2022-01-31
16 Martin Vigoureux Created "Approve" ballot
2022-01-31
16 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2022-01-31
16 Martin Vigoureux Ballot writeup was changed
2022-01-28
16 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-16.txt
2022-01-28
16 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-01-28
16 Ketan Talaulikar Uploaded new revision
2022-01-28
15 Luc André Burdet Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Matthew Bocci.
2022-01-26
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2022-01-26
15 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-15.txt
2022-01-26
15 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2022-01-26
15 Ketan Talaulikar Uploaded new revision
2022-01-14
14 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Matthew Bocci
2022-01-14
14 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Matthew Bocci
2022-01-13
14 John Scudder Assignment of request for Last Call review by RTGDIR to John Scudder was rejected
2022-01-13
14 Haomian Zheng Request for Last Call review by RTGDIR is assigned to John Scudder
2022-01-13
14 Haomian Zheng Request for Last Call review by RTGDIR is assigned to John Scudder
2022-01-13
14 Haomian Zheng Assignment of request for Last Call review by RTGDIR to Manav Bhatia was withdrawn
2022-01-12
14 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Manav Bhatia
2022-01-12
14 Haomian Zheng Request for Last Call review by RTGDIR is assigned to Manav Bhatia
2022-01-12
14 Haomian Zheng Assignment of request for Last Call review by RTGDIR to Lou Berger was withdrawn
2021-12-30
14 Barry Leiba Request for Last Call review by ARTART is assigned to Cullen Jennings
2021-12-30
14 Barry Leiba Request for Last Call review by ARTART is assigned to Cullen Jennings
2021-12-30
14 Barry Leiba Assignment of request for Last Call review by ARTART to Bernard Aboba was marked no-response
2021-11-24
14 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-11-23
14 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2021-11-23
14 Michelle Cotton
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-spring-segment-routing-policy-14. If any part of this review is inaccurate, please let …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-spring-segment-routing-policy-14. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there is a single action which we must complete.

A new registry is to be created called the Segment Types registry. The new registry will be created on the Segment Routing registry page located at:

https://www.iana.org/assignments/segment-routing/

The registry consists of alphabetical identifiers A to Z and may be extended on exhaustion with the identifiers AA to AZ, BA to BZ and so on through till ZZ. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-------+-----------------------------------------------+---------------+ | Value | Description | Reference |
+-------+-----------------------------------------------+---------------+
| A | SR-MPLS Label | [ RFC-To-be ] |
| B | SRv6 SID | [ RFC-To-be ] |
| C | IPv4 Prefix with optional SR Algorithm | [ RFC-To-be ] |
| D | IPv6 Global Prefix with optional SR Algorithm | [ RFC-To-be ] |
| | for SR-MPLS | |
| E | IPv4 Prefix with Local Interface ID | [ RFC-To-be ] |
| F | IPv4 Addresses for link endpoints as Local, | [ RFC-To-be ] |
| | Remote pair | |
| G | IPv6 Prefix and Interface ID for link | [ RFC-To-be ] |
| | endpoints as Local, Remote pair for SR-MPLS | |
| H | IPv6 Addresses for link endpoints as Local, | [ RFC-To-be ] |
| | Remote pair for SR-MPLS | |
| I | IPv6 Global Prefix with optional SR Algorithm | [ RFC-To-be ] |
| | for SRv6 | |
| J | IPv6 Prefix and Interface ID for link | [ RFC-To-be ] |
| | endpoints as Local, Remote pair for SRv6 | |
| K | IPv6 Addresses for link endpoints as Local, | [ RFC-To-be ] |
| | Remote pair for SRv6 | |
+-------+-----------------------------------------------+---------------+

The IANA Functions Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Michelle Cotton
IANA Services
2021-11-23
14 Benjamin Schwartz Request for Last Call review by SECDIR Completed: Ready. Reviewer: Benjamin Schwartz. Sent review to list.
2021-11-16
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2021-11-16
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Nagendra Nainar
2021-11-12
14 David Schinazi Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: David Schinazi. Sent review to list.
2021-11-12
14 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2021-11-12
14 Jean Mahoney Request for Last Call review by GENART is assigned to David Schinazi
2021-11-11
14 Barry Leiba Request for Last Call review by ARTART is assigned to Bernard Aboba
2021-11-11
14 Barry Leiba Request for Last Call review by ARTART is assigned to Bernard Aboba
2021-11-11
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Schwartz
2021-11-11
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Schwartz
2021-11-10
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-11-10
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-11-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-spring-segment-routing-policy@ietf.org, james.n.guichard@futurewei.com, martin.vigoureux@nokia.com, spring-chairs@ietf.org, spring@ietf.org …
The following Last Call announcement was sent out (ends 2021-11-24):

From: The IESG
To: IETF-Announce
CC: draft-ietf-spring-segment-routing-policy@ietf.org, james.n.guichard@futurewei.com, martin.vigoureux@nokia.com, spring-chairs@ietf.org, spring@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Segment Routing Policy Architecture) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Segment Routing Policy
Architecture'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-11-24. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-policy/


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3184/
  https://datatracker.ietf.org/ipr/3185/





2021-11-10
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-11-10
14 Cindy Morgan Last call announcement was generated
2021-11-10
14 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Lou Berger
2021-11-10
14 Luc André Burdet Request for Last Call review by RTGDIR is assigned to Lou Berger
2021-11-10
14 Martin Vigoureux Requested Last Call review by RTGDIR
2021-11-10
14 Martin Vigoureux Last call was requested
2021-11-10
14 Martin Vigoureux Ballot approval text was generated
2021-11-10
14 Martin Vigoureux Ballot writeup was generated
2021-11-10
14 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-11-09
14 Martin Vigoureux Last call announcement was generated
2021-10-25
14 (System) Changed action holders to Martin Vigoureux (IESG state changed)
2021-10-25
14 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-10-25
14 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-14.txt
2021-10-25
14 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-10-25
14 Ketan Talaulikar Uploaded new revision
2021-10-04
13 (System) Changed action holders to Clarence Filsfils, Martin Vigoureux, Dan Voyer, Paul Mattes, Alex Bogdanov, Ketan Talaulikar (IESG state changed)
2021-10-04
13 Martin Vigoureux IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-09-14
13 (System) Changed action holders to Martin Vigoureux (IESG state changed)
2021-09-14
13 Martin Vigoureux IESG state changed to AD Evaluation from Publication Requested
2021-05-28
13 Jim Guichard
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy
instantiation and the egress/destination of the policy termination.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Segment Routing [RFC8402] 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.

Working Group Summary:

This document is a foundation for segment routing policy concepts and steering techniques into an SR policy. It has been largely reviewed, commented on and supported by the working group.

Document Quality:

The document is well written with many examples of policy concepts and steering techniques.

Personnel:

The Document Shepherd is James N Guichard.
The Responsible Area Director is Martin Vigoureux.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed before and after the WGLC.  Numerous comments and suggested textual improvements sent and were addressed by the document editor.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns as the document has been widely reviewed by the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Each author and contributor has replied to the IPR call on the mailing list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Two IPR disclosure have been filed by the same vendor. No WG discussion on this IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

This document has been largely reviewed and received large support, both from vendors and network operators. It has multiple implementations and deployments.

The specification has several implementations for many years. The following are the links to the whitepapers released publicly by EANTC:

https://eantc.de/fileadmin/eantc/downloads/events/2017-2020/MPLS2018/EANTC-MPLSSDNNFV2018-WhitePaper-final.pdf
https://eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf
https://eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf

Note that these whitepapers do not explicitly reference the draft. Rather, they reference BGP-SRTE, PCEP or Netconf based mechanisms for provisioning/signaling of SR Policies.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Idnits has been run and any errors have been corrected.
Internet-Drafts Checklist done.
Shepherd has reviewed the draft and made comments. Those have been addressed by the editor.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, Yang model, media type or URI type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. All normative references are active RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations are consistent with the body of the document. No additional comments or concerns.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document contains a "Guidance for Designated Experts" section.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document has no sections written in formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not define a YANG module but makes reference to I-D.ietf-spring-sr-policy-yang section-11 as part of the manageability considerations.

2021-05-28
13 Jim Guichard Responsible AD changed to Martin Vigoureux
2021-05-28
13 Jim Guichard IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2021-05-28
13 Jim Guichard IESG state changed to Publication Requested from I-D Exists
2021-05-28
13 Jim Guichard IESG process started in state Publication Requested
2021-05-28
13 Jim Guichard Tag Doc Shepherd Follow-up Underway cleared.
2021-05-28
13 Jim Guichard IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Consensus: Waiting for Write-Up
2021-05-28
13 Jim Guichard Changed consensus to Yes from Unknown
2021-05-28
13 Jim Guichard Intended Status changed to Proposed Standard from None
2021-05-28
13 Jim Guichard
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

Standard Track is requested and indicated in the title page header. This is appropriate for a specification of packet steering into an SR policy needing interoperability between the ingress/source of the policy
instantiation and the egress/destination of the policy termination.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  Segment Routing [RFC8402] 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.

Working Group Summary:

This document is a foundation for segment routing policy concepts and steering techniques into an SR policy. It has been largely reviewed, commented on and supported by the working group.

Document Quality:

The document is well written with many examples of policy concepts and steering techniques.

Personnel:

The Document Shepherd is James N Guichard.
The Responsible Area Director is Martin Vigoureux.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document has been reviewed before and after the WGLC.  Numerous comments and suggested textual improvements sent and were addressed by the document editor.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

No. There have been a lot of reviews and comments from SPRING contributors and all outstanding comments have been addressed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain
parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns as the document has been widely reviewed by the WG.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Each author and contributor has replied to the IPR call on the mailing list.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

Two IPR disclosure have been filed by the same vendor. No WG discussion on this IPR.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

This document has been largely reviewed and received large support, both from vendors and network operators. It has multiple implementations and deployments.

The specification has several implementations for many years. The following are the links to the whitepapers released publicly by EANTC:

https://eantc.de/fileadmin/eantc/downloads/events/2017-2020/MPLS2018/EANTC-MPLSSDNNFV2018-WhitePaper-final.pdf
https://eantc.de/fileadmin/eantc/downloads/News/2019/EANTC-MPLSSDNNFV2019-WhitePaper-v1.2.pdf
https://eantc.de/fileadmin/eantc/downloads/events/MPLS2020/EANTC-MPLSSDNNFV2020-WhitePaper.pdf

Note that these whitepapers do not explicitly reference the draft. Rather, they reference BGP-SRTE, PCEP or Netconf based mechanisms for provisioning/signaling of SR Policies.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

Idnits has been run and any errors have been corrected.
Internet-Drafts Checklist done.
Shepherd has reviewed the draft and made comments. Those have been addressed by the editor.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

The document has no MIB, Yang model, media type or URI type.

(13) Have all references within this document been identified as either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

No. All normative references are active RFCs.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The IANA considerations are consistent with the body of the document. No additional comments or concerns.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

The document contains a "Guidance for Designated Experts" section.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

The document has no sections written in formal language.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

The document does not define a YANG module but makes reference to I-D.ietf-spring-sr-policy-yang section-11 as part of the manageability considerations.

2021-05-28
13 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-13.txt
2021-05-28
13 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-05-28
13 Ketan Talaulikar Uploaded new revision
2021-05-24
12 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-12.txt
2021-05-24
12 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-05-24
12 Ketan Talaulikar Uploaded new revision
2021-05-10
11 Jim Guichard Tag Doc Shepherd Follow-up Underway set.
2021-05-10
11 Jim Guichard IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2021-05-10
11 Jim Guichard Notification list changed to james.n.guichard@futurewei.com because the document shepherd was set
2021-05-10
11 Jim Guichard Document shepherd changed to Jim Guichard
2021-04-30
11 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-11.txt
2021-04-30
11 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-04-30
11 Ketan Talaulikar Uploaded new revision
2021-04-27
10 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-10.txt
2021-04-27
10 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2021-04-27
10 Ketan Talaulikar Uploaded new revision
2021-04-15
09 Jim Guichard IETF WG state changed to In WG Last Call from WG Document
2020-11-10
09 Shuping Peng Added to session: IETF-109: spring  Wed-1200
2020-11-01
09 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-09.txt
2020-11-01
09 (System) New version accepted (logged-in submitter: Ketan Talaulikar)
2020-11-01
09 Ketan Talaulikar Uploaded new revision
2020-07-27
08 Shuping Peng Added to session: IETF-108: spring  Mon-1100
2020-07-08
08 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-08.txt
2020-07-08
08 (System) New version approved
2020-07-07
08 (System) Request for posting confirmation emailed to previous authors: Alex Bogdanov , spring-chairs@ietf.org, Daniel Voyer , Clarence Filsfils , Siva Sivabalan , Paul Mattes
2020-07-07
08 Ketan Talaulikar Uploaded new revision
2020-05-07
07 Mike Koldychev New version available: draft-ietf-spring-segment-routing-policy-07.txt
2020-05-07
07 (System) New version approved
2020-05-07
07 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , Daniel Voyer , Alex Bogdanov , Siva Sivabalan
2020-05-07
07 Mike Koldychev Uploaded new revision
2020-05-06
07 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , Daniel Voyer , Siva Sivabalan , Alex Bogdanov
2020-05-06
07 Mike Koldychev Uploaded new revision
2019-12-15
06 Siva Sivabalan New version available: draft-ietf-spring-segment-routing-policy-06.txt
2019-12-15
06 (System) New version approved
2019-12-15
06 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , Daniel Voyer , Alex Bogdanov , Siva Sivabalan
2019-12-15
06 Siva Sivabalan Uploaded new revision
2019-11-17
05 Siva Sivabalan New version available: draft-ietf-spring-segment-routing-policy-05.txt
2019-11-17
05 (System) New version approved
2019-11-17
05 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , Daniel Voyer , Alex Bogdanov , Siva Sivabalan
2019-11-17
05 Siva Sivabalan Uploaded new revision
2019-11-04
04 Siva Sivabalan New version available: draft-ietf-spring-segment-routing-policy-04.txt
2019-11-04
04 (System) New version approved
2019-11-04
04 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , Daniel Voyer , Alex Bogdanov , Siva Sivabalan
2019-11-04
04 Siva Sivabalan Uploaded new revision
2019-05-12
03 Siva Sivabalan New version available: draft-ietf-spring-segment-routing-policy-03.txt
2019-05-12
03 (System) New version approved
2019-05-12
03 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , " bogdanov@google.com" , " daniel.voyer@bell.ca" , Siva Sivabalan
2019-05-12
03 Siva Sivabalan Uploaded new revision
2019-04-25
02 (System) Document has expired
2018-10-22
02 Siva Sivabalan New version available: draft-ietf-spring-segment-routing-policy-02.txt
2018-10-22
02 (System) New version approved
2018-10-22
02 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , " bogdanov@google.com" , " daniel.voyer@bell.ca" , Siva Sivabalan
2018-10-22
02 Siva Sivabalan Uploaded new revision
2018-07-06
01 Bruno Decraene Added to session: IETF-102: spring  Mon-1330
2018-06-11
01 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-01.txt
2018-06-11
01 (System) New version approved
2018-06-11
01 (System) Request for posting confirmation emailed to previous authors: Paul Mattes , Clarence Filsfils , " bogdanov@google.com" , " daniel.voyer@bell.ca" , Siva Sivabalan
2018-06-11
01 Ketan Talaulikar Uploaded new revision
2018-06-07
00 Rob Shakir This document now replaces draft-filsfils-spring-segment-routing-policy instead of None
2018-06-07
00 Ketan Talaulikar New version available: draft-ietf-spring-segment-routing-policy-00.txt
2018-06-07
00 (System) WG -00 approved
2018-06-04
00 Ketan Talaulikar Set submitter to "Ketan Talaulikar ", replaces to draft-filsfils-spring-segment-routing-policy and sent approval email to group chairs: spring-chairs@ietf.org
2018-06-04
00 Ketan Talaulikar Uploaded new revision