Segment Routing over IPv6 (SRv6) Network Programming
draft-ietf-spring-srv6-network-programming-28

[Ballot comment]
The -27 resolved my Discuss point from the -26; thank you.

I retain my other comments from the -26 unchanged, below, for posterity.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[note: I originally prepared these comments when looking at the -24.  I
tried to remove comments about things fixed in the -25 or -26, but may
have missed a couple; please ignore any such already-addressed comments.
There are also a couple points that we have already been discussing in
the other thread but I retain as a "placeholder"; hopefully we can keep
the actual discussion about them in just one place.]

As mentioned in the Discuss section, I did a lot of background reading
while preparing this updated ballot position.  Another thing I noticed
while doing that reading is that the pseudocode in
https://tools.ietf.org/html/rfc8754#section-4.3.1.1 explicitly mentions
"perform TLV processing"; we might consider repeating that step in our
pseudocode procedures, and otherwise making our procedures as analogous
as possible to the RFC 8754 procedures, just from the perspective of
keeping the writing style as consistent as possible across the related
documents.  However, that's entirely an editorial matter and thus left
to the discretion of the authors/AD.

Section 2

  The following terms used within this document are defined in
  [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint
  Node, Reduced SRH, Segments Left and Last Entry.

It's slightly unfortunate that 8754 didn't have a dedicated terminology
section containing these, though it's too late to really do anything
about it now.

Section 3

  The term "function" refers to the bit-string in the SRv6 SID.  The
  term "behavior" identifies the behavior bound to the SID.  The
  behaviors are defined in Section 4 of this document.

(nit) using "the behaviors" to some extent implies that these are the
only ones allowed or defined, which is not true.  Perhaps "some
behaviors" would be more accurate (or some other phrasing would also
cover the expected evolution of the ecosystem)?

Section 3.3

  A packet could be steered to a non-routed SID 2001:db8:b:2:101:: by
  using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...>
  where the non-routed SID is preceded by a routed SID to the same
  node.  Routed and non-routed SRv6 SIDs are the SRv6 instantiation of
  global and local segments, respectively [RFC8402].

If it's (also) possible to steer a packet to a non-routed SID without a
preceding routed SID for the same node (e.g., via End.X), it seems like
that might be worth listing an example of as well.  Otherwise a reader
might assume that the global segment is a necessary part of using the
non-routed SID.

Section 4

  End.DT2U          Endpoint with decaps and unicast MAC L2table lookup
                    e.g. EVPN Bridging unicast use-case

(nit) we seem to put a space in "L2 table" the other times it appears.

  The list is not exhaustive.  In practice, any function can be
  attached to a local SID: e.g. a node N can bind a SID to a local VM
  or container which can apply any complex processing on the packet.

(nit) the preceding list was a list of well-known behaviors, not a list
of functions.  IIUC, it is more appropriate to use "behavior" here than
"function", since the "function" is just the opaque bitstring.

Section 4.1.1, ...

  When processing the Upper-layer Header of a packet matching a FIB
  entry locally instantiated as an SRv6 End SID do the following:

(editorial, I think) I find it interesting to compare the phrasing here
to what was used in §4.1 (when processing an SRH), where the text is
"receives a packet whose IPv6 DA is S and S is a local End SID".  Why
the distinction between "End SID" and 'SRv6 End SID"?  IIUC the
distinction between checking "IPv6 DA" and "matching a FIB entry locally
instantiated" is important and the language should not be harmonized
between occurrences.
The "..." in the Section number listing indicates that this (or similar)
phrasing appears throughout, whenever we talk about processing an
upper-layer header.

Section 4.2

  Note that if N has an outgoing interface bundle I to a neighbor Q
  made of 10 member links, N may allocate up to 11 End.X local SIDs:
  one for the bundle itself and then up to one for each Layer-2 member
  link.  The flows steered using the End.X SID corresponding to the

(nit) I think that while "up to 11" might be the situation that makes
the most sense (in that having many distinct subgroups with 1 < n < 10
member links doesn't make sense), it is not strictly speaking a physical
or protocol requirement.  Perhaps "might allocate 11" is better than
"may allocate up to 11" for that reason.

Section 4.4, ...

  When N receives a packet destined to S and S is a local End.DX6 SID,
  N does the following processing:

(nit) we have a mismatch of "N does the following processing" (like
appears here) and "N does" or similar; it is probably worth normalizing
on one phrasing.

  When processing the Upper-layer header of a packet matching a FIB
  entry locally instantiated as an SRv6 End.DX6 SID, the following is
  done:

Similarly here, we use "the following is done" but the "N does the
following" phrasing used in some other sections is probably preferred,
as it avoids the passive voice.

Section 4.12

We might give some mnemonic explanation for how the name "FE2" was
chosen to identify the argument value.

  table T flooding.  The allocation of the argument values is local to
  the SR Endpoint Node instantiating this behavior and the signaling of
  the argument to other nodes for the EVPN functionality via control
  plane.

nit(?): s/via control plane/occurs via the control plane/?

Section 4.13

  S05.  If (IPv6 Hop Limit <= 1) {
  S06.      Send an ICMP Time Exceeded message to the Source Address,
              Code 0 (Hop limit exceeded in transit),

(nit) the indentation seems off by one space in the first line of S06
(it doesn't match the other two places where this chunk occurs).

  S14.  The SRH MAY be omitted when the SRv6 Policy B only contains one
  SID and there is no need to use any flag, tag or TLV.
  S17.  The Payload Length, Traffic Class, Hop Limit and Next-Header
  fields are set as per [RFC2473].  The Flow Label is computed as per
  [RFC6437].

(These look to be S15 and S18, respectively, now.)

Section 4.14

  The SRH MAY be omitted when the SRv6 Policy only contains one segment
  and there is no need to use any flag, tag or TLV.

(nit) it's probably worth harmonizing the phrasing between here and the
note on S15 in §4.13 (specifically, "only contains one SID" vs "only
contains one segment").

Section 4.15

(nit) there's a blank line at the end of S06 that doesn't occur in the
other two locations where this pseudocode appears.

  S16.  Submit the packet to the MPLS engine for transmission to the
            topmost label.

(nit) I suggest rewording slightly so as to not imply that the node to
transmit to is determined by the topmost label -- IIUC it's determined
by the MPLS policy, since the interpretation of the label is in general
local to the receiving node.

Section 4.16.1.2

  As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
  within the SR Domain [RFC8402].  Within this framework, the
  Authentication Header (AH) is not used to secure the SRH as described
  in Section 7.5 of [RFC8754].

(repeating from the previous thread as a placeholder) I think we need
another sentence or clause here to clarify why this statement is
relevant, e.g., "Thus, while the AH can detect changes to the IPv6
header chain, it will not be used in combination with the SRH, so use of
PSP will not cause delivery failure due to AH validation checks."

Section 5

(editorial) This is the first place in the document that we talk about
the "headend" or its policy at all, so a bit of background on why it's
useful to tabulate potential headend policy/behaviors might be helpful.

Section 5.x

Tying the other policies more precisely to the pseudocode for H.Encaps
(e.g., replacing S01) seems like it would be useful, to avoid the
appearance of specifying behavior by appealing to examples.

Section 5.1

  Note:
  S03: As described in [RFC6437] (IPv6 Flow Label Specification).

We need to pull in RFC 2473 for payload length, traffic class, and
next-header, IIUC.  (hop-limit is covered a few paragraphs down.) Also
to say how the next-header value is selected.

Section 8.1

  The presence of SIDs in the IGP does not imply any routing semantics
  to the addresses represented by these SIDs.  The routing reachability
  to an IPv6 address is solely governed by the non-SID-related IGP
  prefix reachability information that includes locators.  Routing is
  neither governed nor influenced in any way by a SID advertisement in
  the IGP.

It seems like this is trying to say "the IGP must not advertise prefixes
contained within the LOC part of an SID", but in a very roundabout way.

Section 8.3

  The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V,
  End.DT2U and End.DT2M SIDs can be signaled in BGP.

Since we said earlier that the signaling of SIDs needs to include the
behavior codepoint for each function bitstring, it seems like we should
provide a reference to how BGP will encode the behavior codepoint.

Section 9

There seem to be some security considerations relating to the use of
PSP, in that the egress node loses visibility into which policy was used
for a given packet, so all packets from all policies that egress via
that SID are in the same anonymity (and policy!) set.  In particular,
even if an HMAC TLV was present in the SRH, it is not available and
cannot be validated.  I recognize that the headend (or whatever entity
is assigning SR policy) should know when such validation would be
intended to occur and not assign a policy incompatible with it, but
there are still new considerations in the sense that the headend needs
to be aware of these considerations.

(repeating as a placeholder from the previous thread) I think we should
also say that in the absence of the HMAC TLV, valid FUNC and ARG values
on any given node may be guessable and spoofable, along with the
standard disclaimer that risks are minimal since all nodes in the SR
domain are assumed to be trusted.  This is distinct from the
already-extant ability to spoof a SID in that the underlying structure
in the SID may allow the attacker to induce behavior that was never
intended to be a SID, for example if the implementation logically
separates FUNC and ARG processing and the attacker makes a combination
that was never advertised.

Also, IIUC, the "Segments Left == 0" handling for, e.g., End.X is
important to prevent traffic loops -- if a node fails to perform that
check and blindly sends the packet to the interconnect it will get
returned to that node/SID and loop until the IP hop limit is exhausted.

[Ballot comment]
The -26 resolved my Discuss point from the -25; thank you.

I retain my other comments from the -25 unchanged, below, for posterity.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

[note: I originally prepared these comments when looking at the -24.  I
tried to remove comments about things fixed in the -25 or -26, but may
have missed a couple; please ignore any such already-addressed comments.
There are also a couple points that we have already been discussing in
the other thread but I retain as a "placeholder"; hopefully we can keep
the actual discussion about them in just one place.]

As mentioned in the Discuss section, I did a lot of background reading
while preparing this updated ballot position.  Another thing I noticed
while doing that reading is that the pseudocode in
https://tools.ietf.org/html/rfc8754#section-4.3.1.1 explicitly mentions
"perform TLV processing"; we might consider repeating that step in our
pseudocode procedures, and otherwise making our procedures as analogous
as possible to the RFC 8754 procedures, just from the perspective of
keeping the writing style as consistent as possible across the related
documents.  However, that's entirely an editorial matter and thus left
to the discretion of the authors/AD.

Section 2

  The following terms used within this document are defined in
  [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint
  Node, Reduced SRH, Segments Left and Last Entry.

It's slightly unfortunate that 8754 didn't have a dedicated terminology
section containing these, though it's too late to really do anything
about it now.

Section 3

  The term "function" refers to the bit-string in the SRv6 SID.  The
  term "behavior" identifies the behavior bound to the SID.  The
  behaviors are defined in Section 4 of this document.

(nit) using "the behaviors" to some extent implies that these are the
only ones allowed or defined, which is not true.  Perhaps "some
behaviors" would be more accurate (or some other phrasing would also
cover the expected evolution of the ecosystem)?

Section 3.3

  A packet could be steered to a non-routed SID 2001:db8:b:2:101:: by
  using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...>
  where the non-routed SID is preceded by a routed SID to the same
  node.  Routed and non-routed SRv6 SIDs are the SRv6 instantiation of
  global and local segments, respectively [RFC8402].

If it's (also) possible to steer a packet to a non-routed SID without a
preceding routed SID for the same node (e.g., via End.X), it seems like
that might be worth listing an example of as well.  Otherwise a reader
might assume that the global segment is a necessary part of using the
non-routed SID.

Section 4

  End.DT2U          Endpoint with decaps and unicast MAC L2table lookup
                    e.g. EVPN Bridging unicast use-case

(nit) we seem to put a space in "L2 table" the other times it appears.

  The list is not exhaustive.  In practice, any function can be
  attached to a local SID: e.g. a node N can bind a SID to a local VM
  or container which can apply any complex processing on the packet.

(nit) the preceding list was a list of well-known behaviors, not a list
of functions.  IIUC, it is more appropriate to use "behavior" here than
"function", since the "function" is just the opaque bitstring.

Section 4.1.1, ...

  When processing the Upper-layer Header of a packet matching a FIB
  entry locally instantiated as an SRv6 End SID do the following:

(editorial, I think) I find it interesting to compare the phrasing here
to what was used in §4.1 (when processing an SRH), where the text is
"receives a packet whose IPv6 DA is S and S is a local End SID".  Why
the distinction between "End SID" and 'SRv6 End SID"?  IIUC the
distinction between checking "IPv6 DA" and "matching a FIB entry locally
instantiated" is important and the language should not be harmonized
between occurrences.
The "..." in the Section number listing indicates that this (or similar)
phrasing appears throughout, whenever we talk about processing an
upper-layer header.

Section 4.2

  Note that if N has an outgoing interface bundle I to a neighbor Q
  made of 10 member links, N may allocate up to 11 End.X local SIDs:
  one for the bundle itself and then up to one for each Layer-2 member
  link.  The flows steered using the End.X SID corresponding to the

(nit) I think that while "up to 11" might be the situation that makes
the most sense (in that having many distinct subgroups with 1 < n < 10
member links doesn't make sense), it is not strictly speaking a physical
or protocol requirement.  Perhaps "might allocate 11" is better than
"may allocate up to 11" for that reason.

Section 4.4, ...

  When N receives a packet destined to S and S is a local End.DX6 SID,
  N does the following processing:

(nit) we have a mismatch of "N does the following processing" (like
appears here) and "N does" or similar; it is probably worth normalizing
on one phrasing.

  When processing the Upper-layer header of a packet matching a FIB
  entry locally instantiated as an SRv6 End.DX6 SID, the following is
  done:

Similarly here, we use "the following is done" but the "N does the
following" phrasing used in some other sections is probably preferred,
as it avoids the passive voice.

Section 4.12

We might give some mnemonic explanation for how the name "FE2" was
chosen to identify the argument value.

  table T flooding.  The allocation of the argument values is local to
  the SR Endpoint Node instantiating this behavior and the signaling of
  the argument to other nodes for the EVPN functionality via control
  plane.

nit(?): s/via control plane/occurs via the control plane/?

Section 4.13

  S05.  If (IPv6 Hop Limit <= 1) {
  S06.      Send an ICMP Time Exceeded message to the Source Address,
              Code 0 (Hop limit exceeded in transit),

(nit) the indentation seems off by one space in the first line of S06
(it doesn't match the other two places where this chunk occurs).

  S14.  The SRH MAY be omitted when the SRv6 Policy B only contains one
  SID and there is no need to use any flag, tag or TLV.
  S17.  The Payload Length, Traffic Class, Hop Limit and Next-Header
  fields are set as per [RFC2473].  The Flow Label is computed as per
  [RFC6437].

(These look to be S15 and S18, respectively, now.)

Section 4.14

  The SRH MAY be omitted when the SRv6 Policy only contains one segment
  and there is no need to use any flag, tag or TLV.

(nit) it's probably worth harmonizing the phrasing between here and the
note on S15 in §4.13 (specifically, "only contains one SID" vs "only
contains one segment").

Section 4.15

(nit) there's a blank line at the end of S06 that doesn't occur in the
other two locations where this pseudocode appears.

  S16.  Submit the packet to the MPLS engine for transmission to the
            topmost label.

(nit) I suggest rewording slightly so as to not imply that the node to
transmit to is determined by the topmost label -- IIUC it's determined
by the MPLS policy, since the interpretation of the label is in general
local to the receiving node.

Section 4.16.1.2

  As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
  within the SR Domain [RFC8402].  Within this framework, the
  Authentication Header (AH) is not used to secure the SRH as described
  in Section 7.5 of [RFC8754].

(repeating from the previous thread as a placeholder) I think we need
another sentence or clause here to clarify why this statement is
relevant, e.g., "Thus, while the AH can detect changes to the IPv6
header chain, it will not be used in combination with the SRH, so use of
PSP will not cause delivery failure due to AH validation checks."

Section 5

(editorial) This is the first place in the document that we talk about
the "headend" or its policy at all, so a bit of background on why it's
useful to tabulate potential headend policy/behaviors might be helpful.

Section 5.x

Tying the other policies more precisely to the pseudocode for H.Encaps
(e.g., replacing S01) seems like it would be useful, to avoid the
appearance of specifying behavior by appealing to examples.

Section 5.1

  Note:
  S03: As described in [RFC6437] (IPv6 Flow Label Specification).

We need to pull in RFC 2473 for payload length, traffic class, and
next-header, IIUC.  (hop-limit is covered a few paragraphs down.) Also
to say how the next-header value is selected.

Section 8.1

  The presence of SIDs in the IGP does not imply any routing semantics
  to the addresses represented by these SIDs.  The routing reachability
  to an IPv6 address is solely governed by the non-SID-related IGP
  prefix reachability information that includes locators.  Routing is
  neither governed nor influenced in any way by a SID advertisement in
  the IGP.

It seems like this is trying to say "the IGP must not advertise prefixes
contained within the LOC part of an SID", but in a very roundabout way.

Section 8.3

  The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V,
  End.DT2U and End.DT2M SIDs can be signaled in BGP.

Since we said earlier that the signaling of SIDs needs to include the
behavior codepoint for each function bitstring, it seems like we should
provide a reference to how BGP will encode the behavior codepoint.

Section 9

There seem to be some security considerations relating to the use of
PSP, in that the egress node loses visibility into which policy was used
for a given packet, so all packets from all policies that egress via
that SID are in the same anonymity (and policy!) set.  In particular,
even if an HMAC TLV was present in the SRH, it is not available and
cannot be validated.  I recognize that the headend (or whatever entity
is assigning SR policy) should know when such validation would be
intended to occur and not assign a policy incompatible with it, but
there are still new considerations in the sense that the headend needs
to be aware of these considerations.

(repeating as a placeholder from the previous thread) I think we should
also say that in the absence of the HMAC TLV, valid FUNC and ARG values
on any given node may be guessable and spoofable, along with the
standard disclaimer that risks are minimal since all nodes in the SR
domain are assumed to be trusted.  This is distinct from the
already-extant ability to spoof a SID in that the underlying structure
in the SID may allow the attacker to induce behavior that was never
intended to be a SID, for example if the implementation logically
separates FUNC and ARG processing and the attacker makes a combination
that was never advertised.

Also, IIUC, the "Segments Left == 0" handling for, e.g., End.X is
important to prevent traffic loops -- if a node fails to perform that
check and blindly sends the packet to the interconnect it will get
returned to that node/SID and loop until the IP hop limit is exhausted.

[Ballot discuss]
Thanks for the updates through to the -26; they help a lot.
However, I do think there is one final Discuss-level point that needs to
be resolved: it's mostly a process point, to make sure that what we say
in this document complies to the requirements that were laid out in RFC
8754 for the procedure we're trying to follow.  Specifically, in the
process of trying to finalize my review comments, I ended up doing a lot
of background reading, in which I noticed that RFC 8754 says:

  New SIDs defined in the future MUST specify the mutability properties
  of the Flags, Tag, and Segment List and indicate how the Hashed
  Message Authentication Code (HMAC) TLV (Section 2.1.2) verification
  works.  Note that, in effect, these fields are mutable.

This is a bit confusing to me, in that the SIDs themselves appear as
entries in the Segment List, and it's not quite clear when or how a
per-SID behavior relating to fields in the containing SRH might come
into play.  However, given that we allocate a behavior codepoint for
"the SID defined in RFC 8754", I am forced to conclude that the
behaviors specified in this document meet the definition of "new SIDs"
that are being defined "in the future" (from the reference point of RFC
8754), and therefore that they must specify the indicated properties.
I'm told out of band that the intent is to do the same thing that RFC
8754 does for the SID it defines, and so this should be trivial to
resolve just by adding a brief note that (e.g.) "the SIDs specified in
this document have the same HMAC TLV handling and mutability properties
of the Flags, Tag, and Segment List field as the SID specified in RFC
8754".  However, I believe that such an explicit statement is required,
and that we would introduce an internal inconsistency between this
document and RFC 8754 if we say nothing on this topic.  In particular, I
think that we would not inherit that behavior as some kind of default
behavior if we make no statement at all.

I am sorry that I did not notice this earlier, but I feel that it is
important to remain consistent with the requirements of RFC 8754 and
thus that this is appropriate to raise as a Discuss-level point, even if
I have previously reviewed the text in question.

[Ballot comment]
[note: I originally prepared these comments when looking at the -24.  I
tried to remove comments about things fixed in the -25 or -26, but may
have missed a couple; please ignore any such already-addressed comments.
There are also a couple points that we have already been discussing in
the other thread but I retain as a "placeholder"; hopefully we can keep
the actual discussion about them in just one place.]

As mentioned in the Discuss section, I did a lot of background reading
while preparing this updated ballot position.  Another thing I noticed
while doing that reading is that the pseudocode in
https://tools.ietf.org/html/rfc8754#section-4.3.1.1 explicitly mentions
"perform TLV processing"; we might consider repeating that step in our
pseudocode procedures, and otherwise making our procedures as analogous
as possible to the RFC 8754 procedures, just from the perspective of
keeping the writing style as consistent as possible across the related
documents.  However, that's entirely an editorial matter and thus left
to the discretion of the authors/AD.

Section 2

  The following terms used within this document are defined in
  [RFC8754]: SRH, SR Source Node, Transit Node, SR Segment Endpoint
  Node, Reduced SRH, Segments Left and Last Entry.

It's slightly unfortunate that 8754 didn't have a dedicated terminology
section containing these, though it's too late to really do anything
about it now.

Section 3

  The term "function" refers to the bit-string in the SRv6 SID.  The
  term "behavior" identifies the behavior bound to the SID.  The
  behaviors are defined in Section 4 of this document.

(nit) using "the behaviors" to some extent implies that these are the
only ones allowed or defined, which is not true.  Perhaps "some
behaviors" would be more accurate (or some other phrasing would also
cover the expected evolution of the ecosystem)?

Section 3.3

  A packet could be steered to a non-routed SID 2001:db8:b:2:101:: by
  using a SID list <...,2001:db8:b:1:100::,2001:db8:b:2:101::,...>
  where the non-routed SID is preceded by a routed SID to the same
  node.  Routed and non-routed SRv6 SIDs are the SRv6 instantiation of
  global and local segments, respectively [RFC8402].

If it's (also) possible to steer a packet to a non-routed SID without a
preceding routed SID for the same node (e.g., via End.X), it seems like
that might be worth listing an example of as well.  Otherwise a reader
might assume that the global segment is a necessary part of using the
non-routed SID.

Section 4

  End.DT2U          Endpoint with decaps and unicast MAC L2table lookup
                    e.g. EVPN Bridging unicast use-case

(nit) we seem to put a space in "L2 table" the other times it appears.

  The list is not exhaustive.  In practice, any function can be
  attached to a local SID: e.g. a node N can bind a SID to a local VM
  or container which can apply any complex processing on the packet.

(nit) the preceding list was a list of well-known behaviors, not a list
of functions.  IIUC, it is more appropriate to use "behavior" here than
"function", since the "function" is just the opaque bitstring.

Section 4.1.1, ...

  When processing the Upper-layer Header of a packet matching a FIB
  entry locally instantiated as an SRv6 End SID do the following:

(editorial, I think) I find it interesting to compare the phrasing here
to what was used in §4.1 (when processing an SRH), where the text is
"receives a packet whose IPv6 DA is S and S is a local End SID".  Why
the distinction between "End SID" and 'SRv6 End SID"?  IIUC the
distinction between checking "IPv6 DA" and "matching a FIB entry locally
instantiated" is important and the language should not be harmonized
between occurrences.
The "..." in the Section number listing indicates that this (or similar)
phrasing appears throughout, whenever we talk about processing an
upper-layer header.

Section 4.2

  Note that if N has an outgoing interface bundle I to a neighbor Q
  made of 10 member links, N may allocate up to 11 End.X local SIDs:
  one for the bundle itself and then up to one for each Layer-2 member
  link.  The flows steered using the End.X SID corresponding to the

(nit) I think that while "up to 11" might be the situation that makes
the most sense (in that having many distinct subgroups with 1 < n < 10
member links doesn't make sense), it is not strictly speaking a physical
or protocol requirement.  Perhaps "might allocate 11" is better than
"may allocate up to 11" for that reason.

Section 4.4, ...

  When N receives a packet destined to S and S is a local End.DX6 SID,
  N does the following processing:

(nit) we have a mismatch of "N does the following processing" (like
appears here) and "N does" or similar; it is probably worth normalizing
on one phrasing.

  When processing the Upper-layer header of a packet matching a FIB
  entry locally instantiated as an SRv6 End.DX6 SID, the following is
  done:

Similarly here, we use "the following is done" but the "N does the
following" phrasing used in some other sections is probably preferred,
as it avoids the passive voice.

Section 4.12

We might give some mnemonic explanation for how the name "FE2" was
chosen to identify the argument value.

  table T flooding.  The allocation of the argument values is local to
  the SR Endpoint Node instantiating this behavior and the signaling of
  the argument to other nodes for the EVPN functionality via control
  plane.

nit(?): s/via control plane/occurs via the control plane/?

Section 4.13

  S05.  If (IPv6 Hop Limit <= 1) {
  S06.      Send an ICMP Time Exceeded message to the Source Address,
              Code 0 (Hop limit exceeded in transit),

(nit) the indentation seems off by one space in the first line of S06
(it doesn't match the other two places where this chunk occurs).

  S14.  The SRH MAY be omitted when the SRv6 Policy B only contains one
  SID and there is no need to use any flag, tag or TLV.
  S17.  The Payload Length, Traffic Class, Hop Limit and Next-Header
  fields are set as per [RFC2473].  The Flow Label is computed as per
  [RFC6437].

(These look to be S15 and S18, respectively, now.)

Section 4.14

  The SRH MAY be omitted when the SRv6 Policy only contains one segment
  and there is no need to use any flag, tag or TLV.

(nit) it's probably worth harmonizing the phrasing between here and the
note on S15 in §4.13 (specifically, "only contains one SID" vs "only
contains one segment").

Section 4.15

(nit) there's a blank line at the end of S06 that doesn't occur in the
other two locations where this pseudocode appears.

  S16.  Submit the packet to the MPLS engine for transmission to the
            topmost label.

(nit) I suggest rewording slightly so as to not imply that the node to
transmit to is determined by the topmost label -- IIUC it's determined
by the MPLS policy, since the interpretation of the label is in general
local to the receiving node.

Section 4.16.1.2

  As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
  within the SR Domain [RFC8402].  Within this framework, the
  Authentication Header (AH) is not used to secure the SRH as described
  in Section 7.5 of [RFC8754].

(repeating from the previous thread as a placeholder) I think we need
another sentence or clause here to clarify why this statement is
relevant, e.g., "Thus, while the AH can detect changes to the IPv6
header chain, it will not be used in combination with the SRH, so use of
PSP will not cause delivery failure due to AH validation checks."

Section 5

(editorial) This is the first place in the document that we talk about
the "headend" or its policy at all, so a bit of background on why it's
useful to tabulate potential headend policy/behaviors might be helpful.

Section 5.x

Tying the other policies more precisely to the pseudocode for H.Encaps
(e.g., replacing S01) seems like it would be useful, to avoid the
appearance of specifying behavior by appealing to examples.

Section 5.1

  Note:
  S03: As described in [RFC6437] (IPv6 Flow Label Specification).

We need to pull in RFC 2473 for payload length, traffic class, and
next-header, IIUC.  (hop-limit is covered a few paragraphs down.) Also
to say how the next-header value is selected.

Section 8.1

  The presence of SIDs in the IGP does not imply any routing semantics
  to the addresses represented by these SIDs.  The routing reachability
  to an IPv6 address is solely governed by the non-SID-related IGP
  prefix reachability information that includes locators.  Routing is
  neither governed nor influenced in any way by a SID advertisement in
  the IGP.

It seems like this is trying to say "the IGP must not advertise prefixes
contained within the LOC part of an SID", but in a very roundabout way.

Section 8.3

  The End.DX4, End.DX6, End.DT4, End.DT6, End.DT46, End.DX2, End.DX2V,
  End.DT2U and End.DT2M SIDs can be signaled in BGP.

Since we said earlier that the signaling of SIDs needs to include the
behavior codepoint for each function bitstring, it seems like we should
provide a reference to how BGP will encode the behavior codepoint.

Section 9

There seem to be some security considerations relating to the use of
PSP, in that the egress node loses visibility into which policy was used
for a given packet, so all packets from all policies that egress via
that SID are in the same anonymity (and policy!) set.  In particular,
even if an HMAC TLV was present in the SRH, it is not available and
cannot be validated.  I recognize that the headend (or whatever entity
is assigning SR policy) should know when such validation would be
intended to occur and not assign a policy incompatible with it, but
there are still new considerations in the sense that the headend needs
to be aware of these considerations.

(repeating as a placeholder from the previous thread) I think we should
also say that in the absence of the HMAC TLV, valid FUNC and ARG values
on any given node may be guessable and spoofable, along with the
standard disclaimer that risks are minimal since all nodes in the SR
domain are assumed to be trusted.  This is distinct from the
already-extant ability to spoof a SID in that the underlying structure
in the SID may allow the attacker to induce behavior that was never
intended to be a SID, for example if the implementation logically
separates FUNC and ARG processing and the attacker makes a combination
that was never advertised.

Also, IIUC, the "Segments Left == 0" handling for, e.g., End.X is
important to prevent traffic loops -- if a node fails to perform that
check and blindly sends the packet to the interconnect it will get
returned to that node/SID and loop until the IP hop limit is exhausted.

[Ballot comment]
Thanks for responding to the SECDIR review (and thank you to Brian Weis for doing it)

Thanks for addressing my DISCUSS and COMMENTs.

===[ remaining COMMENTs
** Section 4.1.  Pseudo-code without formal definition might be open to interpretation.  My nits (which likely apply to other sections) are that:
-- it might not be clear that S03, S06 and S10 are effectively returns/exits from this “behavior”, and if they are run, S12-S15 should never be reached (otherwise Segments Left or Hop Limit = -1)

-- (for consistency) the IF … ELSEIF … END construct is used in Section 4.8, but not here.

[Ballot discuss]
[edited to remove nonsensical point that had crept in about the SRH being a new extension
header; it's "just" a routing header]

The current requirement that IANA-assigned SRv6 Endpoint Behavior
codepoints are used, with no range reserved for local assignment, seems
to be inviting codepoint squatting from the nominally reserved range.
Why is there an absolute requirement for registration (even FCFS)
without ranges for local or experimental use?  (What are the various
reserved ranges reserved for?)

The (normative) pseudocode does not seem to handle the case when the SRH
is omitted for the degenerate case where there is only a single segment,
or for the PSP flavor.

The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext
Len is measured in units of 8 octets, and does not include the first 8
octets of the extension header, but Payload Length is measured in
octets.  Literally decreasing the Payload Length by the Hdr Ext Len
value will produce a malformed IPv6 packet.

If "PSP operation is deterministically controlled by the SR Source
Node", why do we need to define behavior codepoints that (for example)
use both PSP and USP?  I don't see how there is full determinism in this
case while being different from the "PSP only" flavor.

There are numerous factual errors and un/under-specified protocol
behavior (see COMMENT), including: how to set the outer Hop Limit
(multiple instances), the order of segments in the SRH, specification of
headend behavior by reference to informal example, L2 frame
en/decapsulation procedures, and the "Opaque" note for endpoint behavior
65535.

[Ballot discuss]
The current requirement that IANA-assigned SRv6 Endpoint Behavior
codepoints are used, with no range reserved for local assignment, seems
to be inviting codepoint squatting from the nominally reserved range.
Why is there an absolute requirement for registration (even FCFS)
without ranges for local or experimental use?  (What are the various
reserved ranges reserved for?)

The (normative) pseudocode does not seem to handle the case when the SRH
is omitted for the degenerate case where there is only a single segment,
or for the PSP flavor.

The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext
Len is measured in units of 8 octets, and does not include the first 8
octets of the extension header, but Payload Length is measured in
octets.  Literally decreasing the Payload Length by the Hdr Ext Len
value will produce a malformed IPv6 packet.

If "PSP operation is deterministically controlled by the SR Source
Node", why do we need to define behavior codepoints that (for example)
use both PSP and USP?  I don't see how there is full determinism in this
case while being different from the "PSP only" flavor.

There are numerous factual errors and un/under-specified protocol
behavior (see COMMENT), including: how to set the outer Hop Limit
(multiple instances), the order of segments in the SRH, specification of
headend behavior by reference to informal example, L2 frame
en/decapsulation procedures, and the "Opaque" note for endpoint behavior
65535.

A discussion topic, which may or may not entail changes to this
document: RFC 8200 notes that specifications of new extension headers
need to indicate their ordering constraints with respect to the other
extension headers, but RFC 8754 makes no such indications.  Are there in
practice ordering constraints that we should attempt to document?

[Ballot comment]
I note that this document references
draft-filsfils-spring-srv6-net-pgm-illustration, which uses
the IPv4 CIDR 20/8 in examples instead of addresses from the RFC 5737
range.  It would be disappointing to have a PS refer to a draft that
squats on the IPv4 namespace in such a manner.

Abstract, Introduction

  This document defines the SRv6 Network Programming concept and
  specifies the base set of SRv6 behaviors that enables the creation of
  interoperable overlays with underlay optimization (Service Level
  Agreements).

I don't understand what the parenthetical is intending to convey.

Section 2

  The following terms used within this document are defined in
  [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
  SID, SR Policy, Prefix SID, and Adjacency SID.

[RFC 8402 spells it Prefix-SID (with hyphen) and Adj-SID.]

Section 3

The text allegedly reproduced from RFC 8754 §4.3 differs in case and
hyphenation.

Section 3.1

  This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
  where a locator (LOC) is encoded in the L most significant bits of
  the SID, followed by F bits of function (FUNCT) and A bits of
  arguments (ARG).  L, the locator length, is flexible, and an operator
  is free to use the locator length of their choice.  F and A may be
  any value as long as L+F+A <= 128.  When L+F+A is less than 128 then
  the remaining bits of the SID MUST be zero.

Why does A have to be a fixed value; can't it safely be a function of F
(even if we exclude things like huffman coding for F)?

  An SRv6 Segment Endpoint Behavior may require additional information
  for its processing (e.g. related to the flow or service).  This
  information may be encoded in the ARG bits of the SID.

(Assuming that it can be sufficiently compactly encoded?)

  The ARG value of a routed SID SHOULD remain constant among packets in
  a given flow.  Varying ARG values among packets in a flow may result

(Thus limiting the type of information that can be represented in the
ARG?)

Section 3.2

  SIDs.  The provider historically deployed IPv6 and assigned
  infrastructure addresses from a portion of the fc00::/7 prefix.  They
  further subdivided the prefix into three /48 prefixes (Country X,
  Country Y, Country Z) to support their SRv6 infrastructure.  From
  those /48 prefixes each router is assigned a /64 prefix from which
  all SIDs of that router are allocated.

This is not the language I would have expected for use of the ULA
address range.  It looks like this may be related to Erik Kline's
Discuss point...

  IPv6 address consumption in both these examples is minimal,
  representing one billionth and one millionth of the assigned address
  space, respectively.

I'm not sure I understand the calculation that produced these values.

  An SR Source Node cannot infer the behavior by examination of the
  FUNCT value of a SID.

  Therefore, the SRv6 Endpoint Behavior codepoint is advertised along
  with the SID in the control plane.

These two sentences feel a little out of place in this spot, occurring
after previous discussion that the endpoint behavior codepoint is
advertised in the control plane.

  o  At Router 3, within the locator 2001:db8:bbbb:3::/64, network
      operator or the router performs dynamic assignment for:

nit: missing article ("the network operator").

      *  Function 100 associated with the behavior End.X (Endpoint with
        cross-connect) between router 3 and its connected neighbor
        router, for example Router 4.  This function is encoded as
        16-bit value and has no arguments.

Please clarify that "function 100" is a hex literal.

I also suggest noting clearly at the start of the example that F is 16
and A is 0.

      *  Function 101 associated with the behavior End.X (Endpoint with
        cross-connect) between router 3 and its connected neighbor
        router, for example Router 2.  This function is encoded as
        16-bit value and has no arguments.

F is a constant for the SR domain; saying it at each SID assignment is
misleading.

[same note about hex for 101]

Section 4

  The list is not exhaustive.  In practice, any function can be
  attached to a local SID: e.g. a node N can bind a SID to a local VM
  or container which can apply any complex processing on the packet.

Yes, but it can't advertise the behavior corresponding to that function
without a codepoint.

Section 4.1.1

  When processing the Upper-layer Header of a packet matching a FIB
  entry locally instantiated as an SRv6 End SID, if Upper-layer Header
  processing is allowed by local configuration (e.g.  ICMPv6), then

nit: the parenthetical is placed so as to apply to "local
configuration", which doesn't really make sense; I presume the intent is
to say that upper-layer header processing is allowed *for that
upper-layer protocol*.  Also, comma after "e.g.".

  problem message to the Source Address and discard the packet.  Error
  code 4 (SR Upper-layer Header Error) and Pointer set to the offset of
  the upper-layer header.

nit: this is not a complete sentence.

Section 4.2

  It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is
  required to express any traffic-engineering policy.

This text reads as if End.X specifically is required for TE, which does
not seem correct to me.

Section 4.4, 4.5

                                        This is equivalent to the per-CE
  VPN label in MPLS [RFC4364].

The phrase "per-CE VPN" does not appear in RFC 4364.

Section 4.5

  S05.  If the End.DX4 SID is bound to an array of L3 adjacencies, then
  one entry of the array is selected based on the hash of the packet's
  header Section 7.

nit: I suggest "(see Section 7)" to match section 4.4.

Section 4.6, 4.7

  is required.  This is equivalent to the per-VRF VPN label in MPLS
  [RFC4364].

The phrase "per-VRF VPN" does not appear in RFC 4364.
(A similar comment applies to Section 4.8 as well.)

  Note that an End.DT6 may be defined for the main IPv6 table in which
  case and End.DT6 supports the equivalent of an IPv6inIPv6

nit: s/and/an/

Section 4.7

  The "Endpoint with decapsulation and specific IPv4 table lookup"
  behavior (End.DT4 for short) is a variant of the End behavior.

nit: variant of End.T, just like End.DT6, no?

Section 4.9

  S04.  An End.DX2 behavior could be customized to expect a specific
  IEEE header (e.g.  VLAN tag) and rewrite the egress IEEE header
  before forwarding on the outgoing interface.

Would this customized behavior require a new codepoint?
Similarly for End.DX2V (Section 4.10)

Section 4.10

  S04. Remove the outer IPv6 Header with all its extension headers,
          lookup the exposed VLANs in L2 table T, and forward
          via the matched table entry.

Just to check my understanding: the "exposed VLANs" (plural?!) are in
the Ethernet header of the packet that we are left with after removing
the outer IPv6 header, right?

  S01.  IANA has allocated the Internet Protocol number 143 to Ethernet
  (see Section 10.1).

This seems like a copy/paste leftover from End.DX2 -- we don't mention
143 in this section.

Section 4.12

  Two of the applications of the End.DT2M behavior are the EVPN
  Bridging of broadcast, unknown and multicast (BUM) traffic with
  Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use-
  cases.

Are there references for either/both of these?

  S04. Remove the IPv6 header and all its extension headers

nit: the rest of the document uses "Remove the outer IPv6 header with
all its extension headers".

  S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2

nit: s/one/ones/

  Arg.FE2 is encoded in the SID as an (k*x)-bit value.  These bits
  represent a list of up to k OIFs, each identified with an x-bit
  value.  Values k and x are defined on a per End.DT2M SID basis.  The
  interface identifier 0 indicates an empty entry in the interface
  list.

(editorial) rather than have to come up with the concept of an "empty
entry" in the interface list, I would probably just say that the
identifier 0 is reserved and is ignored when doing the exclusion of
OIFs.

I also think we need to say that the order and identifier assignment of
elements of the interface list (that is, what the x-bit values index
into) is under the local control of N, but has to remain stable as long
as SIDs are advertised that list members of the list in ARG.  (There is
otherwise a great deal of freedom in assignment since the values are
only consumed by the node that advertises them.)

Section 4.13

It's probably worth calling out the MTU considerations of pushing the
new IPv6 header+SRH and tunneling the packets.  (I know we reference
2473 already, but the MTU is pretty important.)

  S17.  The Payload Length, Traffic Class and Next-Header fields are
  set as per [RFC2473].  The Flow Label is computed as per [RFC6437].

How is the Hop Limit set for the outer header?
(I assume §6.3 of RFC 2473, but given that you provide a reference for
all the other fields, it seems like an omission to not mention Hop Limit
as well.)

Section 4.14

  The SRH MAY be omitted when the SRv6 Policy only contains one segment
  and there is no need to use any flag, tag or TLV.

If this is the case does it matter if I use End.B6.Encaps or
End.B6.Encaps.Red?

Section 4.16

I don't think I understand what it would mean for a specific SID to
support the multiple flavors "in combinations".

Section 4.16.1.2

  A penultimate SR Segment Endpoint Node is one that, as part of the
  SID processing, copies the last SID from the SRH into the IPv6
  Destination Address and decrements Segments Left value from one to
  zero.

I think technically it copies the first SID from the SRH (SRH.Segment
List[0]), which is the last SID from the SR Policy.
Also, nit: "the" for "the Segments Left value".

S14.2.      Update the Next Header field in the preceding header to the
                Next Header value of the SRH

nit: personally, I would write "from the SRH", since "next header value
of the SRH" is very close to "next header value of SRH", i.e., 43.

  As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
  within the SR Domain [RFC8402].  Within this framework, the
  Authentication Header (AH) is not used to secure the SRH as described
  in Section 7.5 of [RFC8754].

I strongly recommend adding another sentence clarifying why this is
relevant to discussion of removing an extension header from the packet.

Section 5

  This list can be expanded in case any new functionality requires it.

How?  By an RFC that Updates: this one?

Section 5.x

I agree with the directorate reviewer that the protocol behavior should
be written out explicitly, without reference to the handling of example
packet(s).

Section 5.1

  S03.  Set outer payload length, traffic class and flow label

What about the outer Hop Limit?

  S03: As described in [RFC6437] (IPv6 Flow Label Specification)

Why is this all the way at the bottom of the section instead of included
with the corresponding content?

Section 5.3

  The encapsulating node MUST remove the preamble or frame check
  sequence (FCS) from the Ethernet frame upon encapsulation and the
  decapsulating node MUST regenerate the preamble or FCS before
  forwarding Ethernet frame.

"or"?  I get to choose one or the other?  It's okay to only put back a
preamble but no FCS (or vice versa)?

Section 6

  traffic that matched that SID and was processed correctly.  The
  retrieval of these counters via MIB, NETCONF/YANG or any other means
  is outside the scope of this document.

(editorial) a MIB is an abstract data structure (likewise a YANG
module); information might be retrieved *from* it but not *via* it.  For
*via*, that would be SNMP, NETCONF, and/or RESTCONF.

Section 8.1

Does it make sense to reference RFCs 8491, 8476, 8841, etc. for
advertising MSD via IGP?

  In particular, the SR source (e.g., H.Encaps), intermediate endpoint
  (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6)
  behaviors.  [...]

This is not a complete sentence, and I really have no idea what verb was
intended.

Section 8.2, 8.3

Can we get references for the BGP variants here and their usage for
signaling SRv6 capabilities and (SID,behavior codepoint) pairs?

Section 9

I would really like to have a stronger reference to Section 5 of RFC
8754 where the conceptual model of a SR Domain as a single system, where
all packets in the domain are encapsulated using IPv6 headers [with SIDs
as SA/DA].  The part in brackets is not spelled out very clearly and
could well be expounded upon in this document.  I can write up some
(very ad hoc) ideas for what I had in mind, which you are welcome to
adopt but expected to wordsmith/edit appropriately:

% Section 5 of [RFC8754] describes the SR deployment model and the
% baseline requirements for securing the SR Domain.  In many ways the SR
% Domain is analogous to an MPLS domain -- it's a tightly controlled
% system where packet processing is controlled by a list (or stack) of
% opaque identifiers that, by and large, only have defined semantics in
% the context of the node that receives and processes the packet when
% that identifier is "topmost" or "current".  Experience in securing and
% operating MPLS domains should be readily transferrable to SRv6
% domains, in ensuring that all traffic within the network is tightly
% controlled, with all external inputs being properly encapsulated (for
% SRv6, by an IPv6 header usually with SRH; for MPLS, by the label
% stack).  The dedicated format for the MPLS label stack and label
% identifiers makes a clear mechanical separation between "internal" and
% "external" identifiers. In contrast, SRv6 uses SIDs for the internal
% identifiers, which have format and operation of IPv6 addresses.  While
% this lets SRv6 benefit from IP longest-prefix routing and thus the
% structure of SID values, it also means that there is not a crisp
% mechanical separation between "internal" and "external" identifiers.
% As such, care and rigor in annotating which IPv6 addresses/headers are
% internal vs external is required in order to maintain the integrity
% and security of the SRv6 domain.

There might also be room for discussion (in the main body of the
document) of how the various decapsulation procedures occur precisely
when the packet is leaving the SR Domain.

Having the ARG structure specified as part of the behavior codepoint
registration means that a node that can apply that SID can also spoof
the ARG to force a different (e.g.) outgoing interface list.
Specifically, it gives the attacker a degree of freedom greater than
just the SID behaviors that the node advertises.  The HMAC TLV would
mitigate this to the extent that it limits what SIDs the node in
question is allowed to apply and what changes can be made on-path.

  services.  Additionally, [RFC8754] defines an HMAC TLV permitting SR
  Endpoint Nodes in the SR domain to verify that the SRH applied to a
  packet was selected by an authorized party and to ensure that the
  segment list is not modified after generation, regardless of the
  number of segments in the segment list.  When enabled by local

I suggest adding a sentence similar to "(This does, however, require
that the segment list, and thus, the SRH is present in the packet; the
optional ability to elide the SRH when there is only a single segment
and no flags, tags, or TLVs needed inherently excludes the protection of
the HMAC TLV.)"

Section 10.1

  definition: The value 143 in the Next Header field of an IPv6 header
  or any extension header indicates that the payload is an Ethernet
  [IEEE.802.3_2018].

nit: is there a missing word here ("frame"?)?

[Ballot discuss]
I support Alvaro's and others' discuss points.  I have only a few points
that I think are easily cleared.

[ section 3.2 ]

* I'm a bit concerned about this first example, as it might give the mistaken
  impression that fc00::/7 is free for anyone to carve up as they wish
  (I say this regardless of what this operator may or may not have done).

  Per 4193, operators are supposed to generate random /48s from fd00::/8.

  I think this is easily corrected though, and I'd suggest:

  OLD:

  .....  The provider historically deployed IPv6 and assigned
  infrastructure addresses from a portion of the fc00::/7 prefix.  They
  further subdivided the prefix into three /48 prefixes (Country X,
  Country Y, Country Z) to support their SRv6 infrastructure.  From
  those /48 prefixes each router is assigned a /64 prefix from which
  all SIDs of that router are allocated.

  NEW:

  .....  The provider historically deployed IPv6 and assigned
  infrastructure addresses from ULA space [RFC 4193].  They specifically
  allocated three /48 prefixes (Country X, Country Y, Country Z) to
  support their SRv6 infrastructure.  From those /48 prefixes each router
  was assigned a /64 prefix from which all SIDs of that router are allocated.

[ section 4.16.2 ]

* I'm not sure I understand what the value of specifying USP is.  This looks
  to me like an implementation detail and seems unnecessary.  In all cases
  where the S03 code block is entered it's the processing of the remainder of
  the inner packet that's important, I would think.

  I guess, what's the value of specifying the way in which an implementation
  can begin to process the next header?  Is this for chained SRHs and thus
  resubmitting the inner SRH to the same SID processing (8200 says that the
  RH 'should appear at most once', but that's as strong as the text gets)?

[ section 4.16.3 ]

* This too seems like an implementation detail, and it's not clear what it's
  adding to the document.  But I must be misunderstanding something.

[ section 7 ]

* What flow label is included in hashing where End.DX4 is concerned?  If
  it's the flow label of the outermost IPv6 header, then the same question
  comes to mind for End.X and End.DX6; I'd assumed it would be the inner
  packet's flow label (and src/dst addresses) that would factor into the
  flow hashing.

[ section 8 ]

* Of what value to the ingress node is knowledge of USP or USD behaviour
  at the terminus?  That still seems like exposing an implementation detail.

[Ballot comment]
[[ comments ]]

[ section 3.2 ]

* First, thanks for adding this section; I think it does help.

* Second, thanks for clarifying that Endpoint Behaviour cannot be inferred
  from FUNCT; much improved.


[[ questions ]]

[ section 4 ]

* When an SRv6-capable node receives a packet destined to a locally
  instantiated SID, doesn't it also apply RFC 8754 processing
  (as well as RFC 8200)?

[ section 4.9 ]

* Can an End.DX2 sID be associated with LAG'd set of outgoing interfaces J,
  analogous to the "interface bundle" description for End.X processing?


[[ nits ]]

[ section 6 ]

* "pair of traffic counter" -> "pair of traffic counters"

[Ballot discuss]
I am balloting DISCUSS because I find the document unclear and lacking proper technical details around significant functionality, as reflected in my first 3 points.  The fourth point is related to the registration policy (which doesn't match the definition in rfc8126), and my last point is for the IESG to consider.


(1) Pseudocode and normative behavior

The use of pseudocode was chosen as the mechanism to specify behavior, as explained in §4:

  An implementation of the pseudocode is compliant as long as the externally
  observable wire protocol is as described by the pseudocode.

Clarity in the pseudocode is essential because it is used to determine compliance.  Several places need improvement:

(1a) In §4.1/§4.13/§4.15, the pseudocode is missing an ELSE after S04, to include the error conditions if SL != 0.  A check for an error condition when SL is decremented is also needed.  As written, the pseudocode could process the packet (SL == 0) *and* send an ICMP time exceeded message... :-(

I'm using as a reference the pseudocode in §4.3.1.1/rfc8754, which includes the same initial statement.


(1b) It would be nice if the behavior in §4.1.1 were also specified using pseudocode.  As written, I am not sure if the intent is to process any upper-layer header or only specific ones.  Is the objective for this operation to be similar to the one in §4.3.1.2/rfc8754?  Please be specific on what is meant by "allowed by local configuration".

[Note: this point by itself is not DISCUSS-worthy, but §4.1.1 is used, for different reasons, in some of the other items I point to below.  That is why I include it here.]


(1c) §4.4/§4.6: S01 of the second piece of pseudocode is an instruction for processing a non-IPv6 upper header.  However, earlier in that section, it is specified that the SID "is associated with one or more L3 IPv6 adjacencies/an IPv6 FIB table".  How can the upper header not be IPv6 if the specification explicitly says it has to be?


(1d) §4.5/§4.7 have the same issue but related to IPv4.


(1e) §4.9 also has the same issue when it specifies that "End.DX2 SID...is associated with one outgoing interface I", but allows for the processing of non-ethernet payloads which could then be forwarded through a different outgoing interface.


(1f) §4.11/§4.12 allows the processing of non-ethernet payloads, which will not be "associated with an L2 Table T" as described.



(2) §4.12 describes the only behavior that can carry an ARG.  I don't understand how it works:

      Arg.FE2 is encoded in the SID as an (k*x)-bit value.  These bits
      represent a list of up to k OIFs, each identified with an x-bit
      value.  Values k and x are defined on a per End.DT2M SID basis.  The
      interface identifier 0 indicates an empty entry in the interface
      list.

Let's assume a router has 10 possible OIFs, and the operator uses 4-bit values to identify them; then, the ARG would take 40 bits of the SID.  Is that how the math works?

Assuming my interpretation is correct, for 20 OIFs and 5-bit values we would need 100 bits.  Considering the examples in §3.2, where a /64 is allocated to a router, this behavior wouldn't have enough bits!  I realize that maybe a better encoding would be to use a 20-bit field, each representing an interface.  However, there would still be a limit of < 64 OIFs.  Am I missing something?

I'm trying to ultimately get to the fact that there are limits to this behavior, but they are not described in the document.  Please clearly explain any limitations and any possible workaround.



(3) The description of the flavors in §4.16 is also unclear.

The section starts with this introduction:

  The PSP, USP and USD flavors are variants of the End, End.X and End.T
  behaviors.  For each of these behaviors these flavors MAY be
  supported for a SID either individually or in combinations.

By being "variants", I interpret that the behavior is different than what is specified in §4.1. 


(3a) Some of the behaviors, as listed in Table 4, include an indication of the flavors.  How are the values interpreted?  For example, the Table lists 8 different behaviors related to End:

| 1          | 0x0001 |  End (no PSP, no USP)  |    [This.ID]    |
| 2          | 0x0002 |      End with PSP      |    [This.ID]    |
| 3          | 0x0003 |      End with USP      |    [This.ID]    |
| 4          | 0x0004 |    End with PSP&USP    |    [This.ID]    |
...
| 28          | 0x001C |      End with USD      |    [This.ID]    |
| 29          | 0x001D |    End with PSP&USD    |    [This.ID]    |
| 30          | 0x001E |    End with USP&USD    |    [This.ID]    |
| 31          | 0x001F | End with PSP, USP & USD |    [This.ID]    |

Is value 1 what is specified in §4.1?  Or does it include USD, which is not explicitly excluded)?


(3b) If a behavior with more than one flavor is signaled, how should the receiving node determine which one to apply?  I guess that the application of behaviors 4 or 29 depends on the number of SLs -- the expected behavior should be clearly specified.

(3c) Is it assumed that all nodes support all behaviors?  Are there mandatory to implement behaviors?  Should the behavior be advertised before it is used?

(3d) §4.16.1.2:

  When a SID of PSP-flavor is processed at a non-penultimate SR Segment
  Endpoint Node, the PSP behavior is not performed as described in the
  pseudocode below since Segments Left would not be zero.

For example, for the End behavior, I'm assuming that behavior 1 is performed instead of 2 (or 4, or 29, or 31) if SL != 0.  Should this be done even if the node did not advertise the non-PSP flavor?  If the node is not known to support the PSP flavor, should it be an error to receive a packet requesting that behavior?

If only the PSP flavor is advertised, can the Source assume that the node also supports the non-PSP flavor?

  [BTW, I'm asking about advertisement because §4.16.1.1 makes the statement
  that the nodes "advertise the SIDs instantiated on them via control plane
  protocols as described in Section 9".  Even though §9 talks about control
  plane protocols are "not necessary for an SDN control plane" because "one
  expects the controller to explicitly provision the SIDs".]


(3e) §4.16.2 describes the USP flavor, which is one where the endpoint consumes the packet by processing the next header.  I don't understand how the outcome due to the extended process is different from the original one in §4.1.  Can you please explain?  It seems to me that the externally observable result is the same.

I have the same question about the USD flavor and the externally observable behavior related to §4.1.

In general, the observable behavior of §4.1, USP, and USD seem the same to me.  The next two points are related.


(3f) §4.16.3 describes the USD flavor, which assumes that the decapsulation results in a packet that can be forwarded.  Can the FIB lookup result in a local destination?


(3g) Does the USD flavor mean that, for the End behavior (as described in §4.1), the action of "process the next header in the packet" cannot result in a forwarded packet?  Same question for the USP behavior?


(3h) The last paragraph in §4.16.3:

  An implementation that supports the USD flavor in conjunction with
  the USP flavor MAY optimize the packet processing by first looking
  whether the conditions for the USD flavor are met, in which case it
  can proceed with USD processing else do USP processing.

What are the "conditions for the USD flavor"?  As far as I can tell from the document, the only condition is for the specific behavior to be signaled.  What else?

Going back to the questions above...  When is the option to optimize possible?  Does a specific behavior have to be used?  Behavior 30 (End with USP&USD)?  Or can it also optimize if behavior 3 (End with USP) is signaled?



(4) §10.2 creates a new registry with an "FCFS" registration procedure.  I am assuming that this is the same as the "First Come First Served" (no abbreviation!) policy from rfc8126; please add a reference if that is the case.  The description used is not the same as what rfc8126 specifies:

- "Requests for allocation...must include a...preferably also a brief
  description of how the value will be used."  Using "preferably" indicates
  that a description is optional.  However, it is not optional in rfc8126.

- "...brief description...may be provided with a reference to an Internet
  Draft or an RFC or in some other documentation that is permanently and
  readily available."  There is no such requirement in rfc8126.  For example,
  the "Specification Required" policy requires "a permanent and readily
  available public specification".  Is that what you want  instead?



(5) This point is for the IESG to discuss.

§4.16.1.2:

      The End, End.X and End.T behaviors with PSP do not contravene
      Section 4 of [RFC8200] because the destination address of the
      incoming packet is the address of the node executing the behavior.

The spring WG's interpretation of rfc8200 was a central point in the appeal presented against the WG consensus on this document.  The text above, I believe, reflects that consensus. 

However, given that the document relies on the spring WG's interpretation of rfc8200, I think it would be better if the text is explicit. 

Suggestion: to add at the end of the paragraph>

  This conclusion represents the consensus interpretation of the spring WG.

[Ballot comment]
(1) §3.1:

  An SRv6 endpoint behavior MAY require additional information for its
  processing (e.g. related to the flow or service).  This information
  may be encoded in the ARG bits of the SID.

The sentence is simply stating a fact, not a normative behavior.  s/MAY/may


(2) All the examples in §3.2 have a /48 prefix allocated to the SRv6 deployment (and then /64s per node).  Is it possible to start with a different SRv6 infrastructure allocation, a /64, or /96 maybe?  If so, please include an example.  If not, please explain any limitations.


(3) §4 starts by saying that "Each FIB entry indicates the behavior associated with a SID instance and its parameters."  But the previous section (§3.3. SID Reachability) says that "node N would advertise IPv6 prefix(es) matching the LOC parts covering its SIDs or shorter-mask prefix" (not the behavior).  IOW, §3.3 sets the expectation of an advertisement covering just the LOC, but §4 seems to expect entries that cover the LOC+FUNC.  Which one is correct? 

In the end, it may not matter which entry is in the FIB, as long as the SID is reachable.  However, the specification of the behavior feels sloppy.


(4) §4.9/§4.10: For the S04 step, perhaps decompose it into individual actions (similar to S04-S06 in §4.7).


(5) §4.11/§4.12  "S05. Learn the exposed MAC Source Address..." 

The note related to this step says that in "EVPN, the learning...is done via the control plane"...but here it is done via the data plane.  What, if any, is the effect on EVPN operation?  Are there issues with learning conflicting information from different sources?  It seems to me that it could be relatively easy to spoof the source and create unexpected entries in the L2 table.  Please point to the EVPN documents where this type of operation is considered.


(6) §4.10/§4.11/§4.12 don't have references to the example applications mentioned.  Please add Informative references.


(7) §4.13/§4.15 instantiate a Binding SID, but only in the case where SL != 0.  What about the case where a Binding SID wouldn't require an extra encapsulation (SL == 0)?  Is there a reason that it is not supported in this document?


(8) §5.1: I'm assuming that the last line in this section (the one starting with S03) should be proceeded by "Note:".


(9) §5.1: "The H.Encaps behavior is valid for any kind of Layer-3 traffic."  While it may be used for any kind of traffic, I'm assuming that there will be a policy that determines which traffic is encapsulated using a specific SRv6 policy, right?  Please be specific about that.


(10) §5.3: "Ethernet [IEEE.802.3_2012]"  Please use the reference when Ethernet is first used in the document.  [I have the same question as Rob related to the version of the 802.3 spec.]


(11) §5.3: "...MUST remove the preamble or frame check sequence (FCS) from the Ethernet frame upon encapsulation and the decapsulating node MUST regenerate the preamble or FCS before forwarding Ethernet frame."  Which one?  The preamble can be easily recreated by the receiver, while removing the FCS may be more problematic -- even if the FCS is not checked in transit, it seems that it would be important to carry it.  In any case, the real question here is: why use "or"?  Is it left at the discretion of the encapsulating node?  Are there any considerations when selecting?


(12) All the headend behaviors (§5) include this text:

  The push of the SRH MAY be omitted when the SRv6 Policy only contains
  one segment and there is no need to use any flag, tag or TLV.

If the endpoint behavior indicates the PSP or USP flavors, what should the receiver do?  Clearly there is no SRH to pop.  Is this an error or should the receiver simply ignore the flavor? 


(13) §6: "counter...for traffic that matched that SID and was processed correctly"  Does "processed correctly" include when the result being an ICMP error message?  Or should those be counted separately?


(14) §7: I'm guessing that "flow-based hash" and "load-balancing hash" are the same thing, is that correct?  It would be nice to use consistent terminology.


(15) §8: A rogue node inside the SR domain may (on purpose) signal the wrong behavior for a flow, which may result in the delivery of the traffic to the wrong destination (potentially including destinations outside the domain), among other things.  Note that this action is possible even if the rogue node is authenticated and authorized to generate an SRH.  I didn't find this threat mentioned in rfc8402/rfc8754.


(16) §9.4: I'm not sure what the purpose of §9 is, as a whole.  But the summary in §9.4 puzzles me more; what is the intent?  Does Table 1 indicate that, for example, an IGP implementation should not advertise the End.B6.Encaps behavior?  Does Table 2 indicate that only BGP-LS should signal the ability to H.Encaps.L2?  I am confused about the value/intent because the text clearly says that the control plane is outside the scope of this document.


(17) [nits]

s/an network operator/a network operator

s/one billionth and one millionth of the assigned address space/one billionth and one millionth of the available address space

s/packet's header Section 7/packet's header (Section 7)/g

s/bundle(LAG)/bundle (LAG)
Please expand LAG.

[Ballot comment]
Thank you for the work put into this document.

Thank you also for having edited the document based on the INT-DIR review by Brian Haberman (thank you Brian for the detailed review!) and replying to Brian's review.
https://datatracker.ietf.org/doc/review-ietf-spring-srv6-network-programming-18-intdir-telechat-haberman-2020-09-14/

Please find below a couple of non-blocking COMMENT points and nits.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
-- Section 3 --
There is some text copied from section 4.3 from RFC 8754. But, even if it seems obvious that the behaviors specified in this document _ONLY_ apply when "A FIB entry that represents a locally instantiated SRv6 SID", I suggest to spell it out to avoid any ambiguity.

-- Section 3.2 --
I am a little ambivalent with Brian's point about the location of the given examples. On one hand, those real case examples of SID allocation are really helpful to understand the impact of allocation; on the other hand, it is usual to move examples in appendix. Curious to see if other IESG members have other point of view.

In the last short example (this one could stay in the current location), should the value of F and A be stated? They are obvious from the used SID value of course, but, let's be complete ?
   
-- Section 3.3 --
Please follow RFC 5952 and write all IPv6 in lowercase.

-- Section 4.2 and 4.3 --
As "End.X" and "End.T" behaviors are variants of the "End" behavior, does the section 4.1.1 (Upper-Layer Header) also apply ?

-- Section 4.9 --
For consistency with previous behavior descriptions of End.DT[46], I suggest to mention that 143 has been reserved by IANA.

== NITS ==
-- Section 2 --
In the bullet list, there are a couple of missing '.' at the end of the list items.

-- Section 3 --
"longest-prefix-match lookup on the packets destination address" "packets" should probably be singular.

In "IPv6 subnet allocated for SRv6 SIDs by the operator", should it rather be "prefix" than "subnet" ?

-- Section 3.2 --
Strongly suggest to be consistent with the use of "IANA Endpoint Behavior codepoint" as sometimes it is shortened into "IANA Behavior" (also unsure whether the "IANA" qualification is really useful here)

-- Section 4.2 --
"one for the bundle(LAG)" Link Aggregation has not been expanded before and I am not sure whether the 'LAG' adds anything to the paragraph.

-- Section 4.16 --
Should PSP, USP, USD be expanded in the short introduction of this section ?

-- Section 8 --

The usual location of the security considerations is after all specification section, so, it should be after the 'control plane' section.

[Ballot comment]
Hi,

Thank for this document.  Not surprisingly given the large number of contributors working on this document I only have a few minor comments:


    2.  Terminology

      NH: Next-header field of the IPv6 header [RFC8200].  NH=SRH means
      that the next-header of the IPv6 header is Routing Header for
      IPv6(43) with the Type field set to 4.
 
Suggest expanding "4" to SRH(4)


    10.1.  Ethernet Next Header Type

      This document requests IANA to allocate, in the "Protocol Numbers"
      registry (https://www.iana.org/assignments/protocol-numbers/protocol-
      numbers.xhtml), a new value for "Ethernet" with the following
      definition: The value 143 in the Next Header field of an IPv6 header
      or any extension header indicates that the payload is an Ethernet
      [IEEE.802.3_2012].

Should this point to the latest published version of 802.3 (2018), or does it specifically need to reference an older version?

 
    3.1.  SID Format

      This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
      where a locator (LOC) is encoded in the L most significant bits of
      the SID, followed by F bits of function (FUNCT) and A bits of
      arguments (ARG).  L, the locator length, is flexible, and an operator
      is free to use the locator length of their choice.  F and A may be
      any value as long as L+F+A <= 128.  When L+F+A is less than 128 then
      the remainder of the SID MUST be zero.

This was reasonably clear to me, but since the rest of the description refers to bits, then I wonder whether the last sentence would be more precise as "the remaining bits of the SID must be set to zero"?


    4.1.  End: Endpoint
      S09.  If ((Last Entry > max_LE) or (Segments Left > Last Entry+1)) {

It wasn't entirely apparent to me where 'Last Entry' comes from, although that became more clear when I saw its usage later.  Possibly it would be helpful to list "Segments Left" and "Last Entry" in the terminology as taken from RFC 8754?


    4.1.  End: Endpoint
      S12.  Decrement Hop Limit by 1
     
Would it be more clear to expand this to say "Decrement IPv6 Hop Limit by 1", since it is referred to as the IPv6 Hop Limit previously.  If this is changed, then there are a couple of other places in the document that should be checked as well.

 
    4.2.  End.X: Layer-3 Cross-Connect

      Note that if N has an outgoing interface bundle I to a neighbor Q
      made of 10 member links, N may allocate up to 11 End.X local SIDs:
      one for the bundle(LAG) itself and then up to one for each Layer-2
      member link.

This behaviour seems slightly unusual to me.  I presume that the intent here is for the SR program to control which member link the traffic travels over rather than the normal behaviour of relying on the Bundle hashing.  Possibly adding a bit more text to clarify the expected behaviour might be helpful.


    4.4.  End.DX6: Decapsulation and IPv6 Cross-Connect

      S05.  If the End.DX6 SID is bound to an array of L3 adjacencies, then
      one entry of the array is selected based on the hash of the packet's
      header Section 7.

The end of this sentence doesn't scan for me, probably it should be something end something like: ", see Section 7"


    6.  Counters

      A node supporting this document SHOULD implement a combined traffic
      counter (packets and bytes) per local SID entry, for traffic that
      matched that SID and was processed correctly.  The retrieval of these
      counters via MIB, NETCONF/YANG or any other means is outside the
      scope of this document.
 
From my reading, a combined counter implies a single counter that is incremented by both the number of packets processed and number of bytes processed.  Normally in the management models you would normally expect this to be modeled as a pair of counters, and I presume that is what is desired here?  If so I would suggest clarifying this text to indicate that it is a pair of counters (one for packets, one for bytes) that are required here.


    Section 4, various places.

At various points the Upper-Layer Header type is compared to a number (e.g. 4, 41, 143).  It might be a bit more readable if the associated names were also included in the description.  E.g., 4(IPv4), 41(IPv6), etc.


    4.10.  End.DX2V: Decapsulation and VLAN L2 Table Lookup

Is this lookup just on the outermost VLAN Id, or all VLAN tags in the exposed Ethernet header?  Or is this implementation specific?

Regards,
Rob

[Ballot discuss]
Section 3.1.  (In case I missed it, please provide the obvious reference) Per “In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 endpoint behavior specification”, is “endpoint behavior specification” Section 4 or another document?  If the former, I don’t see any references to argument bits in the pseudo-code of the Section 4.* subsections.  If the latter, what document?  Can the behaviors be polymorphic (i.e., same network behavior accepting different arguments)?

[Ballot comment]
Thanks for responding to the SECDIR review (and thank you to Brian Weis for doing it)

** Section 3.2.  Per “An SR Source Node cannot infer the behavior by examination of the FUNCT value of a SID”, isn’t there at least some hint provided by the use of the FUNCT from the IANA registry?

** Section 3.2. 
Per “Function 11 associated with the behavior End.X …” AND

Per “Function 12 associated with the behavior End.X …”

The initial registrations for Endpoint Behavior per Section 10.2.1 suggest that Function 11 and 12 are End.T.

** Section 4.1.  Pseudo-code without formal definition might be open to interpretation.  My nits (which likely apply to other sections) are that:
-- it might not be clear that S03, S06 and S10 are effectively returns/exits from this “behavior”, and if they are run, S12-S15 should never be reached (otherwise Segments Left or Hop Limit = -1)

-- (for consistency) the IF … ELSEIF … END construct is used in Section 4.8, but not here.

-- What does it mean to indent the code?  For example S06 is:
S06.      Send an ICMP Time Exceeded message to the Source Address,
                Code 0 (Hop limit exceeded in transit),
                Interrupt packet processing and discard the packet.

I can see why “Code 0 …” is indented under “Send an … “ as this is a line wrap, but why is “Interrupt packet processing?”

** A few other psuedo code nits:
-- Section 4.1.  S05 uses “IPv6 Hop Limit” but S12 uses “Hop Limit”.  Recommend consistency.

-- Section 4.4.  Per S05.  Is “next header” purposely lower case?  I asked because it looks like explicit field names are in upper case (e.g., S03 says “Segments Left field”).

-- Section 4.16.3.  As a style/consistency note, the other sections which check the upper header type seem use of a construct of != 41 or 4 to “Process per Section 4.1.1”. (e.g., Section 4.4, 4.5, 4.6, etc.)

** Section 8.  Given how meticulously the Section 4 guidance was described, it would be helpful to say that the HMAC TLV processing, if present, happens as a notional Step “S0” per guidance in Section 2.1.2.1 of RFC8754.

** Editorial Nits:
-- Section 3.2. Typo. s/an network/a network/

-- Section 3.2. Typo. s/is minimum/is minimal/

[Ballot comment]
Throughout the document:
It should be “an SID”, “an FIB”, “an RIR”, and some others, not “a”, because one reads these as “ess-eye-dee” and “eff-eye-bee”, not as the expansions thereof.

— Section 3.1 —

  An SRv6 endpoint behavior MAY require additional information

I think this is a statement of fact, so “may” (or “might”), not “MAY”.

— Section 3.2 —
Nit: The plural of “SID” is “SIDs”, without an apostrophe.

  The provider historically deployed IPv6 and assigned
  infrastructure address from a portion of the fc00::/7 prefix

Nit: “addresses”.

  In another example, a large mobile and fixed line service provider

Nit: hyphenate “fixed-line”.

  IPv6 address consumption in both these examples is minimum,

Nit: “minimal” (also, put a comma before “respectively”).

  A remote node uses the IANA behavior codepoint to map the received
  SID (B:N:FUNCT) to a behavior.

I don’t know what “IANA behavior codepoint” means.  As the rest of the sentence makes it clear that this is mapping to “a behavior”, maybe it’s better to say “registered codepoint”, or some such?  Or, as you say a couple of paragraphs down, “Endpoint Behavior codepoint”?  In any case, please be consistent about “IANA behavior”, “IANA Behavior”, and “IANA Endpoint Behavior”.  My preference would be to avoid saying “IANA” in these, but use your judgment on what’s most understandable and clear.

  o  Assign an SRv6 Locator 2001:db8:bbbb:3::/64 to the Router 3 in
      their SR Domain

What is “the Router 3” (and router 4)?  There’s no introduction nor diagram that says.  Also, please be consistent in capitalization of these.

— Section 3.3 —

  routing protocol specific aspects that are outside the scope of this

Nit: “routing-protocol-specific” needs to be hyphenated.  As that’s awkward, you might want to reword to avoid it, “are specific to the routing protocol and are outside the scope....”

— Section 4 —

  The pseudocode describing these behaviors detail local processing

Nit: “details”, singular, to match “pseudocode”.

— Section 4.1 —

  The End behavior operates on the same FIB table (i.e.  VRF, L3 relay
  id) associated to the packet.

Is “i.e.” really what you want here?  How does “VRF, L3 relay” equate to “FIB table”?

— Section 4.16.1.3 —

  segments left to 0.  The SDN controller knows that no-other node

Nit: “no other” should not be hyphenated.  For that matter, the word “other” isn’t needed anyway, because you have “after” in there.

  -as part of the decapsulation process the egress PE is required to
    terminates less bytes from the packet.

I can’t figure this out.  It looks like it should be “required to terminate”, but I don’t know what it means to “terminate less bytes”.  Can you reword this?

    to the lookup engine in the forwarding ASIC.

“ASIC” needs to be expanded.  As this is the only place you use it, I suggest just using the expansion and not bothering with the abbreviation.

— Section 7 —

  This document introduces SRv6 Endpoint and SR Policy Headend
  behaviors for implementation on SRv6 capable nodes in the network.
  As such, this document does not introduce any new security
  considerations.

I’m not convinced of this.  It seems that misuse (such as injection or alteration) of some of these Behaviors could, for example, result in packets being forwarded to nodes they were not intended to go to.  Is it not important to discuss issues such as that: how these Behaviors might be attacked?  Is that really fully covered in 8754 and 8402?

— Section 8.1 —

  The presence of SIDs in the IGP do not imply any routing semantics

Nit: “does not”, to match the singular subject “the presence”.

  an IPv6 address is solely governed by the, non-SID-related, IGP

Nit: remove both commas.

  not governed neither influenced in any way by a SID advertisement

Nit: make it “neither governed nor influenced”

  build TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa] based FRR
  solutions

Nit: there needs to be a hyphen in there, but the citation gets in the way.  Make it, “build FRR solutions based on TI-LFA [I-D.ietf-rtgwg-segment-routing-ti-lfa]”.

— Section 8.4 —

  For example, a BGP-LS advertisement of H.Encaps behavior would
  describe the capability of node N to perform a H.Encaps behavior,
  specifically it would describe how many SIDs could be pushed by N
  without significant performance degradation.

This is a comma splice.  Split the sentence before “specifically” (and put a comma after “specifically”).

Closed request for Last Call review by INTDIR with state 'Withdrawn': Closing this Last Call request and opening a 'telechat' one (different deadlines) as discussed over email with secretary and reviewer.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-spring-srv6-network-programming-17.txt. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Assigned Internet Protocol Numbers registry on the Protocol Numbers registry page located at:

https://www.iana.org/assignments/protocol-numbers/

the existing temporary registration for value 143 (Ethernet) will be made permanent and its reference changed to [ RFC-to-be ].

Second, and the main IANA Protocol Registries matrix located at:

https://www.iana.org/protocols

a new registry page will be created called "Segment Routing Parameters" and will be given a reference of [ RFC-to-be ].

Third, on the newly created Segment Routing Parameters registry page created in the step above, a new registry will be created called the SRv6 Endpoint Behaviors registry.

The range of the registry is 0-65535 (0x0000 - 0xFFFF) and has the following registration rules and allocation policies (see RFC8126):

+-------------+---------------+-------------------+-----------------+
| Range | Hex | Registration | Notes |
| | | procedure | |
+-------------+---------------+-------------------+-----------------+
| 0 | 0x0000 | Reserved | Not to be |
| | | | allocated |
| 1-32767 | 0x0001-0x7FFF | FCFS | |
| 32768-65534 | 0x8000-0xFFFE | Reserved | |
| 65535 | 0xFFFF | Reserved | Opaque |
+-------------+---------------+-------------------+-----------------+

There are initial registrations in the new registry as follows:

+-------------+--------+-------------------------+------------------+
| Value | Hex | Endpoint behavior | Reference |
+-------------+--------+-------------------------+------------------+
| 0 | 0x0000 | Reserved | Not to be |
| | | | allocated |
| 1 | 0x0001 | End (no PSP, no USP) | [ RFC-to-be ] |
| 2 | 0x0002 | End with PSP | [ RFC-to-be ] |
| 3 | 0x0003 | End with USP | [ RFC-to-be ] |
| 4 | 0x0004 | End with PSP&USP | [ RFC-to-be ] |
| 5 | 0x0005 | End.X (no PSP, no USP) | [ RFC-to-be ] |
| 6 | 0x0006 | End.X with PSP | [ RFC-to-be ] |
| 7 | 0x0007 | End.X with USP | [ RFC-to-be ] |
| 8 | 0x0008 | End.X with PSP&USP | [ RFC-to-be ] |
| 9 | 0x0009 | End.T (no PSP, no USP) | [ RFC-to-be ] |
| 10 | 0x000A | End.T with PSP | [ RFC-to-be ] |
| 11 | 0x000B | End.T with USP | [ RFC-to-be ] |
| 12 | 0x000C | End.T with PSP&USP | [ RFC-to-be ] |
| 14 | 0x000E | End.B6.Encaps | [ RFC-to-be ] |
| 15 | 0x000F | End.BM | [ RFC-to-be ] |
| 16 | 0x0010 | End.DX6 | [ RFC-to-be ] |
| 17 | 0x0011 | End.DX4 | [ RFC-to-be ] |
| 18 | 0x0012 | End.DT6 | [ RFC-to-be ] |
| 19 | 0x0013 | End.DT4 | [ RFC-to-be ] |
| 20 | 0x0014 | End.DT46 | [ RFC-to-be ] |
| 21 | 0x0015 | End.DX2 | [ RFC-to-be ] |
| 22 | 0x0016 | End.DX2V | [ RFC-to-be ] |
| 23 | 0x0017 | End.DT2U | [ RFC-to-be ] |
| 24 | 0x0018 | End.DT2M | [ RFC-to-be ] |
| 25 | 0x0019 | Reserved | [ RFC-to-be ] |
| 27 | 0x001B | End.B6.Encaps.Red | [ RFC-to-be ] |
| 28 | 0x001C | End with USD | [ RFC-to-be ] |
| 29 | 0x001D | End with PSP&USD | [ RFC-to-be ] |
| 30 | 0x001E | End with USP&USD | [ RFC-to-be ] |
| 31 | 0x001F | End with PSP, USP & USD | [ RFC-to-be ] |
| 32 | 0x0020 | End.X with USD | [ RFC-to-be ] |
| 33 | 0x0021 | End.X with PSP&USD | [ RFC-to-be ] |
| 34 | 0x0022 | End.X with USP&USD | [ RFC-to-be ] |
| 35 | 0x0023 | End.X with PSP, USP & | [ RFC-to-be ] |
| | | USD | |
| 36 | 0x0024 | End.T with USD | [ RFC-to-be ] |
| 37 | 0x0025 | End.T with PSP&USD | [ RFC-to-be ] |
| 38 | 0x0026 | End.T with USP&USD | [ RFC-to-be ] |
| 39 | 0x0027 | End.T with PSP, USP & | [ RFC-to-be ] |
| | | USD | |
| 40-32766 | | Unassigned | |
| 32767 | 0x7FFF | The SID defined in | [ RFC-to-be ] |
| | | RFC8754 | [RFC8754] |
| 32768-65534 | | Reserved | |
| 65535 | 0xFFFF | Opaque | [ RFC-to-be ] |
+-------------+--------+-------------------------+------------------+

IANA Question --> What is the status of values 13 and 26?

The IANA Functions Operator understands that these are the only actions 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.

Please note that specific values cannot be reserved. However, early allocation is available for some types of registrations. For more information, please see RFC 7120.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

The following Last Call announcement was sent out (ends 2020-08-26):

From: The IESG
To: IETF-Announce
CC: draft-ietf-spring-srv6-network-programming@ietf.org, spring@ietf.org, Bruno Decraene , martin.vigoureux@nokia.com, Joel Halpern , jmh@joelhalpern.com, spring-chairs@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (SRv6 Network Programming) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'SRv6 Network Programming'
  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 2020-08-26. 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


  The SRv6 Network Programming framework enables a network operator or
  an application to specify a packet processing program by encoding a
  sequence of instructions in the IPv6 packet header.

  Each instruction is implemented on one or several nodes in the
  network and identified by an SRv6 Segment Identifier in the packet.

  This document defines the SRv6 Network Programming concept and
  specifies the base set of SRv6 behaviors that enables the creation of
  interoperable overlays with underlay optimization (Service Level
  Agreements).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-srv6-network-programming/


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

  https://datatracker.ietf.org/ipr/3464/

Below is the earlier Shepherd writeup from Bruno Decraene.  The following updates are added by Joel Halpern.

The document authors have responded to the IESG Appeal report.
They have added examples of the SID values and usage.  This includes clarifying the meaning of the FUNC and LOC bits, as well as demonstrating some of the alternatives in the number of bits are needed or can be used for the SID prefix.
They have clarified the relationship of the SIDs defined here with the SDI defined in RFC 8754, to address concerns from the Internet ADs.
They have elaborated the description of PSP, including providing better description of some of the value of having the flavor available.

While this shepherd expects there to be objections raised during IETF last call, the document still has the same technical content as it had during the judgement of WG rough consensus, and the IESG report explicitly indicated that a new WG LC was not called for.

Joel M. Halpern

(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 data plane processing needing interoperability between the ingress/source and the egress/destination. The specific forwarding behaviors (aka SR Endpoint behaviors) also need to be advertised in control plane protocols.


(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] leverages the source routing paradigm.  An
  ingress node steers a packet through an ordered list of instructions,
  called segments.  Each one of these instructions represents a
  function to be called at a specific location in the network.  A
  function is locally defined on the node where it is executed and may
  range from simply moving forward in the segment list to any complex
  user-defined behavior.  Network programming combines segment routing
  functions, both simple and complex, to achieve a networking objective
  that goes beyond mere packet routing.

  This document defines the SRv6 Network Programming concept and
  specifies the main segment routing behaviors to enable the creation
  of interoperable overlays with underlay optimization (Service Level
  Agreement).

Working Group Summary:

This document is a foundation for SRv6. It has been largely reviewed, commented and supported.
There is a strong controversy regarding the Penultimate Segment Pop (PSP) flavor which allows an IPv6 source node to instruct the penultimate SRv6 EndPoint (identified, in the IPv6 header, by its IPv6 address) to remove the SRH from the IPv6 packet before the packet reach the final IPv6 destination (the Ultimate SRv6 EndPoint). The consensus to keep that section was particularly rough.

Document Quality:

The specification has multiple implementations, deployments and interop tests.
In particular:
- There are multiple hardware and software implementations. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-4
- There are multiple deployments. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-2
- There have been multiple public interoperability tests https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-5

Personnel:

The Document Shepherd is Bruno Decraene
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 whole document has been reviewed before and after the WGLC. Comments sent and addressed by the editor.
The whole WGLC thread has been reviewed (about 424 emails according to the mailarchive)

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

No.
The WGLC has been sent to two WGs: SPRING & 6MAN.
There has been a lot of reviews and comments from both 6MAN & SPRING contributors.


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

The document uses the IPv6 SRH routing header. The Working Group Last Call has been copied to the 6MAN WG and the document has been reviewed and commented by 6MAN participants.

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

On a personnel side, I'm chair and listed as a co-author of the document, among 23 contributors and 6 authors. The reason for taking the shepherd role is that there was no other available co-chair and 29 persons are either contributors or authors which remove a lot of persons. Finally the WGLC was expected to be difficult on the 6MAN side given the SRv6 history and the WGLC on the SRH specification. So there was both a smaller pool of experienced SPRING shepherd and less candidates for the work with a difficult document.

On a technical side, the section "4.16.1 PSP: Penultimate Segment Pop of the SRH" has generated a lot of controversy from some 6MAN participants.

6.0 Introduction

  The section 4.16.1 proposes that the Segment Routing Penultimate Endpoint, which receives the IPv6 packet since its IPv6 address is in the IPv6 header destination address, be instructed by the IPv6 source node to remove the SRH (routing header) as/when the SRH is not further useful (Segment Left will be zero when received by the Segment Routing Ultimate Endpoint).

6.1 Concern 1 (violation of RFC 8200)

  The first concern is whether this behavior [1] violates RFC 8200 [2].

  More specifically
  " S14.4.      Remove the SRH from the IPv6 extension header chain" in [1]
  Vs
    "  Extension headers (except for the Hop-by-Hop Options header) are not
    processed, inserted, or deleted by any node along a packet's delivery
    path, until the packet reaches the node (or each of the set of nodes,
    in the case of multicast) identified in the Destination Address field
    of the IPv6 header." in [2]

  On this text, what is been discussed is "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."
  More specifically whether "Destination Address field of the IPv6 header" means the "final Destination Address" or the "Destination Address" as seen in the packet that the node received.

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming#section-4.16.1
[2] https://tools.ietf.org/html/rfc8200#section-4

6.2 Concern 2 (letter vs spirit of RFC 8200)

  The second concern is whether the text in the section 4 of RFC 8200 really says what was meant.
  Two erratas have been submitted : https://www.rfc-editor.org/errata/eid5933 https://www.rfc-editor.org/errata/eid6003
 
  The responsible AD (Suresh) classified the first errata as "Held for Document Update" with the below note:
  "Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category.

  The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200."
  [3] https://mailarchive.ietf.org/arch/msg/ipv6/tRn94-NlupHLcWdzo7O9BfHpiik/
  [4] https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
 
6.3 Concern 3 (technical issues with SRH removal)

  Two points have been raised regarding PMTUD and Authentication Header. The first one has been dismissed and the second is already called out of scope of SRH.
 
  It's also worth noted that with Segment Routing, the removal of the SRH is performed by the SR penultimate EndPoint at the _explicit_ request/instruction of the source node. Hence the final destination node receives the IP packet exactly as meant by the IP source node: there is no surprise/unexpected change from both the IP source and the final IP destination point of view.
 
 
6.4 Shepherd opinion
  Regarding concern 1, based on comments received during the last call and my reading of the section 4 of RFC 8200, section 4 of RFC 8200 does seem to allow SRH removal by a node receiving an IPv6 packet with an IPv6 destination address identifying itself.
  Regarding concern 2, cf Suresh's note [3] [4]. Going beyond is probably up to IESG and/or the 6MAN WG in a longer term.
  Regarding concern 3, SRH removal does not create new technical issue.

  In summary, although the controversy was very significant with very strong opinions expressed, up to statements that appeal(s) will be made, from a SPRING WGLC standpoint, I don't believe that there is ground to block the progression of this draft toward the IESG. Quite the contrary, I think that the IESG should make the call by themselves with regards to concern 1 and 2, especially since the IESG had approved the document been debated (RFC 8200, in particular section 4.1.16).


(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 has replied to the IPR call on the mailing list.
Each contributor _except Gaurav Naik and  Milad Sharif_ has replied to the IPR call on the mailing list. Those two contributors (out of 23) could not be reached. Note that both had replied (no IPR) during the call for _adoption_.


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

One IPR disclosure has been filed.
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 a large support, both from vendors and network operators. It has multiple implementations and deployments.
This document is a foundation of the SRv6 specification.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

A few persons threatened for an appeal and I believe that such appeal is likely.
The strong controversy is related to section 4.16.1.  "PSP: Penultimate Segment Pop of the SRH" and whether it violates RFC 8200 (IPv6 specification) section 4.1.16.
Cf question "6" for more details.

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

The document has 6 authors, beyond the 5 authors limit. An exception is requested given the significant work on this document: significant scope, importance (basis of SRv6), with multiple implementations and deployments.

Idnits has been run and error 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.


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

I confirm the points.
The largest part of the IANA section are the codepoints associated with SR EndPoints behaviors. In the document, the behaviors are referred to by "user friendly" names (e.g., End, End.X). The codepoints themselves are only defined in the IANA section, hence there is no risk of inconsistency between the body of the document and the IANA section. Given the number of codepoints, I think that this is better, especially since the codepoints are not used in this document but will be used by future documents (e.g. control planes extension).

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

None.


(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 not 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 has no YANG module.

(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 data plane processing needing interoperability between the ingress/source and the egress/destination. The specific forwarding behaviors (aka SR Endpoint behaviors) also need to be advertised in control plane protocols.


(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] leverages the source routing paradigm.  An
  ingress node steers a packet through an ordered list of instructions,
  called segments.  Each one of these instructions represents a
  function to be called at a specific location in the network.  A
  function is locally defined on the node where it is executed and may
  range from simply moving forward in the segment list to any complex
  user-defined behavior.  Network programming combines segment routing
  functions, both simple and complex, to achieve a networking objective
  that goes beyond mere packet routing.

  This document defines the SRv6 Network Programming concept and
  specifies the main segment routing behaviors to enable the creation
  of interoperable overlays with underlay optimization (Service Level
  Agreement).

Working Group Summary:

This document is a foundation for SRv6. It has been largely reviewed, commented and supported.
There is a strong controversy regarding the Penultimate Segment Pop (PSP) flavor which allows an IPv6 source node to instruct the penultimate SRv6 EndPoint (identified, in the IPv6 header, by its IPv6 address) to remove the SRH from the IPv6 packet before the packet reach the final IPv6 destination (the Ultimate SRv6 EndPoint). The consensus to keep that section was particularly rough.

Document Quality:

The specification has multiple implementations, deployments and interop tests.
In particular:
- There are multiple hardware and software implementations. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-4
- There are multiple deployments. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-2
- There have been multiple public interoperability tests https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-5

Personnel:

The Document Shepherd is Bruno Decraene
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 whole document has been reviewed before and after the WGLC. Comments sent and addressed by the editor.
The whole WGLC thread has been reviewed (about 424 emails according to the mailarchive)

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

No.
The WGLC has been sent to two WGs: SPRING & 6MAN.
There has been a lot of reviews and comments from both 6MAN & SPRING contributors.


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

The document uses the IPv6 SRH routing header. The Working Group Last Call has been copied to the 6MAN WG and the document has been reviewed and commented by 6MAN participants.

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

On a personnel side, I'm chair and listed as a co-author of the document, among 23 contributors and 6 authors. The reason for taking the shepherd role is that there was no other available co-chair and 29 persons are either contributors or authors which remove a lot of persons. Finally the WGLC was expected to be difficult on the 6MAN side given the SRv6 history and the WGLC on the SRH specification. So there was both a smaller pool of experienced SPRING shepherd and less candidates for the work with a difficult document.

On a technical side, the section "4.16.1 PSP: Penultimate Segment Pop of the SRH" has generated a lot of controversy from some 6MAN participants.

6.0 Introduction

  The section 4.16.1 proposes that the Segment Routing Penultimate Endpoint, which receives the IPv6 packet since its IPv6 address is in the IPv6 header destination address, be instructed by the IPv6 source node to remove the SRH (routing header) as/when the SRH is not further useful (Segment Left will be zero when received by the Segment Routing Ultimate Endpoint).

6.1 Concern 1 (violation of RFC 8200)

  The first concern is whether this behavior [1] violates RFC 8200 [2].

  More specifically
  " S14.4.      Remove the SRH from the IPv6 extension header chain" in [1]
  Vs
    "  Extension headers (except for the Hop-by-Hop Options header) are not
    processed, inserted, or deleted by any node along a packet's delivery
    path, until the packet reaches the node (or each of the set of nodes,
    in the case of multicast) identified in the Destination Address field
    of the IPv6 header." in [2]

  On this text, what is been discussed is "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."
  More specifically whether "Destination Address field of the IPv6 header" means the "final Destination Address" or the "Destination Address" as seen in the packet that the node received.

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming#section-4.16.1
[2] https://tools.ietf.org/html/rfc8200#section-4

6.2 Concern 2 (letter vs spirit of RFC 8200)

  The second concern is whether the text in the section 4 of RFC 8200 really says what was meant.
  Two erratas have been submitted : https://www.rfc-editor.org/errata/eid5933 https://www.rfc-editor.org/errata/eid6003
 
  The responsible AD (Suresh) classified the first errata as "Held for Document Update" with the below note:
  "Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category.

  The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200."
  [3] https://mailarchive.ietf.org/arch/msg/ipv6/tRn94-NlupHLcWdzo7O9BfHpiik/
  [4] https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
 
6.3 Concern 3 (technical issues with SRH removal)

  Two points have been raised regarding PMTUD and Authentication Header. The first one has been dismissed and the second is already called out of scope of SRH.
 
  It's also worth noted that with Segment Routing, the removal of the SRH is performed by the SR penultimate EndPoint at the _explicit_ request/instruction of the source node. Hence the final destination node receives the IP packet exactly as meant by the IP source node: there is no surprise/unexpected change from both the IP source and the final IP destination point of view.
 
 
6.4 Shepherd opinion
  Regarding concern 1, based on comments received during the last call and my reading of the section 4 of RFC 8200, section 4 of RFC 8200 does seem to allow SRH removal by a node receiving an IPv6 packet with an IPv6 destination address identifying itself.
  Regarding concern 2, cf Suresh's note [3] [4]. Going beyond is probably up to IESG and/or the 6MAN WG in a longer term.
  Regarding concern 3, SRH removal does not create new technical issue.

  In summary, although the controversy was very significant with very strong opinions expressed, up to statements that appeal(s) will be made, from a SPRING WGLC standpoint, I don't believe that there is ground to block the progression of this draft toward the IESG. Quite the contrary, I think that the IESG should make the call by themselves with regards to concern 1 and 2, especially since the IESG had approved the document been debated (RFC 8200, in particular section 4.1.16).


(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 has replied to the IPR call on the mailing list.
Each contributor _except Gaurav Naik and  Milad Sharif_ has replied to the IPR call on the mailing list. Those two contributors (out of 23) could not be reached. Note that both had replied (no IPR) during the call for _adoption_.


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

One IPR disclosure has been filed.
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 a large support, both from vendors and network operators. It has multiple implementations and deployments.
This document is a foundation of the SRv6 specification.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

A few persons threatened for an appeal and I believe that such appeal is likely.
The strong controversy is related to section 4.16.1.  "PSP: Penultimate Segment Pop of the SRH" and whether it violates RFC 8200 (IPv6 specification) section 4.1.16.
Cf question "6" for more details.

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

The document has 6 authors, beyond the 5 authors limit. An exception is requested given the significant work on this document: significant scope, importance (basis of SRv6), with multiple implementations and deployments.

Idnits has been run and error 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.


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

I confirm the points.
The largest part of the IANA section are the codepoints associated with SR EndPoints behaviors. In the document, the behaviors are referred to by "user friendly" names (e.g., End, End.X). The codepoints themselves are only defined in the IANA section, hence there is no risk of inconsistency between the body of the document and the IANA section. Given the number of codepoints, I think that this is better, especially since the codepoints are not used in this document but will be used by future documents (e.g. control planes extension).

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

None.


(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 not 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 has no YANG module.

(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 data plane processing needing interoperability between the ingress/source and the egress/destination. The specific forwarding behaviors (aka SR Endpoint behaviors) also need to be advertised in control plane protocols.


(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] leverages the source routing paradigm.  An
  ingress node steers a packet through an ordered list of instructions,
  called segments.  Each one of these instructions represents a
  function to be called at a specific location in the network.  A
  function is locally defined on the node where it is executed and may
  range from simply moving forward in the segment list to any complex
  user-defined behavior.  Network programming combines segment routing
  functions, both simple and complex, to achieve a networking objective
  that goes beyond mere packet routing.

  This document defines the SRv6 Network Programming concept and
  specifies the main segment routing behaviors to enable the creation
  of interoperable overlays with underlay optimization (Service Level
  Agreement).

Working Group Summary:

This document is a foundation for SRv6. It has been largely reviewed, commented and supported.
There is a strong controversy regarding the Penultimate Segment Pop (PSP) flavor which allows an IPv6 source node to instruct the penultimate SRv6 EndPoint (identified, in the IPv6 header, by its IPv6 address) to remove the SRH from the IPv6 packet before the packet reach the final IPv6 destination (the Ultimate SRv6 EndPoint). The consensus to keep that section was particularly rough.

Document Quality:

The specification has multiple implementations, deployments and interop tests.
In particular:
- There are multiple hardware and software implementations. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-4
- There are multiple deployments. Some are reported in https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-2
- There have been multiple public interoperability tests https://tools.ietf.org/html/draft-matsushima-spring-srv6-deployment-status-06#section-5

Personnel:

The Document Shepherd is Bruno Decraene
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 whole document has been reviewed before and after the WGLC. Comments sent and addressed by the editor.
The whole WGLC thread has been reviewed (about 424 emails according to the mailarchive)

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

No.
The WGLC has been sent to two WGs: SPRING & 6MAN.
There has been a lot of reviews and comments from both 6MAN & SPRING contributors.


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

The document uses the IPv6 SRH routing header. The Working Group Last Call has been copied to the 6MAN WG and the document has been reviewed and commented by 6MAN participants.

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

On a personnel side, I'm chair and listed as a co-author of the document, among 23 contributors and 6 authors. The reason for taking the shepherd role is that there was no other available co-chair and 29 persons are either contributors or authors which remove a lot of persons. Finally the WGLC was expected to be difficult on the 6MAN side given the SRv6 history and the WGLC on the SRH specification. So there was both a smaller pool of experienced SPRING shepherd and less candidates for the work with a difficult document.

On a technical side, the section "4.16.1 PSP: Penultimate Segment Pop of the SRH" has generated a lot of controversy from some 6MAN participants.

6.0 Introduction

  The section 4.16.1 proposes that the Segment Routing Penultimate Endpoint, which receives the IPv6 packet since its IPv6 address is in the IPv6 header destination address, be instructed by the IPv6 source node to remove the SRH (routing header) as/when the SRH is not further useful (Segment Left will be zero when received by the Segment Routing Ultimate Endpoint).

6.1 Concern 1 (violation of RFC 8200)

  The first concern is whether this behavior [1] violates RFC 8200 [2].

  More specifically
  " S14.4.      Remove the SRH from the IPv6 extension header chain" in [1]
  Vs
    "  Extension headers (except for the Hop-by-Hop Options header) are not
    processed, inserted, or deleted by any node along a packet's delivery
    path, until the packet reaches the node (or each of the set of nodes,
    in the case of multicast) identified in the Destination Address field
    of the IPv6 header." in [2]

  On this text, what is been discussed is "the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header."
  More specifically whether "Destination Address field of the IPv6 header" means the "final Destination Address" or the "Destination Address" as seen in the packet that the node received.

[1] https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming#section-4.16.1
[2] https://tools.ietf.org/html/rfc8200#section-4

6.2 Concern 2 (letter vs spirit of RFC 8200)

  The second concern is whether the text in the section 4 of RFC 8200 really says what was meant.
  Two erratas have been submitted : https://www.rfc-editor.org/errata/eid5933 https://www.rfc-editor.org/errata/eid6003
 
  The responsible AD (Suresh) classified the first errata as "Held for Document Update" with the below note:
  "Some people might interpret the text in RFC8200 to mean the replacement text provided above in the erratum but others might read the text exactly as written ("until the packet reaches the node identified in the Destination Address field of the IPv6 header”). Given that the text in RFC8200 had consensus and it is impossible to tell after the fact if the proposed replacement text would have achieved consensus, I believe this erratum falls under the above category.

  The change proposed by this erratum has to be evaluated for correctness and consensus if and when there is an update of RFC8200."
  [3] https://mailarchive.ietf.org/arch/msg/ipv6/tRn94-NlupHLcWdzo7O9BfHpiik/
  [4] https://mailarchive.ietf.org/arch/msg/ipv6/yVKxBF3VnJQkIRuM8lgWN4_G3-o/
 
6.3 Concern 3 (technical issues with SRH removal)

  Two points have been raised regarding PMTUD and Authentication Header. The first one has been dismissed and the second is already called out of scope of SRH.
 
  It's also worth noted that with Segment Routing, the removal of the SRH is performed by the SR penultimate EndPoint at the _explicit_ request/instruction of the source node. Hence the final destination node receives the IP packet exactly as meant by the IP source node: there is no surprise/unexpected change from both the IP source and the final IP destination point of view.
 
 
6.4 Shepherd opinion
  Regarding concern 1, based on comments received during the last call and my reading of the section 4 of RFC 8200, section 4 of RFC 8200 does seem to allow SRH removal by a node receiving an IPv6 packet with an IPv6 destination address identifying itself.
  Regarding concern 2, cf Suresh's note [3] [4]. Going beyond is probably up to IESG and/or the 6MAN WG in a longer term.
  Regarding concern 3, SRH removal does not create new technical issue.

  In summary, although the controversy was very significant with very strong opinions expressed, up to statements that appeal(s) will be made, from a SPRING WGLC standpoint, I don't believe that there is ground to block the progression of this draft toward the IESG. Quite the contrary, I think that the IESG should make the call by themselves with regards to concern 1 and 2, especially since the IESG had approved the document been debated (RFC 8200, in particular section 4.1.16).


(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 has replied to the IPR call on the mailing list.
Each contributor _except Gaurav Naik and  Milad Sharif_ has replied to the IPR call on the mailing list. Those two contributors (out of 23) could not be reached. Note that both had replied (no IPR) during the call for _adoption_.


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

One IPR disclosure has been filed.
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 a large support, both from vendors and network operators. It has multiple implementations and deployments.
This document is a foundation of the SRv6 specification.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.)

A few persons threatened for an appeal and I believe that such appeal is likely.
The strong controversy is related to section 4.16.1.  "PSP: Penultimate Segment Pop of the SRH" and whether it violates RFC 8200 (IPv6 specification) section 4.1.16.
Cf question "6" for more details.

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

The document has 6 authors, beyond the 5 authors limit. An exception is requested given the significant work on this document: significant scope, importance (basis of SRv6), with multiple implementations and deployments.

Idnits has been run and error 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.


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

I confirm the points.
The largest part of the IANA section are the codepoints associated with SR EndPoints behaviors. In the document, the behaviors are referred to by "user friendly" names (e.g., End, End.X). The codepoints themselves are only defined in the IANA section, hence there is no risk of inconsistency between the body of the document and the IANA section. Given the number of codepoints, I think that this is better, especially since the codepoints are not used in this document but will be used by future documents (e.g. control planes extension).

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

None.


(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 not 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 has no YANG module.

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Pablo Camarillo , Clarence Filsfils , Zhenbin Li

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Pablo Camarillo , Clarence Filsfils , Zhenbin Li

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Pablo Camarillo , Clarence Filsfils , Zhenbin Li

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Pablo Camarillo , Clarence Filsfils , Zhenbin Li

Request for posting confirmation emailed to previous authors: Satoru Matsushima , spring-chairs@ietf.org, John Leddy , " daniel.voyer@bell.ca" , Pablo Camarillo , Clarence Filsfils , Zhenbin Li