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

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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.

[Ballot discuss]
While I understand the assumption that following the capabilities of existing protocols that incorporate similar functionality is okay, I'd like to walk through the security properties left off in the security considerations section to prevent tampering and see what can be done to correct that or minimally to list out the considerations.

There's a few places in the security considerations section to call out specifically.

Section 8.1:
  "The received information is validated using
  existing control plane protocols providing authentication and
  security mechanisms.  Segment Routing does not define any additional
  security mechanism in existing control plane protocols."

For MPLS what "security mechanisms" are referred to in this text?  It would be helpful to list any properties explicitly or drop this phrase if there are no additional security mechanisms.  Since segment routing lists an explicit list of segments (I see that this can be done with MPLS labels and you note it is already exposed), why is there no mention of integrity protection and origin authentication to prevent tampering?  I think EKR's comment is already hinting at this with his comments on IPv6, but I'd like to see explicit text to preferably fix this gap in the architecture, but minimally to document it and the associated security threats that result from this gap for MPLS and IPv6.

Section 8.2:

  "From a network protection standpoint, there is an assumed trust model
  such that any node adding an SRH to the packet is assumed to be
  allowed to do so.  Therefore, by default, the explicit routing
  information MUST NOT be leaked through the boundaries of the
  administered domain.  Segment Routing extensions that have been
  defined in various protocols, leverage the security mechanisms of
  these protocols such as encryption, authentication, filtering, etc."

This document focuses on the same threats as the MPLS use cases with no mention of tampering or mitigations.  Text should be added to describe how origin authentication and integrity are provided in the source routing header for IPv6 with the associated threats or to describe this gap if a solution does not exist.  I have not read the draft referred to at the start of this section, so I don't know if it addresses the concern or not.  In any case, this document isn't complete without some text on tampering considerations within your trusted domain.

Thank you.

[Ballot comment]
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

[Ballot comment]
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?

[Ballot comment]
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., "

[Ballot discuss]
I ended up reading draft-ietf-6man-segment-routing-header in tandem with this document, and I have a question arising out of that. The trust model for SRv6 outlined in this document appears to be one of reliance on the fact that an SRH will only ever be inserted and appear within a single administrative domain. But Section 5.2.2 of draft-ietf-6man-segment-routing-header talks about an SRH being inserted by a device outside of the segment routing domain. Which is correct? I think this is an important question because the whole trust model for the SR information seems to rely on out-of-band trust between participating nodes.

I also think this is important because there is no discussion in this document of the impact of the inclusion of the SR metadata on the fingerprinting of the device that inserted it. Section 5.1.4 of draft-ietf-6man-segment-routing-header sort of alludes to this but seems to equate the capabilities of an active attacker (who can conduct a traceroute) with a passive attacker who could passively collect topology/fingerprinting information simply by observing SRHes flowing by on the network. If the limitation to a single administrative domain is meant to prevent such a passive attack (not sure if that is really true, but perhaps the document assumes it?), that's another reason that the existence of such a limitation needs to be clarified.

[Ballot comment]

Per my DISCUSS comment, I think this document needs to include some considerations concerning the additional metadata that SRv6 adds to the packet. This has implications not just for passive observers but also for any node that logs the SRH.

[Ballot comment]
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.

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

The IANA Services Operator has reviewed draft-ietf-spring-segment-routing-13, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist

The following Last Call announcement was sent out (ends 2017-11-30):

From: The IESG
To: IETF-Announce
CC: spring@ietf.org, spring-chairs@ietf.org, aretana.ietf@gmail.com, draft-ietf-spring-segment-routing@ietf.org, aretana@cisco.com, martin.vigoureux@nokia.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Segment Routing Architecture) to Proposed Standard


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

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

Abstract


  Segment Routing (SR) leverages the source routing paradigm.  A node
  steers a packet through an ordered list of instructions, called
  segments.  A segment can represent any instruction, topological or
  service-based.  A segment can have a semantic local to an SR node or
  global within an SR domain.  SR allows to enforce a flow through any
  topological path while maintaining per-flow state only at the ingress
  nodes to the SR domain.

  Segment Routing can be directly applied to the MPLS architecture with
  no change on the forwarding plane.  A segment is encoded as an MPLS
  label.  An ordered list of segments is encoded as a stack of labels.
  The segment to process is on the top of the stack.  Upon completion
  of a segment, the related label is popped from the stack.

  Segment Routing can be applied to the IPv6 architecture, with a new
  type of routing header.  A segment is encoded as an IPv6 address.  An
  ordered list of segments is encoded as an ordered list of IPv6
  addresses in the routing header.  The active segment is indicated by
  the Destination Address of the packet.  The next active segment is
  indicated by a pointer in the new routing header.





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

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

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

  https://datatracker.ietf.org/ipr/2457/
  https://datatracker.ietf.org/ipr/2275/
  https://datatracker.ietf.org/ipr/2471/

=== AD Review of draft-ietf-spring-segment-routing-12 ===

Dear authors:

I just finished reviewing this document – sorry for the delay in processing.  Thanks for all the work you’ve but into this document!

I have some significant concerns (see below for details).  In general, the document presents an incomplete view of the architecture: details about important pieces are barely mentioned or not fully described, as is the case of the role of a central controller (PCE), and the BGP and Binding Segments.

Also, some of the architectural details are predicated on specific bits defined in the extensions, where this document should describe the general operation and leave the details (like bit names) to the extensions.  Note that I’m not asking that you don’t mention the extensions – pointing to them is fine --, I’m asking you to define the functionality in general and not as a function of the extensions.  For an example, see point M5.1. below.

I will wait for at least the Major comments to be addressed before starting the IETF Last Call.

Thanks!

Alvaro.



Major:

M1. The Introduction mentions several types of segments, and it says that the LDP LSP, RSVP-TE LSP, and BGP LSP segments are “illustrated in [I-D.ietf-spring-segment-routing-mpls]”.  But that is only true for the first two, for which examples are shown.  Where are these segment types defined?  The definition, and not the examples, is the Major issue here.  This document being the main architecture document should include the complete description.  BTW, the list is only about the “MPLS instantiation”, are there similar types of segments for IP?


M2. From Section 2. (Terminology): “Using the same SRGB on all nodes within the SR domain ease operations and troubleshooting and is expected to be a deployment guideline.”  It is “expected to be a deployment guideline” where/when??  Given that this document is the general architecture, I figured that maybe draft-ietf-spring-segment-routing-mpls contained that deployment recommendation, but all that document says is: “As described in [I-D.ietf-spring-segment-routing], using the same SRGB on all nodes within the SR domain eases operations and troubleshooting and is expected to be a deployment guideline.”  So…where are the Deployment/Operational considerations related to the SRGB?  I note that neither document (draft-ietf-spring-segment-routing or draft-ietf-spring-segment-routing-mpls) include them.  I would expect some information to be in this (general) document and other more specific information (like the considerations about using the same SRGB) to be in the more specific document (draft-ietf-spring-segment-routing-mpls, in this case).

M2.1.  The example illustrated in Figure 2 would be a great place to demonstrate the value of having the same SRGB.  In fact, the text now shows things not working and it even warns by saying that “using anycast segment without configuring the same SRGB on nodes belonging to the same device group may lead to misrouting”, but no explanation of how it should be done the right way.


M3. From Section 2. (Terminology): “…a global segment is represented by a globally-unique index.”

M3.1.  I couldn’t find anywhere a discussion about the use of the index.  When it is discussed in 3.1.2, it seems to be an understood concept: “A Prefix-SID is allocated in the form of an index in the SRGB…”  Even if straightforward, I think the concept of the index should be explained (maybe with an example) and not assumed.  I again went to look at draft-ietf-spring-segment-routing-mpls, but that document just points back to this one: “The notion of indexed global segment, defined in [I-D.ietf-spring-segment-routing]…”

M3.2. I assume that “globally-unique index” is really unique to the SR Domain, right?  I ask this question because “globally-unique IPv6 address” has a different connotation (as in unique world-wide, not just inside a domain).  Please clarify.

M3.3.  Note that the latest version (-10) of draft-ietf-spring-segment-routing-mpls introduced the SR Local Block (SRLB) which is not defined in this document.  I mention it here because it was introduced right after the pointer about the index…


M4. Section 3.1.1. (Prefix-SID Algorithm)

M4.1. This section starts by justifying the use of an algorithm based on the IGP protocol extensions: the extensions have an algorithm field, so we should use it.  The justification should be the other way around: this document (the architecture) defines the concept of an algorithm and the extensions implement it.  Please re-word the first 3 paragraphs – note that the instance/topology references seem superfluous to me.

M4.2. The algorithms are not really defined – there are mentions of a “well known ECMP-aware SPF algorithm”, but no specific reference to what that is.  The last sentence in the Section mentions that the “details of the two defined algorithms are defined in…” pointing to the extension drafts – but those drafts just offer an additional piece of information in (from the OSPF document): “the standard shortest path algorithm as computed by the OSPF protocol”.  Ideally the algorithms would be defined here (even if it is just to say: “the standard algorithm used in the corresponding IGP”), and the extensions would just reference it.

M4.3.  When should the packets be dropped??  The following text points to at least 3 different places where it should be dropped, one marked with a MUST.  Please clarify.

M4.3.1. “A router MUST drop any SR traffic associated with the SR algorithm to the adjacent router, if the adjacent router has not advertised support for such SR algorithm.”  Ok, this sounds as if the traffic is dropped one hop before the router not supporting the algorithm – and it has a MUST in it.

M4.3.2. “The ingress node of an SR domain validates that the path to a prefix…includes nodes all supporting the advertised algorithm.  As a consequence, if a node on the path does not support algorithm X, the IGP-Prefix segment will be interrupted and will drop packet on that node.”  This sounds like the traffic would be dropped on the node not supporting the algorithm.

M4.3.3. “It's the responsibility of the ingress node using a segment to check that all downstream nodes support the algorithm of the segment.”  This last sentence hints at the fact that the ingress node should maybe even stop the traffic there, or maybe not sending it unless all nodes in the path support the same algorithm…


M5. Section 3.1.2. (MPLS Dataplane).

M5.1. The first bullet (again!) explains the architecture in function of the extensions.  The architecture should explain what needs to be done and the extensions would then do it…  Suggestion:

NEW>
  In order to achieve a behavior equivalent to Penultimate Hop Popping
  in MPLS [Reference], a Node N advertising a Prefix-SID SID-R for its
  attached prefix R MUST be able to instruct its connected neighbors to
  perform the NEXT operation while processing SID-R.  Upon receiving
  this instruction from Node N, its neighbors of N MUST perform the NEXT
  operation while processing SID-R.  Alternatively, the neighbors of N
  MUST perform the CONTINUE operation while processing SID-R.

M5.1.1. The penultimate bullet refers again to the extensions (but it only mentions the P-bit this time).  Please explain what the architecture intends to do, but not from the point of view of the extensions.  This and the last bullet seem to be the result of the first one (above).  I think that the first bullet would have enough text for the FIB entries to be obvious, but if you want to include this corollary, please do it right after.

M5.2. “A Prefix-SID is allocated in the form of an index in the SRGB (or as a local MPLS label) according to a process similar to IP address allocation.”  The SRGB is defined (in the Terminology section) as “the set of local labels reserved for global segments”, what is the difference between “an index in the SRGB” and “a local MPLS label”?  I’m hoping that the explanation of the concept of index would clarify this.

M5.2.1. Three bullets down… “If a node learns a Prefix-SID having a value that falls outside the locally configured SRGB range, then the node MUST NOT use the Prefix-SID…”  Going back to my previous question: it looks like “a local MPLS label” would have to be included in the SRGB – again, clarifying upfront would help a lot.  Note that this piece of text falls into the recommendation of having the same SRGB configured in all nodes.

M5.2.2.  Related to the concept of index and its relationship to the SRGB…the next bullet says: “…the segment is global (the SID is allocated from the SRGB or as an index)”.  We now have “globally-unique index”, “an index in the SRGB”, and “the SRGB or as an index” (separately).


M6. Section 3.3. (IGP-Anycast Segment, Anycast SID): “…the value of the SID following the anycast SID MUST be understood by all nodes advertising the same anycast segment.”  It seems to me that this is really a statement of fact: all nodes, not just ones advertising an anycast segment must understand what to do with the next SID…  IOW, s/MUST/must  I would even take this sentence out because it is redundant and obvious.


M7. Section 3.4. (IGP-Adjacency Segment, Adj-SID) also tries to explain functionality starting from the extensions.

M7.1. “The encodings of the Adj-SID include the a set of flags among which there is the B-flag.  When set, the Adj-SID refers to an adjacency that is eligible for protection (e.g.: using IPFRR or MPLS-FRR).”  If the Adjacency Segment is one that is locally significant to the node advertising it, what is the purpose of signaling that it is eligible for protection?  Wouldn’t that be a local decision as well?  Maybe an example of how the architecture is expected to work would help.

M7.2. “The encodings of the Adj-SID also include the L-flag.  When set, the Adj-SID has local significance.  By default, the L-flag is set.”  The definition of IGP-Adjacency Segment already says that it is “local (unless explicitly advertised otherwise)”, which makes this statement unnecessary.  If you want to keep it, please figure out a way that doesn’t justify it based on a bit in the extensions.


M8. Section 3.5. (Binding Segment).  A binding segment is not described anywhere in this document – please do so!  Section 3.5.1. (Mapping Server) mentions a “Remote-Binding SID S advertised by the mapping server”, and says that more “details are described in the SR/LDP interworking procedures ([I-D.ietf-spring-segment-routing-ldp-interop]”, but that draft doesn’t mention a Binding Segment.  Section 5. (IGP Mirroring Context Segment) says that “the binding segment [is] defined in SR IGP protocol extensions ( [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions])”; however, those documents don’t mention a Binding Segment, they just (except for the OSPFv2 draft) define TLVs.  Note that I-D.ietf-ospf-segment-routing-extensions points back to this document when referring to the definition of a Binding SID, completing a circular reference.

M8.1. BTW, Section 5. (IGP Mirroring Context Segment) says that the “Mirror SID is advertised using the binding segment”, which then looks like the Mirror Segment is an application of the Binding Segment (+ an explicit indication of it).  I think that Section 5 should then be moved to be a sub-section of 3.5.

M8.2. Part of the Security Considerations (in Section 8.1) are related to the Binding SID, which is another reason for clearly explaining that part of the architecture here.


M9. Section 3.5.1. (Mapping Server) mentions a Mapping Server, but it punts to I-D.ietf-spring-segment-routing-ldp-interop for further details.  While the SRMS can be used for interoperability cases, I think that it is an important part of the overall architecture and as such it should be described and discussed in this document instead…including any Manageability Considerations (as mentioned in Section 9).


M10. Section 3.6. (Inter-Area Considerations)

M10.1. This section shows an example of the behavior: maintain the SID across area boundaries.  But it doesn’t actually say how the architecture is expected to work.  IOW, in the example the SID is maintained, but should that always happen (MUST, SHOULD)? Or is it just an example (MAY)?

M10.2. Another case of explaining the architecture based on the extension functionality: “When an ABR propagates a prefix from one area to another it MUST set the R-Flag.”  Maybe try something like this instead: “The re-advertisement of an SID that originated on a different IGP area MUST be indicated.”

M10.3. [minor] As the advertisement moves to the left (from Area 2 to the Backbone…), the ABRs change the Node-SID for a Prefix-SID, right?  The description in the last 3 paragraphs uses Node-SID: “node S…pushes Node-SID(150)”.

M10.4. [minor] Going back to global vs local significance, it would be nice to remind the readers at this point that the SR domain is really the whole IGP network, and not just one flooding domain…which is why SID 150 can be used throughout.


M11. Section 4. (BGP Peering Segments) is the only non-IGP focused section in this document.  The architecture of the EPE solution (as described in draft-ietf-spring-segment-routing-central-epe) goes beyond what has already been discussed here because it incorporates elements such as a mandatory centralized controller, which was optional before (a PCE server is mentioned only casually in the Terminology section).  This leaves us with an incomplete architecture for the BGP case.  I would prefer it if the whole architecture was defined in this single document (i.e. expand this section by potentially moving parts from draft-ietf-spring-segment-routing-central-epe – which might leave that document without enough content to stand alone).


M12. Section 8. (Security Considerations).  The main part of this section talks about the instructions on the packets – is adding that meta-data a security concern?  I think it could be because someone watching could tell which “forwarding path elements (e.g.: nodes, links, services, etc.)” are used for specific flows, etc.  But I also think that the risk is mitigated by the fact that the information MUST NOT be exposed outside the SR domain.  Mentioning that, and the fact that the SR domain will usually be under a single administration would be a good thing.


M13. Section 9. (Manageability Considerations) says that “an implementation SHOULD protect the network in case of conflict detection by providing a deterministic resolution approach…addressed in [I-D.ietf-spring-conflict-resolution].”  That “SHOULD” is in conflict with I-D.ietf-spring-conflict-resolution (in WGLC) where it says that “All protocols which support SR MUST adhere to the policies defined in this document.”  It seems like the easy way forward is to s/SHOULD/MUST.  In either case, I think that I-D.ietf-spring-conflict-resolution should be a Normative reference.



Minor:

P1. Introduction

P1.1. The term “service chain” is used in the Abstract and in the Introduction.  Given that the concept is not vital to the architecture and that there might be unnecessary confusion with SFC, I would suggest taking it out.

P1.2.  Related…  Section 1.1 says that this document “defines…the service segments”, but there’s no specific mention of “service segments” anywhere, except for a very quick mention in Section 5. (IGP Mirroring Context Segment).  What am I missing?  Consider taking “service segments” off the list of things this document defines.

P1.3. The last paragraph says that “This document defines a set of instructions (called segments) that are required to fulfill the described use-cases.”  The use cases are not mentioned until 1.1.  Suggestion: merge Section 1 and 1.1 to provide proper flow to the text.

P1.4. Speaking of use cases, I-D.ietf-spring-oam-usecase doesn’t actually include use cases that will affect the architecture.  It includes use case of how to use monitoring system defined in it.  Same comment for the mention in Section 9.


P2. From Section 2. (Terminology)

P2.1. SID is not defined, just extended.  Besides the examples, please provide an actual definition.

P2.2. “The CONTINUE instruction is implemented as the SWAP instruction in the MPLS dataplane.”  Please include a reference to where the “SWAP instruction” is defined.  I assume you’re really referring to “label swapping” in rfc3031, are you?  If so, please be consistent as “MPLS dataplane” and “MPLS architecture” are used in different places.

P2.3. The “Local Segment” definition says that for IPv6 it “is not advertised in any routing protocol”.  But for MPLS it is advertised, right?  Please clarify.  I think that some of the vocabulary is a little confusing, for example, the definition of IGP-Adjacency Segment says that it “is local (unless explicitly advertised otherwise) to the node that advertises it” – this means that for IPv6 this piece of the architecture wouldn’t apply because a Local Segment is not advertised.  To add to the confusion, draft-filsfils-spring-srv6-network-programming talks about local SIDs…  IOW, in some places it sounds as if what should be the general architecture only really applies to MPLS – or maybe we need a more explicit local qualifier.

P2.4. “The PCEP discovery capability is described in [I-D.ietf-pce-segment-routing].”  That document doesn’t even mention the word “discovery”.  Please use the proper name for easier cross-reference.

P2.5. “unless explicitly advertised otherwise” is used to qualify the global/local nature of a segment.  How do the characteristics of the segment change if “explicitly advertised otherwise”?  For example, if an IGP-Prefix Segment is advertised as local, how do its characteristics change, or do they?

P2.5.1. In Section 3.4. (IGP-Adjacency Segment, Adj-SID), the use of an Adj-SID is illustrated for both the local and global cases, but both explanations say the same thing: “forwarded along the shortest-path to N and then be switched by N, without any IP shortest-path consideration, towards link L” – I don’t see a difference in behavior between the local and global nature of this SID.  There is some additional text related to global: “The use of global Adj-SID allows to reduce the size of the segment list when expressing a path at the cost of additional state (i.e.: the global Adj-SID will be inserted by all routers within the area in their forwarding table).”  If node N is the one executing on the Adj-SID, how does including it in other FIBs help?

P2.6. None of the segments after Section 3.4 (binding, BGP, mirroring) are defined in the Terminology.  Please do so for completeness.


P3. Referring to Figure 1: “…each PE device is connected to two routers in each of the groups A and B.”  The routers connected to the PEs (Rx) are not in either group.


P4. s/Obviously//


P5. Section 3.4. (IGP-Adjacency Segment, Adj-SID): “The remote node MAY be an adjacent IGP neighbor or a non-adjacent neighbor…”  The “MAY” is out of place as there isn’t another option, it is one or the other.  s/MAY/may


P6. Maybe it’s because the rest of 3.5 is incomplete, but Section 3.5.2. (Tunnel Head-end) has no context to speak of – without that, it feels like an orphan section.


P7. Section 8.1. (MPLS Data Plane)

P7.1. You included a couple of references at the end of this section, which is good.  I would however not explicitly mention specific sections, as the whole RFCs (rfc4381 and rfc5920) are about MPLS-related security.

P7.2. You compare the use of a single segment to RSVP-TE – if the security characteristics are similar, please provide a reference.


P8. References

P8.1. RFC2460 was obsoleted by RFC8200 / RFC6822 was obsoleted by RFC8202

P8.2. I think that the reference to RFC4206 should be Informative.



Nits:

N1. The Abstract is very long – I would even say too long.  If it was up to me, I would leave just the first paragraph.

N2. The second to last paragraph in the Introduction (“Numerous use-cases…”) references the “marketing style” content of I-D.ietf-spring-oam-usecase.  I have asked the authors of that document to please focus their content.  Please consider taking this paragraph out.

N3. s/participating into the source based/participating in the source based

N4. References.  Please add Informative references to netconf (Section 2), PCEP (2), FRR (3.1.1), “parallel adjacency suppression” (3.4).

N5. Section 3: “IGP segments require extensions in link-state IGP protocols.  IGP extensions are required in order to advertise the IGP segments.”  These 2 sentences say the exact same thing.

N6. Please avoid using “we” in the text – except for the Acknowledgements.

N7. s/Regardless Segment Routing/Independent of Segment Routing

N8. s/and not to each other individual nodes in the LAN/and not to individual nodes in the LAN

N9. s/([I-D.ietf-spring-segment-routing-ldp-interop]/[I-D.ietf-spring-segment-routing-ldp-interop]

N10. “IGP deployed using areas”  An area is an OSPF-specific construct – flooding domain is more generic.

N11. It would be nice if the examples used IPv6 instead of IPv4.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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 is the type of RFC being requested. This is indicated in the header.
  This Document defines the functional architecture for Segment Routing.
  As, such the type of RFC being requested is the appropriate one.

(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 (SR) leverages the source routing paradigm.  A node
  steers a packet through an ordered list of instructions, called
  segments.  A segment can represent any instruction, topological or
  service-based.  A segment can have a semantic local to an SR node or
  global within an SR domain.  SR allows to enforce a flow through any
  topological path and service chain while maintaining per-flow state
  only at the ingress nodes to the SR domain.
  Segment Routing can be directly applied to the MPLS architecture with
  no change on the forwarding plane.
  Segment Routing can be applied to the IPv6 architecture, with a new
  type of routing header.

Working Group Summary

  The Working Groups support the publication of this corner stone Document.

Document Quality

  The Document is in good shape and has been reviewed several times.
  There are many implementations of Segment Routing technology.

Personnel

  Martin Vigoureux is the Document Shepherd
  Alvaro Retana is the Responsible Area Director

(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 has done a complete review of the Document, from an editorial, technical, and standard process perspective.
  This version is ready for requesting publication.

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

  No concern. The Document has been in the hands of the Working Group for quite some time.
  It also went through two working group Last Calls and received reviews

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

  No portion need a review from a particular or broader perspective.

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

  No concern.

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

  Yes.

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

  IPR has been disclosed
  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-spring-segment-routing
  No concern was raised against these disclosures. 

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

(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 one has threatened an appeal or otherwise indicated extreme discontent.

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

  ID nits is clean.

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

  No formal review criteria is applicable to this Document.

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

  Yes, but.
  Because Segment Routing technology has generated a lot of documents,
  and because this Document took some time before reaching this stage, it references IGP extensions for Segment Routing:
  I-D.ietf-isis-segment-routing-extensions
  I-D.ietf-ospf-ospfv3-segment-routing-extensions
  I-D.ietf-ospf-segment-routing-extensions
  The body of the text of this Document discusses the use of some flags defined by the above documents.
  As such, may be these documents should be Normative references.

(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. In the current state, all Normative references are RFCs. However if the three IGP documents were to be moved as Normative References
  this wouldn't be the case anymore. On the other hand these Documents should soon be Last Called within their Working Groups.

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

  There are no Downward Normative references.

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

  The publication of this Document will not change the status of pre-existing RFCs.

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

  This Document makes no request to IANA.

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

  No new registry.

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

  No section requires such checks.