[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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.


Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/