| < draft-ietf-ospf-ospfv2-hbit-08.txt | draft-ietf-ospf-ospfv2-hbit-09.txt > | |||
|---|---|---|---|---|
| OSPF K. Patel | OSPF K. Patel | |||
| Internet-Draft Arrcus | Internet-Draft Arrcus | |||
| Updates: 2328,6987 (if approved) P. Pillay-Esnault | Updates: 6987 (if approved) P. Pillay-Esnault | |||
| Intended status: Standards Track Futurewei | Intended status: Standards Track PPE Consulting | |||
| Expires: January 9, 2020 M. Bhardwaj | Expires: March 16, 2020 M. Bhardwaj | |||
| S. Bayraktar | S. Bayraktar | |||
| Cisco Systems | Cisco Systems | |||
| July 8, 2019 | September 13, 2019 | |||
| Host Router Support for OSPFv2 | Host Router Support for OSPFv2 | |||
| draft-ietf-ospf-ospfv2-hbit-08 | draft-ietf-ospf-ospfv2-hbit-09 | |||
| Abstract | Abstract | |||
| The OSPFv2 specifies an SPF algorithm that identifies transit | The Open Shortest Path First Version 2 (OSPFv2) does not have a | |||
| vertices based on their adjacencies. Therefore, OSPFv2 does not have | mechanism for a node to repel transit traffic if it is on the | |||
| a mechanism to prevent traffic transiting a participating node if it | shortest path. This document assigns a new bit (Host-bit) in the | |||
| is a transit vertex in the only existing or shortest path to the | OSPF Router-LSA bit registry and in the OSPF Router Informational | |||
| destination. The use of metrics to make the node undesirable can | Capability Bits Registry that enables a host router to advertise that | |||
| only help to repel traffic if an alternative better route exists. | it is a non-transit router. It also describes the changes needed to | |||
| This document defines the Host-bit functionality to prevent other | support the Host-bit in the domain. In addition, this document | |||
| OSPFv2 routers from using the router for transit traffic in OSPFv2 | updates OSPF Stub Router Advertisement (RFC6987) to advertise for | |||
| routing domains. This document updates the Open Shortest Path First | type-2 External and NSSA LSAs with a high cost in order to repel | |||
| v2 specification (OSPFv2 rfc2328) by assigning a new bit (Host-bit) | traffic effectively. | |||
| in the OSPF Router-LSA bit registry. In addition, if the Host-bit is | ||||
| set, the calculation of the shortest-path tree for an area, as | ||||
| described in OSPFv2, is modified by including a new check to verify | ||||
| that transit vertices have the Host-bit clear. In addition, this | ||||
| document updates OSPF Stub Router Advertisement (rfc6987) to | ||||
| advertise for type-2 External and NSSA 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 January 9, 2020. | ||||
| This Internet-Draft will expire on March 16, 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 39 ¶ | skipping to change at page 2, line 33 ¶ | |||
| 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 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 an SPF algorithm that identifies transit | The OSPFv2 specifies a Shortest Path First (SPF) algorithm that | |||
| vertices based on their adjacencies. Therefore, OSPFv2 does not have | identifies transit vertices based on their adjacencies. Therefore, | |||
| a mechanism to prevent traffic transiting a participating node if it | OSPFv2 does not have a mechanism to prevent traffic transiting a | |||
| is a transit vertex in the only existing or shortest path to the | participating node if it is a transit vertex in the only existing or | |||
| destination. The use of metrics to make the node undesirable can | shortest path to the destination. The use of metrics to make the | |||
| only help to repel traffic if an alternative better route exists. | node undesirable can help to repel traffic only if an alternative | |||
| 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 isolate a router to avoid blackhole scenarios when there is a | |||
| reload and possible long reconvergence times. | 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 reachbility | 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 defines the Host-bit (H-Bit)functionality to prevent | This document describes the Host-bit (H-Bit)functionality that | |||
| other OSPFv2 routers from using the router for transit traffic in | prevents other OSPFv2 routers from using the router for transit | |||
| OSPFv2 routing domains. This document updates the [RFC2328] by - | traffic in OSPFv2 routing domains. This document defines the Host- | |||
| assigning the Host-bit in the OSPFv2 Router Properties Registry - if | bit in the OSPFv2 Router Properties Registry and if the host-bit is | |||
| the host-bit is set then the calculation of the shortest-path tree | set then the calculation of the shortest-path tree for an area, as | |||
| for an area, as described in section 16.1 of [RFC2328], is modified | described in section 16.1 of [RFC2328], is modified by including a | |||
| by including a new check to verify that transit vertices DO NOT have | new check to verify that transit vertices DO NOT have the host-bit | |||
| the host-bit set. | set. | |||
| 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 | |||
| This document defines a new router-LSA bit known as the Host Bit or | This document defines a new router-LSA bit known as the Host Bit or | |||
| the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit | the H-bit. An OSPFv2 router advertising a router-LSA with the H-bit | |||
| set indicates to other OSPFv2 routers in the area supporting the | set indicates that it MUST NOT be used as a transit router (see | |||
| functionality that it MUST NOT be used as a transit router (see | section 4) by other OSPFv2 routers in the area supporting the | |||
| section 4). | functionality. | |||
| If the host-bit is NOT set routers MUST act transit routers as | If the host-bit is NOT set routers MUST act transit routers as | |||
| described in [RFC2328] ensuring backward compatibility. | described in [RFC2328] ensuring backward compatibility. | |||
| 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 | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | LS age | Options | 1 | | | LS age | Options | 1 | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link State ID | | | Link State ID | | |||
| skipping to change at page 4, line 36 ¶ | skipping to change at page 4, line 36 ¶ | |||
| | ... | | | ... | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | TOS | 0 | TOS metric | | | TOS | 0 | TOS metric | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link ID | | | Link ID | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | Link Data | | | Link Data | | |||
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | ... | | | ... | | |||
| Host Bit in router-LSA | Figure 1 | |||
| Host Bit in Router-LSA | ||||
| 0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| |H|0|0|N|W|V|E|B| | |H|0|0|N|W|V|E|B| | |||
| +-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| Host Bit | Host Bit | |||
| Bit H is the high-order bit of the OSPF as shown above. When set, an | Bit H is the high-order bit of the OSPF as shown above. When set, an | |||
| OSPFv2 router is a Host (non-transit) router and is incapable of | OSPFv2 router is a Host (non-transit) router and is incapable of | |||
| forwarding transit traffic. | forwarding transit traffic. In this mode, the other OSPFv2 routers | |||
| in the area MUST NOT use the host router for transit traffic, but use | ||||
| the host router only for its local destinations. | ||||
| An OSPFv2 router originating a router-LSA with the H-bit set MUST | An OSPFv2 router originating a router-LSA with the H-bit set MUST | |||
| advertise all its router links with a link cost of MaxLinkMetric | advertise all its router links with a link cost of MaxLinkMetric | |||
| [RFC6987]. This is to increase the applicability of the H-bit to | [RFC6987]. This is to increase the applicability of the H-bit to | |||
| partial deployments where it is the responsibility of the operator to | partial deployments where it is the responsibility of the operator to | |||
| ensure that OSPFv2 routers not supporting the H-bit do not install | ensure that OSPFv2 routers not supporting the H-bit do not install | |||
| routes causing routing loops. | routes causing routing loops. | |||
| When the H-bit is set, an Area Border Router (ABR) MUST advertise the | When the H-bit is set, an Area Border Router (ABR) MUST advertise the | |||
| same H-bit setting in its self-originated router-LSAs for all | same H-bit setting in its self-originated router-LSAs for all | |||
| attached areas. The consistency of the setting will prevent inter- | attached areas. The consistency of the setting will prevent inter- | |||
| area traffic transiting through the router by suppressing the | area traffic transiting through the router by suppressing | |||
| suppressing advertisement of prefixes from other routers in the area | advertisement of prefixes from other routers in the area in its | |||
| in its summary LSAs. ONLY IPv4 prefixes associated with its local | summary LSAs. Only IPv4 prefixes associated with its local | |||
| interfaces MAY be advertised in summary LSAs to provide reachability | interfaces MUST be advertised in summary LSAs to provide reachability | |||
| to end hosts attached behind a router with the H-bit set. | to end hosts attached behind a router with the H-bit set. | |||
| When the H-bit is set cannot act as an AS Boundary Router (ASBR), as | When the H-bit is set the host router cannot act as an AS Boundary | |||
| ASBR are transit routers to prefixes that are typically imported | Router (ASBR). Indeed, ASBR are transit routers to prefixes that are | |||
| through redistribution of prefixes of other routing protocols. | typically imported through redistribution of prefixes of other | |||
| Therefore, non-local IPv4 prefixes, e.g., those exported from other | routing protocols. Therefore, non-local IPv4 prefixes, e.g., those | |||
| routing protocols, MUST NOT be advertised in AS-external-LSAs for | exported from other routing protocols, MUST NOT be advertised in AS- | |||
| routers acting permanly as a host. However, in use cases such as an | external-LSAs for routers acting permanently as a host. However, in | |||
| overloaded router or a router being gracefully isolated, these | use cases such as an overloaded router or a router being gracefully | |||
| routers are only temporarily acting as host routers and therefore | isolated, these routers are only temporarily acting as host routers | |||
| should continue to advertise their External LSAs but ensure they do | and therefore SHOULD continue to advertise their External LSAs but | |||
| not attract traffic. In addition to the procedure described above, | ensure that they do not attract traffic. In addition to the | |||
| temporary host routers advertising type 2-metric External LSAs MUST | procedure described above, temporary host routers advertising type | |||
| set the metrics to LSInfinity to repel traffic.(see Section 6 of this | 2-metric External LSAs MUST set the metrics to LSInfinity to repel | |||
| document). | 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. Step 2 is modified | |||
| as follows: | as follows: | |||
| 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 | |||
| skipping to change at page 6, line 28 ¶ | skipping to change at page 6, line 28 ¶ | |||
| TransitCapability to TRUE. In any case, | TransitCapability to TRUE. In any case, | |||
| each link described by the LSA gives | each link described by the LSA gives | |||
| the cost to an adjacent vertex. For | the cost to an adjacent vertex. For | |||
| each described link, (say it joins | each described link, (say it joins | |||
| vertex V to vertex W): | vertex V to vertex W): | |||
| 5. Auto Discovery and Backward Compatibility | 5. Auto Discovery and Backward Compatibility | |||
| To avoid the possibility of any routing loops due to partial | To avoid the possibility of any routing loops due to partial | |||
| deployment, this document defines a OSPF Router Information (RI) LSA | deployment, this document defines a OSPF Router Information (RI) LSA | |||
| [RFC7770] with and area flooding scope and a new bit assigned in the | [RFC7770] with and an area flooding scope and a new bit assigned in | |||
| OSPF Router Informational Capability Bits Registry. Bit: | the OSPF Router Informational Capability Bits Registry. Bit: | |||
| Bit Capabilities | Bit Capabilities | |||
| 7 Host Router Support capability | 7 Host Router Support capability | |||
| Auto Discovery via announcement of the Host Support Functional | Auto Discovery via announcement of the Host Support Functional | |||
| Capability ensures that the H-bit functionality and its associated | Capability ensures that the H-bit functionality and its associated | |||
| SPF changes MUST only take effect if all the routers in a given OSPF | SPF changes MUST only take effect if all the routers in a given OSPF | |||
| area support this functionality. | area support this functionality. | |||
| In normal operations, there is no guarantee that the RI LSA will | In normal operations, there is no guarantee that the RI LSA will | |||
| reach all routers in an area in a timely manner which may result in | reach all routers in an area in a timely manner that may result in | |||
| rooting loops in partial deployments. For example, in a new router | rooting loops in partial deployments. For example, in a new router | |||
| joins an area which previous had only H-bit capable routers with | joins an area which previous had only H-bit capable routers with | |||
| H-bit set then it may take some time for the RI to propagate to all | H-bit set then it may take some time for the RI to propagate to all | |||
| routers. | routers. | |||
| 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 | |||
| skipping to change at page 8, line 19 ¶ | skipping to change at page 8, line 19 ¶ | |||
| 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 except for its local | restricts the use of a router for transit except for its local | |||
| destinations. This is a subset of the operations of a normal router | destinations. This is a subset of the operations of a normal router | |||
| and therefore should not introduce new security considerations beyond | and therefore should not introduce new security considerations beyond | |||
| those already known in OSPF. The feature however does introduce the | those already known in OSPF. The feature, however does introduce the | |||
| flooding of a capability information that allows discovery and | flooding of a capability information that allows discovery and | |||
| verification that all routers in an area are capable before turning | verification that all routers in an area are capable before turning | |||
| on the feature. In case. a rogue or buggy router advertise | on the feature. In the event that a rogue or buggy router advertises | |||
| incorrectly its capability there are two possible cases: | incorrectly its capability there are two possible cases: | |||
| o The router does not have the capability but send H-Bit set in its | o The router does not have the capability but sends H-Bit set in its | |||
| LSAs: In this case, there is a possibility of a routing loop. | 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 of this router | avoided anyway. Moreover, the link metrics cost (MaxLinkMetric) | |||
| should be MaxLinkMetric and will mitigate this situation. In any | of this router will mitigate this situation. In any case, a | |||
| case a router advertising the H-bit capability without its links | router advertising the H-bit capability without its links cost | |||
| cost equal to MaxLinkMetric may be an indicator that this is a | equal to MaxLinkMetric may be an indicator that this is a rogue | |||
| rogue router. | router and to 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. | |||
| 9. Acknowledgements | 9. Acknowledgements | |||
| skipping to change at page 9, line 15 ¶ | skipping to change at page 9, line 15 ¶ | |||
| [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>. | |||
| [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. | ||||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | ||||
| DOI 10.17487/RFC6987, September 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6987>. | ||||
| [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and | [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and | |||
| S. Shaffer, "Extensions to OSPF for Advertising Optional | S. Shaffer, "Extensions to OSPF for Advertising Optional | |||
| Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, | Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, | |||
| February 2016, <https://www.rfc-editor.org/info/rfc7770>. | February 2016, <https://www.rfc-editor.org/info/rfc7770>. | |||
| [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>. | |||
| 10.2. Informative References | 10.2. Informative References | |||
| [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-18 (work in | ietf-idr-bgp-optimal-route-reflection-19 (work in | |||
| progress), April 2019. | progress), July 2019. | |||
| [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. | ||||
| McPherson, "OSPF Stub Router Advertisement", RFC 6987, | ||||
| DOI 10.17487/RFC6987, September 2013, | ||||
| <https://www.rfc-editor.org/info/rfc6987>. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Keyur Patel | Keyur Patel | |||
| Arrcus | Arrcus | |||
| Email: keyur@arrcus.com | Email: keyur@arrcus.com | |||
| Padma Pillay-Esnault | Padma Pillay-Esnault | |||
| Futurewei | PPE Consulting | |||
| 2330 Central Expressway | ||||
| Santa Clara, CA 95050 | ||||
| USA | ||||
| 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 | |||
| End of changes. 22 change blocks. | ||||
| 82 lines changed or deleted | 78 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/ | ||||