draft-ietf-ospf-segment-routing-extensions-09.txt   draft-ietf-ospf-segment-routing-extensions-10.txt 
Open Shortest Path First IGP P. Psenak, Ed. Open Shortest Path First IGP P. Psenak, Ed.
Internet-Draft S. Previdi, Ed. Internet-Draft S. Previdi, Ed.
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: January 7, 2017 Cisco Systems, Inc. Expires: May 1, 2017 Cisco Systems, Inc.
H. Gredler H. Gredler
Individual RtBrick Inc.
R. Shakir R. Shakir
Jive Communications, Inc. Google, Inc.
W. Henderickx W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Individual Individual
July 6, 2016 October 28, 2016
OSPF Extensions for Segment Routing OSPF Extensions for Segment Routing
draft-ietf-ospf-segment-routing-extensions-09 draft-ietf-ospf-segment-routing-extensions-10
Abstract Abstract
Segment Routing (SR) allows a flexible definition of end-to-end paths Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological within IGP topologies by encoding paths as sequences of topological
sub-paths, called "segments". These segments are advertised by the sub-paths, called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF). link-state routing protocols (IS-IS and OSPF).
This draft describes the OSPF extensions required for Segment This draft describes the OSPF extensions required for Segment
Routing. Routing.
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 7, 2017. This Internet-Draft will expire on May 1, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3
2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4 2.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . . . 4
3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4
3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4
3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 6
4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 7 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 8
5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 9 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 9
6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 13 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 10
6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 14 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12
6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 15 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 16
6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 15 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 18
6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 16 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18
6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 17 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 19
6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 18 6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 19
7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 19 6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 21
7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 20 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 21
7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 21 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 23
8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 23 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 23
8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 23 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 24
8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 23 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 26
8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 25 8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 26
8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 25 8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 27
8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 25 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 28
8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 25 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 28
9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 26 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 28
9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 26 9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 29
9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 26 9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 29
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31
14.1. Normative References . . . . . . . . . . . . . . . . . . 29 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Segment Routing (SR) allows a flexible definition of end-to-end paths Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological within IGP topologies by encoding paths as sequences of topological
sub-paths, called "segments". These segments are advertised by the sub-paths, called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF). Prefix segments link-state routing protocols (IS-IS and OSPF). Prefix segments
represent an ECMP-aware shortest-path to a prefix (or a node), as per represent an ECMP-aware shortest-path to a prefix (or a node), as per
the state of the IGP topology. Adjacency segments represent a hop the state of the IGP topology. Adjacency segments represent a hop
over a specific adjacency between two nodes in the IGP. A prefix over a specific adjacency between two nodes in the IGP. A prefix
skipping to change at page 5, line 49 skipping to change at page 5, line 49
the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be
included. included.
1: Strict Shortest Path First (SPF) algorithm based on link 1: Strict Shortest Path First (SPF) algorithm based on link
metric. The algorithm is identical to Algorithm 0 but metric. The algorithm is identical to Algorithm 0 but
Algorithm 1 requires that all nodes along the path will honor Algorithm 1 requires that all nodes along the path will honor
the SPF routing decision. Local policy at the node claiming the SPF routing decision. Local policy at the node claiming
support for Algorithm 1 MUST NOT alter the SPF paths computed support for Algorithm 1 MUST NOT alter the SPF paths computed
by Algorithm 1. by Algorithm 1.
When multiple SR-Algorithm sub-TLVs are received from a given router
the receiver SHOULD use the first occurrence of the sub-TLV in the
Router Information LSA. If the SR-Algorithm sub-TLV appears in
multiple Router Information LSAs that have different flooding scopes,
the SR-Algorithm sub-TLV in the Router Information LSA with the
lowest flooding scope SHOULD be used. If the SR-Algorithm sub-TLV
appears in multiple Router Information LSAs that have the same
flooding scope, the SR-Algorithm sub-TLV in the Router Information
LSA with the numerically smallest Instance ID SHOULD be used and
subsequent instances of the SR-Algorithm sub-TLV SHOULD be ignored.
The RI LSA can be advertised at any of the defined opaque flooding The RI LSA can be advertised at any of the defined opaque flooding
scopes (link, area, or Autonomous System (AS)). For the purpose of scopes (link, area, or Autonomous System (AS)). For the purpose of
SR-Algorithm TLV advertisement, area scope flooding is required. SR-Algorithm TLV advertisement, area scope flooding is required.
3.2. SID/Label Range TLV 3.2. SID/Label Range TLV
The SID/Label Range TLV is a top-level TLV of the Router Information The SID/Label Range TLV is a top-level TLV of the Router Information
Opaque LSA (defined in [RFC7770]). Opaque LSA (defined in [RFC7770]).
The SID/Label Range TLV MAY appear multiple times and has the The SID/Label Range TLV MAY appear multiple times and has the
skipping to change at page 7, line 35 skipping to change at page 8, line 5
index 100 means label 1000 index 100 means label 1000
index 199 means label 1099 index 199 means label 1099
... ...
index 200 means label 500 index 200 means label 500
... ...
The RI LSA can be advertised at any of the defined flooding scopes The RI LSA can be advertised at any of the defined flooding scopes
(link, area, or autonomous system (AS)). For the purpose of SID/ (link, area, or autonomous system (AS)). For the purpose of SID/
Label Range TLV advertisement, area scope flooding is required. Label Range TLV advertisement, area scope flooding is required.
3.3. SR Local Block Sub-TLV
The SR Local Block (SRLB) Sub-TLV contains the range of labels the
node has reserved for local SIDs. Local SIDs are used, e.g., for
Adjacency-SIDs, and may also be allocated by other components than
OSPF protocol. As an example, an application or a controller may
instruct the router to allocate a specific local SID. Therefore, in
order for such applications or controllers to know what are the local
SIDs available in the router, it is required that the router
advertises its SRLB. The SRLB Sub-TLV is used for that purpose.
The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router
Information Opaque LSA (defined in [RFC7770]).
The SR Local Block Sub-TLV MAY only be advertised once in the Router
Information Opaque LSA and has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
+ +
where:
Type: TBD, suggested value 12
Length: variable
Range Size: 3 octets of the SID/label range. MUST be higher then
0.
Initially, the only supported Sub-TLV is the SID/Label TLV as defined
in Section 2.1. The SID/Label advertised in the SID/Label TLV
represents the first SID/Label in the advertised range.
When multiple SRLB sub-TLVs are received from a given router the
receiver SHOULD use the first occurrence of the sub-TLV in the Router
Information LSA. If the SRLB sub-TLV appears in multiple Router
Information LSAs that have different flooding scopes, the SRLB sub-
TLV in the Router Information LSA with the lowest flooding scope
SHOULD be used. If the SRLB sub-TLV appears in multiple Router
Information LSAs that have the same flooding scope, the SRLB sub-TLV
in the Router Information LSA with the numerically smallest Instance
ID SHOULD be used and subsequent instances of the SRLB sub-TLV SHOULD
be ignored.
Each time a SID from the SRLB is allocated, it SHOULD also be
reported to all components (e.g.: controller or applications) in
order for these components to have an up-to-date view of the current
SRLB allocation. This is required to avoid collision between
allocation instructions.
Within the context of OSPF, the reporting of local SIDs is done
through OSPF Sub-TLVs such as the Adjacency-SID (Section 7).
However, the reporting of allocated local SIDs may also be done
through other means and protocols which mechanisms are outside the
scope of this document.
A router advertising the SRLB TLV may also have other label ranges,
outside of the SRLB, used for its local allocation purposes which are
NOT advertised in the SRLB. For example, it is possible that an
Adjacency-SID is allocated using a local label that is not part of
the SRLB.
The RI LSA can be advertised at any of the defined flooding scopes
(link, area, or autonomous system (AS)). For the purpose of SR Local
Block Sub-TLV TLV advertisement, area scope flooding is required.
3.4. SRMS Preference Sub-TLV
The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used
to advertise a preference associated with the node that acts as a SR
Mapping Server. SRMS preference is defined in
[I-D.ietf-spring-conflict-resolution].
The SRMS Preference Sub-TLV is a top-level TLV of the Router
Information Opaque LSA (defined in [RFC7770]).
The SRMS Preference Sub-TLV MAY only be advertised once in the Router
Information Opaque LSA and has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBD, suggested value 13
Length: 4 octets
Preference: 1 octet. SRMS preference value from 0 to 255.
When multiple SRMS Preference sub-TLVs are received from a given
router the receiver SHOULD use the first occurrence of the sub-TLV in
the Router Information LSA. If the SRMS Preference sub-TLV appears
in multiple Router Information LSAs that have different flooding
scopes, the SRLB sub-TLV in the Router Information LSA with the
lowest flooding scope SHOULD be used. If the SRMS Preference sub-TLV
appears in multiple Router Information LSAs that have the same
flooding scope, the SRMS Preference sub-TLV in the Router Information
LSA with the numerically smallest Instance ID SHOULD be used and
subsequent instances of the SRMS Preference sub-TLV SHOULD be
ignored.
The RI LSA can be advertised at any of the defined flooding scopes
(link, area, or autonomous system (AS)). For the purpose of the SRMS
Preference Sub-TLV advertisement, AS scope flooding is required. If
the SRMS advertisements from the SRMS server are only used inside the
area to which the SRMS server is attached, area scope flooding may be
used.
4. OSPF Extended Prefix Range TLV 4. OSPF Extended Prefix Range TLV
In some cases it is useful to advertise attributes for a range of In some cases it is useful to advertise attributes for a range of
prefixes. The Segment Routing Mapping Server, which is described in prefixes. The Segment Routing Mapping Server, which is described in
[I-D.filsfils-spring-segment-routing-ldp-interop], is an example [I-D.filsfils-spring-segment-routing-ldp-interop], is an example
where we need a single advertisement to advertise SIDs for multiple where we need a single advertisement to advertise SIDs for multiple
prefixes from a contiguous address range. prefixes from a contiguous address range.
The OSPF Extended Prefix Range TLV, which is a new top level TLV of The OSPF Extended Prefix Range TLV, which is a new top level TLV of
the Extended Prefix LSA described in [RFC7684] is defined for this the Extended Prefix LSA described in [RFC7684] is defined for this
skipping to change at page 10, line 34 skipping to change at page 13, line 41
significance. significance.
Other bits: Reserved. These MUST be zero when sent and are Other bits: Reserved. These MUST be zero when sent and are
ignored when received. ignored when received.
MT-ID: Multi-Topology ID (as defined in [RFC4915]). MT-ID: Multi-Topology ID (as defined in [RFC4915]).
Algorithm: Single octet identifying the algorithm the Prefix-SID Algorithm: Single octet identifying the algorithm the Prefix-SID
is associated with as defined in Section 3.1. is associated with as defined in Section 3.1.
A router receiving a Prefix-SID from a remote node and with an
algorithm value that such remote node has not advertised in the
SR-Algorithm sub-TLV (Section 3.1) MUST ignore the Prefix-SID sub-
TLV.
SID/Index/Label: According to the V and L flags, it contains SID/Index/Label: According to the V and L flags, it contains
either: either:
A 32-bit index defining the offset in the SID/Label space A 32-bit index defining the offset in the SID/Label space
advertised by this router. advertised by this router.
A 24-bit label where the 20 rightmost bits are used for A 24-bit label where the 20 rightmost bits are used for
encoding the label value. encoding the label value.
If multiple Prefix-SIDs are advertised for the same prefix, the If multiple Prefix-SIDs are advertised for the same prefix, the
skipping to change at page 23, line 44 skipping to change at page 27, line 12
areas. Similar to propagation of prefixes between areas, an ABR only areas. Similar to propagation of prefixes between areas, an ABR only
propagates the OSPF Extended Prefix Range TLV that it considers to be propagates the OSPF Extended Prefix Range TLV that it considers to be
the best from the set it received. The rules used to pick the best the best from the set it received. The rules used to pick the best
OSPF Extended Prefix Range TLV are described in Section 4. OSPF Extended Prefix Range TLV are described in Section 4.
When propagating an OSPF Extended Prefix Range TLV between areas, When propagating an OSPF Extended Prefix Range TLV between areas,
ABRs MUST set the IA-Flag, that is used to prevent redundant flooding ABRs MUST set the IA-Flag, that is used to prevent redundant flooding
of the OSPF Extended Prefix Range TLV between areas as described in of the OSPF Extended Prefix Range TLV between areas as described in
Section 4. Section 4.
If the Prefix-SID that is advertised in a Prefix SID Sub-TLV is also
covered by the OSPF Extended Prefix Range TLV, the Prefix-SID
advertised in Prefix SID Sub-TLV MUST be preferred.
8.2. Inter-area Segment routing in OSPFv2 8.2. Inter-area Segment routing in OSPFv2
In order to support SR in a multi-area environment, OSPFv2 must In order to support SR in a multi-area environment, OSPFv2 must
propagate Prefix-SID information between areas. The following propagate Prefix-SID information between areas. The following
procedure is used to propagate Prefix SIDs between areas. procedure is used to propagate Prefix SIDs between areas.
When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area
prefix to all its connected areas, it will also originate an Extended prefix to all its connected areas, it will also originate an Extended
Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of
the Extended Prefix Opaque LSA type will be set to area-scope. The the Extended Prefix Opaque LSA type will be set to area-scope. The
skipping to change at page 26, line 19 skipping to change at page 29, line 28
9. IANA Considerations 9. IANA Considerations
This specification updates several existing OSPF registries. This specification updates several existing OSPF registries.
9.1. OSPF OSPF Router Information (RI) TLVs Registry 9.1. OSPF OSPF Router Information (RI) TLVs Registry
o 8 (IANA Preallocated) - SR-Algorithm TLV o 8 (IANA Preallocated) - SR-Algorithm TLV
o 9 (IANA Preallocated) - SID/Label Range TLV o 9 (IANA Preallocated) - SID/Label Range TLV
o 12 - SR Local Block Sub-TLV
o 13 - SRMS Preference Sub-TLV
9.2. OSPF Extended Prefix LSA TLV Registry 9.2. OSPF Extended Prefix LSA TLV Registry
Following values are allocated: Following values are allocated:
o 2 - OSPF Extended Prefix Range TLV o 2 - OSPF Extended Prefix Range TLV
9.3. OSPF Extended Prefix LSA Sub-TLV Registry 9.3. OSPF Extended Prefix LSA Sub-TLV Registry
Following values are allocated: Following values are allocated:
skipping to change at page 30, line 33 skipping to change at page 33, line 43
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E.
Crabbe, "Segment Routing Use Cases", draft-filsfils- Crabbe, "Segment Routing Use Cases", draft-filsfils-
spring-segment-routing-use-cases-01 (work in progress), spring-segment-routing-use-cases-01 (work in progress),
October 2014. October 2014.
[I-D.gredler-ospf-label-advertisement] [I-D.gredler-ospf-label-advertisement]
Gredler, H., Amante, S., Scholl, T., and L. Jalil, Gredler, H., Amante, S., Scholl, T., and L. Jalil,
"Advertising MPLS labels in OSPF", draft-gredler-ospf- "Advertising MPLS labels in OSPF", draft-gredler-ospf-
label-advertisement-03 (work in progress), May 2013. label-advertisement-03 (work in progress), May 2013.
[I-D.ietf-spring-conflict-resolution]
Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
"Segment Routing Conflict Resolution", draft-ietf-spring-
conflict-resolution-01 (work in progress), June 2016.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J.,
and E. Crabbe, "Segment Routing Architecture", draft-ietf- and E. Crabbe, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-00 (work in progress), December spring-segment-routing-00 (work in progress), December
2014. 2014.
[I-D.minto-rsvp-lsp-egress-fast-protection] [I-D.minto-rsvp-lsp-egress-fast-protection]
Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP
egress fast-protection", draft-minto-rsvp-lsp-egress-fast- egress fast-protection", draft-minto-rsvp-lsp-egress-fast-
skipping to change at page 31, line 29 skipping to change at page 34, line 44
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Hannes Gredler Hannes Gredler
Individual RtBrick Inc.
Austria
Email: hannes@gredler.at
Email: hannes@rtbrick.com
Rob Shakir Rob Shakir
Jive Communications, Inc. Google, Inc.
1275 West 1600 North, Suite 100 1600 Amphitheatre Parkway
Orem, UT 84057 Mountain View, CA 94043
US US
Email: rrjs@rob.sh Email: robjs@google.com
Wim Henderickx Wim Henderickx
Nokia Nokia
Copernicuslaan 50 Copernicuslaan 50
Antwerp 2018 Antwerp 2018
BE BE
Email: wim.henderickx@nokia.com Email: wim.henderickx@nokia.com
Jeff Tantsura Jeff Tantsura
Individual Individual
 End of changes. 17 change blocks. 
50 lines changed or deleted 195 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/