draft-ietf-ospf-ospfv2-hbit-10.txt   draft-ietf-ospf-ospfv2-hbit-11.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: April 26, 2020 M. Bhardwaj Expires: May 19, 2020 M. Bhardwaj
S. Bayraktar S. Bayraktar
Cisco Systems Cisco Systems
October 24, 2019 November 16, 2019
Host Router Support for OSPFv2 Host Router Support for OSPFv2
draft-ietf-ospf-ospfv2-hbit-10 draft-ietf-ospf-ospfv2-hbit-11
Abstract Abstract
The Open Shortest Path First Version 2 (OSPFv2) does not have a The Open Shortest Path First Version 2 (OSPFv2) does not have a
mechanism for a node to repel transit traffic if it is on the 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 NSSA LSAs with a high cost in order to repel traffic effectively. and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a
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
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 26, 2020. This Internet-Draft will expire on May 19, 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 22 skipping to change at page 2, line 23
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Host-bit Support . . . . . . . . . . . . . . . . . . . . . . 3 3. Host-bit Support . . . . . . . . . . . . . . . . . . . . . . 3
4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5 4. SPF Modifications . . . . . . . . . . . . . . . . . . . . . . 5
5. Auto Discovery and Backward Compatibility . . . . . . . . . . 6 5. Auto Discovery and Backward Compatibility . . . . . . . . . . 6
6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics . . . . . 7 6. OSPF AS-External-LSAs/NSSA LSAs with Type 2 Metrics . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 8 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 specifies a Shortest Path First (SPF) algorithm that
identifies transit vertices based on their adjacencies. Therefore, identifies transit vertices based on their adjacencies. Therefore,
OSPFv2 does not have a mechanism to prevent traffic transiting a OSPFv2 does not have a mechanism to prevent traffic transiting a
participating node if it is a transit vertex in the only existing or participating node if it is a transit vertex in the only existing or
shortest path to the destination. The use of metrics to make the shortest path to the destination. The use of metrics to make the
node undesirable can help to repel traffic only if an alternative node undesirable can help to repel traffic only if an alternative
better route exists. better route exists.
This functionality is particularly useful for a number of use cases: This functionality is particularly useful for a number of use cases:
1. To isolate a router to avoid blackhole scenarios when there is a 1. To gracefully isolate a router to avoid blackhole scenarios when
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.
4. BGP Route reflectors known as virtual Route Reflectors (vRRs), 4. BGP Route reflectors known as virtual Route Reflectors (vRRs),
that are not in the forwarding path but are in central locations that are not in the forwarding path but are in central locations
such as data centers. Such Route Reflectors typically are used such as data centers. Such Route Reflectors typically are used
for route distribution and are not capable of forwarding transit for route distribution and are not capable of forwarding transit
traffic. However, they need to learn the OSPF topology to traffic. However, they need to learn the OSPF topology to
perform SPF computation for optimal routes and reachability perform SPF computation for optimal routes and reachability
resolution for its clients resolution for its clients
[I-D.ietf-idr-bgp-optimal-route-reflection]. [I-D.ietf-idr-bgp-optimal-route-reflection].
This document describes the Host-bit (H-bit) functionality that This document describes the Host-bit (H-bit) functionality that
prevents other OSPFv2 routers from using the host router for transit prevents other OSPFv2 routers from using the host router by excluding
traffic in OSPFv2 routing domains. If the H-bit is set then the it in path calculations for transit traffic in OSPFv2 routing
calculation of the shortest-path tree for an area, as described in domains. If the H-bit is set then the calculation of the shortest-
section 16.1 of [RFC2328], is modified by including a check to verify path tree for an area, as described in section 16.1 of [RFC2328], is
that transit vertices DO NOT have the H-bit set (see Section 4). modified by including a check to verify that transit vertices DO NOT
Furthermore, in order to repel traffic effectively, [RFC6987] is have the H-bit set (see Section 4). Furthermore, in order to repel
updated so that type-2 External and NSSA LSAs are advertised with a traffic effectively, [RFC6987] is updated so that type-2 External and
high cost (see Section 6). NSSA LSAs are advertised with a high cost (see Section 6). Open
Shortest Path First Version 3 defines an option bit for router-LSAs
known as the R-bit in [RFC5340] to support a similar functionality.
2. Requirements Language 2. 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.
3. Host-bit Support 3. Host-bit Support
skipping to change at page 8, line 15 skipping to change at page 8, line 15
Bit Number Capability Name Reference Bit Number Capability Name Reference
7 OSPF Host Router This Document 7 OSPF Host Router This Document
8. Security Considerations 8. Security Considerations
This document introduces the H-bit which is a capability that This document introduces the H-bit which is a capability that
restricts the use of a router for transit, while only its local restricts the use of a router for transit, while only its local
destinations are reachable. This is a subset of the operations of a destinations are reachable. This is a subset of the operations of a
normal router and therefore should not introduce new security normal router and therefore should not introduce new security
considerations beyond those already known in OSPF [RFC2328]. The considerations beyond those already known in OSPFv2 [RFC2328]. The
feature, however does introduce the flooding of a capability feature introduces the advertising of a host router capability
information that allows discovery and verification that all routers information to all OSPFv2 routers in an area. This information can
in an area are capable before turning on the feature. In the event be leveraged for discovery and verification that all routers in the
that a rogue or buggy router advertises incorrectly its capability area support the capability before the feature is turned on. In the
there are two possible cases: event that a rogue or buggy router advertises incorrectly its
capability the possible cases are:
o The router does not have the capability but sends the H-Bit set in o The router does not have the capability but sends the H-Bit set in
its LSAs: In this case, there is a possibility of a routing loop. its LSAs: In this case, there is a possibility of a routing loop.
However this is mitigated by the fact that this router should be However this is mitigated by the fact that this router should be
avoided anyway. Moreover, the link metrics cost (MaxLinkMetric) avoided anyway. Moreover, the link metrics cost (MaxLinkMetric)
of this router will mitigate this situation. In any case, a of this router will mitigate this situation. In any case, a
router advertising the H-bit capability without its links cost router advertising the H-bit capability without its links cost
equal to MaxLinkMetric may be an indicator that this is a rogue equal to MaxLinkMetric may be an indicator that this is a rogue
router and should be avoided. router and should be avoided.
o The router has the capability but sends the H-Bit clear in its o The router has the capability but sends the H-Bit clear in its
LSAs: In this case, the router merely prevents support of other LSAs: In this case, the router merely prevents support of other
H-bit routers in the area and all the routers to run the modified H-bit routers in the area and all the routers to run the modified
SPF. The impact is also mitigated as other H-Bit routers in the SPF. The impact is also mitigated as other H-Bit routers in the
area also advertise MaxLinkMetric cost so they will still be area also advertise MaxLinkMetric cost so they will still be
avoided unless they are the last resort path. avoided unless they are the last resort path.
o The rogue router is on the only transit path for some destinations
and sends the H-Bit set (for no good/valid reason) in its LSAs and
effectively partition the network. This case is indistinguishable
from the normal case where the operator may consciously decide to
set the H-bit to perform maintenance on a router that is on the
only transit path. The OSPF protocol will continue to function
within the partitioned domains.
9. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge Hasmit Grover for discovery of The authors would like to acknowledge Hasmit Grover for discovery of
the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward, the limitation in [RFC6987], Acee Lindem, Abhay Roy, David Ward,
Burjiz Pithawala and Michael Barnes for their comments. Burjiz Pithawala, and Michael Barnes for their comments.
10. References 10. References
10.1. Normative References 10.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>.
skipping to change at page 9, line 35 skipping to change at page 9, line 44
[I-D.ietf-idr-bgp-optimal-route-reflection] [I-D.ietf-idr-bgp-optimal-route-reflection]
Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K. Raszuk, R., Cassar, C., Aman, E., Decraene, B., and K.
Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft- Wang, "BGP Optimal Route Reflection (BGP-ORR)", draft-
ietf-idr-bgp-optimal-route-reflection-19 (work in ietf-idr-bgp-optimal-route-reflection-19 (work in
progress), July 2019. progress), July 2019.
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, DOI 10.17487/RFC3101, January 2003, RFC 3101, DOI 10.17487/RFC3101, January 2003,
<https://www.rfc-editor.org/info/rfc3101>. <https://www.rfc-editor.org/info/rfc3101>.
Authors' Addresses [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
Authors' Addresses
Keyur Patel Keyur Patel
Arrcus Arrcus
Email: keyur@arrcus.com Email: keyur@arrcus.com
Padma Pillay-Esnault Padma Pillay-Esnault
PPE Consulting PPE Consulting
Email: padma.ietf@gmail.com Email: padma.ietf@gmail.com
Manish Bhardwaj Manish Bhardwaj
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: manbhard@cisco.com Email: manbhard@cisco.com
Serpil Bayraktar Serpil Bayraktar
Cisco Systems Cisco Systems
 End of changes. 15 change blocks. 
26 lines changed or deleted 42 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/