draft-ietf-ospf-segment-routing-extensions-18.txt   draft-ietf-ospf-segment-routing-extensions-19.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 19, 2018 Cisco Systems, Inc. Expires: February 26, 2018 Cisco Systems, Inc.
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
R. Shakir R. Shakir
Google, Inc. Google, Inc.
W. Henderickx W. Henderickx
Nokia Nokia
J. Tantsura J. Tantsura
Individual Individual
July 18, 2017 August 25, 2017
OSPF Extensions for Segment Routing OSPF Extensions for Segment Routing
draft-ietf-ospf-segment-routing-extensions-18 draft-ietf-ospf-segment-routing-extensions-19
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 19, 2018. This Internet-Draft will expire on February 26, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 5, line 45 skipping to change at page 5, line 45
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 TLVs are received from a given router, the When multiple SR-Algorithm TLVs are received from a given router, the
receiver SHOULD use the first occurrence of the TLV in the Router receiver SHOULD use the first occurrence of the TLV in the Router
Information LSA. If the SR-Algorithm TLV appears in multiple Router Information LSA. If the SR-Algorithm TLV appears in multiple Router
Information LSAs that have different flooding scopes, the SR- Information LSAs that have different flooding scopes, the SR-
Algorithm TLV in the Router Information LSA with the narrowest Algorithm TLV in the Router Information LSA with the area-scoped
flooding scope SHOULD be used. If the SR-Algorithm TLV appears in flooding scope SHOULD be used. If the SR-Algorithm TLV appears in
multiple Router Information LSAs that have the same flooding scope, multiple Router Information LSAs that have the same flooding scope,
the SR-Algorithm TLV in the Router Information (RI) LSA with the the SR-Algorithm TLV in the Router Information (RI) LSA with the
numerically smallest Instance ID SHOULD be used and subsequent numerically smallest Instance ID SHOULD be used and subsequent
instances of the SR-Algorithm TLV SHOULD be ignored. instances of the SR-Algorithm 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-scoped flooding is REQUIRED. SR-Algorithm TLV advertisement, area-scoped flooding is REQUIRED.
skipping to change at page 11, line 7 skipping to change at page 11, line 7
Router Information LSAs that have different flooding scopes, the SRMS Router Information LSAs that have different flooding scopes, the SRMS
Preference TLV in the Router Information LSA with the narrowest Preference TLV in the Router Information LSA with the narrowest
flooding scope SHOULD be used. If the SRMS Preference TLV appears in flooding scope SHOULD be used. If the SRMS Preference TLV appears in
multiple Router Information LSAs that have the same flooding scope, multiple Router Information LSAs that have the same flooding scope,
the SRMS Preference TLV in the Router Information LSA with the the SRMS Preference TLV in the Router Information LSA with the
numerically smallest Instance ID SHOULD be used and subsequent numerically smallest Instance ID SHOULD be used and subsequent
instances of the SRMS Preference TLV SHOULD be ignored. instances of the SRMS Preference TLV SHOULD be ignored.
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 the SRMS (link, area, or autonomous system (AS)). For the purpose of the SRMS
Preference TLV advertisement, AS-scoped flooding is REQUIRED. This Preference TLV advertisement, AS-scoped flooding SHOULD be used.
is because SRMS servers can be located in a different area then This is because SRMS servers can be located in a different area then
consumers of the SRMS advertisements. If the SRMS advertisements consumers of the SRMS advertisements. If the SRMS advertisements
from the SRMS server are only used inside the SRMS server's area, from the SRMS server are only used inside the SRMS server's area,
area-scoped flooding may be used. area-scoped 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.ietf-spring-segment-routing-ldp-interop], is an example where we [I-D.ietf-spring-segment-routing-ldp-interop], is an example where we
need a single advertisement to advertise SIDs for multiple prefixes need a single advertisement to advertise SIDs for multiple prefixes
from a contiguous address range. from a contiguous address range.
The OSPF Extended Prefix Range TLV, which is a top level TLV of the The OSPF Extended Prefix Range TLV, which is a top level TLV of the
skipping to change at page 25, line 27 skipping to change at page 25, line 27
Thanks to Acee Lindem for the detail review of the draft, Thanks to Acee Lindem for the detail review of the draft,
corrections, as well as discussion about details of the encoding. corrections, as well as discussion about details of the encoding.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, DOI 10.17487/RFC4915, June 2007, RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>. <https://www.rfc-editor.org/info/rfc4915>.
[RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast
and Point-to-Multipoint Interface Type", RFC 6845, and Point-to-Multipoint Interface Type", RFC 6845,
DOI 10.17487/RFC6845, January 2013, DOI 10.17487/RFC6845, January 2013, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6845>. editor.org/info/rfc6845>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <http://www.rfc-editor.org/info/rfc7684>. 2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>. February 2016, <https://www.rfc-editor.org/info/rfc7770>.
13.2. Informative References 13.2. Informative References
[I-D.ietf-spring-conflict-resolution] [I-D.ietf-spring-conflict-resolution]
Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka,
"Segment Routing MPLS Conflict Resolution", draft-ietf- "Segment Routing MPLS Conflict Resolution", draft-ietf-
spring-conflict-resolution-05 (work in progress), July spring-conflict-resolution-05 (work in progress), July
2017. 2017.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
skipping to change at page 26, line 31 skipping to change at page 26, line 31
draft-ietf-spring-segment-routing-ldp-interop-08 (work in draft-ietf-spring-segment-routing-ldp-interop-08 (work in
progress), June 2017. progress), June 2017.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-10 data plane", draft-ietf-spring-segment-routing-mpls-10
(work in progress), June 2017. (work in progress), June 2017.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc2328>. editor.org/info/rfc2328>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<http://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B.,
Litkowski, S., Horneffer, M., and R. Shakir, "Source Litkowski, S., Horneffer, M., and R. Shakir, "Source
Packet Routing in Networking (SPRING) Problem Statement Packet Routing in Networking (SPRING) Problem Statement
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May and Requirements", RFC 7855, DOI 10.17487/RFC7855, May
2016, <http://www.rfc-editor.org/info/rfc7855>. 2016, <https://www.rfc-editor.org/info/rfc7855>.
Authors' Addresses Authors' Addresses
Peter Psenak (editor) Peter Psenak (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Apollo Business Center Apollo Business Center
Mlynske nivy 43 Mlynske nivy 43
Bratislava 821 09 Bratislava 821 09
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
 End of changes. 15 change blocks. 
19 lines changed or deleted 19 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/