| < 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||