draft-ietf-ospf-rfc2370bis-02.txt   draft-ietf-ospf-rfc2370bis-03.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: September 10, 2008 Original Author: Expiration Date: October 24, 2008 Original Author:
Rob Coltun (Acoustra Productions) Rob Coltun (Acoustra Productions)
March 10, 2008 April 24, 2008
The OSPF Opaque LSA Option The OSPF Opaque LSA Option
draft-ietf-ospf-rfc2370bis-02.txt draft-ietf-ospf-rfc2370bis-03.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 September 10, 2008. This Internet-Draft will expire on October 24, 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 2, line 25 skipping to change at page 2, line 25
3.2 Modifications To The Neighbor State Machine ............... 6 3.2 Modifications To The Neighbor State Machine ............... 6
4 Protocol Data Structures .................................. 7 4 Protocol Data Structures .................................. 7
4.1 Additions To The OSPF Neighbor Structure .................. 8 4.1 Additions To The OSPF Neighbor Structure .................. 8
5 Inter-Area Considerations ................................. 8 5 Inter-Area Considerations ................................. 8
6 Management Considerations ................................. 9 6 Management Considerations ................................. 9
7 Backward Compatibility .................................... 9 7 Backward Compatibility .................................... 9
8 Security Considerations ................................... 10 8 Security Considerations ................................... 10
9 IANA Considerations ....................................... 11 9 IANA Considerations ....................................... 11
10 References ................................................ 11 10 References ................................................ 11
10.1 Normative References ...................................... 11 10.1 Normative References ...................................... 11
10.2 Informative References .................................... 12 10.2 Informative References .................................... 11
11 Author's Addresses ........................................ 12 11 Author's Addresses ........................................ 12
12 Appendix A: OSPF Data formats ............................. 13 12 Appendix A: OSPF Data formats ............................. 13
12.1 The Options Field ......................................... 13 12.1 The Options Field ......................................... 13
12.2 The Opaque LSA ............................................ 14 12.2 The Opaque LSA ............................................ 14
13 Full Copyright Statement .................................. 16 13 Full Copyright Statement .................................. 16
14 Intellectual Property ..................................... 16 14 Intellectual Property ..................................... 16
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 36 skipping to change at page 4, line 36
LSAs are not flooded beyond the local (sub)network. LSAs are not flooded beyond the local (sub)network.
o Link-state type-10 denotes an area-local scope. Type-10 Opaque o Link-state type-10 denotes an area-local scope. Type-10 Opaque
LSAs are not flooded beyond the borders of their associated area. LSAs are not flooded beyond the borders of their associated area.
o Link-state type-11 denotes that the LSA is flooded throughout o Link-state type-11 denotes that the LSA is flooded throughout
the Autonomous System (AS). The flooding scope of type-11 the Autonomous System (AS). The flooding scope of type-11
LSAs are equivalent to the flooding scope of AS-external (type-5) LSAs are equivalent to the flooding scope of AS-external (type-5)
LSAs. Specifically, type-11 Opaque LSAs are 1) flooded LSAs. Specifically, type-11 Opaque LSAs are 1) flooded
throughout all transit areas, 2) not flooded into stub areas or throughout all transit areas, 2) not flooded into stub areas or
NSSAs from the backbone and 3) not originated by routers into Not-So-Stubby Areas (NSSAs), see [NSSA], from the backbone and
their connected stub areas or NSSAs. As with type-5 LSAs, if a 3) not originated by routers into their connected stub areas
type-11 Opaque LSA is received in a stub area or NSSA from a or NSSAs. As with type-5 LSAs, if a type-11 Opaque LSA is
neighboring router within the stub area or NSSA the LSA is received in a stub area or NSSA from a neighboring router
rejected. within the stub area or NSSA the LSA is rejected.
The link-state ID of the Opaque LSA is divided into an Opaque type The link-state ID of the Opaque LSA is divided into an Opaque type
field (the first 8 bits) and a type-specific ID (the remaining 24 field (the first 8 bits) and a type-specific ID (the remaining 24
bits). The packet format of the Opaque LSA is given in Appendix A. bits). The packet format of the Opaque LSA is given in Appendix A.
Section 7 describes Opaque type allocation and assignment. Section 7 describes Opaque type allocation and assignment.
The responsibility for proper handling of the Opaque LSA's flooding The responsibility for proper handling of the Opaque LSA's flooding
scope is placed on both the sender and receiver of the LSA. The scope is placed on both the sender and receiver of the LSA. The
receiver must always store a valid received Opaque LSA in its link- receiver must always store a valid received Opaque LSA in its link-
state database. The receiver must not accept Opaque LSAs that state database. The receiver must not accept Opaque LSAs that
skipping to change at page 8, line 43 skipping to change at page 8, line 43
Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem Type-9 opaque LSAs and type-10 opaque LSAs do not have this problem
as a receiving router can detect if the advertising router is as a receiving router can detect if the advertising router is
reachable within the LSA's respective flooding scope. In the case of reachable within the LSA's respective flooding scope. In the case of
type-9 LSAs, the originating router must be an OSPF neighbor in type-9 LSAs, the originating router must be an OSPF neighbor in
Exchange state or greater. In the case of type-10 Opaque LSAs, the Exchange state or greater. In the case of type-10 Opaque LSAs, the
intra-area SPF calculation will determine the advertising router's intra-area SPF calculation will determine the advertising router's
reachability. reachability.
There is a parallel issue in OSPF for the AS scoped AS-external-LSAs There is a parallel issue in OSPF for the AS scoped AS-external-LSAs
(type-5 LSAs). OSPF addresses this by using AS border information (type-5 LSAs). OSPF addresses this by using AS border information
advertised in ASBR-summary-LSAs (type-4 LSAs), see [OSPF] Section advertised in AS boundary router (ASBR) summary-LSAs (type-4 LSAs),
16.4. This same mechanism is reused by this document for type-11 see [OSPF] Section 16.4. This same mechanism is reused by this
opaque LSAs. document for type-11 opaque LSAs.
To enable OSPF routers in remote areas to check availability of the To enable OSPF routers in remote areas to check availability of the
originator of link-state type-11 opaque LSAs, the originators originator of link-state type-11 opaque LSAs, the originators
advertise themselves as ASBRs. This will enable routers to track the advertise themselves as ASBRs. This will enable routers to track the
reachability of the LSA originator either directly via the SPF reachability of the LSA originator either directly via the SPF
calculation (for routers in the same area) or indirectly via type-4 calculation (for routers in the same area) or indirectly via type-4
LSAs originated by ABRs (for routers in other areas). It is important LSAs originated by ABRs (for routers in other areas). It is important
to note that per [OSPF] this solution does not apply to OSPF stub to note that per [OSPF] this solution does not apply to OSPF stub
areas or NSSAs as AS scoped opaque LSAs are not flooded into these areas or NSSAs as AS scoped opaque LSAs are not flooded into these
area types. area types.
skipping to change at page 11, line 20 skipping to change at page 11, line 20
In the case of type-11 Opaque LSAs, this document reuses an ASBR In the case of type-11 Opaque LSAs, this document reuses an ASBR
tracking mechanism that is already employed in basic OSPF for type-5 tracking mechanism that is already employed in basic OSPF for type-5
LSAs. Therefore, applying it to type-11 Opaque LSAs does not create LSAs. Therefore, applying it to type-11 Opaque LSAs does not create
any threats that are not already known for type-5 LSAs. any threats that are not already known for type-5 LSAs.
9. IANA Considerations 9. IANA Considerations
There are no changes to the IANA number assignment requirements from There are no changes to the IANA number assignment requirements from
[RFC2370]. [RFC2370].
Opaque types are maintained by the IANA. Extensions to OSPF which Following the policies outlined in [RFC2434], Opaque type values in
require a new Opaque type must be reviewed by the OSPF working group. the range of 0-127 are maintained by the IANA and allocated through
In the event that the OSPF working group has disbanded the review IETF Consensus. Opaque type values in the range of 128-255 are
shall be performed by a recommended Designated Expert. reserved for Private Use.
Following the policies outlined in [IANA], Opaque type values in the
range of 0-127 are allocated through an IETF Consensus action and
Opaque type values in the range of 128-255 are reserved for private
and experimental use.
10. References 10. References
10.1. Normative References 10.1. Normative References
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC
1793, April 1995. 1793, April 1995.
[IANA] Narten, T., and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, October 1998.
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate [RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997. requirements levels", RFC 2119, March 1997.
[RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an
IANA Considerations Section in RFCs ", RFC 2434, October
1998.
[RFC4750] Joyal, D., et. al., "OSPF Version 2 Management Information [RFC4750] Joyal, D., et. al., "OSPF Version 2 Management Information
Base", RFC 4750, November 2006. Base", RFC 4750, November 2006.
10.2. Informative References 10.2. Informative References
[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-, May 2007. draft-ietf-ospf-ospfv3-update-, 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.
[RFC4576] Rosen, E., et. al., "Using a Link State Advertisement [RFC4576] Rosen, E., et. al., "Using a Link State Advertisement
(LSA) Options Bit to Prevent Looping in BGP/MPLS IP (LSA) Options Bit to Prevent Looping in BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4576, June 2006. Virtual Private Networks (VPNs)", RFC 4576, June 2006.
skipping to change at line 714 skipping to change at line 710
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 Mar 10 10:35:48 EDT 2008 Generated on: Thu Apr 24 13:31:15 EDT 2008
 End of changes. 12 change blocks. 
26 lines changed or deleted 22 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/