On Nov 30, 2016, at 2:27 PM, Stewart Bryant <stewart.bry...@gmail.com> wrote: > On 30/11/2016 10:38, Stefano Previdi (sprevidi) wrote: >>> On Nov 29, 2016, at 8:21 PM, Stewart Bryant <stewart.bry...@gmail.com> >>> 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. >> >> the references points to protocol extensions that would allow to implement >> the architecture. Then, you have other documents describing the use cases. >> >> We’ve been debating quite a bit at the time of the spring wg forming and we >> agreed to separate these topics (i.e.: architecture, protocol extensions and >> use cases). > > Separating them is fine, and having a use case dependency i.e. requirements > is OK, so long as the IESG agree to publish them (there is a policy decision > that makes this less automatic than it used to be).
indeed, things have slightly changed since the time the WG has been authoritatively formed... > However I think the architecture really needs to stand alone and above the > implementations. > >> >> Now, of course, having these references may impact the publication process >> of the architecture draft and maybe we should revisit many of the references. > > That would be wise. Also because you are changing the IPv6 dataplane, I don't > think you can assume it is done until it is done and yet you have a lot of > detail in the architecture. I don't see why the architecture needs any of > that detail. At the arch level you really just have a list of instructions > yet to be executed and everything else is implementation of that architecture. > >> >> Having said that, having a document with all the pointers to use cases and >> protocols helps the reader. >> >> >>> 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. >> >> we can easily re-phrase most of the sections and remove some of the >> references so to free (or relax) most of the dependencies. > That would be a good idea. we’re in sync then. >>> Clearly I think this draft needs significant work before it is >>> ready for submission to the IESG for publication. >> >> Well, I think it may require some editorial changes but I think the >> architecture structure and component is pretty solid... otherwise we >> wouldn’t have multi-vendor implementations and deployments... > > I agree that the MPLS side is likely to be safe. well, even for SR IPv6 we do have multivendor implementations. s. > I don't think IP is as safe and will not do so until I actually see it in the > RFC editor's queue. I do worry that the stack/(list+pointer) + address scope > differences may lead to design stress going forward. > > I have not looked at the detail of the sub-components yet. > >> >> I’ll go through your other comments in a separate email. >> >> Thanks. >> s. >> > > - Stewart > >> >>> - 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. >>> >>> Segment Routing can be directly applied to the MPLS architecture with >>> no change on the forwarding plane. >>> >>> SB> Applied to or implemented using MPLS? >>> >>> 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. >>> >>> >>> 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. I wonder if it is >>> SB> too late to change? >>> 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? >>> >>> >>> 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. >>> SB> Shouldn't this text be establishing the architectural princples >>> SB> first before getting down in the weeds of the MPLS 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, 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 (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. >>> >>> >>> Numerous use-cases illustrate the benefits of source routing either >>> for FRR, OAM or Traffic Engineering reasons. >>> >>> SB> This needs a reference. >>> >>> 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? >>> >>> 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 >>> >>> 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 >>> >>> 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. >>> >>> 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 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. >>> >>> Global Segment: the related instruction is supported by all the SR- >>> capable nodes in the domain. >>> >>> SB> instruction or identifier. 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) >>> >>> 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. >>> 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. >>> >>> 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 >>> >>> 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. >>> >>> IGP-prefix Segment, Prefix-SID: an IGP-Prefix Segment is an IGP >>> segment attached to an IGP prefix. >>> >>> SB> What does attached mean here? >>> >>> 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? >>> >>> 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? >>> >>> 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? >>> >>> 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? >>> >>> 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. A quick check >>> SB> in google only found the term is one paper. Do you simply mean path? >>> >>> 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. >>> >>> 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? >>> >>> 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 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. >>> >>> 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. >>> >>> >>> 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? 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? >>> >>> 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? 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. >>> >>> 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? >>> >>> 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. >>> SB> >>> SB> This causes me to wonder why there is no overall discussion on the >>> SB> scaling properties and issues, 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? >>> >>> 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. >>> >>> 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? >>> >>> 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. >>> >>> 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. >>> >>> >>> 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? >>> >>> 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" >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> 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. >>> >>> 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? >>> >>> 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 >>> >>> 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. >>> >>> 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. >>> >>> 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? >>> >>> 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? >>> >>> 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: basha...@cisco.com >>> >>> Martin Horneffer >>> Deutsche Telekom >>> Email: martin.hornef...@telekom.de >>> >>> Wim Henderickx >>> Alcatel-Lucent >>> Email: wim.henderi...@alcatel-lucent.com >>> >>> Jeff Tantsura >>> Ericsson >>> Email: jeff.tants...@ericsson.com >>> >>> Edward Crabbe >>> Individual >>> Email: edward.cra...@gmail.com >>> >>> Igor Milojevic >>> Email: milojevici...@gmail.com >>> >>> Saku Ytti >>> TDC >>> Email: s...@ytti.fi >>> >>> 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., jefft...@gmail.com, 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. jefft...@gmail.com, >>> "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., >>> jefft...@gmail.com, 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: cfils...@cisco.com >>> >>> >>> Stefano Previdi (editor) >>> Cisco Systems, Inc. >>> Via Del Serafico, 200 >>> Rome 00142 >>> Italy >>> >>> Email: sprev...@cisco.com >>> >>> >>> Bruno Decraene >>> Orange >>> FR >>> >>> Email: bruno.decra...@orange.com >>> >>> >>> Stephane Litkowski >>> Orange >>> FR >>> >>> Email: stephane.litkow...@orange.com >>> >>> >>> Rob Shakir >>> Google, Inc. >>> 1600 Amphitheatre Parkway >>> Mountain View, CA 94043 >>> >>> Email: ro...@google.com >>> >>> >>> >>> >>> >>> >>> Filsfils, et al. Expires May >>> > _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
