< 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/