| < draft-ietf-ospf-link-overload-11.txt | draft-ietf-ospf-link-overload-16.txt > | |||
|---|---|---|---|---|
| Open Shortest Path First IGP S. Hegde | Open Shortest Path First IGP S. Hegde | |||
| Internet-Draft Juniper Networks, Inc. | Internet-Draft Juniper Networks, Inc. | |||
| Intended status: Standards Track P. Sarkar | Intended status: Standards Track P. Sarkar | |||
| Expires: July 5, 2018 H. Gredler | Expires: August 8, 2018 Arrcus, Inc. | |||
| H. Gredler | ||||
| Individual | Individual | |||
| M. Nanduri | M. Nanduri | |||
| ebay Corporation | ebay Corporation | |||
| L. Jalil | L. Jalil | |||
| Verizon | Verizon | |||
| January 1, 2018 | February 4, 2018 | |||
| OSPF Link Overload | OSPF Graceful Link shutdown | |||
| draft-ietf-ospf-link-overload-11 | draft-ietf-ospf-link-overload-16 | |||
| Abstract | Abstract | |||
| When a link is being prepared to be taken out of service, the traffic | When a link is being prepared to be taken out of service, the traffic | |||
| needs to be diverted from both ends of the link. Increasing the | needs to be diverted from both ends of the link. Increasing the | |||
| metric to the highest metric on one side of the link is not | metric to the highest value on one side of the link is not sufficient | |||
| sufficient to divert the traffic flowing in the other direction. | to divert the traffic flowing in the other direction. | |||
| It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be | It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to | |||
| able to advertise a link as being in an overload state to indicate | be able to advertise a link as being in a graceful-shutdown state to | |||
| impending maintenance activity on the link. This information can be | indicate impending maintenance activity on the link. This | |||
| used by the network devices to re-route the traffic effectively. | information can be used by the network devices to re-route the | |||
| traffic effectively. | ||||
| This document describes the protocol extensions to disseminate link- | This document describes the protocol extensions to disseminate | |||
| overload information in OSPFv2 and OSPFv3. | graceful-link-shutdown information in OSPFv2 and OSPFv3. | |||
| Requirements Language | Requirements Language | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 10 ¶ | |||
| 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 https://datatracker.ietf.org/drafts/current/. | Drafts is at https://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 July 5, 2018. | This Internet-Draft will expire on August 8, 2018. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2018 IETF Trust and the persons identified as the | Copyright (c) 2018 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 | |||
| (https://trustee.ietf.org/license-info) in effect on the date of | (https://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 32 ¶ | |||
| to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
| include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
| the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
| 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Link-Overload sub-TLV . . . . . . . . . . . . . . . . . . . . 4 | 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1. OSPFv2 Link-overload sub-TLV . . . . . . . . . . . . . . 4 | 4.1. OSPFv2 graceful-link-shutdown sub-TLV . . . . . . . . . . 4 | |||
| 4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4 | 4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4 | |||
| 4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5 | 4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5 | |||
| 4.4. OSPFv3 Link-Overload sub-TLV . . . . . . . . . . . . . . 6 | 4.4. OSPFv3 Graceful-Link-Shutdown sub-TLV . . . . . . . . . . 6 | |||
| 4.5. BGP-LS Link-overload TLV . . . . . . . . . . . . . . . . 6 | 4.5. BGP-LS Graceful-Link-Shutdown TLV . . . . . . . . . . . . 6 | |||
| 4.6. Distinguishing parallel links . . . . . . . . . . . . . . 7 | 4.6. Distinguishing parallel links . . . . . . . . . . . . . . 7 | |||
| 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 8 | 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 8 | |||
| 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 8 | 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 9 | |||
| 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 8 | 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 9 | |||
| 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 9 | 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 10 | |||
| 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 9 | 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 10 | |||
| 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 9 | 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 10 | |||
| 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 10 | 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 10 | 7.1. Overlay Network . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7.2. Controller based Traffic Engineering Deployments . . . . 11 | 7.2. Controller based Deployments . . . . . . . . . . . . . . 12 | |||
| 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 12 | 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 13 | |||
| 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 13 | 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 13 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 14 | 11.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
| 1. Introduction | 1. Introduction | |||
| When a node is being prepared for a planned maintenance or upgrade, | This document describes a mechanism for gracefully taking a link out | |||
| [RFC6987] provides mechanisms to advertise the node being in an | of service while allowing it to be used if no other path is | |||
| overload state by setting all outgoing link costs to MaxLinkMetric | available.It also provides a mechanism to divert the traffic from | |||
| (0xffff). These procedures are specific to the maintenance activity | both directions of the link. | |||
| on a node and cannot be used when a single link on the node requires | ||||
| maintenance. | ||||
| In traffic-engineering deployments, LSPs need to be diverted from the | ||||
| link without disrupting the services. [RFC5817] describes | ||||
| requirements and procedures for graceful shutdown of MPLS links. It | ||||
| is useful to be able to advertise the impending maintenance activity | ||||
| on the link and to have LSP re-routing policies at the ingress to | ||||
| route the LSPs away from the link. | ||||
| Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned | Many OSPFv2 or OSPFv3 deployments run on overlay networks provisioned | |||
| by means of pseudo-wires or L2-circuits. Prior to devices in the | by means of pseudo-wires or L2-circuits. Prior to devices in the | |||
| underlying network going offline for maintenance, it is useful to | underlying network going offline for maintenance, it is useful to | |||
| divert the traffic away from the node before the maintenance is | divert the traffic away from the node before the maintenance is | |||
| actually performed. Since the nodes in the underlying network are | actually performed. Since the nodes in the underlying network are | |||
| not visible to OSPF, the existing stub router mechanism described in | not visible to OSPF, the existing stub router mechanism described in | |||
| [RFC6987] cannot be used. An application specific to this use case | [RFC6987] cannot be used. In a service provider's network, there may | |||
| is described in Section 7.1. | be many CE-to-CE connections that run over a single PE. It is | |||
| cumbersome to change the metric on every CE-to-CE connection in both | ||||
| directions. This document provides a mechanism to change the metric | ||||
| of the link on remote side and also use the link as a last-resort- | ||||
| link if no alternate paths are available. An application specific to | ||||
| this use case is described in detail in Section 7.1. | ||||
| This document provides mechanisms to advertise link-overload state in | This document provides mechanisms to advertise graceful-link-shutdown | |||
| the flexible encodings provided by OSPFv2 Prefix/Link Attribute | state in the flexible encodings provided by OSPFv2 Prefix/Link | |||
| Advertisement [RFC7684]. Throughout this document, OSPF is used when | Attribute Advertisement [RFC7684] and E-Router-LSA | |||
| the text applies to both OSPFv2 and OSPFv3. OSPFv2 or OSPFv3 is used | [I-D.ietf-ospf-ospfv3-lsa-extend] fr OSPFv3. Throughout this | |||
| when the text is specific to one version of the OSPF protocol. | document, OSPF is used when the text applies to both OSPFv2 and | |||
| OSPFv3. OSPFv2 or OSPFv3 is used when the text is specific to one | ||||
| version of the OSPF protocol. | ||||
| 2. Motivation | 2. Motivation | |||
| The motivation of this document is to reduce manual intervention | The motivation of this document is to reduce manual intervention | |||
| during maintenance activities. The following objectives help to | during maintenance activities. The following objectives help to | |||
| accomplish this in a range of deployment scenarios. | accomplish this in a range of deployment scenarios. | |||
| 1. Advertise impending maintenance activity so that traffic from | 1. Advertise impending maintenance activity so that traffic from | |||
| both directions can be diverted away from the link. | both directions can be diverted away from the link. | |||
| 2. Allow the solution to be backward compatible so that nodes that | 2. Allow the solution to be backward compatible so that nodes that | |||
| do not understand the new advertisement do not cause routing | do not understand the new advertisement, do not cause routing | |||
| loops. | loops. | |||
| 3. Advertise the maintenance activity to other nodes in the network | 3. Advertise the maintenance activity to other nodes in the network | |||
| so that LSP ingress routers/controllers can learn of the | so that LSP ingress routers/controllers can learn about the | |||
| impending maintenance activity and apply specific policies to re- | impending maintenance activity and apply specific policies to re- | |||
| route the LSPs for traffic-engineering based deployments. | route the LSPs for traffic-engineering based deployments. | |||
| 4. Allow the link to be used as last resort link to prevent traffic | 4. Allow the link to be used as a last resort link to prevent | |||
| disruption when alternate paths are not available. | traffic disruption when alternate paths are not available. | |||
| 3. Flooding Scope | 3. Flooding Scope | |||
| The link-overload information is flooded in area-scoped Extended Link | The graceful-link-shutdown information is flooded in area-scoped | |||
| Opaque LSA [RFC7684]. The Link-Overload sub-TLV MAY be processed by | Extended Link Opaque LSA [RFC7684] for OSPFv2 and E-Router-LSA for | |||
| the head-end nodes or the controller as described in the Section 7. | OSPFv3 [I-D.ietf-ospf-ospfv3-lsa-extend]. The Graceful-Link-Shutdown | |||
| The procedures for processing the Link-Overload sub-TLV are described | sub-TLV MAY be processed by the head-end nodes or the controller as | |||
| in Section 5. | described in the Section 7. The procedures for processing the | |||
| Graceful-Link-Shutdown sub-TLV are described in Section 5. | ||||
| 4. Link-Overload sub-TLV | 4. Protocol Extensions | |||
| 4.1. OSPFv2 Link-overload sub-TLV | 4.1. OSPFv2 graceful-link-shutdown sub-TLV | |||
| The Link-Overload sub-TLV identifies the link as being in overload | The Graceful-Link-Shutdown sub-TLV identifies the link as being | |||
| state.It is advertised in extended Link TLV of the Extended Link | gracefully shutdown. It is advertised in extended Link TLV of the | |||
| Opaque LSA as defined in [RFC7684]. | Extended Link Opaque LSA as defined in [RFC7684]. | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 1: Link-Overload sub-TLV for OSPFv2 | Figure 1: Graceful-Link-Shutdown sub-TLV for OSPFv2 | |||
| Type : TBA (suggested value 7) | Type : TBA (suggested value 7) | |||
| Length: 0 | Length: 0 | |||
| 4.2. Remote IPv4 Address Sub-TLV | 4.2. Remote IPv4 Address Sub-TLV | |||
| This sub-TLV specifies the IPv4 address of remote endpoint on the | This sub-TLV specifies the IPv4 address of remote endpoint on the | |||
| link. It is advertised in the Extended Link TLV as defined in | link. It is advertised in the Extended Link TLV as defined in | |||
| [RFC7684]. This sub-TLV is optional and MAY be advertised in area- | [RFC7684]. This sub-TLV is optional and MAY be advertised in an | |||
| scoped Extended Link Opaque LSA to identify the link when there are | area-scoped Extended Link Opaque LSA to identify the link when there | |||
| multiple parallel links between two nodes. | are multiple parallel links between two nodes. | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Remote IPv4 address | | | Remote IPv4 address | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 2: Remote IPv4 Address Sub-TLV | Figure 2: Remote IPv4 Address Sub-TLV | |||
| Type : TBA (suggested value 8) | Type : TBA (suggested value 8) | |||
| Length: 4 | Length: 4 | |||
| Value: Remote IPv4 address. The remote IP4 address is used to | Value: Remote IPv4 address. The remote IPv4 address is used to | |||
| identify the particular link when there are multiple parallel links | identify a particular link on the remote side when there are multiple | |||
| between two nodes. | parallel links between two nodes. | |||
| 4.3. Local/Remote Interface ID Sub-TLV | 4.3. Local/Remote Interface ID Sub-TLV | |||
| This sub-TLV specifies local and remote interface identifiers. It is | This sub-TLV specifies local and remote interface identifiers. It is | |||
| advertised in the Extended Link TLV as defined in [RFC7684]. This | advertised in the Extended Link TLV as defined in [RFC7684]. This | |||
| sub-TLV is optional and MAY be advertised in area-scoped Extended | sub-TLV is optional and MAY be advertised in an area-scoped Extended | |||
| Link Opaque LSA to identify the link when there are multiple parallel | Link Opaque LSA to identify the link when there are multiple parallel | |||
| unnumbered links between two nodes. The local interface-id is | unnumbered links between two nodes. The local interface-id is | |||
| generally readily available. One of the mechanisms to obtain remote | generally readily available. One of the mechanisms to obtain remote | |||
| interface-id is described in [RFC4203]. | interface-id is described in [RFC4203]. | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 6, line 24 ¶ | skipping to change at page 6, line 24 ¶ | |||
| Figure 3: Local/Remote Interface ID Sub-TLV | Figure 3: Local/Remote Interface ID Sub-TLV | |||
| Type : TBA (suggested value 9) | Type : TBA (suggested value 9) | |||
| Length: 8 | Length: 8 | |||
| Value: 4 octets of Local Interface ID followed by 4 octets of Remote | Value: 4 octets of Local Interface ID followed by 4 octets of Remote | |||
| interface ID. | interface ID. | |||
| 4.4. OSPFv3 Link-Overload sub-TLV | 4.4. OSPFv3 Graceful-Link-Shutdown sub-TLV | |||
| The Link Overload sub-TLV is carried in the Router-Link TLV as | The Graceful-Link-Shutdown sub-TLV is carried in the Router-Link TLV | |||
| defined in the [I-D.ietf-ospf-ospfv3-lsa-extend] for OSPFv3. The | as defined in the [I-D.ietf-ospf-ospfv3-lsa-extend] for OSPFv3. The | |||
| Router-Link TLV contains the neighbour interface-id and can uniquely | Router-Link TLV contains the neighbour interface-id and can uniquely | |||
| identify the link on the remote node. | identify the link on the remote node. | |||
| 0 1 2 3 | 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 | 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 | | | Type | Length | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Figure 4: Link-Overload sub-TLV for OSPFv3 | Figure 4: Graceful-Link-Shutdown sub-TLV for OSPFv3 | |||
| Type : TBA (Suggested value 7) | Type : TBA (Suggested value 7) | |||
| Length: 0 | Length: 0 | |||
| 4.5. BGP-LS Link-overload TLV | 4.5. BGP-LS Graceful-Link-Shutdown TLV | |||
| BGP-LS as defined in [RFC7752] is a mechanism to distribute network | BGP-LS as defined in [RFC7752] is a mechanism to distribute network | |||
| information to external entities using BGP routing protocol. link- | information to the external entities using BGP routing protocol. | |||
| overload is an imporatant link information that the external entities | Graceful-link-shutdown is an important link information that the | |||
| can use for various usecases as defined in Section 7. BGP Link NLRI | external entities can use for various use cases as defined in | |||
| is used to carry the link information. a new TLV called Link- | Section 7. BGP Link NLRI is used to carry the link information. A | |||
| Overload is defined to describe the link attribute corresponding to | new TLV called Graceful-Link-Shutdown is defined to describe the link | |||
| link-overload state. | attribute corresponding to graceful-link-shutdown state. The TLV | |||
| format is as described in [RFC7752] sec 3.1. There is no value field | ||||
| and length field is set to zero for this TLV. | ||||
| 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 | | ||||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Figure 5: Graceful-Link-Shutdown TLV for BGP-LS | ||||
| Type : TBA (Suggested value 1121) | ||||
| Length: 0 | ||||
| 4.6. Distinguishing parallel links | 4.6. Distinguishing parallel links | |||
| ++++++++++I.w I.y +++++++++ | ++++++++++I.w I.y +++++++++ | |||
| |Router A|------------------|Router B | | |Router A|------------------|Router B | | |||
| | |------------------| | | | |------------------| | | |||
| ++++++++++I.x I.z++++++++++ | ++++++++++I.x I.z++++++++++ | |||
| Figure 5: Parallel Linkls | Figure 6: Parallel Linkls | |||
| Consider two routers A and B connected with two parallel point-to- | Consider two routers A and B connected with two parallel point-to- | |||
| point interfaces. I.w and I.x represent the Interface address on | point interfaces. I.w and I.x represent the Interface address on | |||
| Router A's side and I.y and I.z represent Interface addresses on | Router A's side and I.y and I.z represent Interface addresses on | |||
| Router B's side. The extended link opaque LSA as described in | Router B's side. The extended link opaque LSA as described in | |||
| [RFC7684] describes links using link-type, Link-ID and Link-data. | [RFC7684] describes links using link-type, Link-ID and Link-data. | |||
| For ex. Link with address I.w is described as below on Router A. | For ex. Link with address I.w is described as below on Router A. | |||
| Link-type = Point-to-point | Link-type = Point-to-point | |||
| Link-ID: Router-ID B | Link-ID: Router-ID of B | |||
| Link-Data = I.w | Link-Data = I.w | |||
| A third node (controller or head-end) in the network cannot | A third node (controller or head-end) in the network cannot | |||
| distinguish the Interface on router B which is connected to this | distinguish the Interface on router B which is connected to this | |||
| particular Interface with the above information. Interface with | particular Interface with the above information. Interface with | |||
| address I.y or I.z could be chosen due to this ambiguity. In such | address I.y or I.z could be chosen due to this ambiguity. In such | |||
| cases Remote-IPv4 Address sub-TLV should be originated and added to | cases Remote-IPv4 Address sub-TLV should be originated and added to | |||
| the extended link-TLV. The usecases as described in Section 7 | the Extended Link TLV. The use cases as described in Section 7 | |||
| require controller or head-end nodes to interpret the link-overload | require controller or head-end nodes to interpret the graceful-link- | |||
| information and hence the need for the RemoteIPv4 address sub-TLV. | shutdown information and hence the need for the Remote IPv4 address | |||
| I.y is carried in the extended-link-TLV which unambiguously | sub-TLV. I.y is carried in the Extended Link TLV which unambiguously | |||
| identifies the interface on the remote side. OSPFv3 Router-link-TLV | identifies the interface on the remote side. OSPFv3 Router-link-TLV | |||
| as described in [I-D.ietf-ospf-ospfv3-lsa-extend] contains Interface | as described in [I-D.ietf-ospf-ospfv3-lsa-extend] contains Interface | |||
| ID and neighbor's Interface-ID which can uniquely identify connecting | ID and neighbor's Interface-ID which can uniquely identify connecting | |||
| interface on the remote side and hence OSPFv3 does not require | interface on the remote side and hence OSPFv3 does not require | |||
| seperate Remote-IPv6 address to be advertised along with OSPFv2-link- | seperate Remote-IPv6 address to be advertised along with the OSPFv3- | |||
| overload-sub-TLV. | Graceful-Link-Shutdown sub-TLV. | |||
| 5. Elements of procedure | 5. Elements of procedure | |||
| As defined in [RFC7684] every link on the node will have a separate | As defined in [RFC7684] every link on the node will have a separate | |||
| Extended Link Opaque LSA. The node that has the link to be taken out | Extended Link Opaque LSA. The node that has the link to be taken out | |||
| of service SHOULD advertise the Link-Overload sub-TLV in the Extended | of service MUST advertise the Graceful-Link-Shutdown sub-TLV in the | |||
| Link TLV of the Extended Link Opaque LSA as defined in [RFC7684] for | Extended Link TLV of the Extended Link Opaque LSA as defined in | |||
| OSPFv2. The Link-Overload sub-TLV indicates that the link identified | [RFC7684] for OSPFv2 and Router-Link TLV of E-Router-LSA for OSPFv3. | |||
| by the sub-TLV is overloaded. The Link-Overload information is | The Graceful-Link-Shutdown sub-TLV indicates that the link identified | |||
| advertised as a property of the link and is flooded across the area. | by the sub-TLV is subjected to maintenance. | |||
| This information can be used by ingress routers or controllers to | ||||
| take special actions. An application specific to this use case is | For the purposes of changing the metric OSPFv2 and OSPFv3 Router-LSAs | |||
| described in Section 7.2. | need to be re-orignated and for Traffic Engineering metric, TE Opaque | |||
| LSAs [RFC3630] in OSPFv2 and Intra-area-TE-LSA [RFC5329]in OSPFv3 | ||||
| need to be re-originated. | ||||
| The Graceful-Link-Shutdown information is advertised as a property of | ||||
| the link and is flooded through the area. This information can be | ||||
| used by ingress routers or controllers to take special actions. An | ||||
| application specific to this use case is described in Section 7.2. | ||||
| When a link is ready to carry traffic, the Graceful-Lnk-Shutdown sub- | ||||
| TLV MUST be removed from the Extended Link TLV/Router-Link TLV and | ||||
| the corresponding LSAs MUST be readvertised. Similarly, metric MUST | ||||
| be set to original values and corresponding LSAs MUST be | ||||
| readvertised. | ||||
| The procedures described in this draft may be used to divert the | ||||
| traffic away from the link in scenarios other than link-shutdown or | ||||
| link-replacement activity. | ||||
| The precise action taken by the remote node at the other end of the | The precise action taken by the remote node at the other end of the | |||
| link identified as overloaded depends on the link type. | link identified for graceful-shutdown depends on the link type. | |||
| 5.1. Point-to-point links | 5.1. Point-to-point links | |||
| The node that has the link to be taken out of service MUST set metric | The node that has the link to be taken out of service MUST set metric | |||
| of the link to MaxLinkMetric (0xffff) and re-originate its router- | of the link to MaxLinkMetric (0xffff) and re-originate its router- | |||
| LSA. The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and | LSA. The Traffic Engineering metric of the link SHOULD be set to | |||
| the node SHOULD re-originate the corresponding TE Link Opaque LSAs. | (0xffffffff) and the node SHOULD re-originate the corresponding TE | |||
| When a Link-Overload sub-TLV is received for a point-to-point link, | Link Opaque LSAs. When a Graceful-Link-Shutdown sub-TLV is received | |||
| the remote node MUST identify the local link which corresponds to the | for a point-to-point link, the remote node MUST identify the local | |||
| overloaded link and set the metric to MaxLinkMetric (0xffff)and the | link which corresponds to the graceful-shutdown link and set its | |||
| remote node MUST re-originate its router-LSA with the changed metric. | metric to MaxLinkMetric (0xffff) and the remote node MUST re- | |||
| The TE metric SHOULD be set to MAX-TE-METRIC (0xfffffffe) and the TE | originate its router-LSA with the changed metric. When TE is | |||
| opaque LSA for the link SHOULD be re-originated with new value. | enabled, the Traffic Engineering metric of the link SHOULD be set to | |||
| (0xffffffff) and follow procedures of [RFC5817]. Similarly, the | ||||
| remote node SHOULD set the Traffic Engineering metric of the link to | ||||
| 0xffffffff and SHOULD re-originate the TE Link Opaque LSA for the | ||||
| link with the new value. | ||||
| The Extended link opaque LSAs and the Extended link TLV are not | The Extended link opaque LSAs and the Extended link TLV are not | |||
| scoped for multi-topology [RFC4915]. In multi-topology deployments | scoped for multi-topology [RFC4915]. In multi-topology deployments | |||
| [RFC4915], the Link-Overload sub-TLV advertised in an Extended Link | [RFC4915], the Graceful-Link-Shutdown sub-TLV advertised in an | |||
| opaque LSA corresponds to all the topologies which include the link. | Extended Link opaque LSA corresponds to all the topologies which | |||
| The receiver node SHOULD change the metric in the reverse direction | include the link. The receiver node SHOULD change the metric in the | |||
| for all the topologies which include the remote link and re-originate | reverse direction for all the topologies which include the remote | |||
| the router-LSA as defined in [RFC4915]. | link and re-originate the router-LSA as defined in [RFC4915]. | |||
| When the originator of the Link-Overload sub-TLV purges the Extended | When the originator of the Graceful-Link-Shutdown sub-TLV purges the | |||
| Link Opaque LSA or re-originates it without the Link-Overload sub- | Extended Link Opaque LSA or re-originates it without the Graceful- | |||
| TLV, the remote node must re-originate the appropriate LSAs with the | Link-Shutdown sub-TLV, the remote node must re-originate the | |||
| metric and TE metric values set to their original values. | appropriate LSAs with the metric and TE metric values set to their | |||
| original values. | ||||
| 5.2. Broadcast/NBMA links | 5.2. Broadcast/NBMA links | |||
| Broadcast or NBMA networks in OSPF are represented by a star topology | Broadcast or NBMA networks in OSPF are represented by a star topology | |||
| where the Designated Router (DR) is the central point to which all | where the Designated Router (DR) is the central point to which all | |||
| other routers on the broadcast or NBMA network logically connect. As | other routers on the broadcast or NBMA network logically connect. As | |||
| a result, routers on the broadcast or NBMA network advertise only | a result, routers on the broadcast or NBMA network advertise only | |||
| their adjacency to the DR. Routers that do not act as DR do not form | their adjacency to the DR. Routers that do not act as DR do not form | |||
| or advertise adjacencies with each other. For the Broadcast links, | or advertise adjacencies with each other. For the Broadcast links, | |||
| the MaxLinkMetric on the remote link cannot be changed since all the | the MaxLinkMetric on the remote link cannot be changed since all the | |||
| neighbors are on same link. Setting the link cost to MaxLinkMetric | neighbors are on same link. Setting the link cost to MaxLinkMetric | |||
| would impact paths going via all neighbors. | would impact paths going via all neighbors. | |||
| The node that has the link to be taken out of service MUST set metric | The node that has the link to be taken out of service MUST set metric | |||
| of the link to MaxLinkMetric (0xffff) and re-originate the Router- | of the link to MaxLinkMetric (0xffff) and re-originate the Router- | |||
| LSA. The TE metric SHOULD be set to MAX-TE-METRIC( 0xfffffffe) and | LSA. The Traffic Engineering metric of the link SHOULD be set to ( | |||
| the node SHOULD re-originate the corresponding TE Link Opaque LSAs. | 0xffffffff) and the node SHOULD re-originate the corresponding TE | |||
| For a broadcast link, the two part metric as described in [RFC8042] | Link Opaque LSAs. For a broadcast link, the two part metric as | |||
| is used. The node originating the Link-Overload sub-TLV MUST set the | described in [RFC8042] is used. The node originating the Graceful- | |||
| metric in the Network-to-Router Metric sub-TLV to MaxLinkMetric | Link-Shutdown sub-TLV MUST set the metric in the Network-to-Router | |||
| (0xffff) for OSPFv2 and OSPFv3 and re-originate the corresponding | Metric sub-TLV to MaxLinkMetric (0xffff) for OSPFv2 and OSPFv3 and | |||
| LSAs. The nodes that receive the two-part metric should follow the | re-originate the corresponding LSAs. The nodes that receive the two- | |||
| procedures described in [RFC8042]. The backward compatibility | part metric should follow the procedures described in [RFC8042]. The | |||
| procedures described in [RFC8042] should be followed to ensure loop | backward compatibility procedures described in [RFC8042] should be | |||
| free routing. | followed to ensure loop free routing. | |||
| 5.3. Point-to-multipoint links | 5.3. Point-to-multipoint links | |||
| Operation for the point-to-multipoint links is similar to the point- | Operation for the point-to-multipoint links is similar to the point- | |||
| to-point links. When a Link-Overload sub-TLV is received for a | to-point links. When a Graceful-Link-Shutdown sub-TLV is received | |||
| point-to-multipoint link the remote node MUST identify the neighbour | for a point-to-multipoint link the remote node MUST identify the | |||
| which corresponds to the overloaded link and set the metric to | neighbour which corresponds to the graceful-shutdown link and set its | |||
| MaxLinkMetric (0xffff). The remote node MUST re-originate the | metric to MaxLinkMetric (0xffff). The remote node MUST re-originate | |||
| router-LSA with the changed metric for the correponding neighbor. | the router-LSA with the changed metric for the correponding neighbor. | |||
| 5.4. Unnumbered interfaces | 5.4. Unnumbered interfaces | |||
| Unnumbered interface do not have a unique IP address and borrow their | Unnumbered interfaces do not have a unique IP address and borrow | |||
| address from other interfaces. [RFC2328] describes procedures to | their address from other interfaces. [RFC2328] describes procedures | |||
| handle unnumbered interfaces in the context of the router-LSA. We | to handle unnumbered interfaces in the context of the router-LSA. We | |||
| apply a similar procedure to the Extended Link TLV advertising the | apply a similar procedure to the Extended Link TLV advertising the | |||
| Link-Overload sub-TLV in order to handle unnumbered interfaces. The | Graceful-Link-Shutdown sub-TLV in order to handle unnumbered | |||
| link-data field in the Extended Link TLV includes the Local | interfaces. The link-data field in the Extended Link TLV includes | |||
| interface-id instead of the IP address. The Local/Remote Interface | the Local interface-id instead of the IP address. The Local/Remote | |||
| ID sub-TLV MUST be advertised when there are multiple parallel | Interface ID sub-TLV MUST be advertised when there are multiple | |||
| unnumbered interfaces between two nodes. One of the mechanisms to | parallel unnumbered interfaces between two nodes. One of the | |||
| obtain the interface-id of the remote side are defined in [RFC4203]. | mechanisms to obtain the interface-id of the remote side is defined | |||
| in [RFC4203]. | ||||
| 5.5. Hybrid Broadcast and P2MP interfaces | 5.5. Hybrid Broadcast and P2MP interfaces | |||
| Hybrid Broadcast and P2MP interfaces represent a broadcast network | Hybrid Broadcast and P2MP interfaces represent a broadcast network | |||
| modeled as P2MP interfaces. [RFC6845] describes procedures to handle | modeled as P2MP interfaces. [RFC6845] describes procedures to handle | |||
| these interfaces. Operation for the Hybrid interfaces is similar to | these interfaces. Operation for the Hybrid interfaces is similar to | |||
| the P2MP interfaces. When a Link-Overload sub-TLV is received for a | the P2MP interfaces. When a Graceful-Link-Shutdown sub-TLV is | |||
| hybrid link, the remote node MUST identify the neighbor which | received for a hybrid link, the remote node MUST identify the | |||
| corresponds to the overloaded link and set the metric to | neighbor which corresponds to the graceful-shutdown link and set its | |||
| MaxLinkMetric (0xffff). All the remote nodes connected to originator | metric to MaxLinkMetric (0xffff). All the remote nodes connected to | |||
| MUST re-originate the router-LSA with the changed metric for the | originator MUST re-originate the router-LSA with the changed metric | |||
| neighbor. | for the neighbor. | |||
| 6. Backward compatibility | 6. Backward compatibility | |||
| The mechanisms described in the document are fully backward | The mechanisms described in the document are fully backward | |||
| compatible. It is required that the node adverting the Link-Overload | compatible. It is required that the node adverting the Graceful- | |||
| sub-TLV as well as the node at the remote end of the overloaded link | Link-Shutdown sub-TLV as well as the node at the remote end of the | |||
| support the extensions described herein for the traffic to diverted | graceful-shutdown link support the extensions described herein for | |||
| from the overloaded link. If the remote node doesn't support the | the traffic to diverted from the graceful-shutdown link. If the | |||
| capability, it will still use the overloaded link but there are no | remote node doesn't support the capability, it will still use the | |||
| other adverse effects. In the case of broadcast links using two-part | graceful-shutdown link but there are no other adverse effects. In | |||
| metrics, the backward compatibility procedures as described in | the case of broadcast links using two-part metrics, the backward | |||
| [RFC8042] are applicable. | compatibility procedures as described in [RFC8042] are applicable. | |||
| 7. Applications | 7. Applications | |||
| 7.1. Pseudowire Services | 7.1. Overlay Network | |||
| Many service providers offer pseudo-wire services to customers using | Many service providers offer L2 services to a customer connecting | |||
| L2 circuits. The IGP protocol that runs in the customer network | different locations. The customer's IGP protocol creates a seamless | |||
| would also run over the pseudo-wire to create a seamless private | private network (overlay network) across the locations for the | |||
| network for the customer. Service providers want to offer overload | customer. Service providers want to offer graceful-shutdown | |||
| functionality when the PE device is taken-out for maintenance. The | functionality when the PE device is taken-out for maintenance. There | |||
| provider should guarantee that the PE is taken out for maintenance | can be large number of customers attached to a PE node and the remote | |||
| only after the service is successfully diverted on an alternate path. | end-points for these L2 attachments circuits are spread across the | |||
| There can be large number of customers attached to a PE node and the | ||||
| remote end-points for these pseudo-wires are spread across the | ||||
| service provider's network. It is a tedious and error-prone process | service provider's network. It is a tedious and error-prone process | |||
| to change the metric for all pseudo-wires in both directions. The | to change the metric for all corresponding L2 circuits in both | |||
| link-overload feature simplifies the process by increasing the metric | directions. The graceful-link-shutdown feature simplifies the | |||
| on the link in the reverse direction as well so that traffic in both | process by increasing the metric on the CE-CE overlay link so that | |||
| directions is diverted away from the PE undergoing maintenance. The | traffic in both directions is diverted away from the PE undergoing | |||
| Link-Overload feature allows the link to be used as a last resort | maintenance. The Graceful-Link-Shutdown feature allows the link to | |||
| link so that traffic is not disrupted when alternative paths are not | be used as a last resort link so that traffic is not disrupted when | |||
| available. | alternate paths are not available. | |||
| Private VLAN | ------PE3---------------PE4------CE3 | |||
| ======================================= | / \ | |||
| | | | / \ | |||
| | | | ||||
| | ------PE3---------------PE4------CE3 | ||||
| | / \ | ||||
| | / \ | ||||
| CE1---------PE1----------PE2---------CE2 | CE1---------PE1----------PE2---------CE2 | |||
| | \ | \ | |||
| | \ | \ | |||
| | ------CE4 | ------CE4 | |||
| | | | ||||
| | | | ||||
| | | | ||||
| ================================= | ||||
| Private VLAN | ||||
| Figure 6: Pseudowire Services | Figure 7: Overlay Network | |||
| In the example shown in Figure 6, when the PE1 node is going out of | In the example shown in Figure 7, when the PE1 node is going out of | |||
| service for maintenance, service providers set the PE1 to overload | service for maintenance, a service provider sets the PE1 to stub- | |||
| state. The PE1 going in to overload state triggers all the CEs | router state and communicates the pending maintenance action to the | |||
| connected to the PE (CE1 in this case) to set their pseudowire links | overlay customer networks. The mechanisms used to communicate | |||
| passing via PE1 to link-overload state. The mechanisms used to | between PE1 and CE1 is outside the scope of this document. CE1 sets | |||
| communicate between PE1 and CE1 is outside the scope of this | the graceful-link-shutdown state on its links connecting CE3, CE2 and | |||
| document. CE1 sets the link-overload state on its private VLAN | CE4 and changes the metric to MaxLinkMetric and re-originates the | |||
| connecting CE3, CE2 and CE4 and changes the metric to MAX_METRIC and | corresponding LSA. The remote end of the link at CE3, CE2, and CE4 | |||
| re-originates the corresponding LSA. The remote end of the link at | also set the metric on the link to MaxLinkMetric and the traffic from | |||
| CE3, CE2, and CE4 also set the metric on the link to MaxLinkMetric | both directions gets diverted away from PE1. | |||
| and the traffic from both directions gets diverted away from the | ||||
| pseudowires. | ||||
| 7.2. Controller based Traffic Engineering Deployments | 7.2. Controller based Deployments | |||
| In controller-based deployments where the controller participates in | In controller-based deployments where the controller participates in | |||
| the IGP protocol, the controller can also receive the link-overload | the IGP protocol, the controller can also receive the graceful-link- | |||
| information as a warning that link maintenance is imminent. Using | shutdown information as a warning that link maintenance is imminent. | |||
| this information, the controller can find alternate paths for traffic | Using this information, the controller can find alternate paths for | |||
| which uses the affected link. The controller can apply various | traffic which uses the affected link. The controller can apply | |||
| policies and re-route the LSPs away from the link undergoing | various policies and re-route the LSPs away from the link undergoing | |||
| maintenance. If there are no alternate paths satisfying the traffic | maintenance. If there are no alternate paths satisfying the | |||
| engineering constraints, the controller might temporarily relax those | constraints, the controller might temporarily relax those constraints | |||
| constraints and put the service on a different path. Increasing the | and put the service on a different path. Increasing the link metric | |||
| link metric alone does not specify the maintenance activity as the | alone does not specify the maintenance activity as the metric could | |||
| metric could increase in events such as LDP-IGP synchronisation. An | increase in events such as LDP-IGP synchronisation. An explicit | |||
| explicit indication from the router using the link-overload sub-TLV | indication from the router using the graceful-link-shutdown sub-TLV | |||
| is needed to inform the Controller or head-end routers. | is needed to inform the Controller or head-end routers. | |||
| _____________ | _____________ | |||
| | | | | | | |||
| -------------| Controller |-------------- | -------------| Controller |-------------- | |||
| | |____________ | | | | |____________ | | | |||
| | | | | | | |||
| |--------- Primary Path ------------------| | |--------- Primary Path ------------------| | |||
| PE1---------P1----------------P2---------PE2 | PE1---------P1----------------P2---------PE2 | |||
| | | | | | | |||
| | | | | | | |||
| |________P3________| | |________P3________| | |||
| Alternate Path | Alternate Path | |||
| Figure 7: Controller based Traffic Engineering | Figure 8: Controller based Traffic Engineering | |||
| In the above example, PE1->PE2 LSP is set-up to satisfy a constraint | In the above example, PE1->PE2 LSP is set-up to satisfy a constraint | |||
| of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have | of 10 Gbps bandwidth on each link. The links P1->P3 and P3->P2 have | |||
| only 1 Gbps capacity and there is no alternate path satisfying the | only 1 Gbps capacity and there is no alternate path satisfying the | |||
| bandwidth constraint of 10Gbps. When P1->P2 link is being prepared | bandwidth constraint of 10Gbps. When P1->P2 link is being prepared | |||
| for maintenance, the controller receives the link-overload | for maintenance, the controller receives the graceful-link-shutdown | |||
| information, as there is no alternate path available which satisfies | information, as there is no alternate path available which satisfies | |||
| the constraints, the controller chooses a path that is less optimal | the constraints, the controller chooses a path that is less optimal | |||
| and temporarily sets up an alternate path via P1->P3->P2. Once the | and temporarily sets up an alternate path via P1->P3->P2. Once the | |||
| traffic is diverted, the P1->P2 link can be taken out of service for | traffic is diverted, the P1->P2 link can be taken out of service for | |||
| maintenance/upgrade. | maintenance/upgrade. | |||
| 7.3. L3VPN Services and sham-links | 7.3. L3VPN Services and sham-links | |||
| Many service providers offer L3VPN services to customers and CE-PE | Many service providers offer L3VPN services to customers and CE-PE | |||
| links run OSPF [RFC4577]. When PE is taken out of service for | links run OSPF [RFC4577]. When PE is taken out of service for | |||
| maintenance, all the links on the PE can be set to link-overload | maintenance, all the links on the PE can be set to graceful-link- | |||
| state which will gurantee that the traffic to/from dual-homed CEs | shutdown state which will gurantee that the traffic to/from dual- | |||
| gets diverted. The interaction between OSPF and BGP is outside the | homed CEs gets diverted. The interaction between OSPF and BGP is | |||
| scope of this document. [RFC6987] based mechanism with summaries and | outside the scope of this document. [RFC6987] based mechanism with | |||
| externals advertised with high metrics could also be used to achieve | summaries and externals advertised with high metrics could also be | |||
| the same functionality when implementations support high metrics | used to achieve the same functionality when implementations support | |||
| advertisement for summaries and externals. | high metrics advertisement for summaries and externals. | |||
| Another useful usecase is when ISPs provide sham-link services to | Another useful usecase is when ISPs provide sham-link services to | |||
| customers [RFC4577]. When PE goes out of service for maintenance, | customers [RFC4577]. When PE goes out of service for maintenance, | |||
| all sham-links on the PE can be set to link-overload state and | all sham-links on the PE can be set to graceful-link-shutdown state | |||
| traffic can be divered from both ends without having to touch the | and traffic can be divered from both ends without having to touch the | |||
| configurations on the remote end of the sham-links. | configurations on the remote end of the sham-links. | |||
| 7.4. Hub and spoke deployment | 7.4. Hub and spoke deployment | |||
| OSPF is largely deployed in Hub and Spoke deployments with a large | OSPF is largely deployed in Hub and Spoke deployments with a large | |||
| number of spokes connecting to the Hub. It is a general practice to | number of spokes connecting to the Hub. It is a general practice to | |||
| deploy multiple Hubs with all spokes connecting to these Hubs to | deploy multiple Hubs with all spokes connecting to these Hubs to | |||
| achieve redundancy. The [RFC6987] mechanism can be used to divert | achieve redundancy. The [RFC6987] mechanism can be used to divert | |||
| the spoke-to-spoke traffic from the overloaded hub router. The | the spoke-to-spoke traffic from the overloaded hub router. The | |||
| traffic that flows from spokes via the hub into an external network | traffic that flows from spokes via the hub into an external network | |||
| may not be diverted in certain scenarios.When a Hub node goes down | may not be diverted in certain scenarios.When a Hub node goes down | |||
| for maintenance, all links on the Hub can be set to link-overload | for maintenance, all links on the Hub can be set to graceful-link- | |||
| state and traffic gets divered from the spoke sites as well without | shutdown state and traffic gets divered from the spoke sites as well | |||
| having to make configuration changes on the spokes. | without having to make configuration changes on the spokes. | |||
| 8. Security Considerations | 8. Security Considerations | |||
| This document does not introduce any further security issues other | This document utilizes the OSPF packets and LSAs described in | |||
| than those discussed in [RFC2328] and [RFC5340]. | [RFC2328] , [RFC5340] , [RFC3630] and [RFC5329]. The authentication | |||
| procedures described in [RFC2328] for OSPFv2 and [RFC4552] for OSPFv3 | ||||
| are applicable to this document as well. This document does not | ||||
| introduce any further security issues other than those discussed in | ||||
| [RFC2328] and [RFC5340]. | ||||
| 9. IANA Considerations | 9. IANA Considerations | |||
| This specification updates one OSPF registry: | This specification updates one OSPF registry: | |||
| OSPFv2 Extended Link TLV Sub-TLVs | OSPFv2 Extended Link TLV Sub-TLVs | |||
| i) Link-Overload Sub-TLV - Suggested value 7 | i) Graceful-Link-Shutdown Sub-TLV - Suggested value 7 | |||
| ii) Remote IPv4 Address Sub-TLV - Suggested value 8 | ii) Remote IPv4 Address Sub-TLV - Suggested value 8 | |||
| iii) Local/Remote Interface ID Sub-TLV - Suggested Value 9 | iii) Local/Remote Interface ID Sub-TLV - Suggested Value 9 | |||
| OSPFv3 Extended-LSA sub-TLV Registry | OSPFv3 Extended-LSA sub-TLV Registry | |||
| i) Link-Overload sub-TLV - suggested value 7 | i) Graceful-Link-Shutdown sub-TLV - suggested value 7 | |||
| BGP-LS Link NLRI Registry [RFC7752] | BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and | |||
| Attribute TLVs [RFC7752] | ||||
| i)Link-Overload TLV - Suggested 1101 | i)Graceful-Link-Shutdown TLV - Suggested 1121 | |||
| 10. Acknowledgements | 10. Acknowledgements | |||
| Thanks to Chris Bowers for valuable inputs and edits to the document. | Thanks to Chris Bowers for valuable inputs and edits to the document. | |||
| Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs. | Thanks to Jeffrey Zhang, Acee Lindem and Ketan Talaulikar for inputs. | |||
| Thanks to Karsten Thomann for careful review and inputs on the | Thanks to Karsten Thomann for careful review and inputs on the | |||
| applications where link-overload is useful. | applications where graceful-link-shutdown is useful. | |||
| Thanks to Alia Atlas, Deborah Brungard, Alvaro Retana, Andrew G. | ||||
| Malis and Tim Chown for valuable inputs. | ||||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [I-D.ietf-ospf-ospfv3-lsa-extend] | [I-D.ietf-ospf-ospfv3-lsa-extend] | |||
| Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 | Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. | |||
| LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-10 | Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- | |||
| (work in progress), May 2016. | lsa-extend-23 (work in progress), January 2018. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, | ||||
| DOI 10.17487/RFC2119, March 1997, | ||||
| <https://www.rfc-editor.org/info/rfc2119>. | ||||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | ||||
| DOI 10.17487/RFC2328, April 1998, | ||||
| <https://www.rfc-editor.org/info/rfc2328>. | ||||
| [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering | ||||
| (TE) Extensions to OSPF Version 2", RFC 3630, | ||||
| DOI 10.17487/RFC3630, September 2003, | ||||
| <https://www.rfc-editor.org/info/rfc3630>. | ||||
| [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., | ||||
| "Traffic Engineering Extensions to OSPF Version 3", | ||||
| RFC 5329, DOI 10.17487/RFC5329, September 2008, | ||||
| <https://www.rfc-editor.org/info/rfc5329>. | ||||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | ||||
| for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, | ||||
| <https://www.rfc-editor.org/info/rfc5340>. | ||||
| [RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, | ||||
| "Graceful Shutdown in MPLS and Generalized MPLS Traffic | ||||
| Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, | ||||
| April 2010, <https://www.rfc-editor.org/info/rfc5817>. | ||||
| [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-editor.org/info/rfc6845>. | <https://www.rfc-editor.org/info/rfc6845>. | |||
| [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. | ||||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | ||||
| DOI 10.17487/RFC6987, September 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6987>. | ||||
| [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, <https://www.rfc-editor.org/info/rfc7684>. | 2015, <https://www.rfc-editor.org/info/rfc7684>. | |||
| [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and | [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and | |||
| S. Ray, "North-Bound Distribution of Link-State and | S. Ray, "North-Bound Distribution of Link-State and | |||
| Traffic Engineering (TE) Information Using BGP", RFC 7752, | Traffic Engineering (TE) Information Using BGP", RFC 7752, | |||
| DOI 10.17487/RFC7752, March 2016, | DOI 10.17487/RFC7752, March 2016, | |||
| <https://www.rfc-editor.org/info/rfc7752>. | <https://www.rfc-editor.org/info/rfc7752>. | |||
| [RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part | [RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part | |||
| Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, | Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, | |||
| <https://www.rfc-editor.org/info/rfc8042>. | <https://www.rfc-editor.org/info/rfc8042>. | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, | ||||
| DOI 10.17487/RFC2119, March 1997, | ||||
| <https://www.rfc-editor.org/info/rfc2119>. | ||||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | ||||
| DOI 10.17487/RFC2328, April 1998, | ||||
| <https://www.rfc-editor.org/info/rfc2328>. | ||||
| [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in | [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in | |||
| Support of Generalized Multi-Protocol Label Switching | Support of Generalized Multi-Protocol Label Switching | |||
| (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, | (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, | |||
| <https://www.rfc-editor.org/info/rfc4203>. | <https://www.rfc-editor.org/info/rfc4203>. | |||
| [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality | ||||
| for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, | ||||
| <https://www.rfc-editor.org/info/rfc4552>. | ||||
| [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the | [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the | |||
| Provider/Customer Edge Protocol for BGP/MPLS IP Virtual | Provider/Customer Edge Protocol for BGP/MPLS IP Virtual | |||
| Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, | Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, | |||
| June 2006, <https://www.rfc-editor.org/info/rfc4577>. | June 2006, <https://www.rfc-editor.org/info/rfc4577>. | |||
| [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, | |||
| <https://www.rfc-editor.org/info/rfc4915>. | <https://www.rfc-editor.org/info/rfc4915>. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | ||||
| for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, | ||||
| <https://www.rfc-editor.org/info/rfc5340>. | ||||
| [RFC5817] Ali, Z., Vasseur, JP., Zamfir, A., and J. Newton, | ||||
| "Graceful Shutdown in MPLS and Generalized MPLS Traffic | ||||
| Engineering Networks", RFC 5817, DOI 10.17487/RFC5817, | ||||
| April 2010, <https://www.rfc-editor.org/info/rfc5817>. | ||||
| [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. | ||||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | ||||
| DOI 10.17487/RFC6987, September 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6987>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Shraddha Hegde | Shraddha Hegde | |||
| Juniper Networks, Inc. | Juniper Networks, Inc. | |||
| Embassy Business Park | Embassy Business Park | |||
| Bangalore, KA 560093 | Bangalore, KA 560093 | |||
| India | India | |||
| Email: shraddha@juniper.net | Email: shraddha@juniper.net | |||
| Pushpasis Sarkar | Pushpasis Sarkar | |||
| Individual | Arrcus, Inc. | |||
| Email: pushpasis.ietf@gmail.com | Email: pushpasis.ietf@gmail.com | |||
| Hannes Gredler | Hannes Gredler | |||
| Individual | Individual | |||
| Email: hannes@gredler.at | Email: hannes@gredler.at | |||
| Mohan Nanduri | Mohan Nanduri | |||
| ebay Corporation | ebay Corporation | |||
| 2025 Hamilton Avenue | 2025 Hamilton Avenue | |||
| San Jose, CA 98052 | San Jose, CA 98052 | |||
| US | US | |||
| Email: mnanduri@ebay.com | Email: mnanduri@ebay.com | |||
| Luay Jalil | Luay Jalil | |||
| Verizon | Verizon | |||
| Email: luay.jalil@verizon.com | Email: luay.jalil@verizon.com | |||
| End of changes. 75 change blocks. | ||||
| 261 lines changed or deleted | 307 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/ | ||||