IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-26

Received changes through RFC Editor sync (created alias RFC 8754, changed abstract to 'Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).  This document describes the SRH and how it is used by nodes that are Segment Routing (SR) capable.', changed pages to 27, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2020-03-14, changed IESG state to RFC Published)

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

[Ballot comment]
Thank you for addressing my Discuss points (including by having a discussion to
clarify that some of them are in fact non-issues)!

Please also consider the following comments on the -25, none of which quite
rise to Discuss-level, but some of which are significant.

I wonder whether we will ever want to have the HMAC protect (some of)
the other TLVs associated with the SRH; the current formulation is quite
rigid about what the HMAC input is (and trying to change that later,
e.g., by the presence of some other TLV, seems like a bad idea).  What
we have here is fine for now, though, and we could always define a new
"HMACplus" TLV with richer semantics if a need arises.

With respect to the "changing that later seems like a bad idea" point, I
do see this text in Section 2:

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

I'm coming at this from a perspective of the operational considerations
when an HMAC verification node might implement only [this document] and
thus anything attempting to generate an HMAC according to a modified
procedure specified in some future document would produce an HMAC value
that would fail to verify.


Section 2.1.2 has:

  o  RESERVED: 15 bits.  MUST be 0 on transmission and ignored on
      receipt.

yet those bits are used as input to the HMAC calculation, which seems to
defy the "ignored" portion.


Section 2.1.2.1 has:

  An implementation that supports the generation and verification of
  the HMAC SHOULD support the following default behavior as defined in
  the remainder of this section.

which seems like it might have some vestiges of the previous model where
most of the HMAC verification procedure was up to local configuration; I
think we are now at a place where the following behavior is the only
behavior (not "default") and there's no need to qualify it with
"SHOULD".

Also, it might be possible to spend some thought and convince ourselves
that the 'D' bit is not strictly needed, since an entity creating an SRH
for which the 'D' bit might be needed could just choose to not use the
reduced SRH in cases where verification of the first segment would be
needed.  But I did not spend the time to reason through this, so I'm not
advocating for removing the 'D' bit at this time.

Section 2.1.2.2 has:

  At the HMAC TLV generating node, the Text for the HMAC computation is
  set to the IPv6 header fields and SRH fields as they would appear at
  the verification node, not necessarily the same as the source node
  sending a packet with the HMAC TLV.

  Pre-shared key roll-over is supported by having two key IDs in use
  while the HMAC TLV generating node and verifying node converge to a
  new key.

which implies a single verification node (my recollection is that we
settled on multiple verification nodes being possible).  (Section
2.1.2.1 also has "as it would be reeived at the node verifying the
HMAC", in a similar vein.)


Section 4.3.1.1.1 has:

  Example 2:
  For any packet received from interface I1
    If first TLV is HMAC {
      Process the HMAC TLV
    }
    Else {
      Discard the packet
    }

This shows the location of the HMAC TLV as being up to local policy.
This is ... probably okay from a security point of view, but I mention
it in case our previous discussions have caused us to not want to
endorse this being a part of local policy.

[Ballot comment]
Thank you for addressing my Discuss points (including by having a discussion to
clarify that some of them are in fact non-issues)!

Please also consider the following comments on the -25, none of which quite
rise to Discuss-level, but some of which are significant.

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

[Ballot discuss]
Thanks for resolving some of my discusses.

3. Section 5.3:

5.3.  MTU Considerations
An SR Domain ingress edge node encapsulates packets traversing the SR
  Domain, and needs to consider the MTU of the SR Domain.  Within the
  SR Domain, well known mitigation techniques are RECOMMENDED, such as
  deploying a greater MTU value within the SR Domain than at the
  ingress edges.

I find this section very much lacking. Considering that the minimal usage of this RH is 24 bytes, and getting above 100 bytes of overhead is trivial. 3 segments plus the HMAC TLV is 96 bytes.

The text mentions well known techniques (Note plural) but suggests only one. Are the more that can be referenced?

The one mentioned requires one to calculate the worst case overhead for the SR domain for the this routing header. Then take the lowest available path MTU and subtract that worst case overhead to find the supported MTU. Then police that value at the ingresses to the SR domain to ensure consistent behavior that Path MTU discovery methods can work with.

What do you do if one of the path MTUs inside the SR domain is 1280?

This document do need to answer this question or I believe write an applicability statement restrict this to not work in such network where the 1280 minimal MTU can be ensured. As Joe Touch note in his TSV-ART review this is non trivial and I don't see punting on these MTU question will work in general: https://mailarchive.ietf.org/arch/msg/tsv-art/cdMgmFS79lBr7oha9Z4S4qqqA8c

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

[Ballot comment]
Hi,

thank you for this document.
I have a couple of questions on the definition of an SR segment endpoint node.

Maybe I'm missing something obvious, but I read:
  A SR segment endpoint node is any node receiving an IPv6 packet where
  the destination address of that packet is locally configured as a
  segment or local interface.
and then, in 4.3:
      A FIB entry that represents a non-local route
      No Match
it seems to me that if we happen to be in such situations then the node doing the LPM is not an SR Segment Endpoint Node for that specific packet. As such, I'm not sure why these cases are being described in 4.3 and subsections.

Also, 4.3.2 says:
  If the FIB entry represents a local interface, not locally
  instantiated as an SRv6 SID, the SRH is processed as follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing Header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.

This is the exact same text as what 8200 specifies when the Routing Header type is unknown. That makes me wonder if a "node receiving an IPv6 packet where the destination address of that packet is locally configured as a [...] local interface" is effectively an SR segment endpoint node.


nits:
      Padding TLVs are ignored by a node processing the SRH TLV.
did you mean SRH's TLV(s)


  IPv6 headers are represented as the tuple of (source, destination).
  For example, a packet with source address A1 and destination address
  A2 is represented as (A1,A2).
But then we find
  (SA,DA) ...
  o  Source Address is SA, Destination Addresses is DA, ...
Why not keep the formalism defined above and write it as (A1,A2) ?


  For registration requests where a Designated Expert should be
  consulted, the responsible IESG area director should appoint the
  Designated Expert.  The intention is that any allocation will be
  accompanied by a published RFC. 
If an RFC is really what the WG expects why not choose "RFC Required"?

[Ballot comment]
Thank you for the hard work put into this easy to read document. Happy to see how this document has improved since the first drafts, years ago while I contributed to those first drafts.

Regards,

-éric

== COMMENTS ==

-- Section 2 --
C.1) Unsure whether the use of multiple "U" to indicate unused bit is useful, most RFC states that this field is reserved.

C.2) An explanation about why segments are in the reverse order would be helpful for the reader.

-- Section 2.1 --
C.3) " an implementation adding or parsing TLVs MUST support PAD TLVs" is it just 'parsing' == read them ?

-- Section 2.1.2 --
C.4) it is possibly already in the security AD DISCUSSes, but, I would make the HMAC field variable length as it depends on the HMAC algorithm being used.

-- Section 2.1.2.1 --
C.5) "It may be based on ..., HMAC Key ID, or other packet fields." seems to contradict the opaque quality of the HMAC Key ID. I suggest to remove the mention of 'HMAC Key ID' here.
C.6) See also C.4 (so please address either C.6 or C.4), need to specify what to truncate: most significant or least significant bytes.

-- Section 4.3.1.1.1. --
C.7) Describing the use cases behind the example could help the reader.

-- Section 4.3.1.2. --
C.8) rather a question of mine, is this behavior applicable for all SID on the paths? (i.e. on all SRv6-capable routers where the current DA matches the locally configured interface addresses/SID ?) I would have guessed that decapsultion only happen at the last segment as explained in 4.3.2.

== NITS ==

-- Section 2.1.1 --
s/to verify the source of a packet/to verify whether the source of a packet/

-- Section 5.4 --
Please add a note to change the '4' to the IANA allocated value.

[Ballot discuss]
I have several issues that appears to be serious enough that I really like some feedback on them prior to approving the document.



1. Section 2.1:

  An implementation MAY limit the number and/or length of TLVs it
  processes based on local configuration.  It MAY:
o  Limit the number of consecutive Pad1 (Section 2.1.1.1) options to
      1, if padding of more than one byte is required then PadN
      (Section 2.1.1.2) should be used.
o  Limit the length in PadN to 5.
o  Limit the maximum number of non-Pad TLVs to be processed.
o  Limit the maximum length of all TLVs to be processed.
The implementation MAY stop processing additional TLVs in the SRH
  when these configured limits are exceeded.

Isn't this repeating the same interoperability and extensibility issues we have for IPv6 extension headers in an IPv6 Routing header? Wouldn't it be better to tighten a bit the possibilities for the basic support of at least handling TLVs, and if anyone defines something larger they know this will be more uphill work to ensure that you get support for it. But it will making matching the constraints likely more easily to deploy as implementations haven't made different choices of what is required to support when it comes to handling TLVs and buffer them for example in their implementations.

2. Section 2.1.2.1

  If HMAC verification fails, an ICMP error message (parameter problem,
  error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
  limited) and SHOULD be logged.

Shouldn't it be made explicit that the packet should be discarded? Please clarify the text.

3. Section 5.3:

5.3.  MTU Considerations
An SR Domain ingress edge node encapsulates packets traversing the SR
  Domain, and needs to consider the MTU of the SR Domain.  Within the
  SR Domain, well known mitigation techniques are RECOMMENDED, such as
  deploying a greater MTU value within the SR Domain than at the
  ingress edges.

I find this section very much lacking. Considering that the minimal usage of this RH is 24 bytes, and getting above 100 bytes of overhead is trivial. 3 segments plus the HMAC TLV is 96 bytes.

The text mentions well known techniques (Note plural) but suggests only one. Are the more that can be referenced?

The one mentioned requires one to calculate the worst case overhead for the SR domain for the this routing header. Then take the lowest available path MTU and subtract that worst case overhead to find the supported MTU. Then police that value at the ingresses to the SR domain to ensure consistent behavior that Path MTU discovery methods can work with.

What do you do if one of the path MTUs inside the SR domain is 1280?

This document do need to answer this question or I believe write an applicability statement restrict this to not work in such network where the 1280 minimal MTU can be ensured. As Joe Touch note in his TSV-ART review this is non trivial and I don't see punting on these MTU question will work in general: https://mailarchive.ietf.org/arch/msg/tsv-art/cdMgmFS79lBr7oha9Z4S4qqqA8c

[Ballot comment]
1. Section 2.
o  Tag: tag a packet as part of a class or group of packets, e.g.,
      packets sharing the same set of properties.  When tag is not used
      at source it MUST be set to zero on transmission.  When tag is not
      used during SRH Processing it SHOULD be ignored.  Tag is not used
      when processing the SID defined in Section 4.3.1.  It may be used
      when processing other SIDs which are not defined in this document.
      The allocation and use of tag is outside the scope of this
      document.

  Consistent with the source routing model, the source of the SRH
  always knows how to set the segment list, Flags, Tag and TLVs of the
  SRH for use within the SR Domain.  How it achieves this is outside
  the scope of this document, but may be based on topology, available
  SIDs and their mutability properties, the SRH mutability requirements
  of the destination, or any other information.

Are there any scoping of the Tag field? I assume that it is SR domain local, is there any scoping based on any other IPv6 header fields? To me this tag appears to be a magic field, which one can hang almost any functionality on. It can represent QoS, policy, etc. I at least see it as 16-bit extra DSCP field, is that a misunderstanding? Have there been much discussion about how this field is going to affect interoperability?

I also note that the rest of the document does not discuss the tag field. I can assume that it is only segment endpoints that will process it due to the transit nodes are supposed to not look at the routing header. (But is something that could easily be violated if the goal is to enable the use of the tag for some purpose assuming that you can get implementations that does that.)

[Ballot discuss]
The new "Segment Routing Header TLVs" registry (§8.2) includes a range "for TLVs that may change en route".  However, I couldn't find a specification for these types of TLVs.  The only clues come from §4.3.1 (FIB Entry Is Locally Instantiated SRv6 SID), where it says:

  Processing this SID modifies the Segments Left and, if configured to
  process TLVs, it may modify the "variable length data" of TLV types
  that change en route.  Therefore Segments Left is mutable and TLVs
  that change en route are mutable.  The remainder of the SRH (Flags,
  Tag, Segment List, and TLVs that do not change en route) are
  immutable while processing this SID.

I am balloting DISCUSS because the description of "TLVs that may change en route" is not clear or specific enough.  I would like to see a clear specification of what "TLVs that may change en route" are, *AND* corresponding instructions to the Designated Experts-to-be. 

  Some related questions that come to mind include: Where can these TLVs be
  processed/changed?  If the data is modified, what about the alignment,
  should the Padding TLVs be also changed?  If no data is left, can the TLV be
  removed?  The instructions above (for the SRV6 SID) seem generic enough to
  apply to other potential future SIDs, what type of variation is expected?

[Ballot comment]
(1) I support Ben's DISCUSS.

Adding to his HMAC concerns, §2.1 says that when "processing the SID defined in Section 4.3.1, all TLVs are ignored unless local configuration indicates otherwise (Section 4.3.1.1.1).  Thus, TLV and HMAC support is optional for any implementation..."  This seems to indicate that, regardless of the HMAC security properties, it will be ignored by default.

(2) §4.1.1: "When a source does not require the entire SID list to be preserved in the SRH, a reduced SRH may be used."  When does a source require the entire SID list to be preserved?  Please provide an example of these cases.
 
(3) §8.1: Given that the SRH Flags Bits are limited, I would like to see instructions to the DEs-to-be about the type of information that may need to be encoded in the Header.

[Ballot discuss]
I find the new registries (not "registers", as in the titles of Sections 8.1 and 8.2) to be oddly defined, and would like to discuss that.

In Section 8, you seem to be giving instructions to the designated expert to require an RFC.  You also seem to be telling the DE to consult the 6man working group (or the residual mailing list, after the WG closes).  So when you say "Expert Review", you're really saying at least "Expert Review and RFC Required", and possibly "Expert Review and IETF Review".  I suggest that you instead go with "IETF Review" and eliminate the need for a designated expert.  If you want to additionally require specific review on the 6man list, you can add that to the IETF Review, with something like "IETF Review, with at least a two-week review on the 6man list," or some such.  (You could also consider "Standards Action" if you want to require that the RFC be Standards Track and not, say, Experimental or Informational.)  The point of having a DE is to handle cases when you are NOT necessarily using RFCs to do the registrations, and you don't have the consequent IETF review of things.

[Ballot comment]
Oh, and here:

  The following policies are used here with the meanings defined in BCP
  26: "Private Use", "First Come First Served", "Expert Review",
  "Specification Required", "IETF Consensus", "Standards Action".

"IETF Consensus" is not defined in BCP 26; "IETF Review" is.

[Ballot discuss]
(1) Section 7.1.  This section seems to be enumerating the attacks possible with source routing, and noting that the scope of these are limited to nodes inside the SR domain because of SRH requires ingress filtering.  No issue with this position.  This feedback is around the clarity of the attacks in question.  The text currently says:

(a) (from the CanSecWest reference in from RFC5095) “Such attacks include bypassing filtering devices, reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast”

(b) In addition, “other known attacks on an IP network (e.g.  DOS/DDOS, topology discovery, man-in-the-middle, traffic interception/siphoning)” are also noted.

-- Per (a), the issue is broader than “bypassing filtering devices”, it’s also the “bypassing of network management, auditing or security devices”.

-- Per (b), the enumeration of attacks using the parenthetical suggested that these attacks are generically possible on “IP networks” and not SRH specific.  If that is the appropriate read, then somewhere in the earlier text it should be noted that SRH can also facilitate traffic steering for DDoS, eavesdropping and traffic manipulation through the manipulation (deletion, re-ordering) of the SRHs.  If (b) is a complementary list to (a) on SRH specific list of attacks, then it needs to be reconciled for duplication with (a) (e.g., per “bandwidth exhaustion” of (a) and “DOS/DDOS” of (b), are they the same?).  I think it is important to make clear what new attacks TTPs are possible with SRH even if the attack type is already possible through another TTPs on a generic IP network.

[Ballot comment]
(2) I support Ben Kaduk's DISCUSS position.

(3) Section 2.1.2.1.  Per “Local configuration determines when to check for an HMAC and potentially indicates what the HMAC protects”, can you clarify on how the local config changes the fields/input/content of what is protected by the HMAC?  Subsequent text in this section seems to be clear on what gets passed as input to the HMAC (i.e., the definition of “Text”).

[Ballot discuss]
(1) Section 2.1.2.1 says:

  Local configuration determines when to check for an HMAC and
  potentially indicates what the HMAC protects, and a requirement on
  where the HMAC TLV must appear (e.g. first TLV), and whether or not
  to verify the destination address is equal to the current segment.

I'm uncomfortable about leaving so much of the semantics of a
security mechanism up to the local configuration.
Specifically, the "potentially indicates what the HMAC protects" and
"whether or not to verify the destination address is equal to the
current segment", which leaves some of the key security properties of
the system in the hands of someone that is potentially quite
inexperinced in reasoning about the relevant security properties.
I do think we can still specify something useful and interoperable that
still allows flexibility about when to check and where the TLV can
appear.  (This may in practice also allow flexibility about what it protects,
if the semantics are something like "it protects everything prior to it"
and we allow for other TLVs to appear after it, but the actual *rules*
for what it protects would be well-specified.)

(2) I also think we should discuss what is protected by the HMAC.  I note in
the COMMENT that this seems to be more about protecting the SRH contents
than the packet payload, but at present there is no binding at all to
the containing packet or flow, which seems to in effect present the SRH
as a self-contained, "signed", policy blob, which can be detached from
packet data and transferred at will.  It's probably also best practice
to include a fixed "contxt string" like "IPv6 SRH HMAC" even though the
risk of key reuse and cross-protocol attacks seems quite small here.
It's also pretty tempting to pull in the representation of the
"immutable TLVs", though there are probably some tricky details to
describing how to do that, and that can present complexity challenges
if/when nodes not trusted with HMAC keys are expected to apply varying
TLVs at runtime.  (The lack of defined TLVs other than HMAC and padding
make it hard for an outsider to gague the intent for TLV usage.)

(3) I'm concerned that this mechanism may not be consistent with BCP 107's
guidance on automated vs. manual key management, with respect to
directly using the long-term HMAC key to key the HMAC.  Most modern
designs will introduce an intermediate key-derivation step that mixes
some message- or flow-specific data into the intermediate key that is
then used to key the per-message MAC.  Section 5.5 seems to suggest that
the IPv6 flow label may be usable (i.e., fixed within the domain for a
given flow) for this purpose, but I may be missing a subtlety about
intra- vs. inter-domain traffic, and it may not be feasible to involve a
central controller into flow identifier assignment.
If the HMAC is solely intended to make self-contained "authorized policy
blobs" that are infrequently changing, then the direct use of the
long-term key may not be as problematic as it first seems.
Additionally, if the SDN-oriented or "trusted key distribution protocol such as
[RFC6407]" cases are used, then this is somewhat less of a concern,
though there may still be key usage lifetime considerations to worry
about and potentially force somewhat-rapid key turnover (i.e., weeks or
months).

(4) I'm not sure that the scoping of key IDs per destination node is
consistent with the use cases depcicted.  I mention this in the COMMENT
section in a few places, but the short version is roughly "if the HMAC
is fixed for the life of the packet, then we can either have the key ID
namespaced by destination address but only have one verifier, or we can
have multiple verifiers on the path but the key ID space is global".  We
do currently have text that talks about verification being performed at
multiple points on the path, so I'm not sure which scenario is intended.

(5) I think we need to have some discussion about key
revocation/rotation.  The mode of operation for the HMAC TLV that
appears to be envisioned by this document is that there is a central
trusted service that computes "blessed" segment routes with an
accompanying HMAC "signature" (not a real signature, but a sign of
aproval in some sense), and that the resulting token of (SRH including
HMAC TLV) is distributed by SDN configuration.  These SRH tokens are
treated by many nodes as opaque blobs, applied to outgoing traffic
according to the procedure configured alongside the token.  Some other
(trusted) nodes in the network may look inside the SRH to verify the
MAC, and check that the rout in question should be coming from that
direction, but those nodes may be a minority of nodes.  In this
scenario, we need to consider the behavior when the central controller
changes what routes are to be used, and effectively wants to "revoke"
the old ones and ensure that the deprecated routes are not in use in the
SR domain.  The only mechanism for doing so seems to be to rotate the
HMAC key in question so as to discard all HMACs generated by the key in
question (since keeping something akin to a CRL of "revoked" HMAC values
seems infeasible in general); I think we should have some discussion
about needing to do a key rotation to effectuate such "revocation" (that
is, cryptographically ensure that previously configured/"blessed" routes
are no longer in use).  It would also be pretty easy to tie this in to
text about recovering from a compromised HMAC key.

[Ballot comment]
As something of a general note, this document (specifically, the HMAC
portions) was initially challenging for me to read, since in the
security community we tend to have HMAC (or MACs in general) apply to
specific messages and protect the content from end to end.  The usage
here seems rather different, in that the HMAC is protecting not the
packet payload, but (essentially) just the SRH, which is to a large
extent a fixed (e.g., per-flow) artifact that reflects routing policy.  So the
MAC is serving to authenticate policy, more than messaging, and there
was very little in the document that tried to make that distinction.
I've tried to indicate some locations/changes that would improve readability
in this regard.

Section 1

  The Segment Routing Architecture [RFC8402] describes Segment Routing
  and its instantiation in two data planes MPLS and IPv6.

nit: we need some form of punctuation after "data planes".

Section 2

  o  Tag: tag a packet as part of a class or group of packets, e.g.,
      packets sharing the same set of properties.  When tag is not used
      at source it MUST be set to zero on transmission.  When tag is not
      used during SRH Processing it SHOULD be ignored.  Tag is not used
      when processing the SID defined in Section 4.3.1.  It may be used
      when processing other SIDs which are not defined in this document.
      The allocation and use of tag is outside the scope of this
      document.

At what scope does its use need to be defined?  Can it be defined on a
per-segment basis or must it be deployment-global?

  The mutability of the TLV value is defined by the most significant
  bit in the type, as specified in Section 2.1.

It seems like this presents the design as one where we rely on the
participants to be trusted to properly respect the (im)mutability, and
there are not external mechanisms (e.g., cryptography) to enforce them.
So, we have SR nodes that are in a hybrid state of not being trusted
with HMAC keys (and thus to generate routing policy) but are trusted to
"be implemented correctly" and not mutate fields that are supposed to be
immutable.  This multi-tier trust system should probably be discussed in
the security considerations.

Section 2.1

  An implementation MAY limit the number and/or length of TLVs it
  processes based on local configuration.  It MAY:
  [...]

Is this list an exhaustive enumeration of the granted permissions or are
other limitations possible?

  o  Limit the number of consecutive Pad1 (Section 2.1.1.1) options to
      1, if padding of more than one byte is required then PadN
      (Section 2.1.1.2) should be used.

nit: comma splice

  Type: An 8 bit value.  Unrecognized Types MUST be ignored on receipt.

  Length: The length of the Variable length data.

Do we want to give a pointer to (e.g.) the registry for these type
values?
I see we say in the next entry that Length measures bytes, though
perhaps it is more natural to mention it here.

  Type Length Value (TLV) contain OPTIONAL information that may be used
  by the node identified in the Destination Address (DA) of the packet.

nit: there seems to be a singular/plural mismatch of sorts here, in that
the current TLV incarnation mostly acts as a singular.  I'd suggest
adding another word like "entries" or "structures" after the
parenthetical, as a resolution.

  The highest-order bit of the TLV type specifies whether or not the
  TLV data of that type can change en route to the packet's final
  destination:

For clarity: that's bit '0' in the above figure?

Section 2.1.1

      Padding TLVs are used for meeting the alignment requirement of the
      subsequent TLVs.
      [...]
      Padding TLVs are used for alignment.

Is there some redundancy here we could deduplicate?

Section 2.1.1.1

  required.  If more than one byte of padding is required a Pad1 TLV
  MUST NOT be used, the PadN TLV MUST be used.

nit: comma splice

Section 2.1.1.2

      Padding: Length octets of padding.  Padding bits have no
      semantics.  They MUST be set to 0 on transmission and ignored on

[Elsewhere in the document we've used "semantic" as a singular; it might
be worth a pass to check for consistency of usage]

Section 2.1.2

I echo the sentiments already expressed about this HMAC format being
likely to reflect substantial wasted space in much common usage.
(Unless the intent is that since TLV support is optional, it's unlikely
to be implemented at all, in which case the wastefulness of a
nonexistent feature doesn't matter?)
In particular, having to specify the details of which bits of the 'HMAC'
field have significance when the HMAC algorithm in use has fewer than 32
bytes of output seems to be just as much effort as making the field
variable length.
Four octets of Key ID also seems like far more than will be needed,
though we don't really discuss the scope (in space/topology and time) in
which it needs to be unique -- we should probably talk about that here!
(I do see a bit of discussion in Section 2.1.2.2 that seems to say that
the key-ID is scoped by the destination IP address.)  On the other hand,
this much Key ID space could be used if there was a desire to have very
fine-grained routing policy and revocation ability (see below), but it's
still unclear that even in a high-churn fine-grained situation there
would be the will to store millions of HMAC keys on the
controller/verifier.

  The HMAC TLV is used to verify the source of a packet is permitted to
  use the current segment in the destination address of the packet, and
  ensure the segment list is not modified in transit.

I'd suggest some revisions to this along the lines of:

%  The HMAC TLV is used to verify that the SR applied to a packet was
%  selected by an authorized party, and to ensure that the segment list is
%  not modified after generation.  This also allows for verification that
%  the current segment (by virtue of being in the authorized segment list)
%  is an authorized use.

since the expected usage seems to not be to give the keys (and thus the
choice of segment lists) to the actual source of the packet, and we are
detecting modification of the Segment List since the HMAC generation,
which could span a broader period of time than just when the packet
carrying the HMAC is "in transit".

Section 2.1.2.1

  For HMAC algorithms producing digests less than 32 octets, the digest
  is placed in the lowest order octets of the HMAC field.  Remaining
  octets MUST be set to zero.

To keep me from second-guessing myself, are these the "lowest order
octets" if we are treating the field as a 32-byte big-endian integer?
(As opposed to an array of bytes enumerated in order per the figure.)

  If HMAC verification is successful, the packet is forwarded to the
  next segment.

Does this really mean "processing proceeds as normal", to allow for the
possibility of local action/modification before forwarding?

Section 2.1.2.2

  The HMAC Key ID field is opaque, i.e., it has neither syntax nor
  semantic except as an identifier of the right combination of pre-
  shared key and hash algorithm, and except that a value of 0 means
  that there is no HMAC field.

"No HMAC field" or "the HMAC field is filled entirely with zeros"?  The
previous diagram/discussion does not suggest that the HMAC field is
sometimes omitted.

  At the HMAC TLV verification node the Key ID uniquely identifies the
  pre-shared key and HMAC algorithm.

  At the HMAC TLV generating node the Key ID and destination address
  uniquely identify the pre-shared key and HMAC algorithm.  Utilizing

This decision to make the key-ID space scoped to the destination address
seems to have some potentially substantial consequences that I don't see
discussed in the draft.  Specifically, since the destination address
will change on every hop, it would seem to preclude a model where the
HMAC TLV is generated by the sender and not modified subsequently (which
itself would probably have knock-on effects).  Is the additional scoping
by IP address of key-ID necessary even with the 4-octet key-ID, or would
scoping the key-ID to be globally unique within a SR domain suffice?
Unless the intent is that there is only a single verification node in a
given path?  The desired usage remains quite unclear to me.

Section 3.2, 3.3

nit(?): We seem to talk about "an IPv6 packet" when we really mean "an
IPv6 packet with SRH", "an SR IPv6 packet", "an SRv6" or similar.

Section 4.1

  A Source node steers a packet into an SR Policy.  If the SR Policy
  results in a segment list containing a single segment, and there is
  no need to add information to SRH flag or TLV, the DA is set to the
  single segment list entry and the SRH MAY be omitted.

nit: "to the SRH flags or to add TLVs"

      HMAC TLV may be set according to Section 7.

Do we want to say anything about other, to-be-specified, TLVs here?
Like "HMAC (or other) TLVs may be set" or "TLVs (including HMAC) may be
set according to their specifications"?

4.1.1.  Reduced SRH

  A reduced SRH does not contain the first segment of the related SR
  Policy (the first segment is the one already in the DA of the IPv6
  header), and the Last Entry field is set to n-2 where n is the number
  of elements in the SR Policy.

This seems to imply that Segments Left is not constrained to point
inside the Segment List (and can point one past it); is that correct?

Section 4.3.1

  This document, and section, defines a single SRv6 SID.  Future
  documents may define additional SRv6 SIDs.  In which case, the entire
  content of this section will be defined in that document.

nit: perhaps this is just me, but I tend to read "defines a single SRv6
SID" as "defines a single SRv6 SID value"; the intent here seems to be
more along the lines of "SID behavior" or "SID processing algorithm".
The second sentence could also be phrased similarly to "Such documents
will need to specify the analogous behavior as is described in this
section and subsections".

Section 4.3.1.1

Is this pseudocode normative, or the text of the following subsections?

Section 5.1

  Nodes outside the SR Domain are not trusted: they cannot directly use
  the SID's of the domain.  This is enforced by two levels of access

nit: "SIDs" (no apostrophe)

  1.  Any packet entering the SR Domain and destined to a SID within
      the SR Domain is dropped.  This may be realized with the
      following logic, other methods with equivalent outcome are
      considered compliant:

nit: comma splice  (also in (2))

      *  Failure to implement this method of ingress filtering exposes
          the SR Domain to source routing attacks as described and
          referenced in [RFC5095]

nit: this doesn't seem like a bullet point in the list, but rather a
standalone paragraph of commentary.
It may also be worth reiterating that failure to do so on even a single
edge node puts the entire network at risk.

Section 5.2

  Consider a top of rack switch (T) connected to host (H) via interface
  (I).  H receives an SRH (SRH1) with a computed HMAC via some SDN
  method outside the scope of this document.  H classifies traffic it
  sources and adds SRH1 to traffic requiring a specific SLA.  T is

I'm having a hard time parsing how the SRH1 that H receives via SDN can
be the same SRH1 that H adds to traffic.  The key insight seems to be
that the SRH received via SDN is not attached to an IPv6 packet as a
"live" routing header, but is rather a piece of configuration data to be
applied as the SRH on flows sent on a given SR.  (The formalism is
slightly weird, as "receiving an SRH" includes the "next header" value,
which is arguably artificially limiting, but this is probably minor
enough to ignore.)  So perhaps we want to say that "H receives, along
with the configuration for applying SR to a given flow, an SRH (SRH1)
with pre-computed HMAC that reflects that SR flow, via some SDN method
outside the scope fo this document."

  An operator of the SR Domain may choose to have all segments in the
  SR Domain verify the HMAC.  This mechanism would verify that the SRH
  segment list is not modified while traversing the SR Domain.

As partially covered above, this seems inconsistent with having the HMAC
key-ID be scoped by the destination SID when the destination SID changes
from segment to segment.

Section 5.4

  For the source of an invoking packet to process the ICMP error
  message, the correct destination address must be determined.  The

"correct" in what sense/for what operation?

      *  If routing header is type 4 (SRH)

(This is still "TBD", formally, right?)

        +  Use the SID at Segment List[0] as the destination address of
            the invoking packet.

Similarly to the first comment on this section, do we want some language
about how this is "use"d "for processing by the upper layer transport"?

Section 5.6

I'm slightly tempted to add a sentence along the lines of "the
mechanisms in this document are known to not be directly transferrable
to multi-domain deployment models without substantial impact on these
properties", but (1) it's an absolute statement that seems like it would
be hard to be 100% confident in, and (2) it's not entirely clear that it
adds much value to the general reader (as opposed to providing a
security disclaimer to make the security AD happy).  So I'm curious to
hear about how much thought has already gone into this, pointers to
ongoing documents on the topic, etc.

Section 6.1

I a little bit wonder if mixing zero-based (Segments Left; Last Entry)
and one-based (S1, S2, S3) indexing is going to cause undue cognitive
load for anyone.

Section 6.2

  o  The SR domain is secured as per Section 5.1 and no external packet
      can enter the domain with a destination address equal to a segment
      of the domain.

I'd suggest using "firewalled" rather than "secured", since "secured"
can mean many different things and we have a more-precise term
available.

Section 6.3.2

Is it worth calling out that P5 does not have an SRH?

Section 6.9

  This section describes how a function may be delegated within the SR
  Domain to non SR source nodes.  [...]

I'm kind of confused about what "non SR source node" means in the
context of a source node that is adding an SRH for verification
elsewhere.

Section 6.6.1

  An operator may prefer to add the SRH at source 8, while 5 verifies
  the SID list is valid.

I note that "add" here means "apply a fixed bitstring to the packet",
not "compute the value of"...

  For illustration purpose, an SDN controller provides 8 an SRH
  terminating at node 9, with segment list , and HMAC TLV
  computed for the SRH.  The HMAC key is shared with 5, node 8 does not
  know the key.  Node 5 is configured with an IACL applied to the

... since the SRH value is computed by the controller and distributed to
8 as almost an opaque token.  It would be good if we could reword this
to be more clear about how the mechanics work such that 5 does not need
the HMAC key.

  Node 8 originates packets with the received SRH with HMAC TLV.

nit: I suggest s/with HMAC TLV/including HMAC TLV/

Section 7.1

Does the ability to create traffic loops or near-loops (that span the
same links dozens or hundreds of times) merit a specific mention outside
of "DOS/DDOS"?

Section 7.5

  The SR Domain is a trusted domain, as defined in [RFC8402] Section 2
  and Section 8.2.  The SR Source is trusted to add an SRH (optionally
  verified via the HMAC TLV in this document), and segments advertised

I suggest s/verified/verified as having been generated by a
trusted configuration source/.

  The use of SRH with AH by an SR source node, and processing at a SR
  segment endpoint node, is not defined in this document.  Future
  documents may define use of SRH with AH and its processing.

It's not entirely clear to me what this is intended to convey.  It this
saying "SRH MUST NOT be used in the same packet as AH" or something more
like "we make no statements about the use of SRH in combination with
AH"?

Section 8

  RFC will be published.  The Designated expert will post a request to
  the 6man WG mailing list (or a successor designated by the Area
  Director) for comment and review, including an Internet-Draft.

nit: this wording makes it sound like either the DE includes an I-D in
the body of the mail or is the author of the I-D in question; I assume
we just want a pointer or link to the draft requesting the
allocation(s).

Section 12.2

I-D.filsfils-spring-srv6-interop and
I-D.matsushima-spring-srv6-deployment-status are only referenced from
the Implementation Status section (that is to be removed); should the
references be removed as well?

I think RFCs 2104, 6437, and 6438 need to be normative.

[Ballot comment]
I have a couple of questions/comments:

1) Given this is an IP header extension that would need to be added to every single packet when used, I would have expected a more byte-conserving design for the HMAC TLV. It doesn't seems that the RESERVED field is actually needed (as padding can be done by the padding TLVs) and the HMAC TLV could even be variable length based on the actual output of the HMAC algorithm used. Why was the current design chosen instead?

2) I agree with the TSV-ART review (Thanks Joe!) that MTU discussion in section 5.3 is not sufficient and at least a pointer to draft-ietf-intarea-tunnels would be good.

3) Sec 5.6: I would rather like to see a clear applicability state at the beginning of this document that the statement in section 5.6 at the end of the document. E.g. use of the HMAC TLV also assumes some kind of common (centralised/SDN-based) pre-configuration. I think it would be important to state these kind of constraints upfront. I think this point does not raise discuss level, however, I think it would be really important to address because it becomes clear when ready the document that certain deployment scenario was assumed and I think it would be appropriate to restrict the applicability of this spec to this scenario. Otherwise I think it would not be acceptable to have some of the "out-of-scope" statements in this doc.

4) I also agree with the TSV-ART review that the registration procedure for the Flags should be "IETF review". Alternatively I actually recommend to not create this registry now and leave this decision to the first RFC that will assign a flag (which would anyway need to update this RFC).

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

The IANA Functions Operator has completed its review of draft-ietf-6man-segment-routing-header-22. 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 four actions which we must complete.

First, in the Routing Types registry on the Internet Protocol Version 6 (IPv6) Parameters registry page located at:

https://www.iana.org/assignments/ipv6-parameters/

a new registration is to be made as follows:

Value: [ TBD-at-Registration ]
Description: Segment Routing Header (SRH)
Reference: [ RFC-to-be ]

IANA understands that the authors have suggested a value of 4 for this registration.

Second, in the Type 4 - Parameter Problem subregistry of the ICMPv6 "type" Numbers registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

a new registration is to be made as follows:

Code: [ TBD-at-Registration ]
Name: SR Upper-layer Header Error
Reference: [ RFC-to-be ]

Third, a new registry is to be created called the Segment Routing Header Flags registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Expert Review as defined in RFC 8126. IANA understands that there are eight bits to be registered in this registry.

IANA Question --> Do any of the bits have initial registrations?

Fourth, a new registry is to be created called the Segment Routing Header TLVs registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

Values in the new registry range from 0-255. The new registry is managed via Expert Review as defined in RFC 8126. There are initial registrations in the new registry as follows:

Assigned Description Reference
Value
------------------------------------------------------
0 Pad1 TLV [ RFC-to-be ]
1 Reserved [ RFC-to-be ]
2 Reserved [ RFC-to-be ]
3 Reserved [ RFC-to-be ]
4 PadN TLV [ RFC-to-be ]
5 HMAC TLV [ RFC-to-be ]
6 Reserved [ RFC-to-be ]
124-126 Experimentation and Test [ RFC-to-be ]
127 Reserved [ RFC-to-be ]
252-254 Experimentation and Test [ RFC-to-be ]
255 Reserved [ RFC-to-be ]

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.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-08-20):

From: The IESG
To: IETF-Announce
CC: ipv6@ietf.org, draft-ietf-6man-segment-routing-header@ietf.org, bob.hinden@gmail.com, Robert Hinden , suresh@kaloom.com, 6man-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (IPv6 Segment Routing Header (SRH)) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document: - 'IPv6 Segment Routing Header (SRH)'
  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
ietf@ietf.org mailing lists by 2019-08-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Segment Routing can be applied to the IPv6 data plane using a new
  type of Routing Extension Header called the Segment Routing Header.
  This document describes the Segment Routing Header and how it is used
  by Segment Routing capable nodes.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ballot/

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

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

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

Document Shepard Write up for draft-ietf-6man-segment-routing-header-21.txt
Bob Hinden
18 June 2019


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

  Proposed Standard. 
  Header indicates Standards Track.


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

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Segment Routing is designed to be applied to the IPv6 data plane using
  a new type of Routing Extension Header (SRH) in this document.  This
  document describes the Segment Routing Extension Header and how it is
  used by Segment Routing capable nodes.

  The Segment Routing Architecture [RFC8402] describes Segment Routing
  and its instantiation in two data planes MPLS and IPv6.  The encoding
  of IPv6 segments in the Segment Routing Extension Header is defined in
  this document.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

  The work on SRH has been underway for a long time.  The first working
  group version of the draft was published in December 2015, the first
  working group call started on March 2018.  Given the number of issues
  that were raised the chairs started an issue tracker.  Fifty issues
  were tracked.  After further discussion, many new drafts, and
  confirmation at IETF 104, the chairs started a second working group
  last call in May 2019.  After further discussion two new drafts were
  published and the chairs concluded the last call and declared that
  there is consensus to advance this document on 14 June 2019.  See:

  https://mailarchive.ietf.org/arch/msg/ipv6/_9OrqvZYpDB0lJEE8jxB0a0N44M

  The chairs believe there is a strong consensus to advance this
  document, but it was not unanimous.

  There remains a desire by a few people to add more clarity on
  mutability of segment lists and other fields.  The chairs conclusion
  is that the text added since the last call closes this topic, but a
  few would like to see more.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Section 9 lists current implementations, these include:

      Linux Kernel v4.14
      Cisco Systems IOS XR and IOS XE
      FD.io  VPP/Segment Routing for IPv6
      Barefoot Networks Tofino NPU

  Detailed reviews were done in the course of review this document in
  the 6man working group.  Several people did extensive reviews, they
  include Joel Halpern, Ron Bonica, Mark Smith, and Tom Herbert.  The
  6man chairs have also reviewed this document.  These reviews resulted
  in many improvements to the document.

  No MIBs or other media types to be reviewed.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Bob Hinden is the Document Shepherd.
  Suresh Krishnan is the Responsible AD.


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

  The document shepherd reviewed the draft (actually 21 versions since
  it became a w.g. draft), followed and participated in the discussion
  on the mailing list and at 6man sessions.  The chairs put a lot of
  effort into determining where there was consensus on issues and in
  several cases proposed text changes to resolve issues.  This was
  accepted pretty well by the working group and the authors.
 
  The document shepherd believes this document is ready to be advanced
  to the IESG.


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

  The shepherd has no concerns about the reviews done in 6man, any
  issues remaining will require wider review as part of the next steps
  in the process.  SRH as part of the Spring architecture has broader
  implications than just a routing protocol (that is, beyond the routing
  area where the Spring w.g. Is located).  The 6man review was very
  thorough, but there are not many 6man working group participants that
  are also Spring architecture experts.


(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 chairs think a thorough review by the security area for issues like
  the HMAC, the use of AH with SRH, and the security of source routing in
  general is warranted.


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

  This document has six authors, one over the limit.  Much earlier,
  there were about 12 authors, the chairs were able to have the authors
  reduce it to five.  We noticed later in the process, that Darren Dukes
  who was clearly acting a document editor, was not listed as an author.
  We asked him to add his name.  The chairs think an exception is
  reasonable in this case.


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

  All authors have confirmed this.

  stefano@previdi.net  Confirmed 16 June 2019
  cfilsfil@cisco.com Confirmed 18 June 2018
  ddukes@cisco.com  Confirmed 17 June 2019
  john@leddy.net Confirmed 17 June 2019
  satoru.matsushima@g.softbank.co.jp  Confirmed 17 June 2019
  daniel.voyer@bell.ca  Confirmed 17 June 2019


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

  There is one IPR disclosure from Cisco filed for an earlier draft, see:

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

  Summary is:

  “If technology in this document is included in a standard adopted by
  IETF and any claims of any Cisco patents are necessary for practicing
  the standard, any party will have the right to use any such patent
  claims under reasonable, non-discriminatory terms, with reciprocity,
  to implement and fully comply with the standard.”


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

  The consensus is strong to advance.  It is not unanimous however.
  There has been a very active discussion on this document over a long
  period of time, the current draft is significantly improved and the
  chairs think the 6man working group would like to see it advanced.


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

  No appeals threatened.


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

  ID nits of the current draft is good.


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

  N/A


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

  All Normative reference point to published RFCs.


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

  All Normative reference point to published RFCs.


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

  This document does not change the status of any existing RFC.


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

  The Document Shepherd reviewed the IANA considerations section and
  thinks the text in the current version is good.  Earlier, changes were
  requested, these are in the current version.


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

  This is described in Section 8. “IANA Considerations” in detail.


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

  N/A

Document Shepard Write up for draft-ietf-6man-segment-routing-header-21.txt
Bob Hinden
18 June 2019


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

  Proposed Standard. 
  Header indicates Standards Track.


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

Relevant content can frequently be found in the abstract and/or
introduction of the document. If not, this may be an indication that
there are deficiencies in the abstract or introduction.

  Segment Routing is designed to be applied to the IPv6 data plane using
  a new type of Routing Extension Header (SRH) in this document.  This
  document describes the Segment Routing Extension Header and how it is
  used by Segment Routing capable nodes.

  The Segment Routing Architecture [RFC8402] describes Segment Routing
  and its instantiation in two data planes MPLS and IPv6.  The encoding
  of IPv6 segments in the Segment Routing Extension Header is defined in
  this document.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was
there controversy about particular points or were there decisions where
the consensus was particularly rough?

  The work on SRH has been underway for a long time.  The first working
  group version of the draft was published in December 2015, the first
  working group call started on March 2018.  Given the number of issues
  that were raised the chairs started an issue tracker.  Fifty issues
  were tracked.  After further discussion, many new drafts, and
  confirmation at IETF 104, the chairs started a second working group
  last call in May 2019.  After further discussion two new drafts were
  published and the chairs concluded the last call and declared that
  there is consensus to advance this document on 14 June 2019.  See:

  https://mailarchive.ietf.org/arch/msg/ipv6/_9OrqvZYpDB0lJEE8jxB0a0N44M

  The chairs believe there is a strong consensus to advance this
  document, but it was not unanimous.

  There remains a desire by a few people to add more clarity on
  mutability of segment lists and other fields.  The chairs conclusion
  is that the text added since the last call closes this topic, but a
  few would like to see more.


Document Quality:

Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  Section 9 lists current implementations, these include:

      Linux Kernel v4.14
      Cisco Systems IOS XR and IOS XE
      FD.io  VPP/Segment Routing for IPv6
      Barefoot Networks Tofino NPU

  Detailed reviews were done in the course of review this document in
  the 6man working group.  Several people did extensive reviews, they
  include Joel Halpern, Ron Bonica, Mark Smith, and Tom Herbert.  The
  6man chairs have also reviewed this document.  These reviews resulted
  in many improvements to the document.

  No MIBs or other media types to be reviewed.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Bob Hinden is the Document Shepherd.
  Suresh Krishnan is the Responsible AD.


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

  The document shepherd reviewed the draft (actually 21 versions since
  it became a w.g. draft), followed and participated in the discussion
  on the mailing list and at 6man sessions.  The chairs put a lot of
  effort into determining where there was consensus on issues and in
  several cases proposed text changes to resolve issues.  This was
  accepted pretty well by the working group and the authors.
 
  The document shepherd believes this document is ready to be advanced
  to the IESG.


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

  The shepherd has no concerns about the reviews done in 6man, any
  issues remaining will require wider review as part of the next steps
  in the process.  SRH as part of the Spring architecture has broader
  implications than just a routing protocol (that is, beyond the routing
  area where the Spring w.g. Is located).  The 6man review was very
  thorough, but there are not many 6man working group participants that
  are also Spring architecture experts.


(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 chairs think a thorough review by the security area for issues like
  the HMAC, the use of AH with SRH, and the security of source routing in
  general is warranted.


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

  This document has six authors, one over the limit.  Much earlier,
  there were about 12 authors, the chairs were able to have the authors
  reduce it to five.  We noticed later in the process, that Darren Dukes
  who was clearly acting a document editor, was not listed as an author.
  We asked him to add his name.  The chairs think an exception is
  reasonable in this case.


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

  All authors have confirmed this.

  stefano@previdi.net  Confirmed 16 June 2019
  cfilsfil@cisco.com Confirmed 18 June 2018
  ddukes@cisco.com  Confirmed 17 June 2019
  john@leddy.net Confirmed 17 June 2019
  satoru.matsushima@g.softbank.co.jp  Confirmed 17 June 2019
  daniel.voyer@bell.ca  Confirmed 17 June 2019


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

  There is one IPR disclosure from Cisco filed for an earlier draft, see:

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

  Summary is:

  “If technology in this document is included in a standard adopted by
  IETF and any claims of any Cisco patents are necessary for practicing
  the standard, any party will have the right to use any such patent
  claims under reasonable, non-discriminatory terms, with reciprocity,
  to implement and fully comply with the standard.”


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

  The consensus is strong to advance.  It is not unanimous however.
  There has been a very active discussion on this document over a long
  period of time, the current draft is significantly improved and the
  chairs think the 6man working group would like to see it advanced.


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

  No appeals threatened.


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

  ID nits of the current draft is good.


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

  N/A


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

  All Normative reference point to published RFCs.


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

  All Normative reference point to published RFCs.


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

  This document does not change the status of any existing RFC.


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

  The Document Shepherd reviewed the IANA considerations section and
  thinks the text in the current version is good.  Earlier, changes were
  requested, these are in the current version.


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

  This is described in Section 8. “IANA Considerations” in detail.


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

  N/A

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

Request for posting confirmation emailed to previous authors: Satoru Matsushima , " daniel.voyer@bell.ca" , John Leddy , Darren Dukes , Clarence Filsfils , Stefano Previdi

Request for posting confirmation emailed to previous authors: Tomoya Kosugi , Dirk Steinberg , Satoru Matsushima , Robert Raszuk , " daniel.voyer@bell.ca" , David Lebrun , John Leddy , Eric Vyncke , " daniel.bernier@bell.ca" , Darren Dukes , Kamran Raza , Ida Leung , Brian Field , Clarence Filsfils , Ebben Aries , Stefano Previdi , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tomoya Kosugi , Dirk Steinberg , Satoru Matsushima , Robert Raszuk , " daniel.voyer@bell.ca" , David Lebrun , John Leddy , Eric Vyncke , " daniel.bernier@bell.ca" , Darren Dukes , Kamran Raza , Ida Leung , Brian Field , Clarence Filsfils , Ebben Aries , Stefano Previdi , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tomoya Kosugi , Dirk Steinberg , Satoru Matsushima , Robert Raszuk , David Lebrun , John Leddy , Eric Vyncke , " daniel.bernier@bell.ca" , " daniel.voyer@bell.ca" , Kamran Raza , Ida Leung , Brian Field , Clarence Filsfils , Ebben Aries , Stefano Previdi , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tomoya Kosugi , Stefano Previdi , Satoru Matsushima , Robert Raszuk , David Lebrun , John Leddy , Eric Vyncke , " daniel.voyer@bell.ca" , Kamran Raza , " daniel.bernier@bell.ca" , Dirk Steinberg , Clarence Filsfils , Brian Field , Ida Leung , Ebben Aries , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: Tomoya Kosugi , Stefano Previdi , David Lebrun , Eric Vyncke , Ida Leung , Brian Field , Clarence Filsfils , Ebben Aries , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Eric Vyncke" , "Ida Leung" , "Brian Field" , "Ebben Aries" , "Clarence Filsfils" , "Stefano Previdi" , "David Lebrun" , "Tomoya Kosugi" , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Eric Vyncke" , "Ida Leung" , "Brian Field" , "Ebben Aries" , "Clarence Filsfils" , "Stefano Previdi" , "David Lebrun" , "Tomoya Kosugi" , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Eric Vyncke" , "Ida Leung" , "Brian Field" , "Ebben Aries" , "Clarence Filsfils" , "Stefano Previdi" , "David Lebrun" , "Tomoya Kosugi" , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Eric Vyncke" , "Ida Leung" , "Brian Field" , "Ebben Aries" , "Clarence Filsfils" , "Stefano Previdi" , "David Lebrun" , "Tomoya Kosugi" , "J. Linkova" , 6man-chairs@ietf.org

Request for posting confirmation emailed to previous authors: "Eric Vyncke" , "Ida Leung" , "Brian Field" , "Ebben Aries" , "Clarence Filsfils" , "Stefano Previdi" , "David Lebrun" , "Tomoya Kosugi" , "J. Linkova" , 6man-chairs@ietf.org