draft-ietf-ccamp-automesh-04.txt   rfc4972.txt 
Networking Working Group JP. Vasseur, Ed. Network Working Group JP. Vasseur, Ed.
Internet-Draft Cisco Systems, Inc Request for Comments: 4972 Cisco Systems, Inc
Intended status: Standards Track JL. Leroux, Ed. Category: Standards Track JL. Leroux, Ed.
Expires: July 27, 2007 France Telecom France Telecom
S. Yasukawa S. Yasukawa
NTT NTT
S. Previdi S. Previdi
P. Psenak P. Psenak
Cisco Systems, Inc Cisco Systems, Inc
P. Mabbey P. Mabbey
Comcast Comcast
January 23, 2007 Routing Extensions for Discovery of Multiprotocol (MPLS)
Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership
Routing extensions for discovery of Multiprotocol (MPLS) Label Switch
Router (LSR) Traffic Engineering (TE) mesh membership
draft-ietf-ccamp-automesh-04.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/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 27, 2007. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
The set up of a full mesh of Multi-Protocol Label Switching (MPLS) The set up of a full mesh of Multi-Protocol Label Switching (MPLS)
Traffic Engineering (TE) Label Switched Paths (LSP) among a set of Traffic Engineering (TE) Label Switched Paths (LSP) among a set of
Label Switch Routers (LSR) is a common deployment scenario of MPLS Label Switch Routers (LSR) is a common deployment scenario of MPLS
Traffic Engineering either for bandwidth optimization, bandwidth Traffic Engineering either for bandwidth optimization, bandwidth
guarantees or fast rerouting with MPLS Fast Reroute. Such deployment guarantees or fast rerouting with MPLS Fast Reroute. Such deployment
may require the configuration of potentially a large number of TE may require the configuration of a potentially large number of TE
LSPs (on the order of the square of the number LSRs). This document LSPs (on the order of the square of the number of LSRs). This
specifies Interior Gateway Protocol (IGP) routing extensions for document specifies Interior Gateway Protocol (IGP) routing extensions
Intermediate System-to-Intermediate System (IS-IS) and Open Shortest for Intermediate System-to-Intermediate System (IS-IS) and Open
Path First (OSPF) so as to provide an automatic discovery of the set Shortest Path First (OSPF) so as to provide an automatic discovery of
of LSRs members of a mesh in order to automate the creation of such the set of LSRs members of a mesh in order to automate the creation
mesh of TE LSPs. of such mesh of TE LSPs.
Requirements Language
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 RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction ....................................................2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions .....................................................3
3. Description of a TE Mesh-Group . . . . . . . . . . . . . . . . 5 2.1. Conventions Used in This Document ..........................4
4. TE-MESH-GROUP TLV formats . . . . . . . . . . . . . . . . . . 6 3. Description of a TE Mesh-Group ..................................4
4.1. OSPF TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 6 4. TE-MESH-GROUP TLV Formats .......................................4
4.2. IS-IS TE-MESH-GROUP sub-TLV format . . . . . . . . . . . . 8 4.1. OSPF TE-MESH-GROUP TLV Format ..............................4
5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 9 4.2. IS-IS TE-MESH-GROUP Sub-TLV Format .........................7
5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Elements of Procedure ...........................................9
5.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. OSPF .......................................................9
6. Backward compatibility . . . . . . . . . . . . . . . . . . . . 12 5.2. IS-IS .....................................................10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Backward Compatibility .........................................11
7.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations ............................................11
7.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. OSPF ......................................................11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7.2. IS-IS .....................................................11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations ........................................12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgements ...............................................12
10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 10. References ....................................................12
10.2. Informative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References .....................................12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 10.2. Informative References ...................................13
Intellectual Property and Copyright Statements . . . . . . . . . . 16
1. Terminology
Terminology used in this document
IGP: Interior Gateway Protocol.
IGP Area: OSPF area or IS-IS level.
IS-IS: Intermediate System-to-Intermediate System (IS-IS).
LSR: Label Switch Router.
OSPF: Open Shortest Path First (OSPF).
OSPF LSA: OSPF Link State Advertisement.
TE LSP: Traffic Engineering Label Switched Path.
TE LSP head-end: head/source of the TE LSP.
TE LSP tail-end: tail/destination of the TE LSP.
TLV: Type Lenght Value
2. Introduction 1. Introduction
There are two well-known approaches in deploying MPLS Traffic There are two well-known approaches in deploying MPLS Traffic
Engineering: Engineering:
(1) The so-called "strategic" approach that consists of setting up a (1) The so-called "strategic" approach that consists of setting up a
full mesh of TE LSPs between a set of LSRs, full mesh of TE LSPs between a set of LSRs.
(2) The so-called "tactical" approach where a set of TE LSPs are (2) The so-called "tactical" approach, where a set of TE LSPs are
provisioned on well identified "hot spots" in order to alleviate a provisioned on well-identified "hot spots" in order to alleviate a
congestion resulting for instance from an unexpected traffic growth congestion resulting, for instance, from an unexpected traffic growth
in some parts of the network. in some parts of the network.
The set up of a full mesh of TE LSPs among a set of LSRs is a common The set up of a full mesh of TE LSPs among a set of LSRs is a common
deployment scenario of MPLS Traffic Engineering either for bandwidth deployment scenario of MPLS Traffic Engineering either for bandwidth
optimization, bandwidth guarantees or fast rerouting with MPLS Fast optimization, bandwidth guarantees, or fast rerouting with MPLS Fast
Reroute. Setting up a full mesh of TE LSPs between N LSRs requires Reroute. Setting up a full mesh of TE LSPs between N LSRs requires
the configuration of a potentially large number of TE LSPs (O(N^2)). the configuration of a potentially large number of TE LSPs (O(N^2)).
Furthermore, the addition of any new LSR in the mesh requires the Furthermore, the addition of any new LSR in the mesh requires the
configuration of N additional TE LSPs on the new LSR and one new TE configuration of N additional TE LSPs on the new LSR and one new TE
LSP on every LSR of the existing mesh destined to this new LSR, which LSP on every LSR of the existing mesh destined to this new LSR, which
gives a total of 2*N TE LSPs to be configured. Such operation is not gives a total of 2*N TE LSPs to be configured. Such an operation is
only time consuming but also a risky operation (prone to not only time consuming but also risky (prone to misconfiguration)
misconfiguration) for Service Providers. Hence, an automatic for Service Providers. Hence, an automatic mechanism for setting up
mechanism for setting up TE LSPs meshes is desirable and requires the TE LSPs meshes is desirable and requires the ability to automatically
ability to automatically discover the set of LSRs that belong to the discover the set of LSRs that belong to the mesh. This document
mesh. This document specifies routing extensions so as to specifies routing extensions so as to automatically discover the
automatically discover the members of a mesh, also referred to as a members of a mesh, also referred to as a "TE mesh-group". Note that
"TE mesh-group". Note that the mechanism(s) needed for the dynamic the mechanism(s) needed for the dynamic creation of TE LSPs is
creation of TE LSPs is implementation specific and outside the scope implementation specific and outside the scope of this document.
of this document.
Routing extensions have been defined in [I-D.ietf-ospf-cap] and Routing extensions have been defined in [RFC4970] and [RFC4971] in
[I-D.ietf-isis-caps] in order to advertise router capabilities. This order to advertise router capabilities. This document specifies IGP
document specifies IGP (OSPF and IS-IS) TE Mesh Group (Type Lenght (OSPF and IS-IS) TE Mesh Group (Type Length Value) TLVs allowing for
Value) TLVs allowing for the automatic discovery of a TE mesh-group the automatic discovery of a TE mesh-group members, to be carried in
members, to be carried in the OSPF Router Information (Link State the OSPF Router Information (Link State Advertisement) LSA [RFC4970]
Advertisement) LSA [I-D.ietf-ospf-cap] and IS-IS Router Capability and IS-IS Router Capability TLV [RFC4971]. The routing extensions
TLV [I-D.ietf-isis-caps]. The routing extensions specified in this specified in this document provide the ability to signal multiple TE
document provide the ability to signal multiple TE mesh groups. An mesh groups. An LSR may belong to more than one TE mesh-group(s).
LSR may belong to more than one TE mesh-group(s).
There are relatively tight real-time constraints on the operation of There are relatively tight real-time constraints on the operation of
IGPs (such as OSPF and IS-IS). For this reason some care needs to be IGPs (such as OSPF and IS-IS). For this reason, some care needs to
applied when proposing to carry additional information in an IGP. be applied when proposing to carry additional information in an IGP.
The information described in this document is both relatively small The information described in this document is both relatively small
in total volume (compared with other information already carried in in total volume (compared with other information already carried in
IGPs), and also relatively stable (ie, changes are based on IGPs), and also relatively stable (i.e., changes are based on
configuration changes, but not based on dynamic events within the configuration changes, but not on dynamic events within the network,
network, and not based on dynamic triggers such as the leaking of or on dynamic triggers, such as the leaking of information from other
information from other routing protocols or routing protocol routing protocols or routing protocol instances).
instances).
2. Definitions
Terminology used in this document
IGP: Interior Gateway Protocol
IGP Area: OSPF area or IS-IS level
IS-IS: Intermediate System-to-Intermediate System (IS-IS)
LSR: Label Switch Router
OSPF: Open Shortest Path First
OSPF LSA: OSPF Link State Advertisement
TE LSP: Traffic Engineering Label Switched Path
TE LSP head-end: head/source of the TE LSP
TE LSP tail-end: tail/destination of the TE LSP.
TLV: Type Length Value
2.1. 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 RFC 2119 [RFC2119].
3. Description of a TE Mesh-Group 3. Description of a TE Mesh-Group
A TE mesh-group is defined as a group of LSRs that are connected by a A TE mesh-group is defined as a group of LSRs that are connected by a
full mesh of TE LSPs. Routing extensions are specified in this full mesh of TE LSPs. Routing extensions are specified in this
document allowing for dynamic discovery of the TE mesh-group members. document, allowing for dynamic discovery of the TE mesh-group
Procedures are also specified for a member to join and leave a TE members. Procedures are also specified for a member to join and
mesh-group. For each TE mesh-group membership announced by an LSR, leave a TE mesh-group. For each TE mesh-group membership announced
the following information is avdertized: by an LSR, the following information is advertised:
- A mesh-group number identifying the TE mesh-group the LSR belongs - A mesh-group number identifying the TE mesh-group that the LSR
to, belongs to,
- A Tail-end address (used as the TE LSP Tail-end address by other - A tail-end address (used as the TE LSP Tail-end address by other
LSRs belonging to the same mesh-group), LSRs belonging to the same mesh-group),
- A Tail-end name: a display string that is allocated to the Tail-end - A tail-end name: a display string that is allocated to the tail-
used to ease the TE-LSP naming. end used to ease the TE-LSP naming.
4. TE-MESH-GROUP TLV formats 4. TE-MESH-GROUP TLV Formats
4.1. OSPF TE-MESH-GROUP TLV format 4.1. OSPF TE-MESH-GROUP TLV Format
The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to
join/leave a given TE mesh-group. No sub-TLV is currently defined join/leave a given TE mesh-group. No sub-TLV is currently defined
for the TE-MESH-GROUP TLV. for the TE-MESH-GROUP TLV.
The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information
LSA defined in [I-D.ietf-ospf-cap]) has the following format: LSA defined in [RFC4970]) 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Value // // Value //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - OSPF TE-MESH-GROUP TLV format Figure 1 - OSPF TE-MESH-GROUP TLV format
Where Where
Type: identifies the TLV type Type: identifies the TLV type
Length: length of the value field in octets Length: the length of the value field in octets
The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV
format used by the Traffic Engineering Extensions to OSPF format used by the Traffic Engineering Extensions to OSPF
(see[RFC3630]). The TLV is padded to four-octet alignment; padding (see[RFC3630]). The TLV is padded to a four-octet alignment; padding
is not included in the length field (so a three octet value would is not included in the length field (so a three-octet value would
have a length of three, but the total size of the TLV would be eight have a length of three, but the total size of the TLV would be eight
octets). Nested TLVs are also 32-bit aligned. Unrecognized types octets). Nested TLVs are also 32-bit aligned. Unrecognized types
are ignored. All types between 32768 and 65535 are reserved for are ignored. All types between 32768 and 65535 are reserved for
vendor-specific extensions. All other undefined type codes are vendor-specific extensions. All other undefined type codes are
reserved for future assignment by IANA. reserved for future assignment by IANA.
The OSPF TE-MESH-GROUP TLV format for IPv4 (figure 2) and IPv6 The OSPF TE-MESH-GROUP TLV format for IPv4 (Figure 2) and IPv6
(figure 3) is as follows: (Figure 3) is as follows:
TYPE: To be assigned by IANA (Suggested Value: 3)
TYPE: 3
LENGTH: Variable LENGTH: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 | | mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address 1 | | Tail-end IPv4 address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 | | Name length | Tail-end name 1 |
skipping to change at page 7, line 15 skipping to change at page 6, line 4
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n | | mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address n | | Tail-end IPv4 address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n | | Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address)
TYPE: 4
TYPE: To be assigned by IANA (Suggested Value: 4)
LENGTH: Variable LENGTH: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 | | mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Tail-end IPv6 address 1 | | Tail-end IPv6 address 1 |
| | | |
skipping to change at page 7, line 45 skipping to change at page 6, line 33
| | | |
| Tail-end IPv6 address n | | Tail-end IPv6 address n |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n | | Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address) Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address)
The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group entries The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group
where each entry correspond to a TE mesh-group and is made of the entries, where each entry corresponds to a TE mesh-group and is made
following fields: of the following fields:
- A mesh-group-number that identifies the mesh-group number.
- A mesh-group-number that identifies the mesh-group number,
- A Tail-end address: an IPv4 or IPv6 IP address to be used as a - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
tail-end TE LSP address by other LSRs belonging to the same mesh- tail-end TE LSP address by other LSRs belonging to the same mesh-
group, group.
- Name length field: An integer, expressed in octets, that indicates
the length of the Tail-end name before padding.
- A Tail-end name: A display string that is allocated to the Tail- - A Tail-end name: A display string that is allocated to the Tail-
end. The field is of variable length field and is used to facilitate end. The field is of variable length field and is used to
the TE LSP identification. - Name length field: An integer, expressed facilitate the TE LSP identification.
in octets, that indicates the length of the Tail-end name before
padding.
4.2. IS-IS TE-MESH-GROUP sub-TLV format 4.2. IS-IS TE-MESH-GROUP Sub-TLV Format
The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR
to join/leave a given TE mesh-group. No sub-TLV is currently defined to join/leave a given TE mesh-group. No sub-TLV is currently defined
for the TE-MESH-GROUP sub-TLV. for the TE-MESH-GROUP sub-TLV.
The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY
TLV defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the TLV defined in [RFC4971]) is composed of 1 octet for the type, 1
type, 1 octet specifying the TLV length and a value field. The octet specifying the TLV length and a value field. The format of the
format of the TE-MESH-GROUP sub-TLV is identical to the TLV format TE-MESH-GROUP sub-TLV is identical to the TLV format used by the
used by the Traffic Engineering Extensions for IS-IS [RFC3784]. Traffic Engineering Extensions for IS-IS [RFC3784].
The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (figure 4) and IPv6 The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (Figure 4) and IPv6
(figure 5) is as follows: (Figure 5) is as follows:
TYPE: To be assigned by IANA (Suggested value: 3).
TYPE: 3
LENGTH: Variable LENGTH: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 | | mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address 1 | | Tail-end IPv4 address 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name 1 | | Name length | Tail-end name 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number n | | mesh-group-number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tail-end IPv4 address n | | Tail-end IPv4 address n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n | | Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address) Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address)
TYPE: 4
TYPE: To be assigned by IANA (Suggested Value: 4)
LENGTH: Variable LENGTH: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| mesh-group-number 1 | | mesh-group-number 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Tail-end IPv6 address 1 | | Tail-end IPv6 address 1 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 34 skipping to change at page 8, line 37
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Name length | Tail-end name n | | Name length | Tail-end name n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address) Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address)
The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group
entries where each entry correspond to a TE mesh-group and is made of entries where each entry correspond to a TE mesh-group and is made of
the following fields: the following fields:
- A mesh-group-number that identifies the mesh-group number, - A mesh-group-number that identifies the mesh-group number.
- A Tail-end address: an IPv4 or IPv6 IP address to be used as a - A Tail-end address: an IPv4 or IPv6 IP address to be used as a
tail-end TE LSP address by other LSRs belonging to the same mesh- tail-end TE LSP address by other LSRs belonging to the same mesh-
group, group.
- Name length field: An integer, expressed in octets, that indicates
the length of the Tail-end name before padding.
- A Tail-end name: A display string that is allocated to the Tail- - A Tail-end name: A display string that is allocated to the Tail-
end. The field is of variable length field and is used to facilitate end. The field is of variable length and is used to facilitate
the TE LSP identification. - Name length field: An integer, expressed the TE LSP identification.
in octets, that indicates the length of the Tail-end name before
padding.
5. Elements of procedure 5. Elements of Procedure
The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing
Information LSA and the TE-MESH-GROUP sub-TLV is caried within the Information LSA and the IS-IS TE-MESH-GROUP sub-TLV is carried within
IS-IS Router capability TLV. As such, elements of procedure are the IS-IS Router capability TLV. As such, elements of procedure are
inherited from those defined in [I-D.ietf-ospf-cap] and inherited from those defined in [RFC4970] and [RFC4971] for OSPF and
[I-D.ietf-isis-caps] for OSPF and IS-IS respectively. Specifically, IS-IS respectively. Specifically, a router MUST originate a new
a router MUST originate a new LSA/LSP whenever the content of this LSA/LSP whenever the content of this information changes, or whenever
information changes, or whenever required by regular routing required by regular routing procedure (e.g., updates).
procedure (e.g. update).
The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one
of each of the IPv4 instance or the IPv6 instance. If either the of each of the IPv4 instances or the IPv6 instance. If either the
IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within
the OSPF Router Information LSA, only the first instance is the OSPF Router Information LSA, only the first instance is
processed, subsequent TLV(s) SHOULD be silently ignored. Similarly, processed, subsequent TLV(s) SHOULD be silently ignored. Similarly,
if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs
more than once within the ISIS Router capability TLV, only the first more than once within the IS-IS Router capability TLV, only the first
instance is processed, subsequent TLV(s) SHOULD be silently ignored. instance is processed, subsequent TLV(s) SHOULD be silently ignored.
5.1. OSPF 5.1. OSPF
The TE-MESH-GROUP TLV is advertised within an OSPF Router Information The TE-MESH-GROUP TLV is advertised within an OSPF Router Information
opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 [RFC2328]
and within a new LSA (Router Information LSA) for OSPFv3 ([RFC2740]). and within a new LSA (Router Information LSA) for OSPFv3 [RFC2740].
The Router Information LSAs for OSPFv2 and OSPFv3 are defined in The Router Information LSAs for OSPFv2 and OSPFv3 are defined in
([I-D.ietf-ospf-cap]). [RFC4970].
A router MUST originate a new OSPF router information LSA whenever A router MUST originate a new OSPF router information LSA whenever
the content of the any of the advertised TLV changes or whenever the content of any of the advertised TLV changes or whenever required
required by the regular OSPF procedure (LSA update (every by the regular OSPF procedure (LSA update (every LSRefreshTime)). If
LSRefreshTime)). If an LSR desires to join or leave a particular TE an LSR desires to join or leave a particular TE mesh group, it MUST
mesh group, it MUST originate a new OSPF Router Information LSA originate a new OSPF Router Information LSA comprising the updated
comprising the updated TE-MESH-GROUP TLV. In the case of a join, a TE-MESH-GROUP TLV. In the case of a join, a new entry will be added
new entry will be added to the TE-MESH-GROUP TLV; conversely, if the to the TE-MESH-GROUP TLV; conversely, if the LSR leaves, a mesh-group
LSR leaves a mesh-group the corresponding entry will be removed from the corresponding entry will be removed from the TE-MESH-GROUP TLV.
the TE-MESH-GROUP TLV. Note that both operations can be performed in Note that both operations can be performed in the context of a single
the context of a single LSA update. An implementation SHOULD be able LSA update. An implementation SHOULD be able to detect any change to
to detect any change to a previously received TE-MESH-GROUP TLV from a previously received TE-MESH-GROUP TLV from a specific LSR.
a specific LSR.
As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the
flooding scope of the Router Information LSA is determined by the LSA flooding scope of the Router Information LSA is determined by the LSA
Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3.
For OSPFv2 Router Information opaque LSA: For OSPFv2 Router Information opaque LSA:
- Link-local scope: type 9; - Link-local scope: type 9;
- Area-local scope: type 10; - Area-local scope: type 10;
- Routing-domain scope: type 11. In this case, the flooding scope is - Routing-domain scope: type 11. In this case, the flooding scope
equivalent to the Type 5 LSA flooding scope. is equivalent to the Type 5 LSA flooding scope.
For OSPFv3 Router Information LSA: For OSPFv3 Router Information LSA:
- Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 - Link-local scope: OSPFv3 Router Information LSA with the S1 and S2
bits cleared; bits cleared;
- Area-local scope: OSPFV3 Router Information LSA with the S1 bit set - Area-local scope: OSPFv3 Router Information LSA with the S1 bit
and the S2 bit cleared; set and the S2 bit cleared;
- Routing-domain scope: OSPFv3 Router Information LSA with S1 bit - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit
cleared and the S2 bit set. cleared and the S2 bit set.
A router may generate multiple OSPF Router Information LSAs with A router may generate multiple OSPF Router Information LSAs with
different flooding scopes. different flooding scopes.
The TE-MESH-GROUP TLV may be advertised within an Area-local or The TE-MESH-GROUP TLV may be advertised within an Area-local or
Routing-domain scope Router Information LSA depending on the MPLS TE Routing-domain scope Router Information LSA, depending on the MPLS TE
mesh group profile: mesh group profile:
- If the MPLS TE mesh-group is contained within a single area (all - If the MPLS TE mesh-group is contained within a single area (all
the LSRs of the mesh-group are contained within a single area), the the LSRs of the mesh-group are contained within a single area),
TE-MESH-GROUP TLV MUST be generated within an Area-local Router the TE-MESH-GROUP TLV MUST be generated within an Area-local
Information LSA. Router Information LSA.
- If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh-
group TLV MUST be generated within a Routing-domain scope router group TLV MUST be generated within a Routing-domain scope router
information LSA. information LSA.
5.2. IS-IS 5.2. IS-IS
The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router
CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST CAPABILITY TLV defined in [RFC4971]. An IS-IS router MUST originate
originate a new IS-IS LSP whenever the content of the any of the a new IS-IS LSP whenever the content of any of the advertised sub-TLV
advertised sub-TLV changes or whenever required by regular IS-IS changes or whenever required by regular IS-IS procedure (LSP
procedure (LSP update). If an LSR desires to join or leave a updates). If an LSR desires to join or leave a particular TE mesh
particular TE mesh group, it MUST originate a new LSP comprising the group, it MUST originate a new LSP comprising the refreshed IS-IS
refreshed IS-IS Router capability TLV comprising the updated TE-MESH- Router capability TLV comprising the updated TE-MESH-GROUP sub-TLV.
GROUP sub-TLV. In the case of a join, a new entry will be added to In the case of a join, a new entry will be added to the TE-MESH-GROUP
the TE-MESH-GROUP sub-TLV; conversely, if the LSR leaves a mesh-group sub-TLV; conversely, if the LSR leaves a mesh-group, the
the corresponding entry will be deleted from the TE-MESH-GROUP sub- corresponding entry will be deleted from the TE-MESH-GROUP sub-TLV.
TLV. Note that both operations can be performed in the context of a Note that both operations can be performed in the context of a single
single update. An implementation SHOULD be able to detect any change update. An implementation SHOULD be able to detect any change to a
to a previously received TE-MESH-GROUP sub-TLV from a specific LSR. previously received TE-MESH-GROUP sub-TLV from a specific LSR.
If the flooding scope of an MPLS Traffic Engineering capability is If the flooding scope of a TE-MESH-GROUP sub-TLV is limited to an
limited to an IS-IS level/area, the sub-TLV MUST not be leaked across IS-IS level/area, the sub-TLV MUST not be leaked across level/area
level/area and the S flag of the Router CAPABILITY TLV MUST be and the S flag of the Router CAPABILITY TLV MUST be cleared.
cleared. Conversely, if the flooding scope of an MPLS Traffic Conversely, if the flooding scope of a TE-MESH-GROUP sub-TLV is the
Engineering capability is the entire routing domain, the TLV MUST be entire routing domain, the TLV MUST be leaked across IS-IS
leaked across IS-IS levels/areas, and the S flag of the Router levels/areas, and the S flag of the Router CAPABILITY TLV MUST be
CAPABILITY TLV MUST be set. In both cases the flooding rules set. In both cases, the flooding rules specified in [RFC4971] apply.
specified in [I-D.ietf-isis-caps] apply.
As specified in [I-D.ietf-isis-caps], a router may generate multiple As specified in [RFC4971], a router may generate multiple IS-IS
IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different Router CAPABILITY TLVs within an IS-IS LSP with different flooding
flooding scopes. scopes.
6. Backward compatibility 6. Backward Compatibility
The TE-MESH-GROUP TLVs defined in this document do not introduce any The TE-MESH-GROUP TLVs defined in this document do not introduce any
interoperability issue. For OSPF, a router not supporting the TE- interoperability issue. For OSPF, a router not supporting the TE-
MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in
[RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP sub- [RFC2370]. For an IS-IS, a router not supporting the TE-MESH-GROUP
TLV SHOULD just silently ignore the sub-TLV. sub-TLV SHOULD just silently ignore the sub-TLV.
7. IANA Considerations 7. IANA Considerations
7.1. OSPF 7.1. OSPF
Once a registry for the Router Information LSA defined in The registry for the Router Information LSA is defined in [RFC4970].
[I-D.ietf-ospf-cap] will have been assigned, IANA will assign a new IANA assigned a new OSPF TLV code-point for the TE-MESH-GROUP TLVs
OSPF TLV code-point for the TE-MESH-GROUP TLVs carried within the carried within the Router Information LSA.
Router Information LSA.
Value Sub-TLV References Value Sub-TLV References
----- -------- ---------- ----- -------- ----------
3 TE-MESH-GROUP TLV (IPv4) draft-ietf-ospf-cap (to be replaced by RFC number) 3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc)
4 TE-MESH-GROUP TLV (IPv6) draft-ietf-ospf-cap (to be replaced by RFC number) 4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc)
7.2. IS-IS 7.2. IS-IS
Once a registry for the Router Capability TLV defined in The registry for the Router Capability TLV is defined in [RFC4971].
[I-D.ietf-isis-caps] will have been assigned, IANA will assign a new IANA assigned a new IS-IS sub-TLV code-point for the TE-MESH-GROUP
IS-IS sub-TLV code-point for the TE-MESH-GROUP sub-TLVs carried sub-TLVs carried within the IS-IS Router Capability TLV.
within the IS-IS Router Capability TLV.
Value Sub-TLV References Value Sub-TLV References
----- -------- ---------- ----- -------- ----------
3 TE-MESH-GROUP TLV (IPv4) draft-ietf-isis-caps (to be replaced by RFC number) 3 TE-MESH-GROUP TLV (IPv4) RFC 4972 (this doc)
4 TE-MESH-GROUP TLV (IPv6) draft-ietf-isis-caps (to be replaced by RFC number) 4 TE-MESH-GROUP TLV (IPv6) RFC 4972 (this doc)
8. Security Considerations 8. Security Considerations
The function described in this document does not create any new The function described in this document does not create any new
security issues for the OSPF and the IS-IS protocols. Security security issues for the OSPF and IS-IS protocols. Security
considerations are covered in [RFC2328] and [RFC2740] for the base considerations are covered in [RFC2328] and [RFC2740] for the base
OSPF protocol and in [RFC1195] for IS-IS. It must be noted that the OSPF protocol and in [RFC1195] for IS-IS. It must be noted that the
advertisement of "fake" TE Mesh Group membership(s) by a mis- advertisement of "fake" TE Mesh Group membership(s) by a mis-
configured or malicious LSR Y would not have any major impact on the configured or malicious LSR Y would not have any major impact on the
network (other than overloading the IGP) such as triggering the set network (other than overloading the IGP), such as triggering the set
up of new MPLS TE LSP: indeed for a new TE LSP originated by another up of new MPLS TE LSP: indeed, for a new TE LSP originated by another
LSR X destined to LSR Y to be set up, the same TE Mesh group LSR X destined to LSR Y to be set up, the same TE Mesh group
membership must be configured on both LSRs. Thus such fake membership must be configured on both LSRs. Thus such fake
advertisement could not amplify any DoS attack. advertisement could not amplify any Denial of Service (DoS) attack.
9. Acknowledgements 9. Acknowledgements
We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec, We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec,
Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri
Papadimitriou and Lakshminath Dondeti for their useful comments. Papadimitriou, and Lakshminath Dondeti for their useful comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-isis-caps] [RFC4971] Vasseur, J-P., Ed., Shen, N., Ed., and R. Aggarwal, Ed.,
Vasseur, J., "IS-IS Extensions for Advertising Router "Intermediate System to Intermediate System (IS-IS)
Information", draft-ietf-isis-caps-06 (work in progress), Extensions for Advertising Router Information", RFC 4971,
January 2006. July 2007.
[I-D.ietf-ospf-cap]
Lindem, A., "Extensions to OSPF for Advertising Optional
Router Capabilities", draft-ietf-ospf-cap-09 (work in
progress), October 2006.
[RFC1194] Zimmerman, D., "Finger User Information Protocol", [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
RFC 1194, November 1990. S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July
July 1998. 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC
RFC 2740, December 1999. 2740, December 1999.
10.2. Informative References 10.2. Informative References
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630, September
September 2003. 2003.
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)", System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004. RFC 3784, June 2004.
Authors' Addresses Authors' Addresses
JP Vasseur (editor) JP Vasseur (editor)
Cisco Systems, Inc Cisco Systems, Inc
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Email: jpv@cisco.com EMail: jpv@cisco.com
JL Le Roux (editor) JL Le Roux (editor)
France Telecom France Telecom
2, Avenue Pierre-Marzin 2, Avenue Pierre-Marzin
Lanion, 22307 Lanion, 22307
FRANCE FRANCE
Email: jeanlouis.leroux@francetelecom.com EMail: jeanlouis.leroux@orange-ftgroup.com
Seisho Yasukawa Seisho Yasukawa
NTT NTT
9-11, Midori-Cho 3-Chome 3-1, Otemachi 2-Chome Chiyoda-ku
Tokyo, 180-8585 Tokyo, 100-8116
JAPAN JAPAN
Email: yasukawa.seisho@lab.ntt.co.jp EMail: s.yasukawa@hco.ntt.co.jp
Stefano Previdi Stefano Previdi
Cisco Systems, Inc Cisco Systems, Inc
Via Del Serafico 200 Via Del Serafico 200
Roma, 00142 Roma, 00142
Italy Italy
Email: sprevidi@cisco.com EMail: sprevidi@cisco.com
Peter Psenak Peter Psenak
Cisco Systems, Inc Cisco Systems
Pegasus Park DE Kleetlaan 6A Mlynske Nivy 43
Diegmen, 1831 821 09
BELGIUM Bratislava
Slovakia
Email: ppsenak@cisco.com EMail: ppsenak@cisco.com
Paul Mabbey Paul Mabbey
Comcast Comcast Cable
4100 E. Dry Creek Rd
Centennial, CO 80122
USA USA
Email: EMail: Paul_Mabey@cable.comcast.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 16, line 45 skipping to change at page 15, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is currently provided by the
Administrative Support Activity (IASA). Internet Society.
 End of changes. 79 change blocks. 
275 lines changed or deleted 250 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/