Internet DRAFT - draft-bryskin-ospf-lsa-type11-validation
draft-bryskin-ospf-lsa-type11-validation
Internet Draft Igor Bryskin (Movaz Networks)
Category: Standards Track Alex Zinin (Alcatel)
Expiration Date: October 2006 Lou Berger (LabN Consulting, LLC)
April 2006
Validation of OSPF AS-scope opaque LSAs
draft-bryskin-ospf-lsa-type11-validation-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes a mechanism enabling an OSPF node to validate
AS-scope opaque LSAs (LSAs type-11, [RFC2370]) originated outside of
the node's OSPF area.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Bryskin, Zinin, Berger [Page 1]
Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006
1. Introduction
[RFC2370] introduces a mechanism for the distribution of application
specific information using the OSPF ([RFC2328]) protocol (i.e. OSPF
advertising, Link State Data Base (LSDB) synchronization and
flooding procedures). Link State Advertisements (LSAs) that carry
such information are called opaque LSAs. According to [RFC2370] the
distribution of opaque LSAs is limited to:
a) only immediate neighbors of the originator (LSAs type-9);
b) only OSPF nodes located within the originator's OSPF area
(LSAs type-10);
c) all OSPF nodes within the originator's OSPF domain/AS (LSAs
type-11)
One issue related to AS scoped Opaque LSAs is that there is no way
for OSPF nodes in remote areas to check availability of the LSA
originator.
Specifically, if an OSPF node originates an LSA type-11 and, after
that, goes out of service, OSFP nodes located outside of the
originator's OSPF area have no way of detecting this fact and may use
the stale information for a considerable period of time (up to 60
minutes). This could prove to be suboptimal for some applications,
and may result in others not functioning.
Opaque LSAs type-9 and type-10 do not have this problem as the fact
that the LSA originator has ceased functioning can be immediately
detected by the received LSA processing node due to the loss of the
OSPF adjacency (case LSA type-9) or the sequence of OSPF adjacencies
(case LSA type-10) connecting the LSA receiving and originating
nodes.
There is a parallel issue in OSPF for the AS scoped AS-external-LSAs
(type-5 LSAs). This issue is addressed by using AS border
information advertised in ASBR-summary-LSAs (type-4 LSAs), see
[RFC2328] Section 16.4.
This memo proposes a simple way for validating AS-scope opaque LSAs
originated outside of the OSPF area where they are processed. This
solution reuses mechanisms defined in [RFC2328] used for validation
of type-5 LSAs.
Bryskin, Zinin, Berger [Page 2]
Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006
2. Solution
The problem described in the previous section is solved by reusing
The ASBR advertisement and summary mechanisms defined in [RFC2328].
The basic solution is for nodes that generate type-11 opaque LSAs
to advertise themselves as ASBRs. This will enable nodes to track
the reachability of the LSA originator either directly via the SPF
calculation (for nodes in the same area) or indirectly via type-4
LSAs originated by ABRs (for nodes in other areas). It is important
to note that this solution is not applicable for OSPF stub areas as
neither type-11 LSAs are flooded nor type-4 LSAs are originated
into such areas.
The specific solution is:
1) An OSPF node that is configured to originate AS-scope opaque LSAs
MUST set E-bit in the Options field of every originated OSPF Hello
packet;
2) Such nodes also MUST set the E-bit in the Options field of the
header of every LSA it injects into the network;
3) When processing a received type-11 Opaque LSA, the node MUST look
up the routing table entries (potentially one per attached area)
for the AS boundary router (ASBR) that originated the LSA. If no
entries exist for router ASBR (i.e., ASBR is unreachable), the
node MUST do nothing with this LSA. It also MUST discontinue
using all Opaque LSAs injected into the network by the same
originator whenever it is detected that the originator is
unreachable.
3. Backward compatibility
The solution proposed in this memo introduces no interoperability
issues. Note, that OSPF nodes that do not implement this
specification, will continue using stale type-11 LSAs even
if the LSA originator implements it and announces itself as an ASBR.
4. Stub Area Considerations
While the extension defined in this document does not present any
interoperability issues, there are two issues related to OSPF stub
areas. As previously stated, the extension defined in this document
MUST NOT be used in stub networks. If the E-bit is set in the
Options field of Hello packets in a stub area, the
ExternalRoutingCapability check will fail and the adjacency will not
be established.
Bryskin, Zinin, Berger [Page 3]
Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006
Additionally, the extension defined in this document does not overcome
the fact that (according to [RFC2370]) type-11 LSAs originated outside
of stub areas are not flooded into stub areas. Even if the flooding
would have been allowed the validation of the LSAs using the mechanism
described in this memo would not be possible because (according to
[RFC2328]) ABRs do not originate type-4 LSAs into stub areas.
5. Security Considerations
This document reuses an ASBR tracking mechanism that is already
employed in basic OSPF for type-5 LSAs. Applying it to type-11 Opaque
LSAs does not create any threats that are not already known for
type-5 LSAs.
6. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Bryskin, Zinin, Berger [Page 4]
Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
7. Acknowledgement
We would like to thank Acee Lindem for the useful discussion on the
matter during IETF65.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirements levels", RFC 2119, March 1997.
[RFC2328] Moy, J., " OSPF Version 2 ", RFC 2328, April 1998.
[RFC2370] Coltun, R., " The OSPF Opaque LSA Option ", RFC 2730,
July 1998.
9. Authors' Addresses
Igor Bryskin
Movaz Networks, Inc.
Email: ibryskin@movaz.com
Alex Zinin
Alcatel,
Email: zinin@psg.com
Lou Berger
LabN Consulting, LLC
Email: lberger@labn.net
10. Full Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
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.
Bryskin, Zinin, Berger [Page 5]
Internet Draft draft-bryskin-ospf-lsa-type11-validation-00.txtApril 2006
11. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
