| < draft-ietf-lsr-ospf-reverse-metric-04.txt | draft-ietf-lsr-ospf-reverse-metric-05.txt > | |||
|---|---|---|---|---|
| Link State Routing K. Talaulikar | Link State Routing K. Talaulikar | |||
| Internet-Draft P. Psenak | Internet-Draft Arrcus Inc | |||
| Intended status: Standards Track Cisco Systems, Inc. | Intended status: Standards Track P. Psenak | |||
| Expires: April 25, 2022 H. Johnston | Expires: October 30, 2022 Cisco Systems, Inc. | |||
| H. Johnston | ||||
| AT&T Labs | AT&T Labs | |||
| October 22, 2021 | April 28, 2022 | |||
| OSPF Reverse Metric | OSPF Reverse Metric | |||
| draft-ietf-lsr-ospf-reverse-metric-04 | draft-ietf-lsr-ospf-reverse-metric-05 | |||
| Abstract | Abstract | |||
| This document specifies the extensions to OSPF that enables a router | This document specifies the extensions to OSPF that enable a router | |||
| to signal to its neighbor the metric that the neighbor should use | to use link-local signaling to signal the metric that receiving | |||
| towards itself using link-local advertisement between them. The | neighbor(s) should use for a link to the signaling router. The | |||
| signaling of this reverse metric, to be used on the links towards | signaling of this reverse metric, to be used on the link to the | |||
| itself, allows a router to influence the amount of traffic flowing | signaling router, allows a router to influence the amount of traffic | |||
| towards itself and in certain use-cases enables routers to maintain | flowing towards itself and in certain use cases enables routers to | |||
| symmetric metric on both sides of a link between them. | maintain symmetric metric on both sides of a link between them. | |||
| 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 | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| 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 April 25, 2022. | This Internet-Draft will expire on October 30, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2022 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. Symmetrical Metric Based on Reference Bandwidth . . . . . 3 | 2.1. Link Maintenance . . . . . . . . . . . . . . . . . . . . 4 | |||
| 2.2. Adaptive Metric Signaling . . . . . . . . . . . . . . . . 4 | 2.2. Adaptive Metric Signaling . . . . . . . . . . . . . . . . 4 | |||
| 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. LLS Reverse Metric TLV . . . . . . . . . . . . . . . . . . . 6 | 4. LLS Reverse Metric TLV . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. LLS Reverse TE Metric TLV . . . . . . . . . . . . . . . . . . 6 | 5. LLS Reverse TE Metric TLV . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 | 7. Operational Guidelines . . . . . . . . . . . . . . . . . . . 8 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 9 | |||
| 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
| 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 12.1. Normative References . . . . . . . . . . . . . . . . . . 10 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 12.2. Informative References . . . . . . . . . . . . . . . . . 11 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 10 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 11 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 1. Introduction | 1. Introduction | |||
| Routers running the Open Shortest Path First (OSPFv2) [RFC2328] and | Routers running the Open Shortest Path First (OSPFv2) [RFC2328] and | |||
| OSPFv3 [RFC5340] routing protocols originate a Router-LSA (Link State | OSPFv3 [RFC5340] routing protocols originate a Router-LSA (Link State | |||
| Advertisement) that describes all its links to its neighbors and | Advertisement) that describes all its links to its neighbors and | |||
| includes a metric that indicates its "cost" of reaching the neighbor | includes a metric that indicates its "cost" of reaching the neighbor | |||
| over that link. Consider two routers R1 and R2 that are connected | over that link. Consider two routers R1 and R2 that are connected | |||
| via a link. The metric for this link in direction R1->R2 is | via a link. The metric for this link in direction R1->R2 is | |||
| configured on R1 and in the direction R2->R1 is configured on R2. | configured on R1 and in the direction R2->R1 is configured on R2. | |||
| Thus the configuration on R1 influences the traffic that it forwards | Thus the configuration on R1 influences the traffic that it forwards | |||
| towards R2 but does not influence the traffic that it may receive | towards R2 but does not influence the traffic that it may receive | |||
| from R2 on that same link. | from R2 on that same link. | |||
| This document describes certain use-cases where a router is required | This document describes certain use cases where a router is required | |||
| to signal what we call the "reverse metric" (RM) to its neighbor to | to signal what we call the "reverse metric" (RM) to its neighbor to | |||
| adjust the routing metric in the inbound direction. When R1 signals | adjust the routing metric in the inbound direction. When R1 signals | |||
| its reverse metric on its link to R2, then R2 advertises this value | its reverse metric on its link to R2, then R2 advertises this value | |||
| as its metric to R1 in its Router-LSA instead of its locally | as its metric to R1 in its Router-LSA instead of its locally | |||
| configured value. Once this information is part of the topology then | configured value. Once this information is part of the topology, | |||
| all other routers do their computation using this value which results | then all other routers do their computation using this value which | |||
| in the desired change in the traffic distribution that R1 wanted to | results in the desired change in the traffic distribution that R1 | |||
| achieve towards itself over the link from R2. | wanted to achieve towards itself over the link from R2. | |||
| This document proposes an extension to OSPF link-local signaling | This document describes extensions to OSPF Link-Local Signaling (LLS) | |||
| (LLS) [RFC5613] for signaling the OSPF reverse metric using the LLS | [RFC5613] to signal OSPF reverse metrics. Section 4 specifies the | |||
| Reverse Metric TLV in Section 4, the reverse Traffic Engineering (TE) | LLS Reverse Metric TLV and Section 5 specifies the LLS Reverse TE | |||
| metric [RFC3630] using the LLS Reverse TE Metric TLV in Section 5 and | Metric TLV. The related procedures are specified in Section 6. | |||
| describes the related procedures in section Section 6. | ||||
| 1.1. Requirements Language | 1.1. 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", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. Use Cases | 2. Use Cases | |||
| This section describes certain use-cases that OSPF reverse metric | This section describes certain use cases that OSPF reverse metric | |||
| helps to address. The usage of the OSPF reverse metric need not be | helps address. The usage of the OSPF reverse metric need not be | |||
| limited to these cases and is intended to be a generic mechanism. | limited to these cases and is intended to be a generic mechanism. | |||
| 2.1. Symmetrical Metric Based on Reference Bandwidth | ||||
| Certain OSPF implementations and deployments deduce the metric of | ||||
| links based on their bandwidth using a reference bandwidth. The OSPF | ||||
| MIB [RFC4750] has ospfReferenceBandwidth that is used by entries in | ||||
| the ospfIfMetricTable. This mechanism is leveraged in deployments | ||||
| where the link metrics get lowered or increased as bandwidth capacity | ||||
| is removed or added e.g. consider layer-2 links bundled as a layer-3 | ||||
| interface on which OSPF is enabled. In the situations where these | ||||
| layer-2 links are directly connected to the two routers, the link and | ||||
| bandwidth availability are detected and updated on both sides. This | ||||
| allows for schemes where the metric is maintained to be symmetric in | ||||
| both directions based on the bandwidth. | ||||
| Now consider a variation of the same deployment where the links | ||||
| between routers are not directly connected and instead are | ||||
| provisioned over a layer-2 network consisting of switches or other | ||||
| mechanisms for a layer-2 emulation. In such scenarios, as shown in | ||||
| Figure 1, the router on one side of the link would not detect when | ||||
| the neighboring router has lost one of its layer-2 links and has | ||||
| reduced capacity to its layer-2 switch. Note that the number of | ||||
| links and their capacities on the router R0 may not be the same as | ||||
| those on R1, R2 and R3. The left-hand side diagram shows the actual | ||||
| physical topology in terms of the layer-2 links while the right-hand | ||||
| side diagram shows the logical layer-3 link topology between the | ||||
| routers. | ||||
| +--------+ | ||||
| | R0 | | ||||
| | Router | | ||||
| +--------+ +--------+ | ||||
| (a) Physical ^ ^ ^ (b) Layer-3 | R0 | | ||||
| Topology | | | Topology +--------+ | ||||
| v v v ^ ^ ^ | ||||
| +----------------+ | | | | ||||
| | Layer 2 Switch | | | | | ||||
| | (Aggregation) | +---+ | +---+ | ||||
| +----------------+ | | | | ||||
| ^^ ^ ^ ^ ^ ^ v | v | ||||
| || | | | | | +------+ | +------+ | ||||
| +----+| | | | | | | R1 | | | R3 | | ||||
| | +---+ | | | | +----+ +------+ | +------+ | ||||
| v v v v v v v v | ||||
| +--------+ +--------+ +--------+ +--------+ | ||||
| | R1 | | R2 | | R3 | | R2 | | ||||
| | Router | | Router | | Router | +--------+ | ||||
| +-- -----+ +--------+ +--------+ | ||||
| Figure 1: Routers Interconnected over Layer-2 Network | ||||
| In such a scenario, the amount of traffic that can be forwarded in | ||||
| bidirectional manner between say R0 and R1 is dictated by the lower | ||||
| of the link capacity of R0 and R1 to the layer-2 transport network. | ||||
| In this scenario, when one of the link from R1 to the switch goes | ||||
| down, it would increase its link metric to R0 from say 20 to 40. | ||||
| However, similarly, R0 also needs to increase its link metric to R1 | ||||
| as well from 20 to 40 as otherwise, the traffic will hit congestion | ||||
| and get dropped. | ||||
| When R1 can signal the OSPF reverse metric of 40 towards itself to | ||||
| R0, then R0 also updates its metric without any manual intervention | ||||
| to ensure the correct traffic distribution. Consider if some | ||||
| destinations were reachable from R0 via R1 previously and this | ||||
| automatic metric adjustment now makes some of those destinations | ||||
| reachable from R0 via R3. This allows some of the traffic load on | ||||
| the link R0 to R1 to now flow via R3 to these destinations. | ||||
| 2.2. Adaptive Metric Signaling | ||||
| Now consider another deployment scenario where, as shown in Figure 2, | ||||
| two routers AGGR1 and AGGR2 are connected to a bunch of routers R1 | ||||
| thru RN that are dual-homed to them and aggregating the traffic from | ||||
| them towards a core network. At some point T, AGGR1 loses some of | ||||
| its capacity towards the core or is facing some congestion issue | ||||
| towards the core and it needs to reduce the traffic going through it | ||||
| and perhaps redirect some of that load via AGGR2 which is not facing | ||||
| a similar issue. Altering its metric towards Rx routers would | ||||
| influence the traffic flowing through it in the direction from the | ||||
| core to the Rx but not the other way around as desired. | ||||
| Core Network | Core Network | |||
| ^ ^ | ^ ^ | |||
| | | | | | | |||
| V v | V v | |||
| +----------+ +----------+ | +----------+ +----------+ | |||
| | AGGR1 | | AGGR2 | | | AGGR1 | | AGGR2 | | |||
| +----------+ +----------+ | +----------+ +----------+ | |||
| ^ ^ ^ ^ | ^ ^ ^ ^ | |||
| | | | | | | | | | | |||
| | +-----------+ | | | +-----------+ | | |||
| | | | | | | | | | | |||
| | +--------+ | | | | +--------+ | | | |||
| v v v v | v v v v | |||
| +-----------+ +-----------+ | +-----------+ +-----------+ | |||
| | R1 | | RN | | | R1 | | RN | | |||
| | Router | ... | Router | | | Router | ... | Router | | |||
| +-----------+ +-----------+ | +-----------+ +-----------+ | |||
| Figure 2: Adaptive Metric for Dual Gateways | Figure 1: Reference Dual Hub and Spoke Topology | |||
| In such a scenario, the AGGR1 router could signal an incremental | Consider a deployment scenario where, as shown in Figure 1, a bunch | |||
| value of OSPF reverse metric towards some or all of the Rx routers. | of routers R1 through RN, are dual-home connected to AGGR1 and AGGR2 | |||
| When the Rx routers apply this signaled reverse metric offset value | that are aggregating their traffic towards a core network. | |||
| to the original metric on their links towards AGGR1 then the path via | ||||
| AGGR2 becomes a better path causing traffic towards the core getting | 2.1. Link Maintenance | |||
| diverted away from it. Note that the reverse metric mechanism allows | ||||
| such adaptive metric changes to be applied on the AGGR1 as opposed to | Before network maintenance events are performed on individual links, | |||
| being provisioning statically on the possibly large number of Rx | operators substantially increase (to maximum value) the OSPF metric | |||
| routers. | simultaneously on both routers attached to the same link. In doing | |||
| so, the routers generate new Router LSAs that are flooded throughout | ||||
| the network and cause all routers to gradually shift traffic onto | ||||
| alternate paths with very little or no disruption to in-flight | ||||
| communications by applications or end-users. When performed | ||||
| successfully, this allows the operator to confidently perform | ||||
| disruptive augmentation, fault diagnosis, or repairs on a link | ||||
| without disturbing ongoing communications in the network. | ||||
| In deployments such as a hub and spoke topology as shown in Figure 1, | ||||
| it is quite common to have routers with several hundred interfaces | ||||
| and individual interfaces that move anywhere from several hundred | ||||
| gigabits/second to terabits/second of traffic. The challenge in such | ||||
| conditions is that the operator must accurately identify the same | ||||
| point-to-point link on two separate devices to increase (and | ||||
| afterward decrease) the OSPF metric appropriately and to do so in a | ||||
| coordinated manner. When considering maintenance for PE-CE links | ||||
| when a large number of CE routers connect to a PE router, an | ||||
| additional challenge related to coordinating access to the CE routers | ||||
| may arise when the CEs are not managed by the provider. | ||||
| The OSPF reverse metric mechanism helps address these challenges. | ||||
| The operator can set the link on one of the routers (generally the | ||||
| hub like AGGR1 or a PE) in a "maintenance mode". This causes the | ||||
| router to advertise the maximum metric for that link and also to | ||||
| signal its neighbor on the same link to advertise maximum metric via | ||||
| the reverse metric signaling mechanism. Once the link maintenance is | ||||
| completed and the "maintenance mode" is turned off, the router | ||||
| returns to using its provisioned metric for the link and also stops | ||||
| the signaling of reverse metric on that link resulting in its | ||||
| neighbor to also revert to its provisioned metric for that link. | ||||
| 2.2. Adaptive Metric Signaling | ||||
| In Figure 1 above, consider that at some point T, AGGR1 loses some of | ||||
| its capacity towards the core that may result in a congestion issue | ||||
| towards the core and it needs to reduce the traffic towards the core | ||||
| by redirecting some of the load to transit AGGR2 which is not | ||||
| experiencing a similar issue. Altering its link metric towards the | ||||
| R1-RN routers would influence the traffic from the core towards R1-RN | ||||
| but not the other way around as desired. | ||||
| In such a scenario, the AGGR1 router could signal an incremental OSPF | ||||
| reverse metric to some or all of the R1-RN routers. When the R1-RN | ||||
| routers add this signaled reverse metric offset to the provisioned | ||||
| metric on their links towards AGGR1, then the path via AGGR2 becomes | ||||
| a better path causing traffic towards the core to be diverted away | ||||
| from AGGR1. Note that the reverse metric mechanism allows such | ||||
| adaptive metric changes to be applied on the AGGR1 as opposed to | ||||
| being provisioned on a possibly large number of R1-RN routers. | ||||
| The reverse metric mechanism may also be similarly applied between | ||||
| spine and leaf nodes in a CLOS topology deployment. | ||||
| 3. Solution | 3. Solution | |||
| To address the use-cases described earlier and to allow an OSPF | To address the use cases described earlier and to allow an OSPF | |||
| router to indicate its reverse metric for a specific point-to-point | router to indicate its reverse metric for a specific link to its | |||
| or point-to-multipoint link to its neighbor, this document proposes | neighbor(s), this document proposes to extend OSPF link-local | |||
| to extend OSPF link-local signaling to advertise the Reverse Metric | signaling to signal the Reverse Metric TLV in OSPF Hello packets. | |||
| TLV in OSPF Hello packets. This ensures that the RM signaling is | This ensures that the RM signaling is scoped ONLY to each specific | |||
| scoped ONLY to each specific link individually. The router continues | link individually. The router continues to include the Reverse | |||
| to include the Reverse Metric TLV in its Hello packets on the link as | Metric TLV in its Hello packets on the link as long as it needs its | |||
| long as it needs its neighbor to use that metric value towards | neighbor to use that metric value towards itself. Further details of | |||
| itself. Further details of the procedures involve are specified in | the procedures involved are specified in Section 6. | |||
| Section 6. | ||||
| The RM signaling specified in this document is not required for | The reverse metric mechanism specified in this document applies only | |||
| broadcast or non-broadcast-multi-access (NBMA) links since the same | for point-to-point, point-to-multipoint, and hybrid broadcast point- | |||
| objective is achieved there using the OSPF Two-Part Metric mechanism | to-multipoint ( [RFC6845]) links. It is not applicable for broadcast | |||
| [RFC8042]. | or non-broadcast-multi-access (NBMA) links since the same objective | |||
| is achieved there using the OSPF Two-Part Metric mechanism [RFC8042] | ||||
| for OSPFv2. The OSPFv3 solution for broadcast or NBMA links is | ||||
| outside the scope of this document. | ||||
| 4. LLS Reverse Metric TLV | 4. LLS Reverse Metric TLV | |||
| The Reverse Metric TLV is a new LLS TLV. It has following format: | The Reverse Metric TLV is a new LLS TLV. It has following format: | |||
| 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 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | MTID | Flags |O|H| Reverse Metric | | | MTID | Flags |O|H| Reverse Metric | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| Type: 19 | Figure 2: Reverse Metric TLV | |||
| Type: 19 | ||||
| Length: 4 octet | Length: 4 octet | |||
| MTID : the multi-topology identifier of the link ([RFC4915]) | MTID : the multi-topology identifier of the link ([RFC4915]) | |||
| Flags: 1 octet, following are defined currently and the rest MUST | Flags: 1 octet, the following flags are defined currently and the | |||
| be set to 0 and ignored on reception. | rest MUST be set to 0 on transmission and ignored on reception. | |||
| * H (0x1) : Indicates that neighbor should use value only if | * H (0x1) : Indicates that the neighbor should use the value only | |||
| higher than its current metric value in use | if it is higher than its provisioned metric value for the link. | |||
| * O (0x2) : Indicates that the reverse metric value provided is | * O (0x2) : Indicates that the reverse metric value provided is | |||
| an offset that is to be added to the original metric | an offset that is to be added to the provisioned metric. | |||
| Reverse Metric: 2 octets, the value or offset of reverse metric to | Reverse Metric: 2 octets, the value or offset of reverse metric to | |||
| be used | replace or be added to the provisioned link metric. | |||
| 5. LLS Reverse TE Metric TLV | 5. LLS Reverse TE Metric TLV | |||
| The Reverse TE Metric TLV is a new LLS TLV. It has the following | The Reverse TE Metric TLV is a new LLS TLV. It has the following | |||
| format: | format: | |||
| 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 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Flags |O|H| RESERVED | | | Flags |O|H| RESERVED | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Reverse TE Metric | | | Reverse TE Metric | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| where: | where: | |||
| Figure 3: Reverse TE Metric TLV | ||||
| Type: 20 | Type: 20 | |||
| Length: 4 octet | Length: 4 octet | |||
| Flags: 1 octet, following are defined currently and the rest MUST | Flags: 1 octet, the following flags are defined currently and the | |||
| be set to 0 and ignored on reception. | rest MUST be set to 0 on transmission and ignored on reception. | |||
| * H (0x1) : Indicates that neighbor should use value only if | * H (0x1) : Indicates that the neighbor should use the value only | |||
| higher than its current TE metric value in use | if it is higher than its provisioned TE metric value for the | |||
| link. | ||||
| * O (0x2) : Indicates that the reverse TE metric value provided | * O (0x2) : Indicates that the reverse TE metric value provided | |||
| is an offset that is to be added to the original TE metric | is an offset that is to be added to the provisioned TE metric. | |||
| RESERVED: 24-bit field. SHOULD be set to 0 on transmission and | RESERVED: 24-bit field. SHOULD be set to 0 on transmission and | |||
| MUST be ignored on receipt. | MUST be ignored on receipt. | |||
| Reverse TE Metric: 4 octets, the value or offset of reverse | Reverse TE Metric: 4 octets, the value or offset of reverse | |||
| traffic engineering metric to be used | traffic engineering metric to replace or to be added to the | |||
| provisioned TE metric of the link. | ||||
| 6. Procedures | 6. Procedures | |||
| When a router needs to signal an RM value that its neighbor(s) should | When a router needs to signal an RM value that its neighbor(s) should | |||
| use towards itself, it includes the Reverse Metric TLV in the LLS | use for a link towards the router, it includes the Reverse Metric TLV | |||
| block of its hello messages sent on the link and continues to include | in the LLS block of its hello messages sent on that link and | |||
| this TLV for as long as it needs its neighbor to use this value. The | continues to include this TLV for as long as it needs its neighbor to | |||
| mechanisms used to determine the value to be used for the RM is | use this value. The mechanisms used to determine the value to be | |||
| specific to the implementation and use-case and is outside the scope | used for the RM is specific to the implementation and use case and is | |||
| of this document. e.g. in the use-case related to symmetric metric | outside the scope of this document. For example, the RM value may be | |||
| described in Section 2.1, the RM value may be derived based on the | derived based on the router's link bandwidth with respect to a | |||
| router's link's bandwidth with respect to the reference bandwidth. | reference bandwidth. | |||
| A router receiving a hello packet from its neighbor that contains the | A router receiving a hello packet from its neighbor that contains the | |||
| Reverse Metric TLV on its link SHOULD use the RM value to derive the | Reverse Metric TLV on a link SHOULD use the RM value to derive the | |||
| metric for the link in its Router-LSA to the advertising router. | metric for the link to the advertising router in its Router-LSA. | |||
| When the O flag is set, the metric value to be advertised is derived | ||||
| When the O flag is set, the value in the TLV needs to be added to the | by adding the value in the TLV to the provisioned metric for the | |||
| existing original metric provisioned on the link to derive the new | link. When the O flag is clear, the metric value to be advertised is | |||
| metric value to be used. When the O flag is clear, the value in the | derived directly from the value in the TLV. When the H flag is set | |||
| TLV should be directly used as the metric to be used. When the H | and the O flag is clear, the metric value to be advertised is derived | |||
| flag is set and the O flag is clear, this is done only when the RM | directly from the value in the TLV only when the RM value signaled is | |||
| value signaled is higher than the provisioned metric value being used | higher than the provisioned metric for the link. | |||
| already. This mechanism applies only for point-to-point, point-to- | ||||
| multipoint, and hybrid broadcast point-to-multipoint ( [RFC6845]) | ||||
| links. For broadcast and NBMA links the OSPF Two-Part Metric | ||||
| mechanism [RFC8042] should be used in similar use-cases. | ||||
| Implementations SHOULD provide a configuration option to enable the | ||||
| signaling of RM from a router to its neighbors and MAY provide a | ||||
| configuration option to disable the acceptance of the RM from its | ||||
| neighbors. | ||||
| A router stops including the Reverse Metric TLV in its hello messages | A router stops including the Reverse Metric TLV in its hello messages | |||
| when it needs its neighbors to go back to using their own provisioned | when it needs its neighbors to go back to using their own provisioned | |||
| metric values. When this happens, a router that had modified its | metric values. When this happens, a router that had modified its | |||
| metric in response to receiving a Reverse Metric TLV from its | metric in response to receiving a Reverse Metric TLV from its | |||
| neighbor should revert to using its original provisioned metric | neighbor should revert to using its provisioned metric value. | |||
| value. | ||||
| In certain scenarios, two or more routers may start the RM signaling | In certain scenarios, two or more routers may start the RM signaling | |||
| on the same link. This could create collision scenarios. The | on the same link. This could create collision scenarios. The | |||
| following rules MUST be adopted by routers to ensure that there is no | following rules MUST be adopted by routers to ensure that there is no | |||
| instability in the network due to churn in their metric due to | instability in the network due to churn in their metric due to | |||
| signaling of RM: | signaling of RM: | |||
| o The RM value that is signaled by a router to its neighbor MUST NOT | o The RM value that is signaled by a router to its neighbor MUST NOT | |||
| be derived from the reverse metric being signaled by any of its | be derived from the reverse metric being signaled by any of its | |||
| neighbor on any of its links. | neighbors on any of its links. | |||
| o The RM value that is signaled by a router MUST NOT be derived from | o The RM value that is signaled by a router MUST NOT be derived from | |||
| its metric which has been modified on account of an RM signaled | its metric which has been modified on account of an RM signaled | |||
| from any of its neighbors on any of its links. RM signaling from | from any of its neighbors on any of its links. RM signaling from | |||
| other routers can affect the router's metric advertised in its | other routers can affect the router's metric advertised in its | |||
| Router-LSA. When deriving the RM values that a router signals to | Router-LSA. When deriving the RM values that a router signals to | |||
| its neighbors, it should use its "original" local metric values | its neighbors, it should use its provisioned local metric values | |||
| not influenced by any RM signaling. | not influenced by any RM signaling. | |||
| Based on these rules, a router MUST never start or stop or change its | Based on these rules, a router MUST never start, stop, or change its | |||
| RM metric signaling based on the RM metric signaling initiated by | RM metric signaling based on the RM metric signaling initiated by | |||
| some other router. Based on the local configuration policy, each | some other router. Based on the local configuration policy, each | |||
| router would end up accepting the RM value signaled by its neighbor | router would end up accepting the RM value signaled by its neighbor | |||
| and there would be no churn of metrics on the link or the network on | and there would be no churn of metrics on the link or the network on | |||
| account of RM signaling. | account of RM signaling. | |||
| In certain use-case as described in Section 2.1 when symmetrical | In certain use cases when symmetrical metrics are desired (e.g., when | |||
| metrics are desired, the RM signaling can be enabled on routers on | metrics are derived based on link bandwidth), the RM signaling can be | |||
| either ends of a link. In other use-cases as described in | enabled on routers on either end of a link. In other use cases (as | |||
| Section 2.2 RM signaling may need to be enabled only on the router at | described in Section 2.1), RM signaling may need to be enabled only | |||
| one end of a link. | on the router at one end of a link. | |||
| When using multi-topology routing with OSPF [RFC4915] a router MAY | When using multi-topology routing with OSPF [RFC4915], a router MAY | |||
| include multiple instances of the Reverse Metric TLV in the LLS block | include multiple instances of the Reverse Metric TLV in the LLS block | |||
| of its hello message - one for each of the topology for which it | of its hello message - one for each of the topologies for which it | |||
| desires to signal the reserve metric for. | desires to signal the reserve metric. | |||
| In certain scenarios, the OSPF router may also require the | In certain scenarios, the OSPF router may also require the | |||
| modification of the TE metric being advertised by its neighbor router | modification of the TE metric being advertised by its neighbor router | |||
| towards itself in the inbound direction. The Reverse TE Metric TLV, | towards itself in the inbound direction. The Reverse TE Metric TLV, | |||
| using similar procedures as described above, MAY be used to signal | using similar procedures as described above, MAY be used to signal | |||
| the reverse TE metric by a router. The neighbor SHOULD use the | the reverse TE metric for router links. The neighbor SHOULD use the | |||
| reverse TE metric value to derive the TE metric to be used in the TE | reverse TE metric value to derive the TE metric advertised in the TE | |||
| Metric sub-TLV of the Link TLV in its TE Opaque LSA [RFC3630]. | Metric sub-TLV of the Link TLV in its TE Opaque LSA [RFC3630]. | |||
| 7. Backward Compatibility | 7. Operational Guidelines | |||
| The use of reverse metric signaling does not alter the OSPF metric | ||||
| parameters stored in a router's persistent provisioning database. | ||||
| If routers that receive a reverse metric advertisement send a syslog | ||||
| message, this will assist in rapidly identifying the node in the | ||||
| network that is advertising an OSPF metric or TE metric different | ||||
| from that which is configured locally on the device. | ||||
| When the link TE metric is raised to the maximum value, either due to | ||||
| the reverse metric mechanism or by explicit user configuration, this | ||||
| SHOULD immediately trigger the CSPF (Constrained Shortest Path First) | ||||
| recalculation to move the TE traffic away from that link. | ||||
| Implementations SHOULD provide a configuration option to enable the | ||||
| signaling of reverse metric from a router to its neighbors and are | ||||
| RECOMMENDED to provide a configuration option to disable the | ||||
| acceptance of the RM from its neighbors. | ||||
| If an implementation enables this mechanism by default, it is | ||||
| RECOMMENDED that it be disabled by the operators when not explicitly | ||||
| using it. | ||||
| For the use case in Section 2.1, a router SHOULD limit the period of | ||||
| advertising reverse metric towards a neighbor only for the duration | ||||
| of a network maintenance window. | ||||
| 8. Backward Compatibility | ||||
| The signaling specified in this document happens at a link-local | The signaling specified in this document happens at a link-local | |||
| level between routers on that link. A router that does not support | level between routers on that link. A router that does not support | |||
| this specification would ignore the Reverse Metric and Reverse TE | this specification would ignore the Reverse Metric and Reverse TE | |||
| Metric LLS TLVs and take no actions to updates its metric in the | Metric LLS TLVs and not update its metric(s) in the other LSAs. As a | |||
| other LSAs. As a result, the behavior would be the same as before | result, the behavior would be the same as prior to this | |||
| this specification. Therefore, there are no backward compatibility | specification. Therefore, there are no backward compatibility | |||
| related issues or considerations that need to be taken care of when | related issues or considerations that need to be taken care of when | |||
| implementing this specification. | implementing this specification. | |||
| 8. IANA Considerations | 9. IANA Considerations | |||
| This specification updates Link Local Signalling TLV Identifiers | This specification updates Link Local Signalling TLV Identifiers | |||
| registry. | registry. | |||
| Following values have been assigned via early allocation: | IANA is requested to make permanent the following code points that | |||
| have been assigned via early allocation | ||||
| o 19 - Reverse Metric TLV | o 19 - Reverse Metric TLV | |||
| o 20 - Reverse TE Metric TLV | o 20 - Reverse TE Metric TLV | |||
| 9. Security Considerations | 10. Security Considerations | |||
| The security considerations for "OSPF Link-Local Signaling" [RFC5613] | The security considerations for "OSPF Link-Local Signaling" [RFC5613] | |||
| also apply to the extension described in this document. The usage of | also apply to the extension described in this document. The usage of | |||
| the reverse metric TLVs is to alter the metrics used by routers on | the reverse metric TLVs is to alter the metrics used by routers on | |||
| the link and influence the flow and routing of traffic over the | the link and influence the flow and routing of traffic over the | |||
| network. Hence, modification of the Reverse Metric and Reverse TE | network. Hence, modification of the Reverse Metric and Reverse TE | |||
| Metric TLVs may result in misrouting of traffic. If authentication | Metric TLVs may result in misrouting of traffic. If authentication | |||
| is being used in the OSPF routing domain [RFC5709][RFC7474], then the | is being used in the OSPF routing domain [RFC5709][RFC7474], then the | |||
| Cryptographic Authentication TLV [RFC5613] SHOULD also be used to | Cryptographic Authentication TLV [RFC5613] SHOULD also be used to | |||
| protect the contents of the LLS block. | protect the contents of the LLS block. | |||
| Receiving a malformed LLS Reverse Metric or Reverse TE Metric TLVs | Receiving a malformed LLS Reverse Metric or Reverse TE Metric TLVs | |||
| MUST NOT result in a hard router or OSPF process failure. The | MUST NOT result in a hard router or OSPF process failure. The | |||
| reception of malformed LLS TLVs or sub-TLVs SHOULD be logged, but | reception of malformed LLS TLVs or sub-TLVs SHOULD be logged, but | |||
| such logging MUST be rate-limited to prevent denial-of-service (DoS) | such logging MUST be rate-limited to prevent denial-of-service (DoS) | |||
| attacks. | attacks. | |||
| 10. Contributors | 11. Contributors | |||
| Thanks to Jay Karthik for his contributions on the use-cases related | Thanks to Jay Karthik for his contributions to the use cases and the | |||
| to symmetric metric and the review of the solution. | review of the solution. | |||
| 11. Acknowledgements | 12. Acknowledgements | |||
| 12. References | The authors would like to thank Les Ginsberg, Aijun Wang, Gyan | |||
| Mishra, and Matthew Bocci for their review and feedback on this | ||||
| document. The authors would also like to thank Acee Lindem for this | ||||
| detailed shepherd's review and comments on this document. | ||||
| 12.1. Normative References | The document leverages the concept of Reverse Metric for IS-IS, its | |||
| related use cases, and applicability aspects from [RFC8500]. | ||||
| 13. References | ||||
| 13.1. Normative References | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, | |||
| DOI 10.17487/RFC2328, April 1998, | DOI 10.17487/RFC2328, April 1998, | |||
| <https://www.rfc-editor.org/info/rfc2328>. | <https://www.rfc-editor.org/info/rfc2328>. | |||
| skipping to change at page 11, line 5 ¶ | skipping to change at page 11, line 14 ¶ | |||
| [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. | [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. | |||
| Yeung, "OSPF Link-Local Signaling", RFC 5613, | Yeung, "OSPF Link-Local Signaling", RFC 5613, | |||
| DOI 10.17487/RFC5613, August 2009, | DOI 10.17487/RFC5613, August 2009, | |||
| <https://www.rfc-editor.org/info/rfc5613>. | <https://www.rfc-editor.org/info/rfc5613>. | |||
| [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
| 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| 12.2. Informative References | 13.2. Informative References | |||
| [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., | ||||
| Coltun, R., and F. Baker, "OSPF Version 2 Management | ||||
| Information Base", RFC 4750, DOI 10.17487/RFC4750, | ||||
| December 2006, <https://www.rfc-editor.org/info/rfc4750>. | ||||
| [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>. | |||
| [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., | [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., | |||
| Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic | Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic | |||
| Authentication", RFC 5709, DOI 10.17487/RFC5709, October | Authentication", RFC 5709, DOI 10.17487/RFC5709, October | |||
| 2009, <https://www.rfc-editor.org/info/rfc5709>. | 2009, <https://www.rfc-editor.org/info/rfc5709>. | |||
| skipping to change at page 11, line 36 ¶ | skipping to change at page 11, line 40 ¶ | |||
| [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., | [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., | |||
| "Security Extension for OSPFv2 When Using Manual Key | "Security Extension for OSPFv2 When Using Manual Key | |||
| Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, | Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, | |||
| <https://www.rfc-editor.org/info/rfc7474>. | <https://www.rfc-editor.org/info/rfc7474>. | |||
| [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>. | |||
| [RFC8500] Shen, N., Amante, S., and M. Abrahamsson, "IS-IS Routing | ||||
| with Reverse Metric", RFC 8500, DOI 10.17487/RFC8500, | ||||
| February 2019, <https://www.rfc-editor.org/info/rfc8500>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Ketan Talaulikar | Ketan Talaulikar | |||
| Cisco Systems, Inc. | Arrcus Inc | |||
| India | India | |||
| Email: ketant.ietf@gmail.com | Email: ketant.ietf@gmail.com | |||
| Peter Psenak | Peter Psenak | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| Apollo Business Center | Apollo Business Center | |||
| Mlynske nivy 43 | Mlynske nivy 43 | |||
| Bratislava 821 09 | Bratislava 821 09 | |||
| Slovakia | Slovakia | |||
| Email: ppsenak@cisco.com | Email: ppsenak@cisco.com | |||
| Hugh Johnston | Hugh Johnston | |||
| AT&T Labs | AT&T Labs | |||
| USA | USA | |||
| Email: hugh_johnston@labs.att.com | Email: hugh_johnston@labs.att.com | |||
| End of changes. 54 change blocks. | ||||
| 215 lines changed or deleted | 221 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/ | ||||