Segment Routing Architecture
draft-ietf-spring-segment-routing-15

Firstly, thank you for writing this, and including a manageability section.

I'm a little confused by one sentence in this section:
"In addition to the allocation policy/tooling that the operator will have in place, an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach."
Ok, great -- but I'm not at all sure how an implementation would **detect** that conflict in order to resolve it in any manner. I hope I'm being dumb or missing something obvious - are you able to help me understand?

Thanks to everyone who put in work on this document. I do note that the list of authors is over the five-author recommended limit. I checked both the ballot and the shepherd write-up, and was a little surprised not to find an explanation of why this document is exceptional in this regard.

I have one major comment and a handful of editorial comments.

The major comment regards the treatment of trust assumptions in the security section. The SR-MPLS section asserts: "[T]here is an assumed trust model such that any node imposing a label stack on a packet is assumed to be allowed to do so"; the SRv6 section has a similar assertion: "[T]here is an assumed trust model such that any node adding an SRH to the packet is assumed to be allowed to do so."

I leave it to the security area directors to speak to whether it is okay in 2017 to publish documents that forego integrity protection of source routing information based on assumptions of perfectly secured networks. Irrespective of the answer to that question, I'm perplexed that the security section does not go into detail about the consequences that arise when these assumptions are violated. I think a clear description of these consequences is relevant and necessary to include, as it informs the level of care that is appropriate for both implementation and deployment of these protocols.

I want to be clear that I consider this a major flaw in the document, and am on the fence regarding whether it should constitute a blocking DISCUSS. I would support anyone else in issuing a DISCUSS on this topic.

Editorial comments follow.

Section 2 contains the following text:

   Active Segment: the segment that MUST be used by the receiving router
   to process the packet.

I really don't think you want to use normative language in the terminology section. I strongly recommend moving this requirement down to a section that bears more directly on implementation.

Section 3.4.2:

   These extensions are defined in IGP SR extensions documents.

Please add a citation to the relevant documents.

Section 3.5: 

   ABRs G and J will propagate the prefix and its SIDs into the backbone
   area by creating a new instance of the prefix according to normal
   inter-area/level IGP propagation rules.

Please expand the term "ABR" on first use.

I agree with Alissa/Adam.

Thanks for addressing my DISCUSS.

Substantive Comments:

- I support Alissa's discuss and Adam's major comment.

- Requirements Language: There are lower case instances of 2119 keywords. Unless you mean for those to also be normative, please use the boilerplate from RFC 8174.

-3.1.1, last paragraph: Why are the SHOULDs not MUSTs?

-12.2: The citations to the following references seem to be used normatively:
I-D.ietf-6man-segment-routing-header
I-D.ietf-isis-segment-routing-extensions
I-D.ietf-ospf-ospfv3-segment-routing-extensions
I-D.ietf-ospf-segment-routing-extensions

Editorial Comments and Nits:

-1, 2nd paragraph: s/"referred by"/"referred to by"

-2, definition of "Active Segment" : "The segment that MUST be used..."
The MUST seems like a statement of fact. (If that is actually intended to define a requirement, please state it more directly.)

-8, 2nd paragraph, first sentence: s/on/to

-8.2, 2nd paragraph, first sentence: s/on/to

The good news is that, whenever you have ingested the terminology section, you pretty much understand how the protocols works. :-)

1.
Good to see that this new protocol spec. has a "manageability considerations". However, a major comment (not sure if this should be a DISCUSS, so help me understand). I have the same questions as Warren regarding:

    "In addition to the allocation policy/tooling that the operator will have in place, an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach."

I guess you want to start by stressing the SID uniqueness in the different scenario: distributed, centralized, hybrid.
And from there, explain where this apply. I guess the sentence only applies to the hybrid scenario, right?
Then you should explain how an implementation should first detect a conflict and then protect.

2. Section 3.1.1

   The ingress node of an SR domain SHOULD validate that the path to a
   prefix, advertised with a given algorithm, includes nodes all
   supporting the advertised algorithm. 

This is only in the distributed scenario, right? This is what you mean by "advertised with a given algorithm"
In other words, you mean "advertised with a given IGP algorithm".
In hybrid or centralized scenarios, the ingress node might not know. See

   In a centralized scenario,  ...
   The SR architecture allows these SR controllers to discover which
   SID's are instantiated at which nodes and which sets of local (SRLB)
   and global labels (SRGB) are available at which node.


Editorial:
NETCONF would benefit from a reference to RFC6241

I (think I) share the concerns that Alissa and Adam have raised here.
To that end, I am balloting no-obj but I support Alissa's DISCUSS.

The following comments may help get clarity here as well. It seems
to me that the MPLS variant relies on the security properties of
MPLS but that the IPv6 variant can potentially route packets
over the public Internet and relies on the HMAC defines in
draft-ietf-6man-segment-routing-header to protect the SRH from
modification. Is that correct? To that end, the various nodes
in the system must all be within one domain but you can have
an untrusted IPv6 path in between them. Is that correct?
The HMAC doesn't seem to be mandatory? When we look at that
other document should it be mandatory under some conditions? 

I had some trouble understanding the algorithm in S 3.1.2. Let
me see if I can reconstruct the scenario. We have a list of i ranges,
R(i) each of which is identified by L(Ri), N(Ri), so for instance,
so for instance, we might have two ranges:

R0 -> L=10, N=2  -> labels 10, 11
R1 -> L=20, N=3  -> labels 20, 21, 22

And then these are indexed by treating these as one contiguous
array A = [10, 11, 20, 21, 22] and then label(X) = A(X). Is that
right?

Nit: I found a bunch of examples of "e.g.:". The correct form is
"e.g., "

Thanks for the updated text to address my previous discuss point.

I support Alissa's and Kathleen's discusses and I would also like to add on to Spencer's comment: Given this is an architecture document, I think it would be appropriate to at least add a note about path selection and congestion management. This can be as simple as saying that if all traffic is assumed to best effort, it is expected that congestion control is implemented by the endpoints, or if resources are reserved it might make sense to monitor the incoming traffic and e.g. apply traffic shaping.

I'm not surprised to see additional security alarm bells going off for the SRv6 variant - this is quite similar to the additional congestion awareness alarm bells that went off when we were evaluating MPLS (which is usually pretty well contained) over UDP (which can get around the Internet with a lot less effort than MPLS without UDP). That's an opportunity to rethink the impact of changes to an underlying technology.

Which leads me to the point I should be making as a TSV AD. I'm not seeing any obvious mechanism that would tell you that you've managed to set up your segment routing so that some paths will undergo persistent congestion. You might consider whether it's worth recommending that people doing segment routing take a look at https://datatracker.ietf.org/doc/rfc8084/ and decide how much, if anything, would be useful to say about that. https://tools.ietf.org/html/rfc7510#section-5 is an early example of the kind of thing I'm talking about.

I support Alissa and Kathleen's DISCUSSes and look forward to their resolution.