< draft-ietf-isis-rfc4971bis   rfc7981.txt 
Networking Working Group L. Ginsberg Internet Engineering Task Force (IETF) L. Ginsberg
Internet-Draft S. Previdi Request for Comments: 7981 S. Previdi
Obsoletes: 4971 (if approved) Cisco Systems Obsoletes: 4971 Cisco Systems
Intended status: Standards Track M. Chen Category: Standards Track M. Chen
Expires: February 19, 2017 Huawei Technologies Co., Ltd ISSN: 2070-1721 Huawei Technologies Co., Ltd
August 18, 2016 October 2016
IS-IS Extensions for Advertising Router Info IS-IS Extensions for Advertising Router Information
draft-ietf-isis-rfc4971bis-04.txt
Abstract Abstract
This document defines a new optional Intermediate System to This document defines a new optional Intermediate System to
Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
sub-TLVs, which allows a router to announce its capabilities within sub-TLVs, which allows a router to announce its capabilities within
an IS-IS level or the entire routing domain. This document obsoletes an IS-IS level or the entire routing domain. This document obsoletes
RFC 4971. RFC 4971.
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 19, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7981.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
2. IS-IS Router CAPABILITY TLV . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language ......................................3
3. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 4 2. IS-IS Router CAPABILITY TLV .....................................3
4. Interoperability with Routers Not Supporting the Capability 3. Elements of Procedure ...........................................4
TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Interoperability with Routers Not Supporting the IS-IS Router
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 CAPABILITY TLV ..................................................6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations .........................................6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations .............................................7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. References ......................................................7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7 7.1. Normative References .......................................7
8.2. Informational References . . . . . . . . . . . . . . . . 8 7.2. Informative References .....................................8
Appendix A. Changes to RFC 4971 . . . . . . . . . . . . . . . . 8 Appendix A. Changes to RFC 4971 ...................................9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Acknowledgements ..................................................10
Authors' Addresses ................................................10
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
[ISO10589] [RFC1195] routers to learn the capabilities of the other [ISO10589] [RFC1195] routers to learn the capabilities of the other
routers of their IS-IS level, area, or routing domain. For the sake routers of their IS-IS level, area, or routing domain. For the sake
of illustration, three examples related to MPLS Traffic Engineering of illustration, three examples related to MPLS Traffic Engineering
(TE) are described here: (TE) are described here:
1. Mesh-group: the setting up of a mesh of TE Label Switched Paths 1. Mesh-group: The setting up of a mesh of TE Label Switched Paths
(LSPs) [RFC5305] requires some significant configuration effort. (LSPs) [RFC5305] requires some significant configuration effort.
[RFC4972] proposes an auto-discovery mechanism whereby every [RFC4972] proposes an auto-discovery mechanism whereby every
Label Switching Router (LSR) of a mesh advertises its mesh-group Label Switching Router (LSR) of a mesh advertises its mesh-group
membership by means of IS-IS extensions. membership by means of IS-IS extensions.
2. Point to Multipoint TE LSP (RFC4875). A specific sub-TLV 2. Point-to-Multipoint TE LSP (RFC4875): A specific sub-TLV
[RFC5073] allows an LSR to advertise its Point To Multipoint [RFC5073] allows an LSR to advertise its Point-to-Multipoint
capabilities ([RFC4875] and [RFC4461]). capabilities ([RFC4875] and [RFC4461]).
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or 3. Inter-area traffic engineering: Advertisement of the IPv4 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 IS-IS Router 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 illustration. This document proposes a generic capability
advertising mechanism that is not limited to MPLS Traffic advertising mechanism that is not limited to MPLS Traffic
Engineering. 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 IS-IS Router 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. 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].
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 that specifies 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 that starts with 4 octets of Router ID, variable length value field that starts with 4 octets of Router ID,
indicating the source of the TLV, followed by 1 octet of flags. indicating the source of the TLV, 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 [RFC5305]. formatted as described in [RFC5305].
skipping to change at page 3, line 48 skipping to change at page 4, line 5
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 MUST be flooded across the entire routing domain. If the S bit is
not set(0), the TLV MUST NOT be leaked between levels. This bit MUST not set(0), the TLV MUST NOT be leaked between levels. This bit MUST
NOT 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 Level 2 (L2) to Level 1 (L1), the D bit MUST be set. Otherwise, this
be clear. IS-IS Router CAPABILITY TLVs with the D bit set MUST NOT bit MUST be clear. IS-IS Router CAPABILITY TLVs with the D bit set
be leaked from level-1 to level-2. This is to prevent TLV looping. MUST NOT 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 IS-IS Router CAPABILITY TLV is OPTIONAL. As specified in
more than one Router CAPABILITY TLV from the same source MAY be Section 3, more than one IS-IS Router CAPABILITY TLV from the same
present. source MAY be present.
This document does not specify how an application may use the Router This document does not specify how an application may use the IS-IS
CAPABILITY TLV and such specification is outside the scope of this Router CAPABILITY TLV, and such specification is outside the scope of
document. this document.
3. Elements of Procedure 3. Elements of Procedure
The Router ID SHOULD be identical to the value advertised in the The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV [RFC5305]. If no Traffic Traffic Engineering Router ID TLV [RFC5305]. If no Traffic
Engineering Router ID is assigned the Router ID SHOULD be identical Engineering Router ID is assigned, the Router ID SHOULD be identical
to an IP Interface Address [RFC1195] advertised by the originating to an IP Interface Address [RFC1195] advertised by the originating
IS. If the originating node does not support IPv4, then the reserved IS. If the originating node does not support IPv4, then the reserved
value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE value 0.0.0.0 MUST be used in the Router ID field, and the IPv6 TE
Router ID sub-TLV [RFC5316] MUST be present in the TLV. Router Router ID sub-TLV [RFC5316] MUST be present in the TLV. IS-IS Router
CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the CAPABILITY TLVs that have a Router ID of 0.0.0.0 and do NOT have the
IPv6 TE Router ID sub-TLV present MUST NOT be used. IPv6 TE Router ID sub-TLV present MUST NOT be used.
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 IS-IS Router CAPABILITY TLVs,
TLV carrying the set of sub-TLVs with the same flooding scope. For each TLV carrying the set of sub-TLVs with the same flooding scope.
instance, if a router advertises two sets of capabilities, C1 and C2, For instance, if a router advertises two sets of capabilities, C1 and
with an area/level scope and routing domain scope respectively, C1 C2, with an area/level scope and routing domain scope respectively,
and C2 being specified by their respective sub-TLV(s), the router C1 and C2 being specified by their respective sub-TLV(s), the router
will originate two Router CAPABILITY TLVs: will originate two IS-IS Router CAPABILITY TLVs:
- One Router CAPABILITY TLV with the S flag cleared, carrying the o One IS-IS Router CAPABILITY TLV with the S flag cleared, carrying
sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be the sub-TLV(s) relative to C1. This IS-IS Router CAPABILITY TLV
leaked into another level. will not be leaked into another level.
- One Router CAPABILITY TLV with the S flag set, carrying the sub- o One IS-IS Router CAPABILITY TLV with the S flag set, carrying the
TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked sub-TLV(s) relative to C2. This IS-IS Router CAPABILITY TLV will
into other IS-IS levels. When the TLV is leaked from level-2 to be leaked into other IS-IS levels. When the TLV is leaked from
level-1, the D bit will be set in the level-1 LSP advertisement. Level 2 to Level 1, the D bit will be set in the Level 1 LSP
advertisement.
In order to prevent the use of stale CAPABILITY TLVs, a system MUST In order to prevent the use of stale IS-IS Router CAPABILITY TLVs, a
NOT use a CAPABILITY TLV present in an LSP of a system that is not system MUST NOT use an IS-IS Router CAPABILITY TLV present in an LSP
currently reachable via Level-x paths, where "x" is the level (1 or of a system that is not currently reachable via Level x paths, where
2) in which the sending system advertised the TLV. This requirement "x" is the level (1 or 2) in which the sending system advertised the
applies regardless of whether or not the sending system is the TLV. This requirement applies regardless of whether or not the
originator of the CAPABILITY TLV. sending system is the originator of the IS-IS Router CAPABILITY TLV.
When a CAPABILITY TLV is not used, either due to lack of reachability When an IS-IS Router CAPABILITY TLV is not used, either due to a lack
to the originating router or due to unusable Router ID, note that of reachability to the originating router or due to an unusable
leaking the CAPABILITY TLV is one of the uses that is prohibited Router ID, note that leaking the IS-IS Router CAPABILITY TLV is one
under these conditions. of the uses that is prohibited under these conditions.
Example: If Level-1 router A generates a CAPABILITY TLV and floods Example: If Level 1 router A generates an IS-IS Router CAPABILITY
it to two L1/L2 routers, S and T, they will flood it into the TLV and floods it to two L1/L2 routers, S and T, they will flood
Level-2 domain. Now suppose the Level-1 area partitions, such it into the Level 2 domain. Now suppose the Level 1 area
that A and S are in one partition and T is in another. IP routing partitions, such that A and S are in one partition and T is in
will still continue to work, but if A now issues a revised version another. IP routing will still continue to work, but if A now
of the CAP TLV, or decides to stop advertising it, S will follow issues a revised version of the CAP TLV, or decides to stop
suit, but without the above prohibition T will continue to advertising it, S will follow suit, but without the above
advertise the old version until the LSP times out. prohibition, 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 CAPABIITY TLV or S's copy of A's CAPABILITY TLV and they have A's IS-IS Router CAPABILITY TLV or S's copy of A's IS-IS Router
no reliable way to choose. By making sure that T stops leaking A's CAPABILITY TLV, and they have no reliable way to choose. By
information, the possibility that other routers will use stale making sure that T stops leaking A's information, the possibility
information from A is eliminated. that other routers will use stale information from A is
eliminated.
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 that 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), the atomic unit is an entry in the value field (e.g., IS-neighbors), the atomic unit is an entry
in the value field of a TLV. If an update to an entry in a TLV is in the value field of a TLV. If an update to an entry in a TLV is
advertised in an LSP fragment different from the LSP fragment advertised in an LSP fragment different from the LSP fragment
associated with the old advertisement, the possibility exists that associated with the old advertisement, the possibility exists that
other systems can temporarily have either 0 copies of a particular other systems can temporarily have either 0 copies of a particular
advertisement or 2 copies of a particular advertisement, depending on advertisement or 2 copies of a particular advertisement, depending on
the order in which new copies of the LSP fragment that had the old the order in which new copies of the LSP fragment that had the old
advertisement and the fragment that has the new advertisement arrive advertisement and the fragment that has the new advertisement arrive
at other systems. at other systems.
Wherever possible, an implementation SHOULD advertise the update to a Wherever possible, an implementation SHOULD advertise the update to
CAPABILITY TLV in the same LSP fragment as the advertisement that it an IS-IS Router CAPABILITY TLV in the same LSP fragment as the
replaces. Where this is not possible, the two affected LSP fragments advertisement that it replaces. Where this is not possible, the two
should be flooded as an atomic action. affected LSP fragments should be flooded as an atomic action.
Systems that receive an update to an existing CAPABILITY TLV can Systems that receive an update to an existing IS-IS Router CAPABILITY
minimize the potential disruption associated with the update by TLV can minimize the potential disruption associated with the update
employing a holddown time prior to processing the update so as to by 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 CAPABILITY TLV from the Where a receiving system has two copies of an IS-IS Router CAPABILITY
same system that have conflicting information for a given sub-TLV, TLV from the same system that have conflicting information for a
the procedure used to choose which copy shall be used is undefined. given sub-TLV, 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 IS-IS Router
CAPABILITY TLV
Routers that do not support the Router CAPABILITY TLV MUST silently Routers that do not support the IS-IS Router CAPABILITY TLV MUST
ignore the TLV(s) and continue processing other TLVs in the same LSP. silently ignore the TLV(s) and continue processing other TLVs in the
Routers that do not support specific sub-TLVs carried within a Router same LSP. Routers that do not support specific sub-TLVs carried
CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and within an IS-IS Router CAPABILITY TLV MUST silently ignore the
continue processing those sub-TLVs that are supported in the Router unsupported sub-TLVs and continue processing those sub-TLVs that are
CAPABILITY TLV. How partial support may impact the operation of the supported in the IS-IS Router CAPABILITY TLV. How partial support
capabilities advertised within the Router CAPABILITY TLV is outside may impact the operation of the capabilities advertised within the
the scope of this document. IS-IS Router CAPABILITY TLV is outside the scope of this document.
In order for Router CAPABILITY TLVs with domain-wide scope originated In order for IS-IS Router CAPABILITY TLVs with domain-wide scope
by L1 Routers to be flooded across the entire domain, at least one originated by L1 routers to be flooded across the entire domain, at
L1/L2 Router in every area of the domain MUST support the Router least one L1/L2 router in every area of the domain MUST support the
CAPABILITY TLV. Router CAPABILITY TLV.
If leaking of the CAPABILITY TLV is required, the entire CAPABILITY If leaking of the IS-IS Router CAPABILITY TLV is required, the entire
TLV MUST be leaked into another level without change (except for CAPABILITY TLV MUST be leaked into another level without change
changes to the TLV flags as noted in Section 2) even though it may (except for changes to the TLV flags as noted in Section 2) even
contain some sub-TLVs which are unsupported by the Router doing the though it may contain some sub-TLVs that are unsupported by the
leaking. router doing the leaking.
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, the depend upon the opportunity for LSPs to be snooped and modified, the
ease/difficulty of which has not been altered. As the LSPs may now ease/difficulty of which has not been altered. As the LSPs may now
contain additional information regarding router capabilities, this contain additional information regarding router capabilities, 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 security Specifications based on this mechanism need to describe the security
considerations around the disclosure and modification of their considerations around the disclosure and modification of their
information. Note that an integrity mechanism, such as the one information. Note that an integrity mechanism, such as the ones
defined in [RFC5304] or [RFC5310], should be applied if there is high defined in [RFC5304] or [RFC5310], should be applied if there is high
risk resulting from modification of capability information. risk resulting from modification of capability information.
6. IANA Considerations 6. IANA Considerations
IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS IANA originally assigned a TLV codepoint for the IS-IS Router
TLV type named the IS-IS Router CAPABILITY TLV and defined in this CAPABILITY TLV (242) as described in RFC 4971. IANA has updated this
document. The assigned value is 242. entry in the "TLV Codepoints Registry" to refer to this document.
7. Acknowledgements
For the original version of this document (RFC 4971) the authors
thanked Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian
Farrel for their useful comments.
For this new version the authors would like to thank Kris Michielsen
for calling attention to the problem associated with an IPv6 only
router.
8. References 7. References
8.1. Normative References 7.1. Normative References
[ISO10589] [ISO10589] International Organization for Standardization,
International Organization for Standardization, "Information technology -- Telecommunications and
"Intermediate system to Intermediate system intra-domain information exchange between systems -- Intermediate
routeing information exchange protocol for use in System to Intermediate System intra-domain routeing
conjunction with the protocol for providing the information exchange protocol for use in conjunction with
connectionless-mode Network Service (ISO 8473)", ISO/ the protocol for providing the connectionless-mode network
IEC 10589:2002, Second Edition, Nov 2002. service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
November 2002.
[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, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>. December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 8, line 10 skipping to change at page 8, line 15
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <http://www.rfc-editor.org/info/rfc5310>. 2009, <http://www.rfc-editor.org/info/rfc5310>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <http://www.rfc-editor.org/info/rfc5316>. December 2008, <http://www.rfc-editor.org/info/rfc5316>.
8.2. Informational References 7.2. Informative References
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to- [RFC4461] Yasukawa, S., Ed., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006, (LSPs)", RFC 4461, DOI 10.17487/RFC4461, April 2006,
<http://www.rfc-editor.org/info/rfc4461>. <http://www.rfc-editor.org/info/rfc4461>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
skipping to change at page 8, line 35 skipping to change at page 9, line 9
Previdi, S., Psenak, P., and P. Mabbey, "Routing Previdi, S., Psenak, P., and P. Mabbey, "Routing
Extensions for Discovery of Multiprotocol (MPLS) Label Extensions for Discovery of Multiprotocol (MPLS) Label
Switch Router (LSR) Traffic Engineering (TE) Mesh Switch Router (LSR) Traffic Engineering (TE) Mesh
Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007, Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007,
<http://www.rfc-editor.org/info/rfc4972>. <http://www.rfc-editor.org/info/rfc4972>.
Appendix A. Changes to RFC 4971 Appendix A. Changes to RFC 4971
This document makes the following changes to RFC 4971. This document makes the following changes to RFC 4971.
RFC 4971 only allowed a 32 bit Router ID in the fixed header of TLV RFC 4971 only allowed a 32-bit Router ID in the fixed header of TLV
242. This is problematic in an IPv6-only deployment where an IPv4 242. This is problematic in an IPv6-only deployment where an IPv4
address may not be available. This document specifies: address may not be available. This document specifies:
1. The Router ID SHOULD be identical to the value advertised in the 1. The Router ID SHOULD be identical to the value advertised in the
Traffic Engineering Router ID TLV (134) if available. Traffic Engineering Router ID TLV (134) if available.
2. If no Traffic Engineering Router ID is assigned the Router ID 2. If no Traffic Engineering Router ID is assigned, the Router ID
SHOULD be identical to an IP Interface Address [RFC1195] SHOULD be identical to an IP Interface Address [RFC1195]
advertised by the originating IS. advertised by the originating IS.
3. If the originating node does not support IPv4, then the reserved 3. If the originating node does not support IPv4, then the reserved
value 0.0.0.0 MUST be used in the Router ID field and the IPv6 TE value 0.0.0.0 MUST be used in the Router ID field, and the IPv6
Router ID sub-TLV [RFC5316] MUST be present in the TLV. TE Router ID sub-TLV [RFC5316] MUST be present in the TLV.
In addition, some clarifying editorial changes have been made. In addition, some clarifying editorial changes have been made.
Acknowledgements
The authors of RFC 4971 thanked Jean-Louis Le Roux, Paul Mabey,
Andrew Partan, and Adrian Farrel for their useful comments.
The authors of this document would like to thank Kris Michielsen for
calling attention to the problem associated with an IPv6-only router.
Authors' Addresses Authors' Addresses
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
510 McCarthy Blvd. 510 McCarthy Blvd.
Milpitas, CA 95035 Milpitas, CA 95035
USA United States of America
Email: [email protected] Email: [email protected]
Stefano Previdi Stefano Previdi
Cisco Systems Cisco Systems
Via Del Serafico 200 Via Del Serafico 200
Rome 0144 Rome 0144
Italy Italy
Email: [email protected] Email: [email protected]
Mach (Guoyi) Chen Mach(Guoyi) Chen
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District KuiKe Building, No. 9 Xinxi Rd. Hai-Dian District
Beijing 100085 Beijing 100085
P.R. China China
Email: [email protected] Email: [email protected]
 End of changes. 46 change blocks. 
153 lines changed or deleted 157 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/