< draft-ietf-ospf-rfc2370bis-04.txt   draft-ietf-ospf-rfc2370bis-05.txt >
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Obsoletes: 2370 Igor Bryskin (Adva) Obsoletes: 2370 Igor Bryskin (Adva)
Category: Standards Track Alex Zinin (Alcatel) Category: Standards Track Alex Zinin (Alcatel)
Expiration Date: October 28, 2008 Original Author: Expiration Date: November 8, 2008 Original Author:
Rob Coltun (Acoustra Productions) Rob Coltun (Acoustra Productions)
April 28, 2008 May 8, 2008
The OSPF Opaque LSA Option The OSPF Opaque LSA Option
draft-ietf-ospf-rfc2370bis-04.txt draft-ietf-ospf-rfc2370bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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."
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/1id-abstracts.html
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 28, 2008. This Internet-Draft will expire on November 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines enhancements to the OSPF protocol to support a This document defines enhancements to the OSPF protocol to support a
new class of link-state advertisements (LSA) called Opaque LSAs. new class of link-state advertisements (LSA) called Opaque LSAs.
Opaque LSAs provide a generalized mechanism to allow for the future Opaque LSAs provide a generalized mechanism to allow for the future
skipping to change at page 6, line 6 skipping to change at page 6, line 6
When opaque-capable routers and non-opaque-capable OSPF routers are When opaque-capable routers and non-opaque-capable OSPF routers are
mixed together in a routing domain, the Opaque LSAs are typically not mixed together in a routing domain, the Opaque LSAs are typically not
flooded to the non-opaque-capable routers. As a general design flooded to the non-opaque-capable routers. As a general design
principle, optional OSPF advertisements are only flooded to those principle, optional OSPF advertisements are only flooded to those
routers that understand them. routers that understand them.
An opaque-capable router learns of its neighbor's opaque capability An opaque-capable router learns of its neighbor's opaque capability
at the beginning of the "Database Exchange Process" (see Section 10.6 at the beginning of the "Database Exchange Process" (see Section 10.6
of [OSPF], receiving Database Description packets from a neighbor in of [OSPF], receiving Database Description packets from a neighbor in
state ExStart). A neighbor is opaque-capable if and only if it sets state ExStart). A neighbor is opaque-capable if and only if it sets
the O-bit in the Options field of its Database Description packets; the O-bit in the Options field of its Database Description packets;
the O-bit SHOULD NOT be set and SHOULD be ignored when received in the O-bit SHOULD NOT be set and MUST be ignored when received in
packets other than Database Description packets. Then, in the next packets other than Database Description packets. Using the O-bit in
step of the Database Exchange process, Opaque LSAs are included in OSPF packets other than Database Description packets will result in
the Database summary list that is sent to the neighbor (see Sections interoperability issues. The setting of the O-bit is a "SHOULD NOT"
3.2 below and 10.3 of [OSPF]) when the neighbor is opaque capable. rather than a "MUST NOT" to remain compatible with earlier
specifications.
In the next step of the Database Exchange process, Opaque LSAs are
included in the Database summary list that is sent to the neighbor
(see Sections 3.2 below and 10.3 of [OSPF]) when the neighbor is
opaque capable.
When flooding Opaque-LSAs to adjacent neighbors, an opaque-capable When flooding Opaque-LSAs to adjacent neighbors, an opaque-capable
router looks at the neighbor's opaque capability. Opaque LSAs are router looks at the neighbor's opaque capability. Opaque LSAs are
only flooded to opaque-capable neighbors. To be more precise, in only flooded to opaque-capable neighbors. To be more precise, in
Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state
retransmission lists of opaque-capable neighbors and MUST NOT be retransmission lists of opaque-capable neighbors and MUST NOT be
placed on the link-state retransmission lists of non-opaque-capable placed on the link-state retransmission lists of non-opaque-capable
neighbors. However, when sending Link State Update packets as neighbors. However, when sending Link State Update packets as
multicasts, a non-opaque-capable neighbor may (inadvertently) receive multicasts, a non-opaque-capable neighbor may (inadvertently) receive
Opaque LSAs. The non-opaque-capable router will then simply discard Opaque LSAs. The non-opaque-capable router will then simply discard
skipping to change at page 12, line 36 skipping to change at page 12, line 36
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
1994. 1994.
[NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", [NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
[OSPF-MT] Psenak, P., et al., "Multi-Topology (MT) Routing in OSPF", [OSPF-MT] Psenak, P., et al., "Multi-Topology (MT) Routing in OSPF",
draft-ietf-ospf-mt-, January 2007. draft-ietf-ospf-mt-, January 2007.
[OSPFv3] Coltun, R., et al. "OSPF for IPv6", [OSPFv3] Coltun, R., et al. "OSPF for IPv6",
draft-ietf-ospf-ospfv3-update-, April 2008. draft-ietf-ospf-ospfv3-update-21.txt, April 2008.
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995. [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998. July 1998.
[RFC3630] Katz, D., Kompella, K., Yeund, D., "Traffic Engineering [RFC3630] Katz, D., Kompella, K., Yeund, D., "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630, September
2003. 2003.
skipping to change at line 739 skipping to change at line 745
any copyrights, patents or patent applications, or other any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org. IETF at ietf-ipr@ietf.org.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
Generated on: Mon Apr 28 17:10:34 EDT 2008 Generated on: Thu May 8 16:11:50 EDT 2008
 End of changes. 8 change blocks. 
11 lines changed or deleted 17 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/