Re: [spring] WG LC for draft-ietf-spring-segment-routing

["Stefano Previdi (sprevidi)" <[e-mail]>]

Stewart,

I went through your (long) email here and many thanks for your comments. Some of them make sense and I will integrate them in the draft, some others just requires clarification. I understand that SR drafts have been written by implementors and operators directly involved in SR development and deployment and the authors sometimes  assumed that the reader has a SR knowledge allowing a shorter or less detailed description. Of course, that is not what you should expect expect and I’ll add clarification where needed.

See below for some answers and other comments.


> On Nov 29, 2016, at 8:21 PM, Stewart Bryant <[e-mail]> wrote:
> 
> The following are my comments on this text in response to the WGLC.
> A lot of comments are embedded in the draft text below.
> 
> However I have some major overarching comments. Although this is called
> an architecture it seems to be rather more of a description of how
> a large number of other documents combine to produce an overall
> specification for SR. Certainly for an architecture the number
> of forward references to detailed solutions for a description of the
> concept is quite extraordinary.
> 
> So embedded is the contents of some of these referenced documents
> that I do not think that it safe to publish this text other than
> synchronously with some of those documents. This is absolutely the case
> for the dataplane definitions, especially for IPv6, but seems
> likely to apply to other references. The further implication of
> the constant dependence on other documents is that many of them
> are really normative rather  than informative references, making
> this document a hostage to their fate.
> 
> It is far more conventional in an architecture to set out the general
> description and state the invariants, and put the detail into
> specific protocol documents, but to have the architecture as a
> standalone text. In other words to set things out so that
> the reader understands how components fit together, what the subtleties
> are and what the constraints on the components are, but leave the
> component design decisions to the component designers.
> 
> Clearly I think this draft needs significant work before it is
> ready for submission to the IESG for publication.
> 
> - Stewart
> 
> 
> 
> 
> Network Working Group                                   C. Filsfils, Ed.
> Internet-Draft                                           S. Previdi, Ed.
> Intended status: Standards Track                     Cisco Systems, Inc.
> Expires: May 23, 2017                                        B. Decraene
>                                                            S. Litkowski
>                                                                  Orange
>                                                               R. Shakir
>                                                                  Google
>                                                       November 19, 2016
> 
> 
>                      Segment Routing Architecture
>                  draft-ietf-spring-segment-routing-10
> 
> 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 local semantic 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 node to the SR domain.
> 
> SB> Since you mention service chains here, we really should be having
> SB> a wider discussion about whether SR and SFC are really the same
> SB> technology.


or maybe limit the description here to the fact that a segment may represent a host running any sort of application/function. Without interfering with the work done in SFC, it is obvious that building a path based on segment is not restricted to routers but rather includes any element addressable through an IP address (mapped to a segment).


>   Segment Routing can be directly applied to the MPLS architecture with
>   no change on the forwarding plane.
> 
> SB> Applied to or implemented using MPLS?


what it means is that MPLS dataplane fits the SR architecture.


>   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.
> 
> SB> You really cannot say this until the v6 design goes to RFC, although
> SB> I do not see why this needs to be stated.
> SB> What I did not see in here is a proper comparision of the consequences
> SB> of the stack vs list and pointer approach. The consequences of the
> SB> difefrence between these two approaches may be far reaching in the long
> SB> term and lead to biforcation of the architecture, something we should
> SB> think about carefully up front.



architecturally, there are no changes. Dataplanes have their specifics. 

It is good to note that ipv6 architecture has been already provisioned for segment routing. Please read RFC2460(bis) and you’ll see that even the “segment” terminology is already present.

Bottom line, I agree that the architecture draft shouldn’t specify dataplane details.


> Requirements Language
> 
>   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>   document are to be interpreted as described in RFC 2119 [RFC2119].
> 
> Status of This Memo
> 
>   This Internet-Draft is submitted in full conformance with the
>   provisions of BCP 78 and BCP 79.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 1]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   Internet-Drafts are working documents of the Internet Engineering
>   Task Force (IETF).  Note that other groups may also distribute
>   working documents as Internet-Drafts.  The list of current Internet-
>   Drafts is at http://datatracker.ietf.org/drafts/current/.
> 
>   Internet-Drafts are draft documents valid for a maximum of six months
>   and may be updated, replaced, or obsoleted by other documents at any
>   time.  It is inappropriate to use Internet-Drafts as reference
>   material or to cite them other than as "work in progress."
> 
>   This Internet-Draft will expire on May 23, 2017.
> 
> Copyright Notice
> 
>   Copyright (c) 2016 IETF Trust and the persons identified as the
>   document authors.  All rights reserved.
> 
>   This document is subject to BCP 78 and the IETF Trust's Legal
>   Provisions Relating to IETF Documents
>   (http://trustee.ietf.org/license-info) in effect on the date of
>   publication of this document.  Please review these documents
>   carefully, as they describe your rights and restrictions with respect
>   to this document.  Code Components extracted from this document must
>   include Simplified BSD License text as described in Section 4.e of
>   the Trust Legal Provisions and are provided without warranty as
>   described in the Simplified BSD License.
> 
> Table of Contents
> 
>   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
>     1.1.  Companion Documents . . . . . . . . . . . . . . . . . . .   4
>   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
>   3.  Link-State IGP Segments . . . . . . . . . . . . . . . . . . .   7
>     3.1.  IGP Segment, IGP SID  . . . . . . . . . . . . . . . . . .   7
>     3.2.  IGP-Prefix Segment, Prefix-SID  . . . . . . . . . . . . .   7
>       3.2.1.  Prefix-SID Algorithm  . . . . . . . . . . . . . . . .   7
>       3.2.2.  MPLS Dataplane  . . . . . . . . . . . . . . . . . . .   9
>       3.2.3.  IPv6 Dataplane  . . . . . . . . . . . . . . . . . . .  10
>     3.3.  IGP-Node Segment, Node-SID  . . . . . . . . . . . . . . .  10
>     3.4.  IGP-Anycast Segment, Anycast SID  . . . . . . . . . . . .  11
>     3.5.  IGP-Adjacency Segment, Adj-SID  . . . . . . . . . . . . .  14
>       3.5.1.  Parallel Adjacencies  . . . . . . . . . . . . . . . .  15
>       3.5.2.  LAN Adjacency Segments  . . . . . . . . . . . . . . .  16
>     3.6.  Binding Segment . . . . . . . . . . . . . . . . . . . . .  16
>       3.6.1.  Mapping Server  . . . . . . . . . . . . . . . . . . .  16
>       3.6.2.  Tunnel Headend  . . . . . . . . . . . . . . . . . . .  17
>     3.7.  Inter-Area Considerations . . . . . . . . . . . . . . . .  17
>   4.  BGP Peering Segments  . . . . . . . . . . . . . . . . . . . .  18
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 2]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   5.  IGP Mirroring Context  Segment  . . . . . . . . . . . . . . .  19
>   6.  Multicast . . . . . . . . . . . . . . . . . . . . . . . . . .  19
>   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
>   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  19
>     8.1.  MPLS Data Plane . . . . . . . . . . . . . . . . . . . . .  20
>     8.2.  IPv6 Data Plane . . . . . . . . . . . . . . . . . . . . .  21
>   9.  Manageability Considerations  . . . . . . . . . . . . . . . .  22
>   10. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  24
>   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
>   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
>     12.1.  Normative References . . . . . . . . . . . . . . . . . .  25
>     12.2.  Informative References . . . . . . . . . . . . . . . . .  25
>   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29
> 
> 1.  Introduction
> 
>   With Segment Routing (SR), 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
> 
> SB> It really is a pity that we did not use the more descriptive term instructions
> SB> which would have help people understand what they are.


Well, I believe it is well understood now. We have multiple vendors implementations, multiple operator’s deployments, so I don’t think we have an understanding problem.


> I wonder if it is
> SB> too late to change?


I don’t like the idea to change the terminology and description of something that now the industry has widely adopted.

I’m fine with making minor changes so to help people who do not understand what segment routing is but the change MUST be limited.

The draft and the technology is mature and well understood.


> SB> Service based what?
> 
>   local semantic to an SR node or global within an SR domain.  SR
>   allows to enforce a flow through any path and service chain while
>   maintaining per-flow state only at the ingress node of the SR domain.
> 
> SB> I wonder if we should be pulling together SR and SFC into
> SB> a common architecture, since they seem to have converged?


no, that’s a very bad idea. The more you pull in the less you’ll make progress.

SR is not dedicated to service chaining. SR is a generic mechanism leveraging basic routing concepts.


>   Segment Routing can be directly applied to the MPLS architecture
>   ([RFC3031]) 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 active segment is on the top of the stack.  A
>   completed segment is popped off the stack.  The addition of a segment
>   is performed with a push.
> 
> SB> All true, but we are designing a solution for both MPLS and IP.


MPLS and IPv6.

I don’t think anyone is trying to address IPv4 source routing.

Here we are in the introduction section where MPLS and v6 dataplane are very briefly described (and how SR can by applied to them).


> SB> Shouldn't this text be establishing the architectural princples
> SB> first before getting down in the weeds of the MPLS solution?


this is an introduction of about 10 lines, I don’t think it “goes down in the solution”.


> SB>
> 
> SB> IP and MPLS took different approaches so at this level we need to
> SB> be discussing the principles, and establish the properties of
> SB> the list, which again are radically different,


not really “radically”.

 
> and then let the
> SB> solutions drafts describe the instantiation of the list.
> 
>   In the Segment Routing MPLS instantiation, a segment could be of
>   several types:
> 
>   o  an IGP segment,
> 
>   o  a BGP Peering segments,
> 
>   o  an LDP LSP segment,
> 
>   o  an RSVP-TE LSP segment,
> 
>   o  a BGP LSP segment.
> 
> SB> All true, but right down in the weeds. What about the functional
> SB> equivalents in IP?


the first two can be either MPLS or IPv6. 


> 
>   The first two (IGP and BGP Peering segments) types of segments are
>   defined in this document.  The use of the last three types of
>   segments is illustrated in [I-D.ietf-spring-segment-routing-mpls].
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 3]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   Segment Routing can be applied to the IPv6 architecture ([RFC2460]),
>   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.  Upon completion
>   of a segment, a pointer in the new routing header is incremented and
>   indicates the next segment.
> 
> SB> Again this is down in the weeds considering that we are in an architecture
> SB> document and also proposes the detail of a solution that may or may
> SB> not be finalized.


no, it is not “down to the weeds”. It is a brief introductory text about SR-IPv6.
If you want the details, read the SR-MPLS and SRv6 drafts.


>   Numerous use-cases illustrate the benefits of source routing either
>   for FRR, OAM or Traffic Engineering reasons.
> 
> SB> This needs a reference.


I thought you were suggesting there were already too many references.
I think we will reduce the list of references and therefore I’ll skip your redundant comments.


>   This document defines a set of instructions (called segments) that
>   are required to fulfill the described use-cases.  These segments can
>   either be used in isolation (one single segment defines the source
>   route of the packet) or in combination (these segments are part of an
>   ordered list of segments that define the source route of the packet).
> 
> 
> 1.1.  Companion Documents
> 
>   This document defines the SR architecture, its routing model, the
>   IGP-based segments, the BGP-based segments and the service segments.
> 
>   Use cases are described in [RFC7855],
>   [I-D.ietf-spring-segment-routing-central-epe],
>   [I-D.ietf-spring-segment-routing-msdc],
>   [I-D.filsfils-spring-large-scale-interconnect],
>   [I-D.ietf-spring-ipv6-use-cases],
>   [I-D.ietf-spring-resiliency-use-cases], [I-D.ietf-spring-oam-usecase]
>   and [I-D.ietf-spring-sr-oam-requirement].
> 
> SB> It would be helpful to the reader to indicate the contents, so that
> SB> if this just becomes a set of RFC numbers they had some better its
> SB> what the documents are about.
> SB>
> SB> It would also be useful to get an understanding from the AD
> SB> as to which of the use case documents will be published, merged
> SB> become part of a wiki etc given recent policy statements from the IESG.
> 
> 
>   Segment Routing for MPLS dataplane is documented in
>   [I-D.ietf-spring-segment-routing-mpls].
> 
>   Segment Routing for IPv6 dataplane is documented in
>   [I-D.ietf-6man-segment-routing-header].
> 
>   IGP protocol extensions for Segment Routing are described in
>   [I-D.ietf-isis-segment-routing-extensions],
>   [I-D.ietf-ospf-segment-routing-extensions] and
>   [I-D.ietf-ospf-ospfv3-segment-routing-extensions] referred in this
>   document as "IGP SR extensions documents".
> 
>   The FRR solution for SR is documented in
>   [I-D.francois-rtgwg-segment-routing-ti-lfa].
> 
>   The PCEP protocol extensions for Segment Routing are defined in
>   [I-D.ietf-pce-segment-routing].
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 4]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   The interaction between SR/MPLS with other MPLS Signaling planes is
>   documented in [I-D.ietf-spring-segment-routing-ldp-interop].
> 
> 2.  Terminology
> 
>   Segment: an instruction a node executes on the incoming packet (e.g.:
>   forward packet according to shortest path to destination, or, forward
>   packet through a specific interface, or, deliver the packet to a
>   given application/service instance).
> 
>   SID: a Segment Identifier.  Examples of SIDs are: a MPLS label, an
>   index value in a MPLS label space, an IPv6 address.  Other types of
>   SIDs can be defined in the future.
> 
> SB> Definition by example is not a definition.
> 
>   Segment List: ordered list of SID's encoding the topological and
>   service source route of the packet.
> 
> SB> Isn't it an ordered list of SID encoding the ordered set of
> SB> instructions to be applies to the packet as it traverses the
> SB> SR domain?


yes.


>   It is a stack of labels in the
>   MPLS architecture.  It is an ordered list of IPv6 addresses in the
>   IPv6 architecture.
> 
> SB> Again this a architecture it should not go down in those weeds.
> 
> 
>   Segment Routing Domain (SR Domain): the set of nodes participating
>   into the source based routing model.
> SB> Surely is is the set of nodes that form an SR Instance having a
> SB> common view of the mapping of SID to instruction definition


if by “common view” you do intend that all nodes must have the same view, then you’re wrong. In many SR domain the view of segments each node has may be different (a subset or superset or intersection of sets, etc.).


>   These nodes may be connected to
>   the same physical infrastructure (e.g.: a Service Provider's network)
>   as well as nodes remotely connected to each other (e.g.: an
>   enterprise VPN or an overlay).  Note that a SR domain may also be
>   confined within an IGP instance, in which case it is named SR-IGP
>   Domain.
> 
>   Active segment: the segment that MUST be used by the receiving router
>   to process the packet.  In the MPLS dataplane is the top label.  In
>   the IPv6 dataplane is the destination address of a packet having the
>   Segment Routing Header as defined in
>   [I-D.ietf-6man-segment-routing-header].
> 
> SB> I am surprised that you don't need to define POP or Remove


NEXT in the architecture is implemented as a POP in MPLS.


>   PUSH: the insertion of a segment at the head of the Segment list.
> 
> SB> This works for a stack model, but I am not sure it works for
> SB> a list model where you really do an insert.


the text, intentionally, uses the word “insert”. Architecturally, a “PUSH” is fine for both types of operations (an MPLS push and an IPv6 insert).


> 
>   NEXT: the active segment is completed, the next segment becomes
>   active.
> 
>   CONTINUE: the active segment is not completed and hence remains
>   active.  The CONTINUE instruction is implemented as the SWAP
>   instruction in the MPLS dataplane.  In IPv6, this is the plain IPv6
>   forwarding action of a regular IPv6 packet according to its
>   Destination Address.
> 
> SB> Again I worry about definition by example.


SR doesn’t invent anything new in the MPLS dataplane and even in the v6 dataplane (where source routing with routing headers has been invented 20 years ago) so I don’t see why we have to define something different from what exists today.


>   SR Global Block (SRGB): local property of an SR node.  In the MPLS
>   architecture, SRGB is the set of local labels reserved for global
>   segments.  Using the same SRGB on all nodes within the SR domain ease
>   operations and troubleshooting and is expected to be a deployment
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 5]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   guideline.  In the IPv6 architecture, the equivalent of the SRGB is
>   in fact the set of addresses used as global segments.  Since there
>   are no restrictions on which IPv6 address can be used, the concept of
>   the SRGB includes all IPv6 global address space used within the SR
>   domain.
> 
> SB> I worry about whether this is an architectural concept of a
> SB> specific dataplane concept, or an implementation concept. Since
> SB> the IPv6 design moved from a set of short instructions to full
> SB> IPv6 addresses, this does not look like an architectural construct.


The ipv6 address is the instantiation of a segment.

A segment is an instruction.

Therefore, an IPv6 address in a SR domain may be used as an instruction.


>   Global Segment: the related instruction is supported by all the SR-
>   capable nodes in the domain.
> 
> SB> instruction or identifier.


the segment is an instruction, the SID is the identifier of the instruction.


> Isn't the point about this that any node
> SB> knows how to execute its view of the instruction, and indeed
> SB> it is possible that the mapping at some nodes (for example forward)
> SB> may be different from the mapping at another node (for example
> SB> receive, or deliver to attached firewall)


no, a segment is a precise instruction. You van’t have this mismatch between segments.

in your example, the segment corresponding to a given firewall processing has meaning only in the node attaching the firewall (or the firewall itself).

A global segment has a semantic agreed and honored by all nodes.


>   In the MPLS architecture, a Global
>   Segment has a globally-unique index.  The related local label at a
>   given node N is found by adding the globally-unique index to the SRGB
>   of node N.  In the IPv6 architecture, a global segment is a globally-
>   unique IPv6 address.
> 
> SB> Again this muddles architecture and mapping to an instantiation
> SB> of that architecture.


which is an illustrative and useful explanation.


> SB> nit s/has a globally-unique/ is a globally-unique/
> SB> However this begs the question of the scope of global. Certainly
> SB> in MPLS it is restricted to the SR-Domain, and even then it may
> SB> only be a sub-set of it.

> 
>   Local Segment: the related instruction is supported only by the node
>   originating it.
> 
> SB> Again I think it is the mapping of the instruction identifier to
> SB> the instruction rather than the instruction.


the segment is the instruction. It can be local or global.

the SID is the identifier and can also be local or global.


>   In the MPLS architecture, this is a local label
>   outside the SRGB.  In the IPv6 architecture, this can be any IPv6
>   address whose reachability is not advertised in any routing protocol
>   (hence, the segment is known only by the local node).
> 
> SB> Wait a moment the instruction is understood by the imposing node(s)
> SB> and the executing node


the imposing node may just have been instructed/programmed to push/insert the segment without having any other knowledge about it.


>   IGP Segment: the generic name for a segment attached to a piece of
>   information advertised by a link-state IGP, e.g. an IGP prefix or an
>   IGP adjacency.
> 
> SB> I don't think it's a name. Isn't it simply a segment that is advertised
> SB> by an IGP? Of course that takes us back to the scoping definition, since
> SB> all nodes receive the IGP information.


not all nodes. Only the nodes where the IGP has been configured.


>   IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP
>   segment attached to an IGP prefix.
> 
> SB> What does attached mean here?


mapped to. “attach” refers to the control plane where the prefix is advertised with an “attached” attribute or TLV. 

I agree that this definition requires some routing skills not everyone is supposed to have...


>   An IGP-Prefix Segment is global
>   (unless explicitly advertised otherwise) within the SR IGP instance/
>   topology and identifies an instruction to forward the packet along
>   the path computed using the routing algorithm specified in the
>   algorithm field, in the topology and the IGP instance where it is
>   advertised.
> 
> SB> More precisely isn't it an instruction to forward a packet
> SB> along the path computed for a specified prefix?


you mean “less precisely”... your definition is a summarized version of the current one. The current one makes the distinction of the algorithm. Please be sure you’re familiar with the concept.


> The Prefix-SID is the SID of the IGP-Prefix Segment.
> SB> I think that this should be a separate definition.
> 
>   IGP-Anycast: an IGP-Anycast Segment is an IGP-prefix segment which
>   does not identify a specific router, but a set of routers.  The terms
>   "Anycast Segment" or "Anycast-SID" are often used as an abbreviation.
> 
>   IGP-Adjacency: an IGP-Adjacency Segment is an IGP segment attached to
>   an unidirectional adjacency or a set of unidirectional adjacencies.
>   By default, an IGP-Adjacency Segment is local (unless explicitly
>   advertised otherwise) to the node that advertises it.
> 
> SB> What are the semantics of a non local adjacency segment?


a global adjacency segment is a global segment with a global SID.


>   IGP-Node: an IGP-Node Segment is an IGP-Prefix Segment which
>   identifies a specific router (e.g. a loopback).  The terms "Node
>   Segment" or Node-SID" are often used as an abbreviation.
> 
>   SR Tunnel: a list of segments to be pushed on the packets directed on
>   the tunnel.  The list of segments can be specified explicitly or
>   implicitly via a set of abstract constraints (latency, affinity,
>   SRLG, ...).  In the latter case, a constraint-based path computation
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 6]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   is used to determine the list of segments associated with the tunnel.
>   The computation can be local or delegated to a PCE server.  An SR
>   tunnel can be configured by the operator, provisioned via netconf or
>   provisioned via PCEP.  An SR tunnel can be used for traffic-
>   engineering, OAM or FRR reasons.
> 
> SB> So where does tunnel fit into that definition? Isn't the point
> SB> about a tunnel that it is a type of virtual link that constrains
> SB> a packet to a path other than the natural path that would be
> SB> inferred from its native address?


I don’t like the virtual link analogy at all.

In fact, I don’t even like the term “tunnel” much.

I think the term “SR Path” or “SR Explicit Path” is more appropriate.

“Tunnel” refers to an interface/link concept which is not really applicable here.


>   Segment List Depth: the number of segments of an SR tunnel.  The
>   entity instantiating an SR Tunnel at a node N should be able to
>   discover the depth insertion capability of the node N.  The PCEP
>   discovery capability is described in [I-D.ietf-pce-segment-routing].
> 
> SB> Isn't that just one way that such a size might be discovered?


yes, there are others and we may not even list any of them here.


> 3.  Link-State IGP Segments
> 
>   Within a link-state IGP domain, an SR-capable IGP node advertises
>   segments for its attached prefixes and adjacencies.  These segments
>   are called IGP segments or IGP SIDs.  They play a key role in Segment
>   Routing and use-cases as they enable the expression of any
>   topological path throughout the IGP domain.  Such a topological path
>   is either expressed as a single IGP segment or a list of multiple IGP
>   segments.
> 
> SB> I am not sure that topological path is a well known term.


well, it has been clearly understood by everyone... I think.


> A quick check
> SB> in google only found the term is one paper. Do you simply mean path?


yes, you got it right. The term topology is used here to emphasize the fact that the path is computed based on a lsdb.


> 
> 3.1.  IGP Segment, IGP SID
> 
>   The terms "IGP Segment" and "IGP SID" are the generic names for a
>   segment attached to a piece of information advertised by a link-state
>   IGP, e.g. an IGP prefix or an IGP adjacency.
> 
> 3.2.  IGP-Prefix Segment, Prefix-SID
> 
>   An IGP-Prefix Segment is an IGP segment attached to an IGP prefix.
>   An IGP-Prefix Segment is global (unless explicitly advertised
>   otherwise) within the SR/IGP domain.
> 
>   The required IGP protocol extensions are defined in IGP SR extensions
>   documents.
> 
> 3.2.1.  Prefix-SID Algorithm
> 
>   The IGP protocol extensions for Segment Routing define the Prefix-SID
>   advertisement which includes a set of flags and the algorithm field.
>   The algorithm field has the purpose of associating a given Prefix-SID
>   to a routing algorithm.
> 
>   In the context of an instance and a topology, multiple Prefix-SID's
>   MAY be allocated to the same IGP Prefix as long as the algorithm
>   value is different in each one.
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 7]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   Multiple instances and topologies are defined in IS-IS and OSPF in:
>   [RFC5120], [RFC6822], [RFC6549] and [RFC4915].
> 
>   Initially, two "algorithms" have been defined:
> 
>   o  "Shortest Path": this algorithm is the default behavior.  The
>      packet is forwarded along the well known ECMP-aware SPF algorithm
>      however it is explicitly allowed for a midpoint to implement
>      another forwarding based on local policy.. The "Shortest Path"
>      algorithm is in fact the default and current behavior of most of
>      the networks where local policies may override the SPF decision.
> 
> SB> If a node is going to apply local policy, doesn't there need to be a
> SB> comment about loop avoidance, and also possibly cleaning up the
> SB> SR header if local policy is to send the packet out of the domain?
> SB> I worry about what this means when this is applied to a SID
> SB> other than the final SID specifying the path.


having a local policy is what happens everyday in all networks running TE mechanisms. You classify incoming packets and you steer them into IP tunnels, MPLS-RSVP LSPs, VRFs, etc etc.

This is what networks are doing for ages.


> 
> o  "Strict Shortest Path": This algorithm mandates that the packet is
>      forwarded according to ECMP-aware SPF algorithm and instruct any
>      router in the path to ignore any possible local policy overriding
>      SPF decision.  The SID advertised with "Strict Shortest Path"
>      algorithm ensures that the path the packet is going to take is the
>      expected, and not altered, SPF path.
> 
>   An IGP-Prefix Segment identifies the path, to the related prefix,
>   along the path computed as per the algorithm field.
> 
>   A packet injected anywhere within the SR/IGP domain with an active
>   Prefix-SID will be forwarded along path computed by the algorithm
>   expressed in the algorithm field.
> 
>   The ingress node of an SR domain validates that the path to a prefix,
>   advertised with a given algorithm, 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.  It's the responsibility of the
>   ingress node using a segment to check that all downstream nodes
>   support the algorithm of the segment.
> 
>   A router MUST NOT forward any SR traffic associated with the SR
>   algorithm to the adjacent router, if the adjacent router has not
>   advertised support for such SR algorithm.
> 
>   It has to be noted that Fast Reroute (FRR) mechanisms, such as the
>   one described in [I-D.francois-rtgwg-segment-routing-ti-lfa], that
>   are based on post-convergence SPF, are still compliant to the Strict-
>   SPF algorithm definition.
> 
>   Details of the two defined algorithms are defined in
>   [I-D.ietf-isis-segment-routing-extensions],
>   [I-D.ietf-ospf-segment-routing-extensions] and
>   [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
> 
> SB> I am not convinced that the statements on IPFRR belong in the
> SB> architecture, surely they belong in the IPFRR document together
> SB> a declaration of architectural conformance?


I’d remove the references.


> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 8]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
> 3.2.2.  MPLS Dataplane
> 
> SB> I am not convinced that this is architecture, more implementation
> SB> in a specific dataplane. It is not particularly critical in the case of
> SB> MPLS as we pretty much know what it looks like.


I tend to agree.


> I remain to be convinced
> SB> about IP. The problem is that if the dataplane design changes, it may
> SB> invalidate the architecture. Best practise is to be invariant to the
> SB> implementation when there are multiple possible data planes.


yes, we probably better move part or all of this text into the dataplane specific drafts (MPLS and v6).


> When SR is used over the MPLS dataplane:
> 
>   o  the IGP signaling extension for IGP-Prefix segment includes the
>      P-Flag ([I-D.ietf-isis-segment-routing-extensions]) or the NP-Flag
>      ([I-D.ietf-ospf-segment-routing-extensions]).  A Node N
>      advertising a Prefix-SID SID-R for its attached prefix R unset the
>      P-Flag (or NP-Flag) in order to instruct its connected neighbors
>      to perform the NEXT operation while processing SID-R.  This
>      behavior is equivalent to Penultimate Hop Popping in MPLS.  When
>      the flag is unset, the neighbors of N MUST perform the NEXT
>      operation while processing SID-R.  When the flag is set, the
>      neighbors of N MUST perform the CONTINUE operation while
>      processing SID-R.
> 
> SB> That is really down in the weeds, and I am not sure it belongs here.
> SB> surely you need to specify the requirement on the solution, not the
> SB> solution itself in this document. Alternatively, if it does belong here
> SB> it needs a more complete description here.


this document is an architecture draft, not a requirements draft. We must specify how the architecture works but without the implementation details (and flags are implementation details) so I agree, we have to remove the details.


> o  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.  Typically the Prefix-SID is allocated by
>      policy by the operator (or NMS) and the SID very rarely changes.
> 
>   o  While SR allows to attach a local segment to an IGP prefix (using
>      the L-Flag),
> SB> what is an L-flag?
> 
>      we specifically assume that when the terms "IGP-
>      Prefix Segment" and "Prefix-SID" are used, the segment is global
>      (the SID is allocated from the SRGB or as an index).  This is
>      consistent with all the described use-cases that require global
>      segments attached to IGP prefixes.
> 
>   o  The allocation process MUST NOT allocate the same Prefix-SID to
>      different IP prefixes.
> 
>   o  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 and SHOULD issue an error log warning for
>      misconfiguration.
> 
>   o  If a node N advertises Prefix-SID SID-R for a prefix R that is
>      attached to N, N MUST either clear the P-Flag in the advertisement
>      of SID-R, or else maintain the following FIB entry:
> 
> SB> Where did the P-Flag come from?
> 
>      Incoming Active Segment: SID-R
>      Ingress Operation: NEXT
>      Egress interface: NULL
> 
>   o  A remote node M MUST maintain the following FIB entry for any
>      learned Prefix-SID SID-R attached to IP prefix R:
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                  [Page 9]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>     Incoming Active Segment: SID-R
>     Ingress Operation:
>        If the next-hop of R is the originator of R
>        and instructed to remove the active segment: NEXT
>        Else: CONTINUE
>     Egress interface: the interface towards the next-hop along the
>                       path computed using the algorithm advertised with
>                       the SID toward prefix R.
> 
> SB> This is quite confusing. Don't these sorts of operations apply to other sorts of
> SB> SID, such as nodal SIDs?


the above definition apply to prefix-sid and node-sid. The section is about mpls used in an igp domain.

> Why are these called out in detail but not others?
> 
> SB> You talk about ECMP in nodal, doesn't that also apply here?
> 
> 3.2.3.  IPv6 Dataplane
> 
>   When SR is used over the IPv6 dataplane:
> 
>   o  The Prefix-SID is the prefix itself.  No additional identifier is
>      needed for Segment Routing over IPv6.
> 
>   o  Any address belonging to any of the node's prefixes can be used as
>      Prefix-SIDs.
> 
>   o  An operator may want to explicitly indicate which of the node's
>      prefixes can be used as Prefix-SIDs through the setting of a flag
>      (e.g.: using the IGP prefix attribute defined in [RFC7794]) in the
>      routing protocol used for advertising the prefix.
> 
>   o  A global SID is instantiated through any globally advertised IPv6
>      address.
> 
>   o  A local SID is instantiated through a local IPv6 prefix not being
>      advertised and therefore known only by the local node.
> 
>   A node N advertising an IPv6 address R usable as a segment identifier
>   MUST maintain the following FIB entry:
> 
>      Incoming Active Segment: R
>      Ingress Operation: NEXT
>      Egress interface: NULL
> 
>   Regardless Segment Routing, any remote IPv6 node will maintain a
>   plain IPv6 FIB entry for any prefix, no matter if they represent a
>   segment or not.
> 
> 3.3.  IGP-Node Segment, Node-SID
> 
>   An IGP Node Segment is a an IGP Prefix Segment which identifies a
>   specific router (e.g. a loopback).  The terms "Node Segment" or
>   "Node-SID" are often used as an abbreviation.  The IGP SR extensions
>   define a flag that identifies Node-SIDs.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 10]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   A "Node Segment" or "Node-SID" is fundamental to SR.  From anywhere
>   in the network, it enforces the ECMP-aware shortest-path forwarding
>   of the packet towards the related node.
> 
>   An IGP Node-SID MUST NOT be associated with a prefix that is owned by
>   more than one router within the same routing domain.
> 
> 3.4.  IGP-Anycast Segment, Anycast SID
> 
>   An IGP-Anycast Segment is an IGP-prefix segment which does not
>   identify a specific router, but a set of routers.  The terms "Anycast
>   Segment" or "Anycast-SID" are often used as an abbreviation.
> 
>   An "Anycast Segment" or "Anycast SID" enforces the ECMP-aware
>   shortest-path forwarding towards the closest node of the anycast set.
>   This is useful to express macro-engineering policies or protection
>   mechanisms.
> 
>   An IGP-Anycast Segment MUST NOT reference a particular node.
> 
>   Within an anycast group, all routers MUST advertise the same prefix
>   with the same SID value.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 11]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>                               +--------------+
>                               |   Group A    |
>                               |192.0.2.10/32 |
>                               |    SID:100   |
>                               |              |
>                        +-----------A1---A3----------+
>                        |      |    | \ / |   |      |
>             SID:10     |      |    |  /  |   |      |     SID:30
>       203.0.113.1/32   |      |    | / \ |   |      |  203.0.113.3/32
>               PE1------R1----------A2---A4---------R3------PE3
>                 \     /|      |              |      |\     /
>                  \   / |      +--------------+      | \   /
>                   \ /  |                            |  \ /
>                    /   |                            |   /
>                   / \  |                            |  / \
>                  /   \ |      +--------------+      | /   \
>                 /     \|      |              |      |/     \
>               PE2------R2----------B1---B3----+----R4------PE4
>       203.0.113.2/32   |      |    | \ / |   |      | 203.0.113.4/32
>             SID:20     |      |    |  /  |   |      |     SID:40
>                        |      |    | / \ |   |      |
>                        +-----+-----B2---B4----+-----+
>                               |              |
>                               |   Group B    |
>                               | 192.0.2.1/32 |
>                               |    SID:200   |
>                               +--------------+
> 
>                           Transit device groups
> 
>   The figure above describes a network example with two groups of
>   transit devices.  Group A consists of devices {A1, A2, A3 and A4}.
>   They are all provisioned with the anycast address 192.0.2.10/32 and
>   the anycast SID 100.
> 
>   Similarly, group B consists of devices {B1, B2, B3 and B4} and are
>   all provisioned with the anycast address 192.0.2.1/32, anycast SID
>   200.  In the above network topology, each PE device is connected to
>   two routers in each of the groups A and B.
> 
>   PE1 can choose a particular transit device group when sending traffic
>   to PE3 or PE4.  This will be done by pushing the anycast SID of the
>   group in the stack.
> 
>   Processing the anycast, and subsequent segments, requires special
>   care.
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 12]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   Obviously, the value of the SID following the anycast SID MUST be
>   understood by all nodes advertising the same anycast segment.
> 
>                         +-------------------------+
>                         |       Group A           |
>                         |     192.0.2.10/32       |
>                         |        SID:100          |
>                         |-------------------------|
>                         |                         |
>                         |   SRGB:         SRGB:   |
>      SID:10             |(1000-2000)   (3000-4000)|             SID:30
>        PE1---+       +-------A1-------------A3-------+       +---PE3
>               \     /   |    | \           / |    |   \     /
>                \   /    |    |  +-----+   /  |    |    \   /
>         SRGB:   \ /     |    |         \ /   |    |     \ /   SRGB:
>      (7000-8000) R1     |    |          \    |    |      R3 (6000-7000)
>                 / \     |    |         / \   |    |     / \
>                /   \    |    |  +-----+   \  |    |    /   \
>               /     \   |    | /           \ |    |   /     \
>        PE2---+       +-------A2-------------A4-------+       +---PE4
>      SID:20             |   SRGB:         SRGB:   |             SID:40
>                         |(2000-3000)   (4000-5000)|
>                         |                         |
>                         +-------------------------+
> 
>                     Transit paths via anycast group A
> 
>   Considering a MPLS deployment, in the above topology, if device PE1
>   (or PE2) requires to send a packet to the device PE3 (or PE4) it
>   needs to encapsulate the packet in a MPLS payload with the following
>   stack of labels.
> 
> SB> AS an MPLS payload?


yup.


> 
>   o  Label allocated by R1 for anycast SID 100 (outer label).
> 
>   o  Label allocated by the nearest router in group A for SID 30 (for
>      destination PE3).
> 
>   While the first label is easy to compute, in this case since there
>   are more than one topologically nearest devices (A1 and A2), unless
>   A1 and A2 allocated the same label value to the same prefix,
>   determining the second label is impossible.  Devices A1 and A2 may be
>   devices from different hardware vendors.  If both don't allocate the
>   same label value for SID 30, it is impossible to use the anycast
>   group "A" as a transit anycast group towards PE3.  Hence, PE1 (or
>   PE2) cannot compute an appropriate label stack to steer the packet
>   exclusively through the group A devices.  Same holds true for devices
>   PE3 and PE4 when trying to send a packet to PE1 or PE2.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 13]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   To ease the use of anycast segment in a short term, it is recommended
>   to configure the same SRGB on all nodes of a particular anycast
>   group.  Using this method, as mentioned above, computation of the
>   label following the anycast segment is straightforward.
> 
>   Using anycast segment without configuring the same SRGB on nodes
>   belonging to the same device group may lead to misrouting (in a MPLS
>   VPN deployment, some traffic may leak between VPNs).
> 
> SB> So is this an architectural statement that mixed vendor anycast
> SB> does not work?


no. it just states that anycast segments must be understood the same by all nodes.

Note that anycast is addressed in a separate draft.


> In which case I wonder if it should be in the
> SB> architecture at all.
> 
> 3.5.  IGP-Adjacency Segment, Adj-SID
> 
>   An IGP-Adjacency Segment is an IGP segment attached to a
>   unidirectional adjacency or a set of unidirectional adjacencies.  By
>   default, an IGP-Adjacency Segment is local to the node which
>   advertises it.  However, an Adjacency Segment can be global if
>   advertised by the IGP as such.  The SID of the IGP-Adjacency Segment
>   is called the Adj-SID.
> 
> SB> I think that there is some confusion about the meaning of global
> SB> in this draft.Earlier on the term implied that global meant that
> SB> any node would know how to execute the instruction, here it
> SB> seems to imply that it is global if the value is known globally.


global means that the semantic is known by all nodes and its identifier is known by all nodes.


>   The adjacency is formed by the local node (i.e., the node advertising
>   the adjacency in the IGP) and the remote node (i.e., the other end of
>   the adjacency).  The local node MUST be an IGP node.  The remote node
>   MAY be an adjacent IGP neighbor or a non-adjacent neighbor (e.g.: a
>   Forwarding Adjacency, [RFC4206]).
> 
> SB> Aren't Adjacency segments a concept in their own right with the
> SB> IGP just being one way of learning them? In which case shouldn't they
> SB> be introduced and explored in their own right first?


adjacency segments are one type of local segment. 

adjacency segment refers to a local segment applied to an igp adjacency.

of course there are other possible use cases for local segments referring to a link.


>   A packet injected anywhere within the SR domain with a segment list
>   {SN, SNL}, where SN is the Node-SID of node N and SNL is an Adj-SID
>   attached by node N to its adjacency over link L, will be forwarded
>   along the shortest-path to N and then be switched by N, without any
>   IP shortest-path consideration, towards link L.  If the Adj-SID
>   identifies a set of adjacencies, then the node N load- balances the
>   traffic among the various members of the set.
> 
>   Similarly, when using a global Adj-SID, a packet injected anywhere
>   within the SR domain with a segment list {SNL}, where SNL is a global
>   Adj-SID attached by node N to its adjacency over link L, will be
>   forwarded along the shortest-path to N and then be switched by N,
>   without any IP shortest-path consideration, towards link L.
> 
> SB> Ah, I think some clarification is needed earlier in the text.
> SB> You have two types of ADJ-SID, the original one which was
> SB> a local label attached to a node so it only had meaning in
> SB> conjunction with the node identifier, and this new one which
> SB> is a full identity in it's own right. I think that needs to be
> SB> more clearly expressed, together with some discussion on scaling.


the adjacency sid has been always defined as local or global. The text clearly states the difference.

This is well understood, I think, by implementors, and operators.

Let me know what kind of confusion you still have about it.


> SB>
> SB> This causes me to wonder why there is no overall discussion on the
> SB> scaling properties and issues,


probably because from a pragmatical perspective of operators and implementors, there isn’t any.

> since that is very much an
> SB> an architectural concern.

> 
>   If the
>   Adj-SID identifies a set of adjacencies, then the node N load-
>   balances the traffic among the various members of the set.  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).
> 
> SB> Doesn't it also use labels from the global label table which
> SB> is itself of a limited size?


well, the size is always limited even if modern platforms do have large capabilities.

Of course it always  matter of trade-offs.

global means more SRGB space, local means less SRGB space.

SR architecture gives you both options.


>   An "IGP Adjacency Segment" or "Adj-SID" enforces the switching of the
>   packet from a node towards a defined interface or set of interfaces.
>   This is key to theoretically prove that any path can be expressed as
>   a list of segments.
> 
> SB> This is surely a fundamental point that should be earlier in the
> SB> discussion.


ok.


> Filsfils, et al.          Expires May 23, 2017                 [Page 14]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   The encodings of the Adj-SID include the B-flag.  When set, the Adj-
>   SID refers to an adjacency that is eligible for protection (e.g.:
>   using IPFRR or MPLS-FRR).
> 
> SB> Where did the B-flag come from?


this reconnects with your comments about details. I think we need to re-phrase with less protocol details.


>   The encodings of the Adj-SID include the L-flag.  When set, the Adj-
>   SID has local significance.  By default the L-flag is set.
> 
>   A node SHOULD allocate one Adj-SIDs for each of its adjacencies.
> SB> This needs further discussion - for example why .. and is this
> SB> local or global?
> 
>   A node MAY allocate multiple Adj-SIDs to the same adjacency.  An
>   example is where the adjacency is established over a bundle
>   interface.  Each bundle member MAY have its own Adj-SID.
> 
>   A node MAY allocate the same Adj-SID to multiple adjacencies.
> 
> SB> I am wondering is Adj  is the right term here. In routing
> SB> an adjacency is a neighbouring node, but I think we are
> SB> actually talking here about Link-SIDs and Link-Bundle SIDs.


we keep adjacency sid because of the igp control plane where there’s no such “link” definition. Everything is a adjacency.

Of course we can create another term “link-SID” where we address interfaces specific sid’s.

Note that for simplicity we already adopted Adj-SID also for BGP-EPE. 

The terms “adjacenct node” can also be used outside the scope of an igp.


>   Adjacency suppression MUST NOT be performed by the IGP.
> 
> SB> Why/why not?
> 
>   A node MUST install a FIB entry for any Adj-SID of value V attached
>   to data-link L:
> 
>      Incoming Active Segment: V
>      Operation: NEXT
>      Egress Interface: L
> 
>   The Adj-SID implies, from the router advertising it, the forwarding
>   of the packet through the adjacency identified by the Adj-SID,
>   regardless its IGP/SPF cost.  In other words, the use of Adjacency
>   Segments overrides the routing decision made by SPF algorithm.
> 
> SB> nit: by the SPF
> 
> 3.5.1.  Parallel Adjacencies
> 
>   Adj-SIDs can be used in order to represent a set of parallel
>   interfaces between two adjacent routers.
> 
> SB> So we need to be clearer that an Adj-SID can be a Link, a Link Bundle or a link Group.


ok.


>   A node MUST install a FIB entry for any locally originated Adjacency
>   Segment (Adj-SID) of value W attached to a set of link B with:
> 
>      Incoming Active Segment: W
>      Ingress Operation: NEXT
>      Egress interface: loadbalance between any data-link within set B
> 
>   When parallel adjacencies are used and associated to the same Adj-
>   SID, and in order to optimize the load balancing function, a "weight"
>   factor can be associated to the Adj-SID advertised with each
>   adjacency.  The weight tells the ingress (or a SDN/orchestration
>   system) about the loadbalancing factor over the parallel adjacencies.
>   As shown in Figure 1, A and B are connected through two parallel
>   adjacencies
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 15]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>                                  link-1
>                                +--------+
>                                |        |
>                            S---A        B---C
>                                |        |
>                                +--------+
>                                  link-2
> 
>                   Figure 1: Parallel Links and Adj-SIDs
> 
>   Node A advertises following Adj-SIDs and weights:
> 
>   o  Link-1: Adj-SID 1000, weight: 1
> 
>   o  Link-2: Adj-SID 1000, weight: 2
> 
>   Node S receives the advertisements of the parallel adjacencies and
>   understands that by using Adj-SID 1000 node A will loadbalance the
>   traffic across the parallel links (link-1 and link-2) according to a
>   1:2 ratio.
> 
> SB> What happens about flow order when you use this construct?


this is outside the scope of SR. This is about ECMP algorithms as used today with or without SR.


> 
>   The weight value is advertised with the Adj-SID as defined in IGP SR
>   extensions documents.
> 
> 3.5.2.  LAN Adjacency Segments
> 
>   In LAN subnetworks, link-state protocols define the concept of
>   Designated Router (DR, in OSPF) or Designated Intermediate System
>   (DIS, in IS-IS) that conduct flooding in broadcast subnetworks and
>   that describe the LAN topology in a special routing update (OSPF
>   Type2 LSA or IS-IS Pseudonode LSP).
> 
>   The difficulty with LANs is that each router only advertises its
>   connectivity to the DR/DIS and not to each other individual nodes in
>   the LAN.  Therefore, additional protocol mechanisms (IS-IS and OSPF)
>   are necessary in order for each router in the LAN to advertise an
>   Adj-SID associated to each neighbor in the LAN.  These extensions are
>   defined in IGP SR extensions documents.
> 
> SB> This should really be in the form "will need to be provided”


well, in fact, there ARE provided.


> 
> 3.6.  Binding Segment
> 
> SB> I have read this section several times, and it is really not clear.
> SB> Nor is it clear that this is part of SR as opposed to a general
> SB> MPLS feature.


It is not dataplane specific. It is a generic mechanism used to map a single value (SID) to a source routed path.


> 
> 3.6.1.  Mapping Server
> 
>   A Remote-Binding SID S advertised by the mapping server M for remote
>   prefix R attached to non-SR-capable node N signals the same
>   information as if N had advertised S as a Prefix-SID.  Further
>   details are described in the SR/LDP interworking procedures
>   ([I-D.ietf-spring-segment-routing-ldp-interop].
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 16]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   The segment allocation and SRGB Maintenance rules are the same as
>   those defined for Prefix-SID.
> 
> 3.6.2.  Tunnel Headend
> 
>   The segment allocation and SRGB Maintenance rules are the same as
>   those defined for Adj-SID.  A tunnel attached to a head-end H acts as
>   an adjacency attached to H.
> 
>   Note: an alternative consists of representing tunnels as forwarding-
>   adjacencies ( [RFC4206]).  In such case, the tunnel is presented to
>   the routing area as a routing adjacency and is considered as such by
>   all area routers.  The Remote-Binding SID is preferred as it allows
>   to advertise the presence of a tunnel without influencing the LSDB
>   and the SPF computation.
> 
> 3.7.  Inter-Area Considerations
> 
>   In the following example diagram we assume an IGP deployed using
>   areas and where SR has been deployed.
> 
>                 !          !
>                 !          !
>          B------C-----F----G-----K
>         /       |          |     |
>   S---A/        |          |     |
>        \        |          |     |
>         \D------I----------J-----L----Z (192.0.2.1/32, Node-SID: 150)
>                 !          !
>         Area-1  ! Backbone ! Area 2
>                 !   area   !
> 
>                   Figure 2: Inter-Area Topology Example
> 
>   In area 2, node Z allocates Node-SID 150 to his local prefix
>   192.0.2.1/32.  ABRs G and J will propagate the prefix into the
>   backbone area by creating a new instance of the prefix according to
>   normal inter-area/level IGP propagation rules.
> 
>   Nodes C and I will apply the same behavior when leaking prefixes from
>   the backbone area down to area 1.  Therefore, node S will see prefix
>   192.0.2.1/32 with Prefix-SID 150 and advertised by nodes C and I.
> 
>   It therefore results that a Prefix-SID remains attached to its
>   related IGP Prefix through the inter-area process.
> 
>   When node S sends traffic to 192.0.2.1/32, it pushes Node-SID(150) as
>   active segment and forward it to A.
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 17]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   When packet arrives at ABR I (or C), the ABR forwards the packet
>   according to the active segment (Node-SID(150)).  Forwarding
>   continues across area borders, using the same Node-SID(150), until
>   the packet reaches its destination.
> 
>   When an ABR propagates a prefix from one area to another it MUST set
>   the R-Flag.
> 
> SB> As far as I can see these flags are not properly defined in this architecture document.
> SB> What is really needed is a section on routing protocol indicators.


routing protocols drafts are referenced. In your previous comments you suggested not to have these details.


> 
> 4.  BGP Peering Segments
> 
>   In the context of BGP Egress Peer Engineering (EPE), as described in
>   [I-D.ietf-spring-segment-routing-central-epe], an EPE enabled Egress
>   PE node MAY advertise segments corresponding to its attached peers.
>   These segments are called BGP peering segments or BGP Peering SIDs.
>   They enable the expression of source-routed inter-domain paths.
> 
>   An ingress border router of an AS may compose a list of segments to
>   steer a flow along a selected path within the AS, towards a selected
>   egress border router C of the AS and through a specific peer.  At
>   minimum, a BGP Peering Engineering policy applied at an ingress PE
>   involves two segments: the Node SID of the chosen egress PE and then
>   the BGP Peering Segment for the chosen egress PE peer or peering
>   interface.
> 
>   Hereafter, we will define three types of BGP peering segments/SID's:
>   PeerNodeSID, PeerAdjSID and PeerSetSID.
> 
>   o  PeerNode SID.  A BGP PeerNode segment/SID is a local segment.  At
>      the BGP node advertising it, its semantics is:
> 
>      *  SR header operation: NEXT.
> 
>      *  Next-Hop: the connected peering node to which the segment is
>         related.
> 
>   o  PeerAdj SID: A BGP PeerAdj segment/SID is a local segment.  At the
>      BGP node advertising it, its semantics is:
> 
>      *  SR header operation: NEXT.
> 
>      *  Next-Hop: the peer connected through the interface to which the
>         segment is related.
> 
>   o  PeerSet SID.  A BGP PeerSet segment/SID is a local segment.  At
>      the BGP node advertising it, its semantics is:
> 
>      *  SR header operation: NEXT.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 18]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>      *  Next-Hop: loadbalance across any connected interface to any
>         peer in the related group.
> 
>      A peer set could be all the connected peers from the same AS or a
>      subset of these.  A group could also span across AS.  The group
>      definition is a policy set by the operator.
> 
>   The BGP extensions necessary in order to signal these BGP peering
>   segments will be defined in a separate document.
> 
> 5.  IGP Mirroring Context Segment
> 
>   It is beneficial for an IGP node to be able to advertise its ability
>   to process traffic originally destined to another IGP node, called
>   the Mirrored node and identified by an IP address or a Node-SID,
>   provided that a "Mirroring Context" segment be inserted in the
>   segment list prior to any service segment local to the mirrored node.
> 
>   When a given node B wants to provide egress node A protection, it
>   advertises a segment identifying node's A context.  Such segment is
>   called "Mirror Context Segment" and identified by the Mirror SID.
> 
>   The Mirror SID is advertised using the Binding Segment 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]).
> 
>   In the event of a failure, a point of local repair (PLR) diverting
>   traffic from A to B does a PUSH of the Mirror SID on the protected
>   traffic.  B, when receiving the traffic with the Mirror SID as the
>   active segment, uses that segment and process underlying segments in
>   the context of A.
> 
> 6.  Multicast
> 
>   Segment Routing is defined for unicast.  The application of the
>   source-route concept to Multicast is not in the scope of this
>   document.
> 
> SB> A reference to BIER might be apropriate since that is the
> SB> conceptually similar.
> 
> 7.  IANA Considerations
> 
>   This document does not require any action from IANA.
> 
> 8.  Security Considerations
> 
>   Segment Routing is applicable to both MPLS and IPv6 data planes.
> 
> SB> Isn't it applicable to any forwarding plane in which an ordered
> SB> list of instructions can be imposed on a packet, at least from
> SB> an architectural perspective.


so far, we focused on mpls and v6 but probably applicable to others.


> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 19]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   Segment Routing adds some meta-data on the packet, with the list of
>   forwarding path elements (e.g.: nodes, links, services, etc.) that
>   the packet must traverse.
> 
> SB> Earlier they were instructions, or segments, and it was an ordered list.


it is the case and referred here as metadata. But probably this term may be misunderstood.


> SB> I am trying to figure out if you traverse a service. Either way
> SB> I am struck by the difference between the description here and at
> SB> the front of the document.
> 
> 
>   It has to be noted that the complete
>   source routed path may be represented by a single segment.  This is
>   the case of the Binding SID.
> 
> SB> I am not sure what that adds. The important point is to consider the
> SB> vulnerabilities and it is not clear whether BS is an increased vulnerability
> SB> if not it is unclear what it adds to the analysis.
> 
> 8.1.  MPLS Data Plane
> 
>   When applied to the MPLS data plane, Segment Routing does not
>   introduce any new behavior or any change in the way MPLS data plane
>   works.  Therefore, from a security standpoint, this document does not
>   define any additional mechanism in the MPLS data plane.
> 
> SB> Well not quite. One characteristic of MPLS was that the behaviour
> SB> of a label was only known to its peers. If a packet mislanded at
> SB> a node the behaviour was thus completely unpredictable and thus
> SB> had to exploit. MPLS-SR reduces that unpredictability and thus
> SB> add potential exploits that do not exist in the original MPLS design.


indeed but this is a concern of the overall network operations security (at the edges). Not in the dataplane itself.


>   SR allows the expression of a source routed path using a single
>   segment (the Binding SID).  Compared to RSVP-TE which also provides
>   explicit routing capability, there are no fundamental differences in
>   term of information provided.  Both RSVP-TE and Segment Routing may
>   express a source routed path using a single segment.
> 
>   When a path is expressed using a single label, the syntax of the
>   meta-data is equivalent between RSVP-TE and SR.
> 
> SB> One of the differences is that RSVP actively maintains the path.
> SB> Is there a danger of stale paths being left in an SR network
> SB> and subsequently exploited?


SR paths state is only at ingress (similar to any TE classification mechanism).

SR paths in the core does not exist as it is simply igp/bgp state.


>   When a source routed path is expressed with a list of segments
>   additional meta-data is added to the packet consisting of the source
>   routed path the packet must follow expressed as a segment list.
> 
>   When a path is expressed using a label stack, if one has access to
>   the meaning (i.e.: the Forwarding Equivalence Class) of the labels,
>   one has the knowledge of the explicit path.  For the MPLS data plane,
>   as no data plane modification is required, there is no fundamental
>   change of capability.  Yet, the occurrence of label stacking will
>   increase.
> 
> SB> The difference is that an actor could construct an explicit path
> SB> in a way that was not possible in regular MPLS. In both cases
> SB> they need to get the packet inside the network, but once inside the
> SB> network they could construct various types of amplification attack
> SB> that are not possible in classic MPLS


I think everything is possible knowing how implementations allocate labels.


>   From a network protection standpoint, there is an assumed trust model
>   such that any node imposing a label stack on a packet is assumed to
>   be allowed to do so.  This is a significant change compared to plain
>   IP offering shortest path routing but not fundamentally different
>   compared to existing techniques providing explicit routing capability
>   such as RSVP-TE.  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.
> 
>   In the general case, a segment routing capable router accepts and
>   install labels, only if these labels have been previously advertised
>   by a trusted source.  The received information is validated using
>   existing control plane protocols providing authentication and
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 20]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   security mechanisms.  Segment routing does not define any additional
>   security mechanism in existing control plane protocols.
> 
>   Segment Routing does not introduce signaling between the source and
>   the mid points of a source routed path.  With SR, the source routed
>   path is computed using SIDs previously advertised in the IP control
>   plane.  Therefore, in addition to filtering and controlled
>   advertisement of SIDs at the boundaries of the SR domain, filtering
>   in the data plane is also required.  Filtering MUST be performed on
>   the forwarding plane at the boundaries of the SR domain and may
>   require looking at multiple labels/instruction.
> 
>   For the MPLS data plane, there are no new requirement as the existing
>   MPLS architecture already allow such source routing by stacking
>   multiple labels.
> 
> SB> I think the concern is whether SR make it easier to construct an attack
> SB> given how widely know the labels are in the network compared to
> SB> classic MPLS?
> 
>   And for security protection, [RFC4381] section 2.4
>   and [RFC5920] section 8.2 already calls for the filtering of MPLS
>   packets on trust boundaries.
> 
> 8.2.  IPv6 Data Plane
> 
>   When applied to the IPv6 data plane, Segment Routing does introduce
>   the Segment Routing Header (SRH,
>   [I-D.ietf-6man-segment-routing-header]) which is a type of Routing
>   Extension header as defined in [RFC2460].
> 
>   The SRH adds some meta-data on the IPv6 packet, with the list of
>   forwarding path elements (e.g.: nodes, links, services, etc.) that
>   the packet must traverse and that are represented by IPv6 addresses.
>   A complete source routed path may be encoded in the packet using a
>   single segment (single IPv6 address).
> 
>   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.
> 
> SB> As I understand it there is current debate as to whether adding
> SB> a header to a packet is allowed in the IPv6 architecture.


yes, we reached an agreement in 6man and rfc2460bis will be hopefully published soon.


>   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.
> 
> SB> The worry of course is that the information is so widely known
> SB> in the network that any rogue node can leak this.


not new and not different from igp leaking.


>   In the general case, an SR IPv6 router accepts and install segments
>   identifiers (in the form of IPv6 addresses), only if these SIDs are
>   advertised by a trusted source.  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.
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 21]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   In addition, SR domain boundary routers, by default, MUST apply data
>   plane filters so to only accept packets whose DA and SRH (if any)
>   contain addresses previously advertised as SIDs.
> 
> SB> I am wondering how deep the dpi needs to be here? Also don't you need
> SB> to forbid any packet with an SRH from entering the network?


not by definition.

In some cases you may want to allow srh packets as long as they are allowed to do so and to have a given srh value. authentication is key here.


>   There are a number of security concerns with source routing at the
>   IPv6 data plane [RFC5095].  The new IPv6-based segment routing header
>   defined in [I-D.ietf-6man-segment-routing-header] and its associated
>   security measures address these concerns.
> 
> SB> You can only really say that when that draft is an RFC.
> 
>   The IPv6 Segment Routing
>   Header is defined in a way that blind attacks are never possible,
>   i.e., attackers will be unable to send source routed packets that get
>   successfully processed, without being part of the negations for
>   setting up the source routes or being able to eavesdrop legitimate
>   source routed packets.  In some networks this base level security may
>   be complemented with other mechanisms, such as packet filtering,
>   cryptographic security, etc.
> 
> SB> I am surprised that there are no dataplane invariant aspects to
> SB> the security, and that there are no separate control plane discussion,
> SB> particularly as you are introducing a new control plane to MPLS.
> 
> 9.  Manageability Considerations
> 
>   In SR enabled networks, the path the packet takes is encoded in the
>   header.  As the path is not signaled through a protocol,
> 
> SB> Is this true for Binding SID?


yes, the binding sid is a segment bringing the packet into the node that will then expand the path.


> 
>   OAM
>   mechanisms are necessary in order for the network operator to
>   validate the effectiveness of a path as well as to check and monitor
>   its liveness and performance.
> 
>   However, it has to be noted that SR
>   allows to reduce substantially the number of states in transit nodes
>   and hence the number of elements that a transit node has to manage is
>   smaller.
> 
>   SR OAM use cases and requirements for the MPLS data plane are defined
>   in [I-D.ietf-spring-oam-usecase] and
>   [I-D.ietf-spring-sr-oam-requirement].  OAM procedures for the MPLS
>   data plane are defined in [I-D.ietf-mpls-spring-lsp-ping].
> 
>   SR routers receive advertisement of SIDs (index, label or IPv6
>   address) from the different routing protocols being extended for SR.
>   Each of these protocols have monitoring and troubleshooting
>   mechanisms so to provide operation and management functions for IP
>   addresses that MUST be extended in order to include troubleshooting
>   and monitoring functions of the SID.
> 
>   SR architecture introduces the usage of global segments.  Each global
>   segment must be bound to a globally-unique index or address.  The
>   management of the allocation of such index or address by the operator
>   is critical for the network behavior to avoid situations like mis-
>   routing.  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.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 22]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   An operator may implement tools in order to audit the network and
>   ensure the good allocation of indexes, SIDs or IP addresses.
>   Conflict detection between SIDs, including Mapping Server binding
>   SIDs, and their resolution are addressed in
>   [I-D.ietf-spring-conflict-resolution].
> 
>   SR with the MPLS data plane, can be gracefully introduced in an
>   existing LDP [RFC5036] network.  This is described in
>   [I-D.ietf-spring-segment-routing-ldp-interop].  SR and LDP may also
>   inter-work.  In this case, the introduction of mapping-server may
>   introduce some additional manageability considerations that are
>   discussed in [I-D.ietf-spring-segment-routing-ldp-interop].
> 
>   When a path is expressed using a a label stack, the occurrence of
>   label stacking will increase.  A node may want to signal in the
>   control plane it's ability in terms of size of the label stack it can
>   support.
> 
>   A YANG data model [RFC6020] for segment routing configuration and
>   operations has been defined in [I-D.ietf-spring-sr-yang].
> 
>   When Segment Routing is applied to the IPv6 data plane, segments are
>   identified through IPv6 addresses.  The allocation, management and
>   troubleshooting of segment identifiers is no different than the
>   existing mechanisms applied to the allocation and management of IPv6
>   addresses.
> 
>   In the SR over IPv6 data plane context, the allocation of SIDs
>   results into the allocation of IPv6 addresses.  Therefore,
>   management, troubleshooting, monitoring functions are the same as the
>   one used for IPv6 addresses.
> 
>   The control of a source routed path of an IPv6 packet having an SRH
>   SHOULD be implemented through the inspection of the packet header and
>   more precisely its DA and segment list (in the SRH).  The DA of the
>   packet gives the active segment address.  The segment list in the SRH
>   gives the entire path of the packet.  The validation of the source
>   routed path is done through inspection of DA and SRH present in the
>   packet header matched to the equivalent routing table entries.
> 
>   In the context of SR over the IPv6 data plane, the source routed path
>   is encoded in the SRH as described in
>   [I-D.ietf-6man-segment-routing-header].  The SR IPv6 source routed
>   path is instantiated into the SRH as a list of IPv6 address where the
>   active segment is in the Destination Address (DA) field of the IPv6
>   packet header.  Typically, by inspecting in any node the packet
>   header, it is possible to derive the source routed path it belongs
>   to.  Similar to the context of SR over MPLS data plane, an
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 23]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   implementation may originate path control and monitoring packets
>   where the source routed path is inserted in the SRH and where each
>   segment of the path inserts in the packet the relevant data in order
>   to measure the end to end path and performance.
> 
> 10.  Contributors
> 
>   The following people have substantially contributed to the definition
>   of the Segment Routing architecture and to the editing of this
>   document:
> 
>   Ahmed Bashandy
>   Cisco Systems, Inc.
>   Email: [e-mail]
> 
>   Martin Horneffer
>   Deutsche Telekom
>   Email: [e-mail]
> 
>   Wim Henderickx
>   Alcatel-Lucent
>   Email: [e-mail]
> 
>   Jeff Tantsura
>   Ericsson
>   Email: [e-mail]
> 
>   Edward Crabbe
>   Individual
>   Email: [e-mail]
> 
>   Igor Milojevic
>   Email: [e-mail]
> 
>   Saku Ytti
>   TDC
>   Email: [e-mail]
> 
> 11.  Acknowledgements
> 
>   We would like to thank Dave Ward, Dan Frost, Stewart Bryant, Pierre
>   Francois, Thomas Telkamp, Les Ginsberg, Ruediger Geib, Hannes
>   Gredler, Pushpasis Sarkar, Eric Rosen and Chris Bowers for their
>   comments and review of this document.
> 
> 
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 24]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
> 12.  References
> 
> 12.1.  Normative References
> 
>   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
>              Requirement Levels", BCP 14, RFC 2119,
>              DOI 10.17487/RFC2119, March 1997,
>              <http://www.rfc-editor.org/info/rfc2119>.
> 
>   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
>              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
>              December 1998, <http://www.rfc-editor.org/info/rfc2460>.
> 
>   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
>              Label Switching Architecture", RFC 3031,
>              DOI 10.17487/RFC3031, January 2001,
>              <http://www.rfc-editor.org/info/rfc3031>.
> 
>   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
>              Hierarchy with Generalized Multi-Protocol Label Switching
>              (GMPLS) Traffic Engineering (TE)", RFC 4206,
>              DOI 10.17487/RFC4206, October 2005,
>              <http://www.rfc-editor.org/info/rfc4206>.
> 
> 12.2.  Informative References
> 
> SB> It is unclear to me whether or not many of these references are truely
> SB> informative. It seems that in many cases the architectural description
> SB> is so scant that the reader cannot fully understand elements of the
> SB> the architecture without reading some of these references, and that
> SB> makes them normative.
> 
>   [I-D.filsfils-spring-large-scale-interconnect]
>              Filsfils, C., Cai, D., Previdi, S., Henderickx, W.,
>              Cooper, D., Ferguson, F., Laberge, T., Lin, S., Decraene,
>              B., Jalil, L., [e-mail], j., and R. Shakir,
>              "Interconnecting Millions Of Endpoints With Segment
>              Routing", draft-filsfils-spring-large-scale-
>              interconnect-04 (work in progress), October 2016.
> 
>   [I-D.francois-rtgwg-segment-routing-ti-lfa]
>              Francois, P., Bashandy, A., and C. Filsfils, "Abstract",
>              draft-francois-rtgwg-segment-routing-ti-lfa-02 (work in
>              progress), November 2016.
> 
>   [I-D.ietf-6man-segment-routing-header]
>              Previdi, S., Filsfils, C., Field, B., Leung, I., Linkova,
>              J., Aries, E., Kosugi, T., Vyncke, E., and D. Lebrun,
>              "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-
>              segment-routing-header-02 (work in progress), September
>              2016.
> 
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 25]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   [I-D.ietf-isis-segment-routing-extensions]
>              Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
>              Litkowski, S., Decraene, B., and j. [e-mail],
>              "IS-IS Extensions for Segment Routing", draft-ietf-isis-
>              segment-routing-extensions-09 (work in progress), October
>              2016.
> 
>   [I-D.ietf-mpls-spring-lsp-ping]
>              Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
>              S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
>              Ping/Trace for Segment Routing Networks Using MPLS
>              Dataplane", draft-ietf-mpls-spring-lsp-ping-01 (work in
>              progress), October 2016.
> 
>   [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
>              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
>              Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
>              Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
>              segment-routing-extensions-07 (work in progress), October
>              2016.
> 
>   [I-D.ietf-ospf-segment-routing-extensions]
>              Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
>              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
>              Extensions for Segment Routing", draft-ietf-ospf-segment-
>              routing-extensions-10 (work in progress), October 2016.
> 
>   [I-D.ietf-pce-segment-routing]
>              Sivabalan, S., Medved, J., Filsfils, C., Crabbe, E.,
>              Raszuk, R., Lopez, V., Tantsura, J., Henderickx, W., and
>              J. Hardwick, "PCEP Extensions for Segment Routing", draft-
>              ietf-pce-segment-routing-08 (work in progress), October
>              2016.
> 
>   [I-D.ietf-spring-conflict-resolution]
>              Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
>              "Segment Routing Conflict Resolution", draft-ietf-spring-
>              conflict-resolution-02 (work in progress), October 2016.
> 
>   [I-D.ietf-spring-ipv6-use-cases]
>              Brzozowski, J., Leddy, J., Townsley, W., Filsfils, C., and
>              R. Maglione, "IPv6 SPRING Use Cases", draft-ietf-spring-
>              ipv6-use-cases-07 (work in progress), July 2016.
> 
> 
> 
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 26]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   [I-D.ietf-spring-oam-usecase]
>              Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "A
>              Scalable and Topology-Aware MPLS Dataplane Monitoring
>              System", draft-ietf-spring-oam-usecase-04 (work in
>              progress), October 2016.
> 
>   [I-D.ietf-spring-resiliency-use-cases]
>              Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
>              "Resiliency use cases in SPRING networks", draft-ietf-
>              spring-resiliency-use-cases-08 (work in progress), October
>              2016.
> 
>   [I-D.ietf-spring-segment-routing-central-epe]
>              Filsfils, C., Previdi, S., Aries, E., Ginsburg, D., and D.
>              Afanasiev, "Segment Routing Centralized BGP Peer
>              Engineering", draft-ietf-spring-segment-routing-central-
>              epe-02 (work in progress), September 2016.
> 
>   [I-D.ietf-spring-segment-routing-ldp-interop]
>              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., and
>              S. Litkowski, "Segment Routing interworking with LDP",
>              draft-ietf-spring-segment-routing-ldp-interop-04 (work in
>              progress), July 2016.
> 
>   [I-D.ietf-spring-segment-routing-mpls]
>              Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
>              Litkowski, S., Horneffer, M., Shakir, R.,
>              [e-mail], j., and E. Crabbe, "Segment Routing
>              with MPLS data plane", draft-ietf-spring-segment-routing-
>              mpls-05 (work in progress), July 2016.
> 
>   [I-D.ietf-spring-segment-routing-msdc]
>              Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P.
>              Lapukhov, "BGP-Prefix Segment in large-scale data
>              centers", draft-ietf-spring-segment-routing-msdc-02 (work
>              in progress), October 2016.
> 
>   [I-D.ietf-spring-sr-oam-requirement]
>              Kumar, N., Pignataro, C., Akiya, N., Geib, R., Mirsky, G.,
>              and S. Litkowski, "OAM Requirements for Segment Routing
>              Network", draft-ietf-spring-sr-oam-requirement-02 (work in
>              progress), July 2016.
> 
>   [I-D.ietf-spring-sr-yang]
>              Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG
>              Data Model for Segment Routing", draft-ietf-spring-sr-
>              yang-05 (work in progress), October 2016.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 27]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   [RFC4381]  Behringer, M., "Analysis of the Security of BGP/MPLS IP
>              Virtual Private Networks (VPNs)", RFC 4381,
>              DOI 10.17487/RFC4381, February 2006,
>              <http://www.rfc-editor.org/info/rfc4381>.
> 
>   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
>              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
>              RFC 4915, DOI 10.17487/RFC4915, June 2007,
>              <http://www.rfc-editor.org/info/rfc4915>.
> 
>   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
>              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
>              October 2007, <http://www.rfc-editor.org/info/rfc5036>.
> 
>   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
>              of Type 0 Routing Headers in IPv6", RFC 5095,
>              DOI 10.17487/RFC5095, December 2007,
>              <http://www.rfc-editor.org/info/rfc5095>.
> 
>   [RFC5120]  Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
>              Topology (MT) Routing in Intermediate System to
>              Intermediate Systems (IS-ISs)", RFC 5120,
>              DOI 10.17487/RFC5120, February 2008,
>              <http://www.rfc-editor.org/info/rfc5120>.
> 
>   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
>              Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
>              <http://www.rfc-editor.org/info/rfc5920>.
> 
>   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
>              the Network Configuration Protocol (NETCONF)", RFC 6020,
>              DOI 10.17487/RFC6020, October 2010,
>              <http://www.rfc-editor.org/info/rfc6020>.
> 
>   [RFC6549]  Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
>              Instance Extensions", RFC 6549, DOI 10.17487/RFC6549,
>              March 2012, <http://www.rfc-editor.org/info/rfc6549>.
> 
>   [RFC6822]  Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
>              Ward, "IS-IS Multi-Instance", RFC 6822,
>              DOI 10.17487/RFC6822, December 2012,
>              <http://www.rfc-editor.org/info/rfc6822>.
> 
>   [RFC7794]  Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
>              U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
>              and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
>              March 2016, <http://www.rfc-editor.org/info/rfc7794>.
> 
> 
> 
> 
> Filsfils, et al.          Expires May 23, 2017                 [Page 28]
> 
> Internet-Draft               Segment Routing               November 2016
> 
> 
>   [RFC7855]  Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
>              Litkowski, S., Horneffer, M., and R. Shakir, "Source
>              Packet Routing in Networking (SPRING) Problem Statement
>              and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
>              2016, <http://www.rfc-editor.org/info/rfc7855>.
> 
> Authors' Addresses
> 
>   Clarence Filsfils (editor)
>   Cisco Systems, Inc.
>   Brussels
>   BE
> 
>   Email: [e-mail]
> 
> 
>   Stefano Previdi (editor)
>   Cisco Systems, Inc.
>   Via Del Serafico, 200
>   Rome  00142
>   Italy
> 
>   Email: [e-mail]
> 
> 
>   Bruno Decraene
>   Orange
>   FR
> 
>   Email: [e-mail]
> 
> 
>   Stephane Litkowski
>   Orange
>   FR
> 
>   Email: [e-mail]
> 
> 
>   Rob Shakir
>   Google, Inc.
>   1600 Amphitheatre Parkway
>   Mountain View, CA  94043
> 
>   Email: [e-mail]
> 
> 
> 
> 
> 
> 
> Filsfils, et al.          Expires May
>