draft-ietf-ccamp-ospf-interas-te-extension-00.txt   draft-ietf-ccamp-ospf-interas-te-extension-01.txt 
Network work group Mach Chen Network work group Mach Chen
Internet Draft Renhai Zhang Internet Draft Renhai Zhang
Expires: December 2007 Huawei Technologies Co.,Ltd Expires: March 2008 Huawei Technologies Co.,Ltd
Category: Standards Track June 6, 2007 Category: Standards Track September 6, 2007
OSPF Traffic Engineering (OSPF-TE) Extensions in Support of Inter-AS OSPF Traffic Engineering (OSPF-TE) Extensions in Support of Inter-AS
Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Traffic Engineering
draft-ietf-ccamp-ospf-interas-te-extension-00.txt draft-ietf-ccamp-ospf-interas-te-extension-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that By submitting this Internet-Draft, each author represents that
any applicable patent or other IPR claims of which he or she is 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 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 becomes aware will be disclosed, in accordance with Section 6 of
BCP 79. BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
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 December 3, 2007. This Internet-Draft will expire on March 6, 2008.
Abstract Abstract
This document describes extensions to the OSPF Traffic Engineering This document describes extensions to the OSPF v2 and v3 Traffic
(OSPF-TE) mechanisms to support Multiprotocol Label Switching (MPLS) Engineering (OSPF-TE) mechanisms to support Multiprotocol Label
and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering(TE)
Autonomous Systems (ASes). It defines OSPF-TE extensions for the for multiple Autonomous Systems (ASes). It defines OSPF-TE extensions
flooding of TE information about inter-AS links which can be used to for the flooding of TE information about inter-AS links which can be
perform inter-AS TE path computation. used to perform inter-AS TE path computation.
Conventions used in this document 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",
"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-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
Table of Contents Table of Contents
1. Introduction.................................................2 1. Introduction.................................................2
2. Problem statement............................................3 2. Problem Statement............................................3
2.1. A Note on Non-Objectives................................3 2.1. A Note on Non-Objectives................................3
2.2. Per-Domain Path Determination...........................4 2.2. Per-Domain Path Determination...........................4
2.3. Backward Recursive Path Computation.....................5 2.3. Backward Recursive Path Computation.....................6
3. Extensions to OSPF-TE........................................6 3. Extensions to OSPF-TE........................................7
3.1. Remote AS Number Sub-TLV................................6 3.1. Remote AS Number Sub-TLV................................7
3.2. Inter-AS Link Type......................................7 3.2. Inter-AS Link Type......................................8
3.3. Link ID.................................................7 3.3. Link ID.................................................8
4. Procedure for Inter-AS TE Links..............................7 4. Procedure for Inter-AS TE Links..............................8
5. Security Considerations......................................8 5. Security Considerations......................................9
6. IANA Considerations..........................................8 6. IANA Considerations.........................................10
6.1. OSPF LSA Sub-TLVs type..................................8 6.1. OSPF LSA Sub-TLVs type.................................10
6.2. OSPF TE Link Type.......................................9 6.2. OSPF TE Link Type......................................10
7. Acknowledgments..............................................9 7. Acknowledgments.............................................10
8. References...................................................9 8. References..................................................11
8.1. Normative References....................................9 8.1. Normative References...................................11
8.2. Informative References.................................10 8.2. Informative References.................................11
Author's Addresses.............................................10 Authors' Addresses.............................................12
Intellectual Property Statement................................11 Intellectual Property Statement................................12
Disclaimer of Validity.........................................11 Disclaimer of Validity.........................................13
Copyright Statement............................................11 Copyright Statement............................................13
1. Introduction 1. Introduction
[OSPF-TE] defines extensions to the OSPF protocol [OSPF] to support [OSPF-TE] defines extensions to the OSPF protocol [OSPF] to support
intra-area Traffic Engineering (TE). The extensions provide a way of intra-area Traffic Engineering (TE). The extensions provide a way of
encoding the TE information for TE-enabled links within the network encoding the TE information for TE-enabled links within the network
(TE links) and flooding this information within an area. Type 10 (TE links) and flooding this information within an area. Type 10
opaque LSAs [RFC2370] are used to carry such TE information. Two top- opaque LSAs [RFC2370] are used to carry such TE information. Two top-
level TLVs are defined in [OSPF-TE]: Router Address TLV and Link TLV. level TLVs are defined in [OSPF-TE]: Router Address TLV and Link TLV.
The Link TLV has several nested sub-TLVs which describe the TE The Link TLV has several nested sub-TLVs which describe the TE
skipping to change at page 3, line 20 skipping to change at page 3, line 20
that connect to other ASes. that connect to other ASes.
In this document, some extensions to OSPF-TE are defined in support In this document, some extensions to OSPF-TE are defined in support
of carrying inter-AS TE link information for inter-AS Traffic of carrying inter-AS TE link information for inter-AS Traffic
Engineering. A new sub-TLV is added to the Link TLV and a new link Engineering. A new sub-TLV is added to the Link TLV and a new link
type is introduced. The extensions are equally applicable to OSPFv2 type is introduced. The extensions are equally applicable to OSPFv2
and OSPFv3 as identical extensions to [OSPF-TE] and [OSPF-TE-V3]. The and OSPFv3 as identical extensions to [OSPF-TE] and [OSPF-TE-V3]. The
detailed definitions and procedures are discussed in the following detailed definitions and procedures are discussed in the following
sections. sections.
2. Problem statement 2. Problem Statement
As described in [INTER-AS-TE-REQ], in the case of establishing an As described in [INTER-AS-TE-REQ], in the case of establishing an
inter-AS TE LSP traversing multiple ASes, the Path message [RFC3209] inter-AS TE LSP traversing multiple ASes, the Path message [RFC3209]
may include the following elements in the Explicit Route Object (ERO) may include the following elements in the Explicit Route Object (ERO)
in order to describe the path of the LSP: in order to describe the path of the LSP:
- a set of AS numbers as loose hops; and/or - a set of AS numbers as loose hops; and/or
- a set of LSRs including ASBRs as loose hops. - a set of LSRs including ASBRs as loose hops.
skipping to change at page 4, line 14 skipping to change at page 4, line 14
o There is no mechanism proposed to distribute any form of TE o There is no mechanism proposed to distribute any form of TE
reachability information for destinations outside the AS. reachability information for destinations outside the AS.
o There is no proposed change to the PCE architecture or usage. o There is no proposed change to the PCE architecture or usage.
o TE aggregation is not supported or recommended. o TE aggregation is not supported or recommended.
o There is no exchange of private information between ASes. o There is no exchange of private information between ASes.
o No OSPF adjacencies are formed on the inter-AS link.
Note further that the extensions proposed in this document are Note further that the extensions proposed in this document are
limited to use for information about inter-AS TE links. L1VPN Auto- limited to use for information about inter-AS TE links. L1VPN Auto-
Discovery [L1VPN-OSPF-AD] defines how TE information about links Discovery [L1VPN-OSPF-AD] defines how TE information about links
between Customer Edge (CE) equipment and Provider Edge (PE) equipment between Customer Edge (CE) equipment and Provider Edge (PE) equipment
can be advertised in OSPF alongside the auto-discovery information can be advertised in OSPF-TE alongside the auto-discovery information
for the CE-PE links. That is separate functionality and does not for the CE-PE links. That is separate functionality and does not
overlap with the function defined in this document. overlap with the function defined in this document.
2.2. Per-Domain Path Determination 2.2. Per-Domain Path Determination
In the per-domain method of determining an inter-AS path for an MPLS- In the per-domain method of determining an inter-AS path for an MPLS-
TE LSP, when an LSR that is an entry-point to an AS receives a PATH TE LSP, when an LSR that is an entry-point to an AS receives a PATH
message from an upstream AS with an ERO containing a next hop that is message from an upstream AS with an ERO containing a next hop that is
an AS number, it needs to find which LSRs within the local AS are an AS number, it needs to find which LSRs (ASBRs) within the local AS
connected to the downstream AS so that it can compute a TE LSP are connected to the downstream AS so that it can compute a TE LSP
segment across the AS to that LSR and forward the PATH message to the segment across the AS to one of those LSRs and forward the PATH
LSR and hence into the next AS. See the figure below for an example: message to the LSR and hence into the next AS. See the figure below
for an example:
R1------R3----R5-----R7------R9-----R11 R1------R3----R5-----R7------R9-----R11
| | \ | / | | | \ | / |
| | \ | ---- | | | \ | ---- |
| | \ | / | | | \ | / |
R2------R4----R6 --R8------R10----R12 R2------R4----R6 --R8------R10----R12
: : : :
<-- AS1 -->:<---- AS2 --->:<--- AS3 ---> <-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 1: Inter-AS Reference Model Figure 1: Inter-AS Reference Model
skipping to change at page 6, line 4 skipping to change at page 6, line 11
throughout the local AS if path computation function is fully throughout the local AS if path computation function is fully
distributed among LSRs in the local AS, for example to support LSPs distributed among LSRs in the local AS, for example to support LSPs
that have start points (ingress nodes) within the AS. that have start points (ingress nodes) within the AS.
2.3. Backward Recursive Path Computation 2.3. Backward Recursive Path Computation
Another scenario using PCE techniques has the same problem. [BRPC] Another scenario using PCE techniques has the same problem. [BRPC]
defines a PCE-based TE LSP computation method (called Backward defines a PCE-based TE LSP computation method (called Backward
Recursive Path Computation) to compute optimal inter-domain Recursive Path Computation) to compute optimal inter-domain
constrained MPLS-TE or GMPLS LSPs. In this path computation method, a constrained MPLS-TE or GMPLS LSPs. In this path computation method, a
specific set of traversed domains are assumed to be selected before specific set of traversed domains (ASes) are assumed to be selected
computation starts. Each downstream PCE in domain(i) returns a before computation starts. Each downstream PCE in domain(i) returns
multipoint-to-point tree of potential paths to its upstream neighbor to its upstream neighbor PCE in domain(i-1) a multipoint-to-point
PCE in domain(i-1). Each tree consists of the set of paths from all tree of potential paths. Each tree consists of the set of paths from
Boundary Nodes located in domain(i) to the destination where each all Boundary Nodes located in domain(i) to the destination where each
path satisfies the set of required constraints for the TE LSP path satisfies the set of required constraints for the TE LSP
(bandwidth, affinities, etc.). (bandwidth, affinities, etc.).
So a PCE needs to select Boundary Nodes (that is, ASBRs) that provide So a PCE needs to select Boundary Nodes (that is, ASBRs) that provide
connectivity from the upstream AS. In order that the tree of paths connectivity from the upstream AS. In order that the tree of paths
provided by one PCE to its neighbor can be correlated, the identities provided by one PCE to its neighbor can be correlated, the identities
of the ASBRs for each path need to be referenced, so the PCE must of the ASBRs for each path need to be referenced, so the PCE must
know the identities of the ASBRs in the remote AS reached by any know the identities of the ASBRs in the remote AS reached by any
inter-AS TE link, and, in order that it provides only suitable paths inter-AS TE link, and, in order that it provides only suitable paths
in the tree, the PCE must know the TE properties of the inter-AS TE in the tree, the PCE must know the TE properties of the inter-AS TE
links. links. See the following figure as an example:
PCE1<------>PCE2<-------->PCE3
/ : :
/ : :
R1------R3----R5-----R7------R9-----R11
| | \ | / |
| | \ | ---- |
| | \ | / |
R2------R4----R6 --R8------R10----R12
: :
<-- AS1 -->:<---- AS2 --->:<--- AS3 --->
Figure 2: BRPC for Inter-AS Reference Model
The figure shows three ASes (AS1, AS2, and AS3), three PCEs (PCE1,
PCE2, and PCE3), and twelve LSRs (R1 through R12). R3 and R4 are
ASBRs in AS1. R5, R6, R7, and R8 are ASBRs in AS2. R9 and R10 are
ASBRs in AS3. PCE1, PCE2, and PCE3 cooperate to perform inter-AS path
computation and are responsible for path segment computation within
their own domains.
If an inter-AS TE LSP is planned to be established from R1 to R12,
the traversed domains are assumed to be selected: AS1->AS2->AS3, and
the PCE chain is: PCE1->PCE2->PCE3. First, the path computation
request originated from the PCC (R1) is relayed by PCE1 and PCE2
along the PCE chain to PCE3, then PCE3 begins to compute the path
segments from the entry boundary nodes that provide connection from
AS2 to the destination (R12). But, to provide suitable path segments,
PCE3 must determine which entry boundary nodes provide connectivity
to its upstream neighbor AS (identified by its AS number), and must
know the TE properties of the inter-AS TE links. In the same way,
PCE2 also needs to determine the entry boundary nodes according to
its upstream neighbor AS and the inter-AS TE link capabilities.
Thus, to support Backward Recursive Path Computation the same Thus, to support Backward Recursive Path Computation the same
information as listed in Section 2.2 is required. information as listed in Section 2.2 is required.
3. Extensions to OSPF-TE 3. Extensions to OSPF-TE
Note that this document does not define mechanisms for distribution Note that this document does not define mechanisms for distribution
of TE information from one AS to another, does not distribute any of TE information from one AS to another, does not distribute any
form of TE reachability information for destinations outside the AS, form of TE reachability information for destinations outside the AS,
does not change the PCE architecture or usage, does not suggest or does not change the PCE architecture or usage, does not suggest or
skipping to change at page 6, line 45 skipping to change at page 7, line 37
link type. A new sub-TLV to the Link TLV is defined to carry the link type. A new sub-TLV to the Link TLV is defined to carry the
information about the neighboring AS. The extensions are equally information about the neighboring AS. The extensions are equally
applicable to TE distribution using OSPFv2 and OSPFv3. applicable to TE distribution using OSPFv2 and OSPFv3.
3.1. Remote AS Number Sub-TLV 3.1. Remote AS Number Sub-TLV
As described in [OSPF-TE], the Link TLV describes a single link and As described in [OSPF-TE], the Link TLV describes a single link and
consists of a set of sub-TLVs. A new sub-TLV, the Remote AS Number consists of a set of sub-TLVs. A new sub-TLV, the Remote AS Number
sub-TLV is added to the Link TLV when advertising inter-AS links. The sub-TLV is added to the Link TLV when advertising inter-AS links. The
Remote AS Number sub-TLV specifies the AS number of the neighboring Remote AS Number sub-TLV specifies the AS number of the neighboring
AS to which the advertised link connects. AS to which the advertised link connects. The Remote AS number sub-
TLV is mandatory for an inter-AS TE link.
The Remote AS number sub-TLV is TLV type 21 (which needs to be The Remote AS number sub-TLV is TLV type 21 (which needs to be
confirmed by IANA), and is four octets in length. The format is as confirmed by IANA), and is four octets in length. The format is as
follows: follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number | | Remote AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Remote AS number field has 4 octets. When two octets are used for The Remote AS number field has 4 octets. When only two octets are
the AS number, as in current deployments, the left (high-order) two used for the AS number, as in current deployments, the left (high-
octets MUST be set to zero. order) two octets MUST be set to zero.
3.2. Inter-AS Link Type 3.2. Inter-AS Link Type
To identify a link as an inter-AS link and allow easy identification To identify a link as an inter-AS link and allow easy identification
of these new advertisements, a new Link Type value is defined for use of these new advertisements, a new Link Type value is defined for use
in the Link Type sub-TLV. The value of the Link Type for an inter-AS in the Link Type sub-TLV. The value of the Link Type for an inter-AS
point-to-point link is 3 (which needs to be confirmed by IANA). The point-to-point link is 3 (which needs to be confirmed by IANA).
use of multi-access inter-AS TE links is for future study.
The use of multi-access inter-AS TE links is for future study.
3.3. Link ID 3.3. Link ID
For an inter-AS link, the Link ID carried in the Link ID sub-TLV is For an inter-AS link, the Link ID carried in the Link ID sub-TLV is
the TE Router ID of the remote ASBR reached through this inter-AS the remote ASBR identifier which could be any address of the remote
link. ASBR(e.g., the TE Router ID, Router ID or interface address of the
remote ASBR reached through this inter-AS link). The TE Router ID is
RECOMMENDED.
4. Procedure for Inter-AS TE Links 4. Procedure for Inter-AS TE Links
When TE is enabled on an inter-AS link and the link is up, the ASBR When TE is enabled on an inter-AS link and the link is up, the ASBR
SHOULD advertise this link using the normal procedures for OSPF-TE SHOULD advertise this link using the normal procedures for OSPF-TE
[OSPF-TE]. When either the link is down or TE is disabled on the [OSPF-TE]. When either the link is down or TE is disabled on the
link , the ASBR SHOULD withdraw the advertisement. When there are link , the ASBR SHOULD withdraw the advertisement. When there are
changes to the TE parameters for the link (for example, when the changes to the TE parameters for the link (for example, when the
available bandwidth changes) the ASBR SHOULD re-advertise the link, available bandwidth changes) the ASBR SHOULD re-advertise the link,
but the ASBR MUST take precautions against excessive re- but the ASBR MUST take precautions against excessive re-
advertisements as described in [OSPF-TE]. advertisements as described in [OSPF-TE].
Hellos MUST NOT be exchanged (and consequently, an OSPF adjacency
MUST NOT be formed) over the inter-AS link.
The information advertised comes from the ASBR's knowledge of the TE The information advertised comes from the ASBR's knowledge of the TE
capabilities of the link, the ASBR's knowledge of the current status capabilities of the link, the ASBR's knowledge of the current status
and usage of the link, and configuration at the ASBR of the remote AS and usage of the link, and configuration at the ASBR of the remote AS
number and remote ASBR TE Router ID. number and remote ASBR TE Router ID.
The TE link advertisement SHOULD be carried in a Type 10 Opaque LSA The TE link advertisement SHOULD be carried in a Type 10 Opaque LSA
if the flooding scope is to be limited to within the single IGP area if the flooding scope is to be limited to within the single IGP area
to which the ASBR belongs, or MAY be carried in a Type 11 Opaque LSA to which the ASBR belongs, or MAY be carried in a Type 11 Opaque LSA
if the information should reach all routers (including area border if the information should reach all routers (including area border
routers, ASBRs, and PCEs) in the AS. routers, ASBRs, and PCEs) in the AS. The choice between the use of a
Type 10 or Type 11 Opaque LSA is a network-wide policy choice, and
configuration control SHOULD be provided in ASBR implementations that
support the advertisement of inter-AS TE links.
Legacy routers receiving an advertisement for an inter-AS TE link are Legacy routers receiving an advertisement for an inter-AS TE link are
able to ignore it because the Link Type carries an unknown value. able to ignore it because the Link Type carries an unknown value.
They will continue to flood the LSA, but will not attempt to use the They will continue to flood the LSA, but will not attempt to use the
information received as if the link were an intra-AS TE link. information received as if the link were an intra-AS TE link.
Since there is no OSPF adjacency running on the inter-AS link, the
local ASBR SHOULD do a "proxy" advertisement for the backward
direction of an inter-AS TE link, which facilitates a path
computation entity to do a 2-way check before including the link in a
path computation. As the objective of such a "proxy" advertisement is
to avoid using an inter-AS TE link when the backward direction of the
inter-AS TE link is unavailable or unsuitable, only some mandatory or
essential TE information needs to be advertised, i.e. the Link ID,
the Link Type, and the Remote AS number of an inter-AS TE link.
Routers or PCEs that are capable of processing advertisements of Routers or PCEs that are capable of processing advertisements of
inter-AS TE links SHOULD NOT use such links to compute paths that inter-AS TE links SHOULD NOT use such links to compute paths that
exit an AS to a remote ASBR and then immediately re-enter the AS exit an AS to a remote ASBR and then immediately re-enter the AS
through another TE link. Such paths would constitute extremely rare through another TE link. Such paths would constitute extremely rare
occurrences and SHOULD NOT be allowed except as the result of occurrences and SHOULD NOT be allowed except as the result of
specific policy configurations at the router or PCE computing the specific policy configurations at the router or PCE computing the
path. path.
5. Security Considerations 5. Security Considerations
The protocol extensions defined in this document are relatively minor The protocol extensions defined in this document are relatively minor
and can be secured within the AS in which they are used by the and can be secured within the AS in which they are used by the
existing OSPF security mechanisms. existing OSPF security mechanisms.
There is no exchange of information between ASes, and no change to
the OSPF security relationship between the ASes. In particular, since
no OSPF adjacency is formed on the inter-AS links, there is no
requirement for OSPF security between the ASes.
It should be noted, however, that some of the information included in It should be noted, however, that some of the information included in
these new advertisements(the remote AS number and the remote ASBR ID) these new advertisements(the remote AS number and the remote ASBR ID)
are obtained from a neighboring administration and cannot be verified are obtained from a neighboring administration and cannot be verified
in anyway. Since the means of delivery of this information is likely in anyway. Since the means of delivery of this information is likely
to be part of a commercial relationship, the source of the to be part of a commercial relationship, the source of the
information should be carefully checked before it is entered as information should be carefully checked before it is entered as
configuration information at the ASBR responsible for advertising the configuration information at the ASBR responsible for advertising the
inter-AS TE links. inter-AS TE links.
6. IANA Considerations 6. IANA Considerations
IANA is requested to make the following allocations from registries IANA is requested to make the following allocations from registries
under its control. under its control.
6.1. OSPF LSA Sub-TLVs type 6.1. OSPF LSA Sub-TLVs type
IANA maintains the "Open Shortest Path First (OSPF) Traffic IANA maintains the "Open Shortest Path First (OSPF) Traffic
Engineering TLVs" registry with sub-registry "Types for sub-TLVs in a Engineering TLVs" registry with sub-registry "Types for sub-TLVs in a
TE Link TLV". IANA is requested to assign a new sub-TLV as follows. TE Link TLV". IANA is requested to assign a new sub-TLV as follows.
The number 21 is suggested. The number 21 is suggested as shown in Section 3.1.
Value Meaning Value Meaning
21 Remote AS Number sub-TLV. 21 Remote AS Number sub-TLV.
6.2. OSPF TE Link Type 6.2. OSPF TE Link Type
IANA is requested to create a new sub-registry "TE Link Types" of the IANA is requested to create a new sub-registry "TE Link Types" of the
registry "Open Shortest Path First (OSPF) Traffic Engineering TLVs" registry "Open Shortest Path First (OSPF) Traffic Engineering TLVs"
to track TE Link Types. to track TE Link Types.
skipping to change at page 9, line 29 skipping to change at page 10, line 49
2 Multi-access link [OSPF-TE] 2 Multi-access link [OSPF-TE]
3 Inter-AS link [this document] 3 Inter-AS link [this document]
New allocations from this registry are by IETF Standards Action. New allocations from this registry are by IETF Standards Action.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Adrian Farrel, Acee Lindem, JP The authors would like to thank Adrian Farrel, Acee Lindem, JP
Vasseur, and Dean Cheng for their review and comments to this Vasseur, Dean Cheng, and Jean-Louis Le Roux for their review and
document. comments to this document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
skipping to change at page 10, line 35 skipping to change at page 12, line 9
Element (PCE)-Based Architecture", RFC4655, August 2006. Element (PCE)-Based Architecture", RFC4655, August 2006.
[OSPF-TE-V3] Ishiguro K., Manral V., Davey A., and Lindem A. "Traffic [OSPF-TE-V3] Ishiguro K., Manral V., Davey A., and Lindem A. "Traffic
Engineering Extensions to OSPF version 3", draft-ietf-ospf- Engineering Extensions to OSPF version 3", draft-ietf-ospf-
ospfv3-traffic, {work in progress}. ospfv3-traffic, {work in progress}.
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
2740, April 1998. 2740, April 1998.
[L1VPN-OSPF-AD] Bryskin, I., and Berger, L., "OSPF Based L1VPN Auto- [L1VPN-OSPF-AD] Bryskin, I., and Berger, L., "OSPF Based L1VPN Auto-
Discovery", draft-ietf-l1vpn-ospf-auto-discovery-02.txt, Discovery", draft-ietf-l1vpn-ospf-auto-discovery, (work in
(work in progress). progress).
Author's Addresses Authors' Addresses
Mach Chen Mach Chen
Huawei Technologies Co.,Ltd Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd., KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District Hai-Dian District
Beijing, 100085 Beijing, 100085
P.R. China P.R. China
Email: mach@huawei.com Email: mach@huawei.com
Renhai Zhang Renhai Zhang
Huawei Technologies Co.,Ltd Huawei Technologies Co.,Ltd
KuiKe Building, No.9 Xinxi Rd., KuiKe Building, No.9 Xinxi Rd.,
Hai-Dian District Hai-Dian District
Beijing, 100085 Beijing, 100085
P.R. China P.R. China
Email: zhangrenhai@huawei.com Email: zhangrenhai@huawei.com
Intellectual Property Statement Intellectual Property Statement
 End of changes. 25 change blocks. 
56 lines changed or deleted 118 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/