draft-ietf-isis-caps-07.txt   rfc4971.txt 
Network Working Group Jean-Philippe Vasseur(Ed) Network Working Group JP. Vasseur, Ed.
Internet Draft Naiming Shen (Ed) Request for Comments: 4971 N. Shen, Ed.
Proposed status: Standard Cisco Systems, Inc. Category: Standards Track Cisco Systems, Inc.
Expires: August 2007 Rahul Aggarwal(Ed) R. Aggarwal, Ed.
Juniper Networks Juniper Networks
Intermediate System to Intermediate System (IS-IS) Extensions
for Advertising Router Information
February 2007 Status of This Memo
IS-IS Extensions for Advertising Router Information
draft-ietf-isis-caps-07.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 This document specifies an Internet standards track protocol for the
http://www.ietf.org/ietf/1id-abstracts.txt. 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.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2007. Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document defines a new optional IS-IS TLV named CAPABILITY, This document defines a new optional Intermediate System to
formed of multiple sub-TLVs, which allows a router to announce its Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
capabilities within an IS-IS level or the entire routing domain. sub-TLVs, which allows a router to announce its capabilities within
an IS-IS level or the entire routing domain.
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 [RFC-2119].
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction ....................................................2
2. IS-IS Router CAPABILITY TLV....................................3 1.1. Conventions Used in This Document ..........................2
3. Element of procedure...........................................3 2. IS-IS Router CAPABILITY TLV .....................................3
4. Interoperability with routers not supporting the capability TLV.5 3. Elements of Procedure ...........................................4
5. Security considerations........................................5 4. Interoperability with Routers Not Supporting the
6. Acknowledgment.................................................6 Capability TLV ..................................................5
7. Intellectual Property Considerations...........................6 5. Security Considerations .........................................6
8. References.....................................................6 6. IANA Considerations .............................................6
Normative references..............................................6 7. Acknowledgment ..................................................6
Informative references............................................6 8. References ......................................................6
9. Author's Addresses.............................................7 8.1. Normative References .......................................6
8.2. Informative References .....................................8
1. Introduction 1. Introduction
There are several situations where it is useful for the IS-IS There are several situations where it is useful for the IS-IS [IS-IS]
[IS-IS, IS-IS-IP] routers to learn the capabilities of the other [IS-IS-IP] routers to learn the capabilities of the other routers of
routers of their IS-IS level, area or routing domain. For the sake their IS-IS level, area, or routing domain. For the sake of
of illustration, two examples related to MPLS Traffic Engineering illustration, three examples related to MPLS Traffic Engineering (TE)
are described here: are described here:
1. Mesh-group: the setting up of a mesh of TE LSPs [IS-IS-TE] 1. Mesh-group: the setting up of a mesh of TE Label Switched Paths
requires some significant configuration effort. [AUTOMESH] (LSPs) [IS-IS-TE] requires some significant configuration effort.
proposes an auto-discovery mechanism whereby every LSR of a mesh [AUTOMESH] proposes an auto-discovery mechanism whereby every
advertises its mesh-group membership by means of IS-IS extensions. Label Switching Router (LSR) of a mesh advertises its mesh-group
membership by means of IS-IS extensions.
2. Point to Multi-point TE LSP (P2MP LSP). A specific sub-TLV ([TE- 2. Point to Multipoint TE LSP (P2MP LSP). A specific sub-TLV
NODE-CAP]) allows an LSR to advertise its Point To Multipoint ([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint
capabilities ([P2MP] and [P2MP-REQS]). capabilities ([P2MP] and [P2MP-REQS]).
3. Inter-area traffic engineering: Advertisement of the IPv4 3. Inter-area traffic engineering: Advertisement of the IPv4 and/or
and/or the IPv6 Traffic Engineering Router IDs. the IPv6 Traffic Engineering Router IDs.
The use of IS-IS for Path Computation Element (PCE) discovery may The use of IS-IS for Path Computation Element (PCE) discovery may
also be considered and will be discussed in the PCE WG. also be considered and will be discussed in the PCE WG.
The capabilities mentioned above require the specification of new The capabilities mentioned above require the specification of new
sub-TLVs carried within the CAPABILITY TLV defined in this document. sub-TLVs carried within the CAPABILITY TLV defined in this document.
Note that the examples above are provided for the sake of Note that the examples above are provided for the sake of
illustration. This document proposes a generic capability advertising illustration. This document proposes a generic capability
mechanism not limited to MPLS Traffic Engineering. advertising mechanism that is not limited to MPLS Traffic
Engineering.
This document defines a new optional IS-IS TLV named CAPABILITY, This document defines a new optional IS-IS TLV named CAPABILITY,
formed of multiple sub-TLVs, which allows a router to announce its formed of multiple sub-TLVs, which allows a router to announce its
capabilities within an IS-IS level or the entire routing domain. The capabilities within an IS-IS level or the entire routing domain. The
applications mentioned above require the specification of new sub- applications mentioned above require the specification of new sub-
TLVs carried within the CAPABILITY TLV defined in this document. TLVs carried within the CAPABILITY TLV defined in this document.
Definition of these sub-TLVs is outside the scope of this document. Definition of these sub-TLVs is outside the scope of this document.
1.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 [RFC-2119].
2. IS-IS Router CAPABILITY TLV 2. IS-IS Router CAPABILITY TLV
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type,
1 octet specifying the number of bytes in the value field, and a 1 octet that specifies the number of bytes in the value field, and a
variable length value field, starting with 4 octets of Router ID, variable length value field that starts with 4 octets of Router ID,
indicating the source of the TLV, and followed by 1 octet of flags. indicating the source of the TLV, and followed by 1 octet of flags.
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are A set of optional sub-TLVs may follow the flag field. Sub-TLVs are
formatted as described in RFC 3784 [IS-IS-TE]. formatted as described in RFC 3784 [IS-IS-TE].
TYPE: 242 (To be assigned by IANA) TYPE: 242
LENGTH: from 5 to 255 LENGTH: from 5 to 255
VALUE: VALUE:
Router ID (4 octets) Router ID (4 octets)
Flags (1 octet) Flags (1 octet)
Set of optional sub-TLVs (0-250 octets) Set of optional sub-TLVs (0-250 octets)
Flags Flags
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |D|S| | Reserved |D|S|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Currently two bit flags are defined. Currently two bit flags are defined.
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV
MUST be flooded across the entire routing domain. If the S bit is not MUST be flooded across the entire routing domain. If the S bit is
set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT not set(0), the TLV MUST NOT be leaked between levels. This bit MUST
be altered during the TLV leaking. NOT be altered during the TLV leaking.
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from
level-2 to level-1, the D bit MUST be set. Otherwise this bit MUST be level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST
clear. IS-IS Router capability TLVs with the D bit set MUST NOT be be clear. IS-IS Router capability TLVs with the D bit set MUST NOT
leaked from level-1 to level-2. This is to prevent TLV looping. be leaked from level-1 to level-2. This is to prevent TLV looping.
The Router CAPABILITY TLV is OPTIONAL. As specified in section 3, The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3,
more than one Router CAPABILITY TLVs from the same source MAY be more than one Router CAPABILITY TLV from the same source MAY be
present. present.
This document does not specify how an application may use the Router This document does not specify how an application may use the Router
Capability TLV and such specification is outside the scope of this Capability TLV and such specification is outside the scope of this
document. document.
3. Elements of procedure 3. Elements of Procedure
A router which generates a CAPABILITY TLV MUST have a Router ID A router that generates a CAPABILITY TLV MUST have a Router ID that
which is a 32 bit number. The ID MUST be unique within the IS-IS is a 32-bit number. The ID MUST be unique within the IS-IS area. If
area. If the router generates any capability TLVs with domain the router generates any capability TLVs with domain flooding scope,
flooding scope then the ID MUST also be unique within the IS-IS then the ID MUST also be unique within the IS-IS routing domain.
routing domain.
When advertising capabilities with different flooding scopes, a When advertising capabilities with different flooding scopes, a
router MUST originate a minimum of two Router CAPABILITY TLVs, each router MUST originate a minimum of two Router CAPABILITY TLVs, each
TLV carrying the set of sub-TLVs with the same flooding scope. For TLV carrying the set of sub-TLVs with the same flooding scope. For
instance, if a router advertises two sets of capabilities C1 and C2 instance, if a router advertises two sets of capabilities, C1 and C2,
with an area/level scope and routing domain scope respectively, C1 with an area/level scope and routing domain scope respectively, C1
and C2 being specified by their respective sub-TLV(s), the router and C2 being specified by their respective sub-TLV(s), the router
will originate two Router CAPABILITY TLVs: will originate two Router CAPABILITY TLVs:
- One Router CAPABILITY TLV with the S flag cleared, carrying the - One Router CAPABILITY TLV with the S flag cleared, carrying the
sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be
leaked into another level. leaked into another level.
- One Router CAPABILITY TLV with the S flag set, carrying the sub- - One Router CAPABILITY TLV with the S flag set, carrying the sub-
TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked
into other IS-IS levels. When the TLV is leaked from level-2 to into other IS-IS levels. When the TLV is leaked from level-2 to
level-1, the D bit will be set in the level-1 LSP advertisement. level-1, the D bit will be set in the level-1 LSP advertisement.
In order to prevent the use of stale capabilities information A In order to prevent the use of stale capabilities, a system MUST NOT
system MUST NOT use a Capability TLV present in an LSP of a system use a Capability TLV present in an LSP of a system that is not
which is not currently reachable via Level-x paths, where "x" is the currently reachable via Level-x paths, where "x" is the level (1 or
level (1 or 2) in which the sending system advertised the TLV. This 2) in which the sending system advertised the TLV. This requirement
requirement applies regardless of whether the sending system is the applies regardless of whether or not the sending system is the
originator of the Capabilities TLV or not. Note that leaking a originator of the Capabilities TLV. Note that leaking a Capabilities
Capabilities TLV is one of the uses which is prohibited under these TLV is one of the uses that is prohibited under these conditions.
conditions.
Example: If Level-1 router A generates a Capability TLV and floods Example: If Level-1 router A generates a Capability TLV and floods
it to two L1/L2 routers S and T, they will flood it into the Level-2 it to two L1/L2 routers, S and T, they will flood it into the
domain. Now suppose the Level-1 area partitions, such that A and S Level-2 domain. Now suppose the Level-1 area partitions, such
are in one partition and T is in another. IP routing will still that A and S are in one partition and T is in another. IP routing
continue to work, but if A now issues a revised version of the CAP will still continue to work, but if A now issues a revised version
TLV, or decides to stop advertising it, S will follow suit, but T of the CAP TLV, or decides to stop advertising it, S will follow
will continue to advertise the old version until the LSP times out. suit, but T will continue to advertise the old version until the
LSP times out.
Routers in other areas have to choose whether to trust T's copy of Routers in other areas have to choose whether to trust T's copy of
A's capabilities or S's copy of A's information and they have no A's capabilities or S's copy of A's information and, they have no
reliable way to choose. By making sure that T stops leaking A's reliable way to choose. By making sure that T stops leaking A's
information, this removes the possibility that other routers will information, this removes the possibility that other routers will use
use stale information from A. stale information from A.
In IS-IS, the atomic unit of the update process is a TLV - or more In IS-IS, the atomic unit of the update process is a TLV -- or more
precisely in the case of TLVs which allow multiple entries to appear precisely, in the case of TLVs that allow multiple entries to appear
in the value field (e.g. IS-neighbors) - an entry in the value field in the value field (e.g., IS-neighbors), the atomic unit is an entry
of a TLV. If an update to an entry in a TLV is advertised in an LSP in the value field of a TLV. If an update to an entry in a TLV is
fragment different from the LSP fragment associated with the old advertised in an LSP fragment different from the LSP fragment
advertisement, the possibility exists that other systems can associated with the old advertisement, the possibility exists that
temporarily have either 0 copies of a particular advertisement or 2 other systems can temporarily have either 0 copies of a particular
copies of a particular advertisement, depending on the order in which advertisement or 2 copies of a particular advertisement, depending on
new copies of the LSP fragment which had the old advertisement and the order in which new copies of the LSP fragment that had the old
the fragment which has the new advertisement arrive at other systems. advertisement and the fragment that has the new advertisement arrive
at other systems.
Wherever possible, an implementation SHOULD advertise the update to a Wherever possible, an implementation SHOULD advertise the update to a
capabilities TLV in the same LSP fragment as the advertisement which capabilities TLV in the same LSP fragment as the advertisement that
it replaces. Where this is not possible, the two affected LSP it replaces. Where this is not possible, the two affected LSP
fragments should be flooded as an atomic action. fragments should be flooded as an atomic action.
Systems which receive an update to an existing capability TLV can Systems that receive an update to an existing capability TLV can
minimize the potential disruption associated with the update by minimize the potential disruption associated with the update by
employing a holddown time prior to processing the update so as to employing a holddown time prior to processing the update so as to
allow for the receipt of multiple LSP fragments associated with the allow for the receipt of multiple LSP fragments associated with the
same update prior to beginning processing. same update prior to beginning processing.
Where a receiving system has two copies of a capabilities TLV from Where a receiving system has two copies of a capabilities TLV from
the same system which have different settings for a given attribute, the same system that have different settings for a given attribute,
the procedure used to choose which copy shall be used is undefined. the procedure used to choose which copy shall be used is undefined.
4. Interoperability with routers not supporting the capability TLV. 4. Interoperability with Routers Not Supporting the Capability TLV
Routers which do not support the Router CAPABILITY TLV MUST silently Routers that do not support the Router CAPABILITY TLV MUST silently
ignore the TLV(s) and continue processing other TLVs in the same LSP. ignore the TLV(s) and continue processing other TLVs in the same LSP.
Routers which do not support specific sub-TLVs carried within a Routers that do not support specific sub-TLVs carried within a Router
Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and
and continue processing those sub-TLVs in the Router CAPABILITY TLV continue processing those sub-TLVs that are supported in the Router
which are supported. How partial support may impact the operation of CAPABILITY TLV. How partial support may impact the operation of the
the capabilities advertised within the Router CAPABILITY TLV is capabilities advertised within the Router CAPABILITY TLV is outside
outside the scope of this document. the scope of this document.
In order for Router CAPABILITY TLVs with domain-wide scope originated In order for Router CAPABILITY TLVs with domain-wide scope originated
by L1 Routers to be flooded across the entire domain at least one by L1 Routers to be flooded across the entire domain, at least one
L1/L2 Router in every area of the domain MUST support the Router L1/L2 Router in every area of the domain MUST support the Router
CAPABILITY TLV. CAPABILITY TLV.
If leaking of the CAP TLV is required, the entire CAP TLV MUST be If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
leaked into another level even though it may contain some of the TLV MUST be leaked into another level even though it may contain some
unsupported sub-TLVs. of the unsupported sub-TLVs.
5. Security considerations 5. Security Considerations
Any new security issues raised by the procedures in this document Any new security issues raised by the procedures in this document
depend upon the opportunity for LSPs to be snooped and modified, depend upon the opportunity for LSPs to be snooped and modified, the
the ease/difficulty of which has not been altered. As the LSPs may ease/difficulty of which has not been altered. As the LSPs may now
now contain additional information regarding router capabilities, contain additional information regarding router capabilities, this
this new information would also become available to an attacker. new information would also become available to an attacker.
Specifications based on this mechanism need to describe the Specifications based on this mechanism need to describe the security
security considerations around the disclosure and modification considerations around the disclosure and modification of their
of their information. Note that an integrity mechanism, such as information. Note that an integrity mechanism, such as the one
one defined in RFC3567 or draft-ietf-isis-hmac-sha, should be defined in [RFC-3567] or [IS-IS-HMAC], should be applied if there is
applied if there is high risk resulting from modification of high risk resulting from modification of capability information.
capability information.
6. IANA considerations 6. IANA Considerations
IANA will assign a new IS-IS TLV code-point for the newly defined IS-
IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS
document. Suggested value is 242 (to be assigned by IANA). TLV type named the IS-IS Router CAPABILITY TLV and defined in this
document. The assigned value is 242.
7. Acknowledgment 7. Acknowledgment
The authors would like to thank Jean-Louis Le Roux, Paul Mabey, The authors would like to thank Jean-Louis Le Roux, Paul Mabey,
Andrew Partan and Adrian Farrel for their useful comments. Andrew Partan, and Adrian Farrel for their useful comments.
8. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
9. References 8. References
9.1 Normative references 8.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119. Requirement Levels", BCP 14, RFC 2119, March 1997.
[IS-IS] "Intermediate System to Intermediate System Intra-Domain [IS-IS] "Intermediate System to Intermediate System Intra-
Routeing Exchange Protocol for use in Conjunction with the Domain Routeing Exchange Protocol for use in
Protocol for Providing the Connectionless-mode Network Service Conjunction with the Protocol for Providing the
(ISO 8473)", ISO 10589. Connectionless-mode Network Service (ISO 8473)", ISO
10589.
[RFC-3567] Li, T. and R. Atkinson, "Intermediate System to
Intermediate System (IS-IS) Cryptographic
Authentication", RFC 3567, July 2003.
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [IS-IS-IP] 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.
[IS-IS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic [IS-IS-TE] Smit, H. and T. Li, "Intermediate System to
Engineering", RFC 3784, June 2004. Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
9.2 Informative references 8.2. Informative References
[AUTOMESH] JP Vasseur, JL. Le Roux et al, "Routing extensions for [AUTOMESH] Vasseur, JP., Ed., Le Roux, JL., Ed., Yasukawa, S.,
discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Previdi, S., Psenak, P., and P. Mabbey, "Routing
Engineering (TE) mesh membership", draft-ietf-ccamp-automesh, work in extensions for Discovery of Multiprotocol (MPLS) Label
progress. Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, July 2007.
[TE-NODE-CAP] JP Vasseur, JL. Le Roux et al, "Routing extensions for [TE-NODE-CAP] Vasseur, JP., Ed., and J.L. Le Roux, "Routing
discovery of Traffic Engineering Node Capabilities", draft-ietf- Extensions for Discovery of Traffic Engineering Node
ccamp-te-node-cap, work in progress. Capabilities", Work in Progress, April 2007.
[P2MP] R. Aggarwal,D. Papadimitriou,S. Yasukawa, et. al. "Extensions [P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
to RSVP-TE for Point To Multipoint TE LSPs", draft-ietf-mpls-rsvp-te- Yasukawa, Ed., "Extensions to Resource Reservation
p2mp, work in progress. Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
May 2007.
[P2MP-REQS] S. Yasukawa et al. "Requirements for point to multipoint [P2MP-REQS] Yasukawa, S., Ed., "Signaling Requirements for Point-
extension to RSVP", draft-ietf-mpls-p2mp-sig-requirement, work in to-Multipoint Traffic-Engineered MPLS Label Switched
progress. Paths (LSPs)", RFC 4461, April 2006.
10. Authors' Addresses [IS-IS-HMAC] Bhatia, M., Ed. and V. Manral, Ed., "IS-IS Generic
Cryptographic Authentication", Work in Progress, May
2007.
Authors' Addresses
Jean-Philippe Vasseur Jean-Philippe Vasseur
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
Stefano Previdi Stefano Previdi
CISCO Systems, Inc. CISCO Systems, Inc.
Via Del Serafico 200 Via Del Serafico 200
00142 - Roma 00142 - Roma
ITALY ITALY
Email: sprevidi@cisco.com EMail: sprevidi@cisco.com
Mike Shand Mike Shand
Cisco Systems Cisco Systems
250 Longwater Avenue, 250 Longwater Avenue,
Reading, Reading,
Berkshire, Berkshire,
RG2 6GB RG2 6GB
UK UK
Email: mshand@cisco.com EMail: mshand@cisco.com
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, Ca. 95035 USA Milpitas, Ca. 95035 USA
Email: ginsberg@cisco.com EMail: ginsberg@cisco.com
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Cary, NC 27519 Cary, NC 27519
USA USA
e-mail: acee@redback.com EMail: acee@redback.com
Naiming Shen Naiming Shen
Cisco Systems Cisco Systems
225 West Tasman Drive 225 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
e-mail: naiming@cisco.com EMail: naiming@cisco.com
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 N. Mathilda Avenue 1194 N. Mathilda Avenue
San Jose, CA 94089 San Jose, CA 94089
USA USA
e-mail: rahul@juniper.net EMail: rahul@juniper.net
Scott Shaffer Scott Shaffer
e-mail: sshaffer@bridgeport-networks.com EMail: sshaffer@bridgeport-networks.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). This document is subject to the Copyright (C) The IETF Trust (2007).
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
This document and the information contained herein are provided This document is subject to the rights, licenses and restrictions
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE contained in BCP 78, and except as set forth therein, the authors
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE retain all their rights.
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY This document and the information contained herein are provided on an
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
FOR A PARTICULAR PURPOSE. THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 60 change blocks. 
200 lines changed or deleted 175 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/