< draft-ietf-ospf-prefix-link-attr-00.txt   draft-ietf-ospf-prefix-link-attr-01.txt >
Network Working Group P. Psenak Network Working Group P. Psenak
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track H. Gredler Intended status: Standards Track H. Gredler
Expires: February 13, 2015 Juniper Networks, Inc. Expires: March 12, 2015 Juniper Networks, Inc.
R. Shakir R. Shakir
British Telcom British Telcom
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
J. Tantsura J. Tantsura
Ericsson Ericsson
A. Lindem A. Lindem
Cisco Systems Cisco Systems
August 12, 2014 September 8, 2014
OSPFv2 Prefix/Link Attribute Advertisement OSPFv2 Prefix/Link Attribute Advertisement
draft-ietf-ospf-prefix-link-attr-00.txt draft-ietf-ospf-prefix-link-attr-01.txt
Abstract Abstract
OSPFv2 requires functional extension beyond what can readily be done OSPFv2 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisements (LSAs) as described with the fixed-format Link State Advertisements (LSAs) as described
in RFC 2328. This document defines OSPF opaque LSAs based on Type- in RFC 2328. This document defines OSPF opaque LSAs based on Type-
Length-Value (TLV) tuples that can be used to associate additional Length-Value (TLV) tuples that can be used to associate additional
attributes with advertised prefixes or links. The OSPF opaque LSAs attributes with prefixes or links. Dependent on the application,
are optional and fully backward compatible. these prefixes and links may or not be advertised in the fixed-format
LSAs. The OSPF opaque LSAs are optional and fully backward
compatible.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 13, 2015. This Internet-Draft will expire on March 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 3, line 10 skipping to change at page 3, line 10
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4
2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 4 2. OSPFv2 Extended Prefix Opaque LSA . . . . . . . . . . . . . . 5
2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . . 6 2.1. OSPFv2 Extended Prefix TLV . . . . . . . . . . . . . . . . 6
3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 7 3. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . . . 8
3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 8 3.1. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 9
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 9 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 10 6.1. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 11
6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11 6.2. OSPF Extended Prefix TLV Sub-TLV Registry . . . . . . . . 11
6.3. OSPF Extended Link LSA TLV Registry . . . . . . . . . . . 11 6.3. OSPF Extended Link LSA TLV Registry . . . . . . . . . . . 11
6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 11 6.4. OSPF Extended Link TLV Sub-TLV Registry . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
OSPFv2 requires functional extension beyond what can readily be done OSPFv2 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisements (LSAs) as described with the fixed-format Link State Advertisements (LSAs) as described
in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based in RFC 2328 [OSPFV2]. This document defines OSPF opaque LSAs based
on Type-Length-Value (TLV) tuples that can be used to associate on Type-Length-Value (TLV) tuples that can be used to associate
additional attributes with advertised prefixes or links. The OSPF additional attributes with prefixes or links. Dependent on the
opaque LSAs are optional and fully backward compatible. This is in application, these prefixes and links may or not be advertised in the
contrast to the approach taken in OSPFv3 [OSPFV3-LSA-EXTEND] where fixed-format LSAs. The OSPF opaque LSAs are optional and fully
the existing LSAs will be replaced TLV-based extended LSAs. backward compatible. This is in contrast to the approach taken in
OSPFv3 [OSPFV3-LSA-EXTEND] where the existing LSAs will be replaced
by TLV-based extended LSAs.
New requirements such as source/destination routing, route tagging, New requirements such as source/destination routing, route tagging,
and segment routing necessitate this extension. and segment routing necessitate this extension.
The specfication defines the following OSPFv2 opaque LSAs: This specification defines the following OSPFv2 opaque LSAs:
1. OSPFv2 Extended Prefix LSA - Allows advertisement of additional 1. OSPFv2 Extended Prefix LSA - Allows advertisement of additional
attributes for prefixes advertised in Router-LSAs, Network-LSAs, attributes for prefixes advertised in Router-LSAs, Network-LSAs,
Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2] Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs [OSPFV2]
2. OSPFv2 Extended links LSA - Allows advertisement of additional 2. OSPFv2 Extended links LSA - Allows advertisement of additional
attributes for links advertised in Router-LSAs. attributes for links advertised in Router-LSAs.
Additionally, the following TLVs are defined: Additionally, the following TLVs are defined:
1. OSPFv2 Extended Prefix TLV - Top level TLV advertising attributes 1. OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes
for a prefix in the OSPFv2 Extended Prefix LSA. for a prefix in the OSPFv2 Extended Prefix LSA.
2. OSPFv2 Extended Link TLV - Top level TLV advertising attributes 2. OSPFv2 Extended Link TLV - Top-level TLV advertising attributes
for a link in the OSPFv2 Extended link LSA. for a link in the OSPFv2 Extended link LSA.
1.1. Requirements notation 1.1. Requirements notation
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-KEYWORDS]. document are to be interpreted as described in [RFC-KEYWORDS].
1.2. Acknowledgments 1.2. Acknowledgments
We would like to thank Anton Smirnov for his contribution. We would like to thank Anton Smirnov for his contribution.
Thanks to Tony Przygienda for his review and comments.
2. OSPFv2 Extended Prefix Opaque LSA 2. OSPFv2 Extended Prefix Opaque LSA
The OSPFv2 Extended Prefix Opaque LSA will be used to advertise The OSPFv2 Extended Prefix Opaque LSA will be used to advertise
additional prefix attributes. Opaque LSAs are described in [OPAQUE]. additional prefix attributes. Opaque LSAs are described in [OPAQUE].
Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an
OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix
Opaque LSA depends on the scope of the advertised prefixes and is Opaque LSA depends on the scope of the advertised prefixes and is
under the control of the advertising router. In some cases (e.g., under the control of the advertising router. In some cases (e.g.,
mapping server deployment), the LSA flooding scope may be greater mapping server deployment), the LSA flooding scope may be greater
skipping to change at page 6, line 18 skipping to change at page 6, line 28
field (so a 3-octet value would have a length of 3, but the total field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set aligned. For example, a 1-byte value would have the length field set
to 1, and 3 octets of padding would be added to the end of the value to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV. portion of the TLV.
2.1. OSPFv2 Extended Prefix TLV 2.1. OSPFv2 Extended Prefix TLV
The OSPF Extended Prefix TLV is used in order to advertise additional The OSPF Extended Prefix TLV is used in order to advertise additional
attributes associated with the prefix. Multiple OSPF Extended Prefix attributes associated with the prefix. Multiple OSPF Extended Prefix
TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA but TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA.
all prefixes included in a single OSPFv2 Extended Prefix Opaque LSA However, since the opaque LSA type defines the flooding scope, the
MUST have the same flooding scope. The OSPF Extended Prefix TLV has LSA flooding scope MUST satisfy the application specific requirements
the following format: for all the prefixes included in a single OSPFv2 Extended Prefix
Opaque LSA. The OSPF Extended Prefix TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Prefix Length | AF | Reserved | | Route Type | Prefix Length | AF | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) | | Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 6, line 46 skipping to change at page 7, line 13
OSPFv2 Extended Prefix TLV OSPFv2 Extended Prefix TLV
Type Type
The TLV type. Suggested value is 1. The TLV type. Suggested value is 1.
Length Length
Variable dependent on sub-TLVs. Variable dependent on sub-TLVs.
Route Type Route Type
Route type: type of the OSPF route. If the route type is 0 Route type: type of the OSPF route. If the route type is 0
(unspecified), the information inside the OSPF External Prefix TLV (Unspecified), the information inside the OSPF External Prefix TLV
applies to the prefix regardless of prefix's route-type. This is applies to the prefix regardless of prefix's route-type. This is
useful when prefix specific attributes are advertised by an useful when prefix specific attributes are advertised by an
external entity, which is not aware of the route-type associated external entity, which is not aware of the route-type associated
with the prefix. Supported types are: with the prefix. Supported types are:
0 - unspecified 0 - Unspecified
1 - intra-area 1 - Intra-Area
3 - inter-area 3 - Inter-Area
5 - external 5 - AS External
7 - NSSA external 7 - NSSA External
Prefix Length Prefix Length
Length in of the prefix in bits. Length in of the prefix in bits.
AF AF
Address family for the prefix. Currently, the only supported Address family for the prefix. Currently, the only supported
value is 0 for IPv4 unicast. value is 0 for IPv4 unicast.
Address Prefix Address Prefix
The prefix itself encoded as an even multiple of 32-bit words, The prefix itself encoded as an even multiple of 32-bit words,
padded with zeroed bits as necessary. This encoding consumes padded with zeroed bits as necessary. This encoding consumes
((PrefixLength + 31) / 32) 32-bit words. The default route is ((PrefixLength + 31) / 32) 32-bit words. The default route is
represented by a prefix of length 0. represented by a prefix of length 0.
If this TLV is advertised multiple times for the same prefix in the
same OSPFv2 Extended Prefix Opaque LSA, only the first instance is
used by receiving OSPFv2 Routers. This situation SHOULD be logged as
an error.
If this TLV is advertised multiple times for the same prefix in
different OSPFv2 Extended Prefix Opaque LSAs originated by the same
OSPF router, the OSPF advertising router is re-originating Extended
Prefix Opaque LSAs for multiple prefixes and is most likely repacking
Extended-Prefix-TLVs in Extended Prefix Opaque LSAs. In this case,
the Extended-Prefix-TLV in the Extended Prefix Opaque LSA with the
smallest Instance is used by receiving OSPFv2 Routers. This
situation MAY be logged as a warning.
It is RECOMMENDED that OSPF routers advertising Extended-Prefix-TLVs
in different Extended Prefix Opaque LSAs re-originate these LSAs in
ascending order of Instance to minimize the disruption.
If this TLV is advertised multiple times for the same prefix in
different OSPFv2 Extended Prefix Opaque LSAs originated by the
different OSPF routers, the application using the information is
required to determine which OSPFv2 Extended Prefix Opaque LSA is
used. For example, the application could prefer the LSA providing
the best path to the prefix.
This document creates a registry for OSPF Extended Prefix sub-TLVs in This document creates a registry for OSPF Extended Prefix sub-TLVs in
Section 6. Section 6.
3. OSPFv2 Extended Link Opaque LSA 3. OSPFv2 Extended Link Opaque LSA
The OSPFv2 Extended Link Opaque LSA will be used to advertise The OSPFv2 Extended Link Opaque LSA will be used to advertise
additional link attributes. Opaque LSAs are described in [OPAQUE]. additional link attributes. Opaque LSAs are described in [OPAQUE].
The OSPFv2 Extended Link Opaque LSA has an area flooding scope. The OSPFv2 Extended Link Opaque LSA has an area flooding scope.
Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a
skipping to change at page 10, line 10 skipping to change at page 10, line 27
[OPAQUE], the extensions described herein is fully backward [OPAQUE], the extensions described herein is fully backward
compatible. However, future OSPFv2 extensions utilizing these compatible. However, future OSPFv2 extensions utilizing these
extensions must address backward compatibility of the corresponding extensions must address backward compatibility of the corresponding
functionality. functionality.
5. Security Considerations 5. Security Considerations
In general, new LSAs defined in this document are subject to the same In general, new LSAs defined in this document are subject to the same
security concerns as those described in [OSPFV2]. Additionally, security concerns as those described in [OSPFV2]. Additionally,
implementations must assure that malformed TLV and Sub-TLV implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors which cause hard OSPF failures. permutations do not result in errors that cause hard OSPF failures.
6. IANA Considerations 6. IANA Considerations
This specification updates the Opaque Link-State Advertisements (LSA) This specification updates the Opaque Link-State Advertisements (LSA)
Option Types with the following values: Option Types with the following values:
o 7 (IANA Preallocated) - OSPFv2 Extended Prefix Opaque LSA o 7 (IANA Early Allocation [EARLY-ALLOCATION]) - OSPFv2 Extended
Prefix Opaque LSA
o 8 (IANA preallocated) - OSPFv2 Extended Link Opaque LSA o 8 (IANA Early Allocation [EARLY-ALLOCATION]) - OSPFv2 Extended
Link Opaque LSA
This specification also creates four new registries: This specification also creates four new registries:
o OSPF Extended Prefix LSA TLVs o OSPF Extended Prefix LSA TLVs
o OSPF Extended Prefix TLV Sub-TLVs o OSPF Extended Prefix TLV Sub-TLVs
o OSPF Extended Link LSA TLVs o OSPF Extended Link LSA TLVs
o OSPF Extended Link TLV Sub-TLVs o OSPF Extended Link TLV Sub-TLVs
skipping to change at page 11, line 21 skipping to change at page 11, line 42
The following initial values are allocated: The following initial values are allocated:
o 0 - Reserved o 0 - Reserved
Types in the range 32768-33023 are for experimental use; these will Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs. not be registered with IANA, and MUST NOT be mentioned by RFCs.
Types in the range 33024-65535 are not to be assigned at this time. Types in the range 33024-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there Before any assignments can be made in the 33024-65535 range, there
MUST be an IETF specificatin that specifies IANA Considerations that MUST be an IETF specification that specifies IANA Considerations that
covers the range being assigned. covers the range being assigned.
6.3. OSPF Extended Link LSA TLV Registry 6.3. OSPF Extended Link LSA TLV Registry
The OSPF Extend Link LSA TLV registry will define top-level TLVs for The OSPF Extend Link LSA TLV registry will define top-level TLVs for
Extended Link LSAs and should be placed in the existing OSPF IANA Extended Link LSAs and should be placed in the existing OSPF IANA
registry. New values can be allocated via IETF Consensus or IESG registry. New values can be allocated via IETF Consensus or IESG
Approval. Approval.
Following initial values are allocated: Following initial values are allocated:
skipping to change at page 12, line 32 skipping to change at page 13, line 7
[RFC-KEYWORDS] [RFC-KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003. Extensions to OSPF", RFC 3630, September 2003.
7.2. Informative References 7.2. Informative References
[EARLY-ALLOCATION]
Cotton, M., "Early Allocation of Standards Track Code
Points", RFC 7120, January 2014.
[OSPFV3-LSA-EXTEND] [OSPFV3-LSA-EXTEND]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", LSA Extendibility",
draft-ietf-ospf-ospfv3-lsa-extend-02.txt (work in draft-ietf-ospf-ospfv3-lsa-extend-02.txt (work in
progress). progress).
Authors' Addresses Authors' Addresses
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
 End of changes. 29 change blocks. 
36 lines changed or deleted 73 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/