| < draft-ietf-ospf-rfc3137bis-03.txt | draft-ietf-ospf-rfc3137bis-04.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Retana | Network Working Group A. Retana | |||
| Internet-Draft L. Nguyen | Internet-Draft L. Nguyen | |||
| Obsoletes: 3137 (if approved) Cisco Systems, Inc. | Obsoletes: 3137 (if approved) Cisco Systems, Inc. | |||
| Intended status: Informational A. Zinin | Intended status: Informational A. Zinin | |||
| Expires: July 21, 2013 Cinarra Systems | Expires: October 25, 2013 Cinarra Systems | |||
| R. White | R. White | |||
| D. McPherson | D. McPherson | |||
| Verisign, Inc. | Verisign, Inc. | |||
| January 17, 2013 | April 23, 2013 | |||
| OSPF Stub Router Advertisement | OSPF Stub Router Advertisement | |||
| draft-ietf-ospf-rfc3137bis-03 | draft-ietf-ospf-rfc3137bis-04 | |||
| Abstract | Abstract | |||
| This document describes a backward-compatible technique that may be | This document describes a backward-compatible technique that may be | |||
| used by OSPF (Open Shortest Path First) implementations to advertise | used by OSPF (Open Shortest Path First) implementations to advertise | |||
| unavailability to forward transit traffic or to lower the preference | a router's unavailability to forward transit traffic, or to lower the | |||
| level for the paths through such a router. | preference level for the paths through such a router. | |||
| Status of this Memo | This document obsoletes [RFC3137]. | |||
| 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 http://datatracker.ietf.org/drafts/current/. | Drafts is at http://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 July 21, 2013. | This Internet-Draft will expire on October 25, 2013. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. OSPFv3-only Solution . . . . . . . . . . . . . . . . . . . 4 | 2.1. OSPFv3-only Solution . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Maximum Link Metric . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 4. Deployment Considerations . . . . . . . . . . . . . . . . . . . 4 | 4. Deployment Considerations . . . . . . . . . . . . . . . . . . 4 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 8. Informative References . . . . . . . . . . . . . . . . . . . . 5 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . . 5 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 | |||
| A.1. Changes between the -00 and -01 versions. . . . . . . . . . 5 | 8.2. Informative References . . . . . . . . . . . . . . . . . 5 | |||
| A.2. Changes between the -01 and -02 versions. . . . . . . . . . 6 | Appendix A. Changes from RFC3137 . . . . . . . . . . . . . . . . 5 | |||
| A.3. Changes between the -02 and -03 versions. . . . . . . . . . 6 | Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 5 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 | B.1. Changes between the -00 and -01 versions. . . . . . . . . 6 | |||
| B.2. Changes between the -01 and -02 versions. . . . . . . . . 6 | ||||
| B.3. Changes between the -02 and -03 versions. . . . . . . . . 6 | ||||
| B.4. Changes between the -03 and -04 versions . . . . . . . . 6 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 | ||||
| 1. Introduction | 1. Introduction | |||
| In some situations, it may be advantageous to inform routers in a | In some situations, it may be advantageous to inform routers in a | |||
| network not to use a specific router as a transit point, but still | network not to use a specific router as a transit point, but still | |||
| route to it. Possible situations include the following: | route to it. Possible situations include the following: | |||
| o The router is in a critical condition (for example, has very high | o The router is in a critical condition (for example, has very high | |||
| CPU load or does not have enough memory to store all LSAs or build | CPU load or does not have enough memory to store all Link State | |||
| the routing table). | Advertisements (LSAs) or build the routing table). | |||
| o Graceful introduction and removal of the router to/from the | o Graceful introduction and removal of the router to/from the | |||
| network. | network. | |||
| o Other (administrative or traffic engineering) reasons. | o Other (administrative or traffic engineering) reasons. | |||
| Note that the solution introduced in this document does not remove | Note that the solution introduced in this document does not remove | |||
| the router from the topology view of the network (as could be done by | the router from the topology view of the network (as could be done by | |||
| just flushing that router's router-LSA), but discourages other | just flushing that router's router-LSA), but discourages other | |||
| routers from using it for transit routing, while still routing | routers from using it for transit routing, while still routing | |||
| skipping to change at page 3, line 40 ¶ | skipping to change at page 3, line 25 ¶ | |||
| destined for the networks reachable through such a stub router may | destined for the networks reachable through such a stub router may | |||
| still be routed through it. | still be routed through it. | |||
| 2. Solutions | 2. Solutions | |||
| The solution introduced in this document solves two challenges | The solution introduced in this document solves two challenges | |||
| associated with the outlined problem. In the description below, | associated with the outlined problem. In the description below, | |||
| router X is the router announcing itself as a stub. | router X is the router announcing itself as a stub. | |||
| 1) Making other routers prefer routes around router X while | 1) Making other routers prefer routes around router X while | |||
| performing the Dijkstra calculation. | performing the Dijkstra calculation. | |||
| 2) Allowing other routers to reach IP prefixes directly connected to | 2) Allowing other routers to reach IP prefixes directly connected to | |||
| router X. | router X. | |||
| Note that it would be easy to address issue 1) alone by just flushing | Note that it would be easy to address issue 1) alone by just flushing | |||
| router X's router-LSA from the domain. However, it does not solve | router X's router-LSA from the domain. However, it does not solve | |||
| problem 2), since other routers will not be able to use links to | problem 2), since other routers will not be able to use links to | |||
| router X in Dijkstra (no back link), and because router X will not | router X in Dijkstra (no back link), and because router X will not | |||
| have links to its neighbors. | have links to its neighbors. | |||
| To address both problems, router X announces its router-LSA to the | To address both problems, router X announces its router-LSA to the | |||
| neighbors with the costs of all non-stub links (links of the types | neighbors with the costs of all non-stub links (links of the types | |||
| other than 3) set to MaxLinkMetric. | other than 3) set to MaxLinkMetric (defined in Section 3). | |||
| The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 | The solution above applies to both OSPFv2 [RFC2328] and OSPFv3 | |||
| [RFC5340]. | [RFC5340]. | |||
| 2.1. OSPFv3-only Solution | 2.1. OSPFv3-only Solution | |||
| OSPFv3 [RFC5340] introduced additional options to provide similar, if | OSPFv3 [RFC5340] introduced additional options to provide similar | |||
| not better, control of the forwarding topology; the R-bit provides a | control of the forwarding topology; the R-bit provides an indication | |||
| more granular indication of whether a router is active and should be | of whether a router is active and should be used for transit traffic. | |||
| used for transit traffic. | ||||
| It is left to network operators to decide which technique to use in | It is left to network operators to decide which technique to use in | |||
| their network. | their network. See Section 4 for more details. | |||
| 3. Maximum Link Metric | 3. Maximum Link Metric | |||
| Section 2 refers to the cost of all non-stub links as MaxLinkMetric, | Section 2 refers to the cost of all non-stub links as MaxLinkMetric, | |||
| which is a new fixed architectural value introduced in this document. | which is a new fixed architectural value introduced in this document. | |||
| MaxLinkMetric | MaxLinkMetric | |||
| The metric value indicating that the link described by an LSA | The metric value indicating that the link described by an LSA | |||
| should not be used as transit. Used in router-LSAs (see | should not be used as transit. Used in router-LSAs (see | |||
| Section 2). It is defined to be the 16-bit binary value of all | Section 2). It is defined to be the 16-bit binary value of all | |||
| skipping to change at page 5, line 5 ¶ | skipping to change at page 4, line 35 ¶ | |||
| some alternate paths in the network, both types of routers will agree | some alternate paths in the network, both types of routers will agree | |||
| on using them rather than the path through the stub router. If the | on using them rather than the path through the stub router. If the | |||
| path through the stub router is the only one, the routers of the | path through the stub router is the only one, the routers of the | |||
| first type will not use the stub router for transit (which is the | first type will not use the stub router for transit (which is the | |||
| desired behavior), while the routers of the second type will still | desired behavior), while the routers of the second type will still | |||
| use this path. | use this path. | |||
| On the other hand, clearing the R-bit will consistently result in the | On the other hand, clearing the R-bit will consistently result in the | |||
| router not being used as transit. | router not being used as transit. | |||
| The use of MaxLinkMetric or the R-bit in a network depends on the | ||||
| objectives of the operator. One of the possible considerations for | ||||
| selecting one or the other is in the desired behavior if the path | ||||
| through the stub router is the only one available. Using | ||||
| MaxLinkMetric allows for that path to be used, while the R-bit | ||||
| doesn't. | ||||
| 5. Security Considerations | 5. Security Considerations | |||
| The technique described in this document does not introduce any new | The technique described in this document does not introduce any new | |||
| security issues into the OSPF protocol. | security issues into the OSPF protocol. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This document has no actions for IANA. | This document has no actions for IANA. | |||
| 7. Acknowledgements | 7. Acknowledgements | |||
| skipping to change at page 5, line 15 ¶ | skipping to change at page 5, line 4 ¶ | |||
| 5. Security Considerations | 5. Security Considerations | |||
| The technique described in this document does not introduce any new | The technique described in this document does not introduce any new | |||
| security issues into the OSPF protocol. | security issues into the OSPF protocol. | |||
| 6. IANA Considerations | 6. IANA Considerations | |||
| This document has no actions for IANA. | This document has no actions for IANA. | |||
| 7. Acknowledgements | 7. Acknowledgements | |||
| The authors of this document do not make any claims on the | The authors of this document do not make any claims on the | |||
| originality of the ideas described. Among other people, we would | originality of the ideas described. Among other people, we would | |||
| like to acknowledge Henk Smit for being part of one of the initial | like to acknowledge Henk Smit for being part of one of the initial | |||
| discussions around this topic. | discussions around this topic. | |||
| We would also like to thank Shishio Tsuchiya, Gunter Van de Velde, | We would like to thank Shishio Tsuchiya, Gunter Van de Velde, | |||
| Tomohiro Yamagata, Faraz Shamim and Acee Lindem who provided | Tomohiro Yamagata, Faraz Shamim and Acee Lindem who provided | |||
| significant input for the latest version of this document. | significant input for the latest version of this document. Dave | |||
| Cridland and Tom Yu also provided valuable comments. | ||||
| 8. Informative References | ||||
| [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. | 8. References | |||
| [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. | 8.1. Normative References | |||
| [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. | |||
| [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF | |||
| for IPv6", RFC 5340, July 2008. | for IPv6", RFC 5340, July 2008. | |||
| Appendix A. Change Log | 8.2. Informative References | |||
| A.1. Changes between the -00 and -01 versions. | [RFC1247] Moy, J., "OSPF Version 2", RFC 1247, July 1991. | |||
| [RFC1583] Moy, J., "OSPF Version 2", RFC 1583, March 1994. | ||||
| [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. | ||||
| McPherson, "OSPF Stub Router Advertisement", RFC 3137, | ||||
| June 2001. | ||||
| Appendix A. Changes from RFC3137 | ||||
| This document obsoletes [RFC3137]. | ||||
| In addition to editorial updates, this documents defines a new | ||||
| architectural constant (MaxLinkMetric in Section 3) to eliminate any | ||||
| confusion about the interpretation of LSInfinity. It also | ||||
| incorporates and explains the use of the R-bit [RFC5340] as a | ||||
| solution to the problem addressed in the text. | ||||
| Appendix B. Change Log | ||||
| This section should be removed by the RFC Editor before publication. | ||||
| B.1. Changes between the -00 and -01 versions. | ||||
| o Defined a new architectural constant (MaxLinkMetric) to eliminate | o Defined a new architectural constant (MaxLinkMetric) to eliminate | |||
| any confusion about the interpretation of LSInfinity. | any confusion about the interpretation of LSInfinity. | |||
| o Added a section to reference the R-bit and V6-bit in OSPFv3. | o Added a section to reference the R-bit and V6-bit in OSPFv3. | |||
| o Updated acks and contact information. | o Updated acks and contact information. | |||
| A.2. Changes between the -01 and -02 versions. | B.2. Changes between the -01 and -02 versions. | |||
| o Took out references to not having a standard solution and | o Took out references to not having a standard solution and | |||
| incorporated the R-bit solution as part of the (renamed) | incorporated the R-bit solution as part of the (renamed) | |||
| "Solutions" section. | "Solutions" section. | |||
| o Various minor edits and reordered sections. | o Various minor edits and reordered sections. | |||
| A.3. Changes between the -02 and -03 versions. | B.3. Changes between the -02 and -03 versions. | |||
| o Updated contact information. | o Updated contact information. | |||
| o Renamed the 'Motivation' section to 'Introduction' becuase of an | o Renamed the 'Motivation' section to 'Introduction' becuase of an | |||
| error in idnits. | error in idnits. | |||
| o Took out the rfc2119 references as none of the keywords are used | o Took out the rfc2119 references as none of the keywords are used | |||
| in the text. | in the text. | |||
| o Added an 'IANA Considerations' section to indicate that there are | o Added an 'IANA Considerations' section to indicate that there are | |||
| no actions required. | no actions required. | |||
| Authors' Addresses | B.4. Changes between the -03 and -04 versions | |||
| o Clearly indicated in the text that this document obsoletes | ||||
| RFC3137. | ||||
| o Various minor edits. | ||||
| o Clarified the use of the R-bit and included text in the | ||||
| "Deployment Considerations" section about it. | ||||
| o Updated acks. | ||||
| o Ordered the References section to provide some Normative ones. | ||||
| o Added an Appendix summarizing the changes form RFC3137. | ||||
| Authors' Addresses | ||||
| Alvaro Retana | Alvaro Retana | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| 7025 Kit Creek Rd. | 7025 Kit Creek Rd. | |||
| Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
| USA | USA | |||
| Email: aretana@cisco.com | Email: aretana@cisco.com | |||
| Liem Nguyen | Liem Nguyen | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| End of changes. 25 change blocks. | ||||
| 43 lines changed or deleted | 90 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/ | ||||