| < draft-ppsenak-lsr-igp-pfx-reach-loss-00.txt | draft-ppsenak-lsr-igp-ureach-prefix-announce-00.txt > | |||
|---|---|---|---|---|
| Networking Working Group P. Psenak, Ed. | Networking Working Group P. Psenak, Ed. | |||
| Internet-Draft L. Ginsberg | Internet-Draft C. Filsfils | |||
| Intended status: Informational Cisco Systems | Intended status: Informational S. Litkowski | |||
| Expires: 8 September 2022 D. Voyer | Expires: September 26, 2022 Cisco Systems | |||
| D. Voyer | ||||
| Bell Canada | Bell Canada | |||
| 7 March 2022 | A. Dhamija | |||
| Rakuten | ||||
| March 25, 2022 | ||||
| IGP Prefix Reachability Loss Anouncement | IGP Unreachable Prefix Announcement | |||
| draft-ppsenak-lsr-igp-pfx-reach-loss-00 | draft-ppsenak-lsr-igp-ureach-prefix-announce-00 | |||
| Abstract | Abstract | |||
| In the presence of summarization, there is a need to signal loss of | In the presence of summarization, there is a need to signal loss of | |||
| reachability to an individual prefix covered by the summary in order | reachability to an individual prefix covered by the summary in order | |||
| to enable fast convergence away from paths to the node which owns the | to enable fast convergence away from paths to the node which owns the | |||
| prefix which is no longer reachable. This document describes how to | prefix which is no longer reachable. This document describes how to | |||
| use existing protocol mechanisms in IS-IS and OSPF to advertise such | use existing protocol mechanisms in IS-IS and OSPF to advertise such | |||
| prefix reachability loss. | prefix reachability loss. | |||
| skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 48 ¶ | |||
| 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 8 September 2022. | This Internet-Draft will expire on September 26, 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2022 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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
| license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
| Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
| and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
| extracted from this document must include Revised BSD License text as | to this document. Code Components extracted from this document must | |||
| described in Section 4.e of the Trust Legal Provisions and are | include Simplified BSD License text as described in Section 4.e of | |||
| provided without warranty as described in the Revised BSD License. | the Trust Legal Provisions and are provided without warranty as | |||
| described in the Simplified BSD License. | ||||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Supporting PRLA in IS-IS . . . . . . . . . . . . . . . . . . 3 | 2. Supporting UPA in IS-IS . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. Advertisement of PRLA in IS-IS . . . . . . . . . . . . . 3 | 2.1. Advertisement of UPA in IS-IS . . . . . . . . . . . . . . 3 | |||
| 2.2. Propagation of PRLA in IS-IS . . . . . . . . . . . . . . 4 | 2.2. Propagation of UPA in IS-IS . . . . . . . . . . . . . . . 4 | |||
| 3. Supporting PRLA in OSPF . . . . . . . . . . . . . . . . . . . 4 | 3. Supporting UPA in OSPF . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Advertisement of PRLA in OSPF . . . . . . . . . . . . . . 5 | 3.1. Advertisement of UPA in OSPF . . . . . . . . . . . . . . 5 | |||
| 3.2. Propagation of PRLA in OSPF . . . . . . . . . . . . . . . 5 | 3.2. Propagation of UPA in OSPF . . . . . . . . . . . . . . . 5 | |||
| 4. Deployment Considerations for PRLA . . . . . . . . . . . . . 5 | 4. Deployment Considerations for UPA . . . . . . . . . . . . . . 5 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 | 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 1. Introduction | 1. Introduction | |||
| Link-state IGP protocols like IS-IS and OSPF are primarily used to | Link-state IGP protocols like IS-IS and OSPF are primarily used to | |||
| distribute routing information between routers belonging to a single | distribute routing information between routers belonging to a single | |||
| skipping to change at page 3, line 15 ¶ | skipping to change at page 3, line 16 ¶ | |||
| have been used traditionally to address the scale challenges | have been used traditionally to address the scale challenges | |||
| associated with advertising prefix state outside of the local area/ | associated with advertising prefix state outside of the local area/ | |||
| domain. However, this results in suppression of the individual | domain. However, this results in suppression of the individual | |||
| prefix state that is useful for triggering fast-convergence | prefix state that is useful for triggering fast-convergence | |||
| mechanisms outside of the IGPs - e.g., BGP PIC Edge [I-D.ietf-rtgwg- | mechanisms outside of the IGPs - e.g., BGP PIC Edge [I-D.ietf-rtgwg- | |||
| bgp-pic]. | bgp-pic]. | |||
| This document describes how the use of existing protocol mechanisms | This document describes how the use of existing protocol mechanisms | |||
| can support the necessary functionality without the need for any | can support the necessary functionality without the need for any | |||
| protocol extensions. The functionality being described is called | protocol extensions. The functionality being described is called | |||
| Prefix Reachability Loss Announcement (PRLA). | Unreachable Prefix Announcement (UPA). | |||
| 2. Supporting PRLA in IS-IS | 2. Supporting UPA in IS-IS | |||
| [RFC5305] defines the encoding for advertising IPv4 prefixes using 4 | [RFC5305] defines the encoding for advertising IPv4 prefixes using 4 | |||
| octets of metric information. Section 4 specifies: | octets of metric information. Section 4 specifies: | |||
| "If a prefix is advertised with a metric larger then MAX_PATH_METRIC | "If a prefix is advertised with a metric larger then MAX_PATH_METRIC | |||
| (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered | (0xFE000000, see paragraph 3.0), this prefix MUST NOT be considered | |||
| during the normal SPF computation. This allows advertisement of a | during the normal SPF computation. This allows advertisement of a | |||
| prefix for purposes other than building the normal IP routing table. | prefix for purposes other than building the normal IP routing table. | |||
| " | " | |||
| skipping to change at page 3, line 42 ¶ | skipping to change at page 3, line 43 ¶ | |||
| MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST NOT be considered | MAX_V6_PATH_METRIC (0xFE000000), this prefix MUST NOT be considered | |||
| during the normal Shortest Path First (SPF) computation. This will | during the normal Shortest Path First (SPF) computation. This will | |||
| allow advertisement of a prefix for purposes other than building the | allow advertisement of a prefix for purposes other than building the | |||
| normal IPv6 routing table." | normal IPv6 routing table." | |||
| This functionality can be used to advertise a prefix (IPv4 or IPv6) | This functionality can be used to advertise a prefix (IPv4 or IPv6) | |||
| in a manner which indicates that reachability has been lost - and to | in a manner which indicates that reachability has been lost - and to | |||
| do so without requiring all nodes in the network to be upgraded to | do so without requiring all nodes in the network to be upgraded to | |||
| support the functionality. | support the functionality. | |||
| 2.1. Advertisement of PRLA in IS-IS | 2.1. Advertisement of UPA in IS-IS | |||
| Existing nodes in a network which receive PRLA advertisements will | Existing nodes in a network which receive UPA advertisements will | |||
| ignore them. This allows flooding of such advertisements to occur | ignore them. This allows flooding of such advertisements to occur | |||
| without the need to upgrade all nodes in a network. | without the need to upgrade all nodes in a network. | |||
| Recognition of the advertisement as PRLA is only required on routers | Recognition of the advertisement as UPA is only required on routers | |||
| which have a use case for this information. Area Border Routers | which have a use case for this information. Area Border Routers | |||
| (ABRs), which would be responsible for propagating PRLA | (ABRs), which would be responsible for propagating UPA advertisements | |||
| advertisements into other areas would need to recognize such | into other areas would need to recognize such advertisements. | |||
| advertisements. | ||||
| As per the definitions referenced in the preceding section, any | As per the definitions referenced in the preceding section, any | |||
| prefix advertisement with a metric value greater than 0xFE000000 can | prefix advertisement with a metric value greater than 0xFE000000 can | |||
| be used for purposes other than normal routing calculations. Such an | be used for purposes other than normal routing calculations. Such an | |||
| advertisement can be interpreted by the receiver as a PRLA. | advertisement can be interpreted by the receiver as a UPA. | |||
| Optionally, an implementation may use local configuration to limit | Optionally, an implementation may use local configuration to limit | |||
| the set of metric values which will be interpreted as PRLA. The only | the set of metric values which will be interpreted as UPA. The only | |||
| restriction is that such values MUST be greater than 0xFE000000. | restriction is that such values MUST be greater than 0xFE000000. | |||
| 2.2. Propagation of PRLA in IS-IS | 2.2. Propagation of UPA in IS-IS | |||
| ISIS L1/L2 routers may wish to advertise received PRLAs into other | ISIS L1/L2 routers may wish to advertise received UPAs into other | |||
| areas (upwards and/or downwards). When propagating PRLAs the | areas (upwards and/or downwards). When propagating UPAs the original | |||
| original metric value MUST be preserved. The cost to reach the | metric value MUST be preserved. The cost to reach the originator of | |||
| originator of the received PRLA MUST NOT be considered when | the received UPA MUST NOT be considered when readvertising the UPA. | |||
| readvertising the PRLA. | ||||
| 3. Supporting PRLA in OSPF | 3. Supporting UPA in OSPF | |||
| [RFC2328] Appendix B defines the following architectural constant for | [RFC2328] Appendix B defines the following architectural constant for | |||
| OSPF: | OSPF: | |||
| "LSInfinity The metric value indicating that the destination | "LSInfinity The metric value indicating that the destination | |||
| described by an LSA is unreachable. Used in summary-LSAs and AS- | described by an LSA is unreachable. Used in summary-LSAs and AS- | |||
| external-LSAs as an alternative to premature aging (see | external-LSAs as an alternative to premature aging (see | |||
| Section 14.1). It is defined to be the 24-bit binary value of all | Section 14.1). It is defined to be the 24-bit binary value of all | |||
| ones: 0xffffff." | ones: 0xffffff." | |||
| skipping to change at page 5, line 12 ¶ | skipping to change at page 5, line 5 ¶ | |||
| [RFC2328] section 14.1. also describes the usage of LSInfinity as a | [RFC2328] section 14.1. also describes the usage of LSInfinity as a | |||
| way to indicate loss of prefix reachability: | way to indicate loss of prefix reachability: | |||
| "Premature aging can also be used when, for example, one of the | "Premature aging can also be used when, for example, one of the | |||
| router's previously advertised external routes is no longer | router's previously advertised external routes is no longer | |||
| reachable. In this circumstance, the router can flush its AS- | reachable. In this circumstance, the router can flush its AS- | |||
| external-LSA from the routing domain via premature aging. This | external-LSA from the routing domain via premature aging. This | |||
| procedure is preferable to the alternative, which is to originate a | procedure is preferable to the alternative, which is to originate a | |||
| new LSA for the destination specifying a metric of LSInfinity." | new LSA for the destination specifying a metric of LSInfinity." | |||
| 3.1. Advertisement of PRLA in OSPF | 3.1. Advertisement of UPA in OSPF | |||
| Using the existing mechanism already defined in the standards, as | Using the existing mechanism already defined in the standards, as | |||
| described in previous section, an advertisement of the inter-area or | described in previous section, an advertisement of the inter-area or | |||
| external prefix inside OSPF or OSPFv3 LSA that has the age set to | external prefix inside OSPF or OSPFv3 LSA that has the age set to | |||
| value lower than MaxAge and metic set to LSInfinity can be | value lower than MaxAge and metic set to LSInfinity can be | |||
| interpreted by the receiver as a PRLA. | interpreted by the receiver as a UPA. | |||
| Existing nodes in a network which receive PRLA advertisements will | Existing nodes in a network which receive UPA advertisements will | |||
| propagate it following existing standard procedures defined by OSPF. | propagate it following existing standard procedures defined by OSPF. | |||
| OSPF Area Border Routers (ABRs), which would be responsible for | OSPF Area Border Routers (ABRs), which would be responsible for | |||
| propagating PRLA advertisements into other areas would need to | propagating UPA advertisements into other areas would need to | |||
| recognize such advertisements. | recognize such advertisements. | |||
| 3.2. Propagation of PRLA in OSPF | 3.2. Propagation of UPA in OSPF | |||
| OSPF ABRs may wish to advertise received PRLAs into other connected | OSPF ABRs may wish to advertise received UPAs into other connected | |||
| areas. When doing so, the original LSInfinity metric value in PRLA | areas. When doing so, the original LSInfinity metric value in UPA | |||
| MUST be preserved. The cost to reach the originator of the received | MUST be preserved. The cost to reach the originator of the received | |||
| PRLA MUST NOT be considered when readvertising the PRLA to connected | UPA MUST NOT be considered when readvertising the UPA to connected | |||
| areas. | areas. | |||
| 4. Deployment Considerations for PRLA | 4. Deployment Considerations for UPA | |||
| The economy provided by the use of summary advertisements diminishes | ||||
| in the presence of PRLA. It is therefore recommended that | ||||
| implementations limit the number of PRLA advertisements which can be | ||||
| originated at a given time. This implies that PRLA can be used to | ||||
| signal the loss of reachablity to a modest number of nodes - but it | ||||
| is not a good tool to signal the loss of many nodes simultaneously. | ||||
| The intent of PRLA is to provide an event driven signal of the | The intent of UPA is to provide an event driven signal of the | |||
| transition of a destination from reachable to unreachable. It is not | transition of a destination from reachable to unreachable. It is not | |||
| intended to advertise a persistent state. PRLA advertisements should | intended to advertise a persistent state. UPA advertisements should | |||
| therefore be withdrawn after a modest amount of time, that would | therefore be withdrawn after a modest amount of time, that would | |||
| provides sufficient time for PRLA to be flooded network-wide and | provides sufficient time for UPA to be flooded network-wide and acted | |||
| acted upon by receiving nodes, but limits the presence of PRLA in the | upon by receiving nodes, but limits the presence of UPA in the | |||
| network to a short time period. The time the PRLA is kept in the | network to a short time period. The time the UPA is kept in the | |||
| network SHOULD also reflect the intended use-case for which the PRLA | network SHOULD also reflect the intended use-case for which the UPA | |||
| was advertised. | was advertised. | |||
| As PRLA advertisements in ISIS are advertised in existing Link State | As UPA advertisements in ISIS are advertised in existing Link State | |||
| PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is | PDUs (LSPs) and the unit of flooding in IS-IS is an LSP, it is | |||
| recommended that, when possible, PRLAs are advertised in LSPs | recommended that, when possible, UPAs are advertised in LSPs | |||
| dedicated to this type of advertisement. This will minimize the | dedicated to this type of advertisement. This will minimize the | |||
| number of LSPs which need to be updated when PRLAs are advertised and | number of LSPs which need to be updated when UPAs are advertised and | |||
| withdrawn. | withdrawn. | |||
| In OSPF and OSPFv3, each inter-area and external prefix is advertised | In OSPF and OSPFv3, each inter-area and external prefix is advertised | |||
| in it's own LSA, so the above optimisation does not apply to OSPF. | in it's own LSA, so the above optimisation does not apply to OSPF. | |||
| It is also recommended that implementations limit the number of UPA | ||||
| advertisements which can be originated at a given time. | ||||
| 5. IANA Considerations | 5. IANA Considerations | |||
| This document makes no requests to IANA. | This document makes no requests to IANA. | |||
| 6. Security Considerations | 6. Security Considerations | |||
| The use of PRLAs introduces the possibility that an attacker could | The use of UPAs introduces the possibility that an attacker could | |||
| inject a false, but apparently valid, PRLA. However, the risk of | inject a false, but apparently valid, UPA. However, the risk of this | |||
| this occurring is no greater than the risk today of an attacker | occurring is no greater than the risk today of an attacker injecting | |||
| injecting any other type of false advertisement . | any other type of false advertisement . | |||
| The risks can be reduced by the use of existing security extensions | The risks can be reduced by the use of existing security extensions | |||
| as described in [RFC5304] and [RFC5310] for IS-IS, in [RFC2328][ and | as described in [RFC5304] and [RFC5310] for IS-IS, in [RFC2328][ and | |||
| [RFC7474] for OSPFv2, and in [RFC5340] and [RFC4552] for OSPFv3. | [RFC7474] for OSPFv2, and in [RFC5340] and [RFC4552] for OSPFv3. | |||
| 7. Acknowledgements | 7. Acknowledgements | |||
| TBD | The authors would like to thank Kamran Raza and Michael MacKenzie for | |||
| their contribution to the overall solution proposed in this document. | ||||
| 8. Normative References | 8. Normative References | |||
| [ISO10589] International Organization for Standardization, | [ISO10589] | |||
| International Organization for Standardization, | ||||
| "Intermediate system to Intermediate system intra-domain | "Intermediate system to Intermediate system intra-domain | |||
| routeing information exchange protocol for use in | routeing information exchange protocol for use in | |||
| conjunction with the protocol for providing the | conjunction with the protocol for providing the | |||
| connectionless-mode Network Service (ISO 8473)", November | connectionless-mode Network Service (ISO 8473)", Nov 2002. | |||
| 2002. | ||||
| [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 7, line 46 ¶ | skipping to change at page 7, line 38 ¶ | |||
| 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>. | |||
| Authors' Addresses | Authors' Addresses | |||
| Peter Psenak (editor) | Peter Psenak (editor) | |||
| Cisco Systems | Cisco Systems | |||
| Pribinova Street 10 | Pribinova Street 10 | |||
| Bratislava 81109 | Bratislava 81109 | |||
| Slovakia | Slovakia | |||
| Email: ppsenak@cisco.com | Email: ppsenak@cisco.com | |||
| Les Ginsberg | ||||
| Clarence Filsfils | ||||
| Cisco Systems | Cisco Systems | |||
| 821 Alder Drive | Brussels | |||
| Milpitas, CA 95035 | Belgium | |||
| United States of America | ||||
| Email: ginsberg@cisco.com | Email: cfilsfil@cisco.com | |||
| Stephane Litkowski | ||||
| Cisco Systems | ||||
| La Rigourdiere | ||||
| Cesson Sevigne | ||||
| France | ||||
| Email: slitkows@cisco.com | ||||
| Daniel Voyer | Daniel Voyer | |||
| Bell Canada | Bell Canada | |||
| Email: daniel.voyer@bell.ca | Email: daniel.voyer@bell.ca | |||
| Amit Dhamija | ||||
| Rakuten | ||||
| Email: amit.dhamija@rakuten.com | ||||
| End of changes. 41 change blocks. | ||||
| 76 lines changed or deleted | 85 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/ | ||||