| < draft-ietf-ospf-link-overload-15.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: August 4, 2018 Arrcus, Inc. | Expires: August 8, 2018 Arrcus, Inc. | |||
| H. Gredler | H. Gredler | |||
| Individual | Individual | |||
| M. Nanduri | M. Nanduri | |||
| ebay Corporation | ebay Corporation | |||
| L. Jalil | L. Jalil | |||
| Verizon | Verizon | |||
| January 31, 2018 | February 4, 2018 | |||
| OSPF Graceful Link shutdown | OSPF Graceful Link shutdown | |||
| draft-ietf-ospf-link-overload-15 | 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 value on one side of the link is not sufficient | metric to the highest value on one side of the link is not sufficient | |||
| to divert the traffic flowing in the other direction. | to divert the traffic flowing in the other direction. | |||
| It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to | It is useful for the routers in an OSPFv2 or OSPFv3 routing domain to | |||
| be able to advertise a link as being in a graceful-shutdown state to | be able to advertise a link as being in a graceful-shutdown state to | |||
| skipping to change at page 2, line 10 ¶ | 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 August 4, 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 | |||
| carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Flooding Scope . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 | 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4.1. OSPFv2 graceful-link-shutdown sub-TLV . . . . . . . . . . 4 | 4.1. OSPFv2 graceful-link-shutdown sub-TLV . . . . . . . . . . 4 | |||
| 4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 5 | 4.2. Remote IPv4 Address Sub-TLV . . . . . . . . . . . . . . . 4 | |||
| 4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 6 | 4.3. Local/Remote Interface ID Sub-TLV . . . . . . . . . . . . 5 | |||
| 4.4. OSPFv3 Graceful-Link-Shutdown sub-TLV . . . . . . . . . . 6 | 4.4. OSPFv3 Graceful-Link-Shutdown sub-TLV . . . . . . . . . . 6 | |||
| 4.5. BGP-LS Graceful-Link-Shutdown TLV . . . . . . . . . . . . 7 | 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 . . . . . . . . . . . . . . . . . . 9 | 5.1. Point-to-point links . . . . . . . . . . . . . . . . . . 9 | |||
| 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 10 | 5.2. Broadcast/NBMA links . . . . . . . . . . . . . . . . . . 9 | |||
| 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 10 | 5.3. Point-to-multipoint links . . . . . . . . . . . . . . . . 10 | |||
| 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 10 | 5.4. Unnumbered interfaces . . . . . . . . . . . . . . . . . . 10 | |||
| 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 11 | 5.5. Hybrid Broadcast and P2MP interfaces . . . . . . . . . . 10 | |||
| 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 11 | 6. Backward compatibility . . . . . . . . . . . . . . . . . . . 10 | |||
| 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11 | 7. Applications . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7.1. Pseudowire Services . . . . . . . . . . . . . . . . . . . 11 | 7.1. Overlay Network . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 7.2. Controller based Traffic Engineering Deployments . . . . 12 | 7.2. Controller based Deployments . . . . . . . . . . . . . . 12 | |||
| 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 13 | 7.3. L3VPN Services and sham-links . . . . . . . . . . . . . . 13 | |||
| 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 14 | 7.4. Hub and spoke deployment . . . . . . . . . . . . . . . . 13 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 16 | 11.2. Informative References . . . . . . . . . . . . . . . . . 15 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 | 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 a | of service while allowing it to be used if no other path is | |||
| graceful-shutdown state by setting all outgoing link costs to | available.It also provides a mechanism to divert the traffic from | |||
| MaxLinkMetric (0xffff). These procedures are specific to the | both directions of the link. | |||
| maintenance activity on a node and cannot be used when a single link | ||||
| on a 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. In a service provider's network, there may | [RFC6987] cannot be used. In a service provider's network, there may | |||
| be many CE-to-CE connections that run over a single PE. It is | 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 | cumbersome to change the metric on every CE-to-CE connection in both | |||
| directions. This document provides a mechanism to change the metric | 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- | 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 | link if no alternate paths are available. An application specific to | |||
| this use case is described in detail in Section 7.1. | this use case is described in detail in Section 7.1. | |||
| 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. | ||||
| This document provides mechanisms to advertise graceful-link-shutdown | This document provides mechanisms to advertise graceful-link-shutdown | |||
| state in the flexible encodings provided by OSPFv2 Prefix/Link | state in the flexible encodings provided by OSPFv2 Prefix/Link | |||
| Attribute Advertisement [RFC7684] and E-Router-LSA | Attribute Advertisement [RFC7684] and E-Router-LSA | |||
| [I-D.ietf-ospf-ospfv3-lsa-extend] fr OSPFv3. Throughout this | [I-D.ietf-ospf-ospfv3-lsa-extend] fr OSPFv3. Throughout this | |||
| document, OSPF is used when the text applies to both OSPFv2 and | 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 | OSPFv3. OSPFv2 or OSPFv3 is used when the text is specific to one | |||
| version of the OSPF protocol. | version of the OSPF protocol. | |||
| 2. Motivation | 2. Motivation | |||
| skipping to change at page 5, line 40 ¶ | skipping to change at page 5, line 22 ¶ | |||
| | 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 IPv4 address is used to | Value: Remote IPv4 address. The remote IPv4 address is used to | |||
| identify the particular link on remote side when there are multiple | identify a particular link on the remote side when there are multiple | |||
| parallel links 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 an 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 | |||
| skipping to change at page 7, line 21 ¶ | skipping to change at page 6, line 47 ¶ | |||
| Figure 4: Graceful-Link-Shutdown 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 Graceful-Link-Shutdown 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 the external entities using BGP routing protocol. | information to the external entities using BGP routing protocol. | |||
| Graceful-link-shutdown is an imporatant link information that the | Graceful-link-shutdown is an important link information that the | |||
| external entities can use for various use cases as defined in | external entities can use for various use cases as defined in | |||
| Section 7. BGP Link NLRI is used to carry the link information. A | Section 7. BGP Link NLRI is used to carry the link information. A | |||
| new TLV called Graceful-Link-Shutdown is defined to describe the link | new TLV called Graceful-Link-Shutdown is defined to describe the link | |||
| attribute corresponding to graceful-link-shutdown state. The TLV | attribute corresponding to graceful-link-shutdown state. The TLV | |||
| format is as described in [RFC7752] sec 3.1. There is no value field | format is as described in [RFC7752] sec 3.1. There is no value field | |||
| and length field is set to zero for this TLV. | and length field is set to zero for this TLV. | |||
| 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| skipping to change at page 9, line 8 ¶ | skipping to change at page 8, line 33 ¶ | |||
| [RFC7684] for OSPFv2 and Router-Link TLV of E-Router-LSA for OSPFv3. | [RFC7684] for OSPFv2 and Router-Link TLV of E-Router-LSA for OSPFv3. | |||
| The Graceful-Link-Shutdown sub-TLV indicates that the link identified | The Graceful-Link-Shutdown sub-TLV indicates that the link identified | |||
| by the sub-TLV is subjected to maintenance. | by the sub-TLV is subjected to maintenance. | |||
| For the purposes of changing the metric OSPFv2 and OSPFv3 Router-LSAs | For the purposes of changing the metric OSPFv2 and OSPFv3 Router-LSAs | |||
| need to be re-orignated and for Traffic Engineering metric, TE Opaque | need to be re-orignated and for Traffic Engineering metric, TE Opaque | |||
| LSAs [RFC3630] in OSPFv2 and Intra-area-TE-LSA [RFC5329]in OSPFv3 | LSAs [RFC3630] in OSPFv2 and Intra-area-TE-LSA [RFC5329]in OSPFv3 | |||
| need to be re-originated. | need to be re-originated. | |||
| The Graceful-Link-Shutdown information is advertised as a property of | The Graceful-Link-Shutdown information is advertised as a property of | |||
| the link and is flooded across the area. This information can be | the link and is flooded through the area. This information can be | |||
| used by ingress routers or controllers to take special actions. An | used by ingress routers or controllers to take special actions. An | |||
| application specific to this use case is described in Section 7.2. | 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 for graceful-shutdown depends on the link type. | link identified for graceful-shutdown depends on the link type. | |||
| When a link is ready to carry traffic, the Graceful-Lnk-Shutdown sub- | ||||
| TLV should be removed from the Extended Link TLV/Router-Link TLV and | ||||
| the corresponding LSAs MUST be readvertised. | ||||
| 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 Traffic Engineering metric of the link SHOULD be set to | LSA. The Traffic Engineering metric of the link SHOULD be set to | |||
| (0xffffffff) and the node SHOULD re-originate the corresponding TE | (0xffffffff) and the node SHOULD re-originate the corresponding TE | |||
| Link Opaque LSAs. When a Graceful-Link-Shutdown sub-TLV is received | Link Opaque LSAs. When a Graceful-Link-Shutdown sub-TLV is received | |||
| for a point-to-point link, the remote node MUST identify the local | for a point-to-point link, the remote node MUST identify the local | |||
| link which corresponds to the graceful-shutdown link and set its | link which corresponds to the graceful-shutdown link and set its | |||
| metric to MaxLinkMetric (0xffff) and the remote node MUST re- | metric to MaxLinkMetric (0xffff) and the remote node MUST re- | |||
| originate its router-LSA with the changed metric. When TE is | originate its router-LSA with the changed metric. When TE is | |||
| enabled, the Traffic Engineering metric of the link SHOULD be set to | enabled, the Traffic Engineering metric of the link SHOULD be set to | |||
| (0xffffffff) and the TE opaque LSA for the link SHOULD be re- | (0xffffffff) and follow procedures of [RFC5817]. Similarly, the | |||
| originated with new value.Similarly, the remote node SHOULD set the | remote node SHOULD set the Traffic Engineering metric of the link to | |||
| Traffic Engineering metric of the link to 0xffffffff and SHOULD re- | 0xffffffff and SHOULD re-originate the TE Link Opaque LSA for the | |||
| originate the TE Link Opaque LSA for the link with the new value. | 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 Graceful-Link-Shutdown sub-TLV advertised in an | [RFC4915], the Graceful-Link-Shutdown sub-TLV advertised in an | |||
| Extended Link opaque LSA corresponds to all the topologies which | Extended Link opaque LSA corresponds to all the topologies which | |||
| include the link. The receiver node SHOULD change the metric in the | include the link. The receiver node SHOULD change the metric in the | |||
| reverse direction for all the topologies which include the remote | reverse direction for all the topologies which include the remote | |||
| link and re-originate the router-LSA as defined in [RFC4915]. | link and re-originate the router-LSA as defined in [RFC4915]. | |||
| When the originator of the Graceful-Link-Shutdown sub-TLV purges the | When the originator of the Graceful-Link-Shutdown sub-TLV purges the | |||
| skipping to change at page 10, line 41 ¶ | skipping to change at page 10, line 23 ¶ | |||
| 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 Graceful-Link-Shutdown sub-TLV is received | to-point links. When a Graceful-Link-Shutdown sub-TLV is received | |||
| for a point-to-multipoint link the remote node MUST identify the | for a point-to-multipoint link the remote node MUST identify the | |||
| neighbour which corresponds to the graceful-shutdown link and set its | neighbour which corresponds to the graceful-shutdown link and set its | |||
| metric to MaxLinkMetric (0xffff). The remote node MUST re-originate | metric to MaxLinkMetric (0xffff). The remote node MUST re-originate | |||
| the 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 | |||
| Graceful-Link-Shutdown sub-TLV in order to handle unnumbered | Graceful-Link-Shutdown sub-TLV in order to handle unnumbered | |||
| interfaces. The link-data field in the Extended Link TLV includes | interfaces. The link-data field in the Extended Link TLV includes | |||
| the Local interface-id instead of the IP address. The Local/Remote | the Local interface-id instead of the IP address. The Local/Remote | |||
| Interface ID sub-TLV MUST be advertised when there are multiple | Interface ID sub-TLV MUST be advertised when there are multiple | |||
| parallel unnumbered interfaces between two nodes. One of the | parallel unnumbered interfaces between two nodes. One of the | |||
| mechanisms to obtain the interface-id of the remote side are defined | mechanisms to obtain the interface-id of the remote side is defined | |||
| in [RFC4203]. | 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 Graceful-Link-Shutdown sub-TLV is | the P2MP interfaces. When a Graceful-Link-Shutdown sub-TLV is | |||
| received for a hybrid link, the remote node MUST identify the | received for a hybrid link, the remote node MUST identify the | |||
| neighbor which corresponds to the graceful-shutdown link and set its | neighbor which corresponds to the graceful-shutdown link and set its | |||
| skipping to change at page 11, line 31 ¶ | skipping to change at page 11, line 13 ¶ | |||
| Link-Shutdown sub-TLV as well as the node at the remote end of the | Link-Shutdown sub-TLV as well as the node at the remote end of the | |||
| graceful-shutdown link support the extensions described herein for | graceful-shutdown link support the extensions described herein for | |||
| the traffic to diverted from the graceful-shutdown link. If the | the traffic to diverted from the graceful-shutdown link. If the | |||
| remote node doesn't support the capability, it will still use the | remote node doesn't support the capability, it will still use the | |||
| graceful-shutdown link but there are no other adverse effects. In | graceful-shutdown link but there are no other adverse effects. In | |||
| the case of broadcast links using two-part metrics, the backward | the case of broadcast links using two-part metrics, the backward | |||
| compatibility procedures as described in [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 graceful- | customer. Service providers want to offer graceful-shutdown | |||
| shutdown functionality when the PE device is taken-out for | functionality when the PE device is taken-out for maintenance. There | |||
| maintenance. The provider should guarantee that the PE is taken out | can be large number of customers attached to a PE node and the remote | |||
| for maintenance, only after the service is successfully diverted on | end-points for these L2 attachments circuits are spread across the | |||
| an alternate path. There can be large number of customers attached | service provider's network. It is a tedious and error-prone process | |||
| to a PE node and the remote end-points for these pseudo-wires are | to change the metric for all corresponding L2 circuits in both | |||
| spread across the service provider's network. It is a tedious and | ||||
| error-prone process to change the metric for all pseudo-wires in both | ||||
| directions. The graceful-link-shutdown feature simplifies the | directions. The graceful-link-shutdown feature simplifies the | |||
| process by increasing the metric on the link in the reverse direction | process by increasing the metric on the CE-CE overlay link so that | |||
| as well so that traffic in both directions is diverted away from the | traffic in both directions is diverted away from the PE undergoing | |||
| PE undergoing maintenance. The Graceful-Link-Shutdown feature allows | maintenance. The Graceful-Link-Shutdown feature allows the link to | |||
| the link to be used as a last resort link so that traffic is not | be used as a last resort link so that traffic is not disrupted when | |||
| disrupted when alternate paths are not available. | alternate paths are not available. | |||
| overlay network | ------PE3---------------PE4------CE3 | |||
| ======================================= | / \ | |||
| | | | / \ | |||
| | | | ||||
| | ------PE3---------------PE4------CE3 | ||||
| | / \ | ||||
| | / \ | ||||
| CE1---------PE1----------PE2---------CE2 | CE1---------PE1----------PE2---------CE2 | |||
| | \ | \ | |||
| | \ | \ | |||
| | ------CE4 | ------CE4 | |||
| | | | ||||
| | | | ||||
| | | | ||||
| ================================= | ||||
| overlay network | ||||
| Figure 7: Pseudowire Services | Figure 7: Overlay Network | |||
| In the example shown in Figure 7, 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 stub-router | service for maintenance, a service provider sets the PE1 to stub- | |||
| state. The PE1 going in to maintenance 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 graceful-link-shutdown state. The mechanisms used | between PE1 and CE1 is outside the scope of this document. CE1 sets | |||
| to 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 graceful-link-shutdown state on its links | CE4 and changes the metric to MaxLinkMetric and re-originates the | |||
| connecting CE3, CE2 and CE4 and changes the metric to MaxLinkMetric | corresponding LSA. The remote end of the link at CE3, CE2, and CE4 | |||
| and re-originates the corresponding LSA. The remote end of the link | also set the metric on the link to MaxLinkMetric and the traffic from | |||
| at 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 graceful-link- | the IGP protocol, the controller can also receive the graceful-link- | |||
| shutdown information as a warning that link maintenance is imminent. | shutdown information as a warning that link maintenance is imminent. | |||
| Using this information, the controller can find alternate paths for | Using this information, the controller can find alternate paths for | |||
| traffic which uses the affected link. The controller can apply | traffic which uses the affected link. The controller can apply | |||
| various 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 graceful-link-shutdown | indication from the router using the graceful-link-shutdown sub-TLV | |||
| 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 | |||
| | | | | | | |||
| | | | | | | |||
| skipping to change at page 15, line 4 ¶ | skipping to change at page 14, line 21 ¶ | |||
| BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and | BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and | |||
| Attribute TLVs [RFC7752] | Attribute TLVs [RFC7752] | |||
| i)Graceful-Link-Shutdown TLV - Suggested 1121 | 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 graceful-link-shutdown is useful. | applications where graceful-link-shutdown is useful. | |||
| Thanks to Alia atlas, Deborah Brungard, Alvaro Retana and Tim Chown | Thanks to Alia Atlas, Deborah Brungard, Alvaro Retana, Andrew G. | |||
| for valuable inputs. | 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., Roy, A., Goethals, D., Vallem, V., and F. | Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. | |||
| Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- | Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- | |||
| lsa-extend-23 (work in progress), January 2018. | lsa-extend-23 (work in progress), January 2018. | |||
| skipping to change at page 15, line 43 ¶ | skipping to change at page 15, line 14 ¶ | |||
| [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., | [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., | |||
| "Traffic Engineering Extensions to OSPF Version 3", | "Traffic Engineering Extensions to OSPF Version 3", | |||
| RFC 5329, DOI 10.17487/RFC5329, September 2008, | RFC 5329, DOI 10.17487/RFC5329, September 2008, | |||
| <https://www.rfc-editor.org/info/rfc5329>. | <https://www.rfc-editor.org/info/rfc5329>. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | |||
| for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, | for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, | |||
| <https://www.rfc-editor.org/info/rfc5340>. | <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. | [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. | |||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | McPherson, "OSPF Stub Router Advertisement", RFC 6987, | |||
| DOI 10.17487/RFC6987, September 2013, | DOI 10.17487/RFC6987, September 2013, | |||
| <https://www.rfc-editor.org/info/rfc6987>. | <https://www.rfc-editor.org/info/rfc6987>. | |||
| skipping to change at page 16, line 41 ¶ | skipping to change at page 16, line 19 ¶ | |||
| [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>. | |||
| [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>. | ||||
| 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 | |||
| Arrcus, Inc. | Arrcus, Inc. | |||
| End of changes. 36 change blocks. | ||||
| 111 lines changed or deleted | 91 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/ | ||||