draft-ietf-isis-rfc4971bis-01.txt   draft-ietf-isis-rfc4971bis-02.txt 
Networking Working Group L. Ginsberg Networking Working Group L. Ginsberg
Internet-Draft S. Previdi Internet-Draft S. Previdi
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: October 15, 2016 M. Chen Expires: February 11, 2017 M. Chen
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
April 13, 2016 August 10, 2016
IS-IS Extensions for Advertising Router Info IS-IS Extensions for Advertising Router Info
draft-ietf-isis-rfc4971bis-01.txt draft-ietf-isis-rfc4971bis-02.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. an IS-IS level or the entire routing domain.
Requirements Language Requirements Language
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2016. This Internet-Draft will expire on February 11, 2017.
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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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.
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, and 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].
TYPE: 242 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)
skipping to change at page 4, line 7 skipping to change at page 4, line 7
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 to level-1, the D bit MUST be set. Otherwise, this bit MUST
be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be clear. IS-IS Router CAPABILITY TLVs with the D bit set MUST NOT
be 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 TLV 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
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. Router
CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the CAPABILITY TLVs which have a Router ID of 0.0.0.0 and do NOT have the
IPv6 TE Router ID sub-TLV present MUST be ignored. 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 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, a system MUST NOT In order to prevent the use of stale CAPABILITY TLVs, a system MUST
use a Capability TLV present in an LSP of a system that is not NOT use a CAPABILITY TLV present in an LSP of a system that is not
currently reachable via Level-x paths, where "x" is the level (1 or currently reachable via Level-x paths, where "x" is the level (1 or
2) in which the sending system advertised the TLV. This requirement 2) in which the sending system advertised the TLV. This requirement
applies regardless of whether or not the sending system is the applies regardless of whether or not the sending system is the
originator of the Capabilities TLV. Note that leaking a Capabilities originator of the CAPABILITY TLV.
TLV is one of the uses that is prohibited under these conditions.
Example: If Level-1 router A generates a Capability TLV and floods When a CAPABILITY TLV is not used, either due to lack of reachability
to the originating router or due to unusable Router ID, note that
leaking the CAPABILITY TLV is one of the uses that is prohibited
under these conditions.
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 it to two L1/L2 routers, S and T, they will flood it into the
Level-2 domain. Now suppose the Level-1 area partitions, such Level-2 domain. Now suppose the Level-1 area partitions, such
that A and S are in one partition and T is in another. IP routing that A and S are in one partition and T is in another. IP routing
will still continue to work, but if A now issues a revised version will still continue to work, but if A now issues a revised version
of the CAP TLV, or decides to stop advertising it, S will follow of the CAP TLV, or decides to stop advertising it, S will follow
suit, but T will continue to advertise the old version until the suit, but without the above prohibition T will continue to
LSP times out. 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 CAPABIITY TLV or S's copy of A's CAPABILITY TLV and they have
reliable way to choose. By making sure that T stops leaking A's no reliable way to choose. By making sure that T stops leaking A's
information, this removes the possibility that other routers will use information, the possibility that other routers will use stale
stale information from A. 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 a
capabilities TLV in the same LSP fragment as the advertisement that CAPABILITY TLV in the same LSP fragment as the advertisement that it
it replaces. Where this is not possible, the two affected LSP replaces. Where this is not possible, the two affected LSP fragments
fragments should be flooded as an atomic action. 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 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 CAPABILITY TLV from the
the same system that have different settings for a given attribute, same system that have different settings for a given attribute, the
the procedure used to choose which copy shall be used is undefined. 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 that 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 that do not support specific sub-TLVs carried within a Router Routers that do not support specific sub-TLVs carried within a Router
CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and
continue processing those sub-TLVs that are supported in the Router continue processing those sub-TLVs that are supported in the Router
CAPABILITY TLV. How partial support may impact the operation of the CAPABILITY TLV. How partial support may impact the operation of the
capabilities advertised within the Router CAPABILITY TLV is outside capabilities advertised within the Router CAPABILITY TLV is 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 CAPABILITY TLV is required, the entire CAPABILITY If leaking of the CAPABILITY TLV is required, the entire CAPABILITY
TLV MUST be leaked into another level even though it may contain some TLV MUST be leaked into another level without change even though it
of the unsupported sub-TLVs. may contain some sub-TLVs which are unsupported by the 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
skipping to change at page 6, line 46 skipping to change at page 6, line 47
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 assigned 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 TLV type named the IS-IS Router CAPABILITY TLV and defined in this
document. The assigned value is 242. document. The assigned value is 242.
7. Acknowledgements 7. Acknowledgements
For the original version of RFC 4971 the authors thanked Jean-Louis For the original version of this document (RFC 4971) the authors
Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their thanked Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian
useful comments. Farrel for their useful comments.
For this new version the authors would like to thank Kris Michielsen For this new version the authors would like to thank Kris Michielsen
for calling the problem associated w an IPv6 only router to our for calling attention to the problem associated with an IPv6 only
attention. router.
8. References 8. References
8.1. Normative References 8.1. Normative References
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
skipping to change at page 8, line 45 skipping to change at page 8, line 45
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 TE
Router ID sub-TLV [RFC5316] MUST be present in the TLV. Router ID sub-TLV [RFC5316] MUST be present in the TLV.
In addition, some clarifying editorial changes have been made.
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 USA
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Stefano Previdi Stefano Previdi
 End of changes. 20 change blocks. 
34 lines changed or deleted 41 lines changed or added

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