| < draft-ietf-isis-igp-p2p-over-lan-05.txt | draft-ietf-isis-igp-p2p-over-lan-06.txt > | |||
|---|---|---|---|---|
| Network Working Group Naiming Shen, Ed (Redback Networks) | Network Working Group Naiming Shen (Ed) | |||
| Internet Draft Alex Zinin, Ed (Alcatel) | Internet Draft Cisco Systems | |||
| Expiration Date: January 2005 | Expiration Date: October 2006 Alex Zinin (Ed) | |||
| July 2004 | Alcatel | |||
| April 2006 | ||||
| Point-to-point operation over LAN | Point-to-point operation over LAN | |||
| in link-state routing protocols | in link-state routing protocols | |||
| draft-ietf-isis-igp-p2p-over-lan-05.txt | draft-ietf-isis-igp-p2p-over-lan-06.txt | |||
| Status of this Memo | Status of this Memo | |||
| By submitting this Internet-Draft, I certify that any applicable | By submitting this Internet-Draft, each author represents that any | |||
| patent or other IPR claims of which I am aware have been disclosed, | applicable patent or other IPR claims of which he or she is aware | |||
| or will be disclosed, and any of which I become aware will be | have been or will be disclosed, and any of which he or she becomes | |||
| disclosed, in accordance with RFC 3668. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as | other groups may also distribute working documents as Internet- | |||
| Internet-Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six months | |||
| months and may be updated, replaced, or obsoleted by other | and may be updated, replaced, or obsoleted by other documents at any | |||
| documents at any time. It is inappropriate to use Internet- | time. It is inappropriate to use Internet-Drafts as reference | |||
| Drafts as reference material or to cite them other than as | material or to cite them other than as "work in progress." | |||
| "work in progress." | ||||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/1id-abstracts.html | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on October 10, 2006. | ||||
| Copyright Notice | ||||
| Copyright (C) The Internet Society (2006). | ||||
| Abstract | Abstract | |||
| The two predominant circuit types used by link state routing | The two predominant circuit types used by link state routing | |||
| protocols are point-to-point and broadcast. It is important to | protocols are point-to-point and broadcast. It is important to | |||
| identify the correct circuit type when forming adjacencies, | identify the correct circuit type when forming adjacencies, | |||
| flooding link state database packets, and representing the circuit | flooding link state database packets, and representing the circuit | |||
| topologically. This document describes a simple mechanism to treat | topologically. This document describes a simple mechanism to treat | |||
| the broadcast network as a point-to-point connection from the | the broadcast network as a point-to-point connection from the | |||
| standpoint of IP routing. | standpoint of IP routing. | |||
| Contributors | Contributors | |||
| The following individuals are the authors that contributed to the | The following individuals are the authors that contributed to the | |||
| contents of this document. | contents of this document. | |||
| Acee Lindem | Acee Lindem | |||
| Redback Networks | Cisco Systems | |||
| 102 Carric Bend Court | 7025 Kit Creek Road | |||
| Cary, NC 27519 USA | Research Triangle Park, NC 27709 | |||
| acee@redback.com | USA | |||
| Email: acee@cisco.com | ||||
| Jenny Yuan | Jenny Yuan | |||
| Redback Networks | Cisco Systems | |||
| 350 Holger Way | 225 West Tasman Drive | |||
| San Jose, CA, 95134 USA | San Jose, CA 95134 | |||
| jenny@redback.com | USA | |||
| Email: jenny@cisco.com | ||||
| Russ White | Russ White | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| 7025 Kit Creek Rd. | 7025 Kit Creek Rd. | |||
| Research Triangle Park, NC 27709 | Research Triangle Park, NC 27709 | |||
| e-mail: riw@cisco.com | e-mail: riw@cisco.com | |||
| Stefano Previdi | Stefano Previdi | |||
| Cisco Systems, Inc. | Cisco Systems, Inc. | |||
| De Kleetlaan 6A | De Kleetlaan 6A | |||
| 1831 Diegem - Belgium | 1831 Diegem - Belgium | |||
| email: sprevidi@cisco.com | email: sprevidi@cisco.com | |||
| Terminology | Terminology | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in RFC 2119 [3]. | document are to be interpreted as described in RFC 2119 [ref8]. | |||
| 1. Introduction | 1. Introduction | |||
| Point-to-point and broadcast are the two predominant circuit | Point-to-point and broadcast are the two predominant circuit | |||
| types used by link state routing protocols such as ISIS [ref1] | types used by link state routing protocols such as ISIS [ref1] | |||
| [ref2] and OSPF [ref3, ref5]. They are treated differently with | [ref2] and OSPF [ref3, ref5]. They are treated differently with | |||
| respect to establishing neighbor adjacencies, flooding link-state | respect to establishing neighbor adjacencies, flooding link-state | |||
| information, representation of the topology, SPF calculation and | information, representation of the topology, SPF calculation and | |||
| protocol packets. The most important differences are that broadcast | protocol packets. The most important differences are that broadcast | |||
| circuits utilize the concept of a designated router and are | circuits utilize the concept of a designated router and are | |||
| skipping to change at page 6, line 53 ¶ | skipping to change at page 6, line 53 ¶ | |||
| With this p2p-over-lan extension, the difference between a LAN and | With this p2p-over-lan extension, the difference between a LAN and | |||
| a point-to-point circuit can be made purely by configuration. It is | a point-to-point circuit can be made purely by configuration. It is | |||
| important to implement the mechanisms for early detection of | important to implement the mechanisms for early detection of | |||
| mis-configuration. | mis-configuration. | |||
| If the circuit is configured as point-to-point type and receives | If the circuit is configured as point-to-point type and receives | |||
| LAN hello packets, the router MUST discard the incoming packets; If | LAN hello packets, the router MUST discard the incoming packets; If | |||
| the circuit is a LAN type and receive point-to-point hello packets, | the circuit is a LAN type and receive point-to-point hello packets, | |||
| it MUST discard the incoming packets. If the system ID or the | it MUST discard the incoming packets. If the system ID or the | |||
| router ID of incoming hello packet does not match the system ID or | router ID of incoming hello packet does not match the system ID or | |||
| the router ID of already established adjacency over this p2p-over-lan | the router ID for an established adjacency over a p2p-over-lan | |||
| circuit, it MUST discard the packet. The implementation should offer | circuit, the packet MUST discarded. Furthermore, if OSPF hello | |||
| logging and debugging information of the above events. | suppression as described in [ref7] is active for the adjacency, | |||
| the hello suppression MUST be terminated for a period of | ||||
| RouterIntervalSeconds. After this interval either the neighbor | ||||
| adjacency will time out and an adjacency may be formed with | ||||
| a neighbor with different router ID or hello suppression may be | ||||
| renegotiated. The implementation should offer logging and debugging | ||||
| information of the above events. | ||||
| 5. Compatibility considerations | 5. Compatibility considerations | |||
| Both routers on a LAN must support the p2p-over-lan extension | Both routers on a LAN must support the p2p-over-lan extension | |||
| and both must have the LAN segment configured as a p2p-over-lan | and both must have the LAN segment configured as a p2p-over-lan | |||
| circuit for successful operation. Both routers SHOULD support at | circuit for successful operation. Both routers SHOULD support at | |||
| least one of the above listed methods for mapping ip addresses on | least one of the above listed methods for mapping ip addresses on | |||
| the link to MAC address. If a proprietary method of IP address to | the link to MAC address. If a proprietary method of IP address to | |||
| MAC address resolution is used by one router, both routers must | MAC address resolution is used by one router, both routers must | |||
| be capable of using the same method. Otherwise, the link should | be capable of using the same method. Otherwise, the link should | |||
| skipping to change at page 8, line 4 ¶ | skipping to change at page 8, line 12 ¶ | |||
| If one router on a link thinks that a LAN should be either | If one router on a link thinks that a LAN should be either | |||
| broadcast or p2p-over-lan, and the other router has a different | broadcast or p2p-over-lan, and the other router has a different | |||
| opinion, the adjacencies will never form, as specified in | opinion, the adjacencies will never form, as specified in | |||
| Section 4.5. There are no fallbacks at either end to resolve | Section 4.5. There are no fallbacks at either end to resolve | |||
| the situation, except by a manual configuration change. | the situation, except by a manual configuration change. | |||
| 8. Acknowledgments | 8. Acknowledgments | |||
| The authors would like to acknowledge the following individuals: | The authors would like to acknowledge the following individuals: | |||
| (in last name alphabetical order) Pedro Marques, Christian Martin, | (in last name alphabetical order) Pedro Marques, Christian Martin, | |||
| Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, | Danny McPherson, Ajay Patel, Jeff Parker, Tony Przygienda, | |||
| Alvaro Retana and Pekka Savola. | Alvaro Retana and Pekka Savola. | |||
| 9. Normative References | 11. IANA Considerations | |||
| This document has no IANA considerations. | ||||
| This section should be removed by the RFC Editor to final | ||||
| publication. | ||||
| 10. Normative References | ||||
| [ref1] ISO. Information Technology - Telecommunications and | [ref1] ISO. Information Technology - Telecommunications and | |||
| Information Exchange between Systems - Intermediate System | Information Exchange between Systems - Intermediate System | |||
| to Intermediate System Routing Exchange Protocol for | to Intermediate System Routing Exchange Protocol for | |||
| Use in Conjunction with the Protocol for Providing the | Use in Conjunction with the Protocol for Providing the | |||
| Connectionless-Mode Network Service. ISO, 1990. | Connectionless-Mode Network Service. ISO, 1990. | |||
| [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual | [ref2] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual | |||
| Environments. INTERNET-RFC, Internet Engineering Task Force, | Environments. INTERNET-RFC, Internet Engineering Task Force, | |||
| December 1990. | December 1990. | |||
| [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet | [ref3] J. Moy. OSPF Version 2. Technical Report RFC2328 Internet | |||
| Engineering Task Force, 1998. | Engineering Task Force, 1998. | |||
| [ref4] Hopps, C., "Routing IPv6 with IS-IS", | [ref4] Hopps, C., "Routing IPv6 with IS-IS", | |||
| draft-ietf-isis-ipv6-05.txt, work in progress. | draft-ietf-isis-ipv6-06.txt, work in progress. | |||
| [ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", | [ref5] Coltun, R., Ferguson, D. and J. Moy, "OSPF for IPv6", | |||
| RFC 2740, December 1999. | RFC 2740, December 1999. | |||
| [ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery | [ref6] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery | |||
| for IP Version 6 (IPv6)", RFC 2461, December 1998. | for IP Version 6 (IPv6)", RFC 2461, December 1998. | |||
| [ref7] Bradner, S., "Key words for use in RFCs to Indicate | [ref7] Moy, J., "Extending OSPF to Support Demand Circuits", | |||
| RFC 1793, April 1995. | ||||
| [ref8] Bradner, S., "Key words for use in RFCs to Indicate | ||||
| Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
| 10. Editors' Addresses | 11. Editors' Addresses | |||
| Naiming Shen | Naiming Shen | |||
| Redback Networks | Cisco Systems | |||
| 350 Holger Way | 225 West Tasman Drive | |||
| San Jose, CA, 95134 USA | San Jose, CA 95134 | |||
| naiming@redback.com | USA | |||
| Email: naiming@cisco.com | ||||
| Alex Zinin | Alex Zinin | |||
| Alcatel | Alcatel | |||
| Sunnyvale, CA, USA | Sunnyvale, CA, USA | |||
| e-mail: zinin@psg.com | e-mail: zinin@psg.com | |||
| Intellectual Property Considerations | Intellectual Property Statement | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| intellectual property or other rights that might be claimed to | Intellectual Property Rights or other rights that might be claimed to | |||
| pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
| this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
| might or might not be available; neither does it represent that it | might or might not be available; nor does it represent that it has | |||
| has made any effort to identify any such rights. Information on the | made any independent effort to identify any such rights. Information | |||
| IETF's procedures with respect to rights in standards-track and | on the procedures with respect to rights in RFC documents can be | |||
| standards-related documentation can be found in BCP-11. Copies of | found in BCP 78 and BCP 79. | |||
| claims of rights made available for publication and any assurances of | ||||
| licenses to be made available, or the result of an attempt made to | Copies of IPR disclosures made to the IETF Secretariat and any | |||
| obtain a general license or permission for the use of such | assurances of licenses to be made available, or the result of an | |||
| proprietary rights by implementors or users of this specification can | attempt made to obtain a general license or permission for the use of | |||
| be obtained from the IETF Secretariat. | such proprietary rights by implementers or users of this | |||
| specification can be obtained from the IETF on-line IPR repository at | ||||
| http://www.ietf.org/ipr. | ||||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights which may cover technology that may be required to practice | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF Executive | this standard. Please address the information to the IETF at | |||
| Director. | ietf-ipr@ietf.org. | |||
| Full Copyright Notice | Disclaimer of Validity | |||
| Copyright (C) The Internet Society (2004). This document is subject | This document and the information contained herein are provided on an | |||
| "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | ||||
| OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | ||||
| ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | ||||
| INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | ||||
| INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | ||||
| WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| Copyright Statement | ||||
| Copyright (C) The Internet Society (2006). This document is subject | ||||
| to the rights, licenses and restrictions contained in BCP 78, and | to the rights, licenses and restrictions contained in BCP 78, and | |||
| except as set forth therein, the authors retain all their rights. | except as set forth therein, the authors retain all their rights. | |||
| This document and the information contained herein is provided on an | ||||
| "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
| TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
| BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
| HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
| MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
| Acknowledgment | Acknowledgment | |||
| Funding for the RFC Editor function is currently provided by the | Funding for the RFC Editor function is currently provided by the | |||
| Internet Society. | Internet Society. | |||
| End of changes. 24 change blocks. | ||||
| 62 lines changed or deleted | 92 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/ | ||||