draft-ietf-ospf-ospfv2-hbit-11.txt   draft-ietf-ospf-ospfv2-hbit-12.txt 
OSPF K. Patel OSPF K. Patel
Internet-Draft Arrcus Internet-Draft Arrcus
Updates: 6987 (if approved) P. Pillay-Esnault Updates: 6987 (if approved) P. Pillay-Esnault
Intended status: Standards Track PPE Consulting Intended status: Standards Track PPE Consulting
Expires: May 19, 2020 M. Bhardwaj Expires: June 20, 2020 M. Bhardwaj
S. Bayraktar S. Bayraktar
Cisco Systems Cisco Systems
November 16, 2019 December 18, 2019
Host Router Support for OSPFv2 Host Router Support for OSPFv2
draft-ietf-ospf-ospfv2-hbit-11 draft-ietf-ospf-ospfv2-hbit-12
Abstract Abstract
The Open Shortest Path First Version 2 (OSPFv2) does not have a The Open Shortest Path First Version 2 (OSPFv2) protocol does not
mechanism for a node to repel transit traffic if it is on the have a mechanism for a node to repel transit traffic if it is on the
shortest path. This document defines a bit (Host-bit) that enables a shortest path. This document defines a bit (Host-bit) that enables a
router to advertise that it is a non-transit router. It also router to advertise that it is a non-transit router. It also
describes the changes needed to support the H-bit in the domain. In describes the changes needed to support the H-bit in the domain. In
addition, this document updates RFC 6987 to advertise type-2 External addition, this document updates RFC 6987 to advertise type-2 External
and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a
high cost in order to repel traffic effectively. high cost in order to repel traffic effectively.
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 1, line 41 skipping to change at page 1, line 41
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 May 19, 2020. This Internet-Draft will expire on June 20, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 30 skipping to change at page 2, line 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The OSPFv2 specifies a Shortest Path First (SPF) algorithm that The OSPFv2 protocol specifies a Shortest Path First (SPF) algorithm
identifies transit vertices based on their adjacencies. Therefore, that identifies transit vertices based on their adjacencies.
OSPFv2 does not have a mechanism to prevent traffic transiting a Therefore, OSPFv2 does not have a mechanism to prevent traffic
participating node if it is a transit vertex in the only existing or transiting a participating node if it is a transit vertex in the only
shortest path to the destination. The use of metrics to make the existing or shortest path to the destination. The use of metrics to
node undesirable can help to repel traffic only if an alternative make the node undesirable can help to repel traffic only if an
better route exists. alternative better route exists.
This functionality is particularly useful for a number of use cases: A mechanism to move traffic away from the shortest path is
particularly useful for a number of use cases:
1. To gracefully isolate a router to avoid blackhole scenarios when 1. To gracefully isolate a router to avoid blackhole scenarios when
there is a reload and possible long reconvergence times. there is a reload and possible long reconvergence times.
2. Closet Switches are usually not used for transit traffic but need 2. Closet Switches are usually not used for transit traffic but need
to participate in the topology. to participate in the topology.
3. Overloaded routers could use such a capability to temporarily 3. Overloaded routers could use such a capability to temporarily
repel traffic until they stabilize. repel traffic until they stabilize.
skipping to change at page 5, line 33 skipping to change at page 5, line 33
AS-external-LSAs if the H-bit is set. Some use cases, such as an AS-external-LSAs if the H-bit is set. Some use cases, such as an
overloaded router or a router being gracefully isolated, may benefit overloaded router or a router being gracefully isolated, may benefit
from continued advertisement of non-local prefixes. In these cases, from continued advertisement of non-local prefixes. In these cases,
the type 2-metric in AS-external-LSAs MUST be set to LSInfinity to the type 2-metric in AS-external-LSAs MUST be set to LSInfinity to
repel traffic.(see Section 6 of this document). repel traffic.(see Section 6 of this document).
4. SPF Modifications 4. SPF Modifications
The SPF calculation described in section 16.1 [RFC2328] will be The SPF calculation described in section 16.1 [RFC2328] will be
modified to ensure that the routers originating router-LSAs with the modified to ensure that the routers originating router-LSAs with the
H-bit set will not be used for transit traffic. Step 2 is modified H-bit set will not be used for transit traffic. The Step 2 is
as follows: modified to include a check on H-bit as shown below. (Please note
all the sub-procedures of Step 2 remain unchanged and not included in
the excerpt below.)
2) Call the vertex just added to the 2) Call the vertex just added to the
tree vertex V. Examine the LSA tree vertex V. Examine the LSA
associated with vertex V. This is associated with vertex V. This is
a lookup in the Area A's link state a lookup in the Area A's link state
database based on the Vertex ID. If database based on the Vertex ID. If
this is a router-LSA, and the H-bit this is a router-LSA, and the H-bit
of the router-LSA is set, and of the router-LSA is set, and
vertex V is not the root, then the vertex V is not the root, then the
router should not be used for transit router should not be used for transit
and step (3) should be executed and step (3) should be executed
skipping to change at page 6, line 41 skipping to change at page 6, line 40
7 Host Router Support capability 7 Host Router Support capability
Table 1: OSPF Router Information LSA Capabilities Table 1: OSPF Router Information LSA Capabilities
Auto Discovery via announcement of the Host Router Support Capability Auto Discovery via announcement of the Host Router Support Capability
ensures that the H-bit functionality and its associated SPF changes ensures that the H-bit functionality and its associated SPF changes
MUST only take effect if all the routers in a given OSPF area support MUST only take effect if all the routers in a given OSPF area support
this functionality. this functionality.
In normal operation, there is no guarantee that the RI LSA will reach In normal operation, it is possible that the RI LSA will fail to
all routers in an area in a timely manner, which may result in reach all routers in an area in a timely manner. For example, if a
forwarding loops in partial deployments. For example, if a new new router without H-bit support joins an area that previously had
router joins an area, which previously had only H-bit capable routers only H-bit capable routers with H-bit set then it may take some time
with H-bit set then it may take some time for the RI to propagate to for the RI to propagate to all routers. While it is propagating, the
all routers. routers in the area will gradually detect the presence of a router
not supporting the capability and revert back to normal SPF
calculation. During the propagation time, the area as a whole is
unsure of the status of the new router, and that can cause temporary
transient loops.
The following recommendations will mitigate transient routing loops: The following recommendations will mitigate transient routing loops:
o Implementations are RECOMMENDED to provide a configuration o Implementations are RECOMMENDED to provide a configuration
parameter to manually override enforcement of the H-bit parameter to manually override enforcement of the H-bit
functionality in partial deployments where the topology guarantees functionality in partial deployments where the topology guarantees
that OSPFv2 routers not supporting the H-bit do not compute routes that OSPFv2 routers not supporting the H-bit do not compute routes
resulting in routing loops. resulting in routing loops.
o All routers, with the H-bit set, MUST advertise all of the o All routers with the H-bit set MUST advertise all of the router's
router's non-stub links with a metric equal to MaxLinkMetric non-stub links with a metric equal to MaxLinkMetric [RFC6987] in
[RFC6987] in its LSAs in order to avoid OSPFv2 (unless last its LSAs in order to avoid OSPFv2 (unless last resort) routers not
resort) routers not supporting the H-bit from attempting to use it supporting the H-bit from attempting to use it for transit
for transit traffic. traffic.
o All routers supporting H-Bit MUST check all the RI LSAs of nodes o All routers supporting the H-Bit MUST check the RI LSAs of all
in the area before actively running the modified SPF to account nodes in the area to verify that all nodes support the H-Bit
for the H-bit in order to verify that all routers are in routing before actively using the H-Bit feature. If any router does not
capability. If any router does not advertise the Host Router advertise the Host Router Support capability then the SPF
Support capability then the SPF Modifications (Section 4) MUST NOT Modifications (Section 4) MUST NOT be used in the area.
be used in the area.
6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics
When calculating the path to an OSPF AS-External-LSA or NSSA-LSA When calculating the path to a prefix in an OSPF AS-External-LSA or
[RFC3101] with a Type-2 metric, the advertised Type-2 metric is taken NSSA-LSA [RFC3101] with a Type-2 metric, the advertised Type-2 metric
as more significant than the OSPF intra-area or inter-area path. is taken as more significant than the OSPF intra-area or inter-area
Hence, advertising the links with MaxLinkMetric as specified in path. Hence, advertising the links with MaxLinkMetric as specified
[RFC6987] does not discourage transit traffic when calculating AS in [RFC6987] does not discourage transit traffic when calculating AS
external or NSSA routes with Type-2 metrics. external or NSSA routes with Type-2 metrics.
Consequently, [RFC6987] is updated so that the Type-2 metric in any Consequently, [RFC6987] is updated so that the Type-2 metric in any
self-originated AS-External-LSAs or NSSA-LSAs is advertised as self-originated AS-External-LSAs or NSSA-LSAs is advertised as
LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric LSInfinity-1 [RFC2328]. If the H-bit is set, then the Type-2 metric
MUST be set to LSInfinity. MUST be set to LSInfinity.
7. IANA Considerations 7. IANA Considerations
This document requests the IANA to assign the 0x80 value to the Host- This document requests the IANA to assign the 0x80 value to the Host-
 End of changes. 12 change blocks. 
39 lines changed or deleted 44 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/