| < draft-ietf-isis-node-admin-tag-01.txt | draft-ietf-isis-node-admin-tag-02.txt > | |||
|---|---|---|---|---|
| IS-IS for IP Internets P. Sarkar, Ed. | IS-IS for IP Internets P. Sarkar, Ed. | |||
| Internet-Draft H. Gredler | Internet-Draft H. Gredler | |||
| Intended status: Standards Track S. Hegde | Intended status: Standards Track S. Hegde | |||
| Expires: September 10, 2015 Juniper Networks, Inc. | Expires: December 3, 2015 Juniper Networks, Inc. | |||
| S. Litkowski | S. Litkowski | |||
| B. Decraene | B. Decraene | |||
| Orange | Orange | |||
| Z. Li | Z. Li | |||
| Huawei Technologies | Huawei Technologies | |||
| E. Aries | E. Aries | |||
| R. Rodriguez | R. Rodriguez | |||
| H. Raghuveer | H. Raghuveer | |||
| March 9, 2015 | June 1, 2015 | |||
| Advertising Per-node Admin Tags in IS-IS | Advertising Per-node Admin Tags in IS-IS | |||
| draft-ietf-isis-node-admin-tag-01 | draft-ietf-isis-node-admin-tag-02 | |||
| Abstract | Abstract | |||
| This document describes an extension to IS-IS protocol [ISO10589], | This document describes an extension to IS-IS protocol [ISO10589], | |||
| [RFC1195] to add an optional operational capability, that allows | [RFC1195] to add an optional operational capability, that allows | |||
| tagging and grouping of the nodes in an IS-IS domain. This allows | tagging and grouping of the nodes in an IS-IS domain. This allows | |||
| simple management and easy control over route and path selection, | simple management and easy control over route and path selection, | |||
| based on local configured policies. | based on local configured policies. | |||
| This document describes the protocol extensions to disseminate per- | This document describes the protocol extensions to disseminate per- | |||
| skipping to change at page 2, line 7 ¶ | skipping to change at page 2, line 7 ¶ | |||
| 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 September 10, 2015. | This Internet-Draft will expire on December 3, 2015. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 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 2, line 31 ¶ | skipping to change at page 2, line 31 ¶ | |||
| 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. Administrative Tag . . . . . . . . . . . . . . . . . . . . . 3 | 2. Administrative Tag . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 3. TLV format . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. TLV format . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Per-node Admin Tag sub-TLV . . . . . . . . . . . . . . . 4 | 3.1. Per-node Admin Tag sub-TLV . . . . . . . . . . . . . . . 4 | |||
| 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5 | 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5 | |||
| 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 | |||
| 9.2. Informative References . . . . . . . . . . . . . . . . . 12 | 9.2. Informative References . . . . . . . . . . . . . . . . . 12 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 1. Introduction | 1. Introduction | |||
| skipping to change at page 3, line 29 ¶ | skipping to change at page 3, line 29 ¶ | |||
| An administrative Tag is a 32-bit integer value that can be used to | An administrative Tag is a 32-bit integer value that can be used to | |||
| identify a group of nodes in the IS-IS domain. The new sub-TLV | identify a group of nodes in the IS-IS domain. The new sub-TLV | |||
| specifies one or more administrative tag values. An IS-IS router | specifies one or more administrative tag values. An IS-IS router | |||
| advertises the set of groups it is part of in the specific IS-IS | advertises the set of groups it is part of in the specific IS-IS | |||
| level. As an example, all PE-nodes may be configured with certain | level. As an example, all PE-nodes may be configured with certain | |||
| tag value, whereas all P-nodes are configured with a different tag | tag value, whereas all P-nodes are configured with a different tag | |||
| value. | value. | |||
| The new sub-TLV defined will be carried inside the IS-IS Router | The new sub-TLV defined will be carried inside the IS-IS Router | |||
| Capability TLV-242 [RFC4971]) in the Link State PDUs originated by | Capability TLV-242 [RFC4971]) in the Link State PDUs originated by | |||
| the router. Link State PDUs [ISO10589] can be either flooded within | the router. TLV 242 can be either specified to be flooded within the | |||
| the specific level (i.e. L1 or L2) or can be relayed across from one | specific level in which the same has been originated, or they can be | |||
| level to another. Per-node administrative tags included in a TLV 242 | specfied to be relayed from originating level to the other as well. | |||
| to be distributed within the specific level are perceived to have | Per-node administrative tags that are included in a 'level-specific' | |||
| 'level-wide' scope only. On the other hand, per-node administrative | TLV 242 have a 'level-wide' flooding scope associated. On the other | |||
| tag included in a TLV 242 to be distributed across levels are | hand, per-node administrative tags included in a 'domain-wide' TLV | |||
| perceived to have 'domain-wide' scope. | 242 have 'domain-wide' flooding scope associated. For details on how | |||
| TLV 242 are flooded and relayed in the entire network please, refer | ||||
| to [RFC4971]. | ||||
| Choosing the flooding scope to be associate with group tags are | Choosing the flooding scope to be associated with group tags, is | |||
| defined by the needs of the operator's usage and is a matter of local | defined by the needs of the operator's usage and is a matter of local | |||
| policy or configuration. Operator may choose to advertise a set of | policy or configuration. Operator may choose to advertise a set of | |||
| per-node administrative tags across levels and another set of per- | per-node administrative tags across levels and another set of per- | |||
| node administrative tags within the specific level. But evidently | node administrative tags within the specific level. But evidently | |||
| the same set of per-node administrative tags cannot be advertised | the same set of per-node administrative tags cannot be advertised | |||
| both across levels and within a specific level. A receiving IS-IS | both across levels and within a specific level. A receiving IS-IS | |||
| router will not be able to distinguish between the significance of a | router will not be able to distinguish between the significance of a | |||
| per-node administrative tag advertised globally from that of an | per-node administrative tag advertised with 'domain-wide' scope, from | |||
| administrative tag advertised locally if they have the same value | that of an administrative tag advertised with 'level-wide' scope, if | |||
| associated but different significance across different scopes. | they have the same value associated but different significance across | |||
| different scopes. | ||||
| Implementations SHOULD allow configuring one or more per-node | Implementations SHOULD allow configuring one or more per-node | |||
| administrative tags to be advertised from a given device along with | administrative tags to be advertised from a given device along with | |||
| the floofing scope associated with the same. It SHOULD allow | the flooding scope associated with the same. It SHOULD allow | |||
| provisioning a set of per-node administrative tags having a 'domain- | provisioning a set of per-node administrative tags having a 'domain- | |||
| wide' flooding scope, as well as, a set of per-node administrative | wide' flooding scope, as well as, a set of per-node administrative | |||
| tags with 'level-wide' flooding scope only. A given per-node | tags with 'level-wide' flooding scope only. A given per-node | |||
| administrative tag MAY be advertised with level-specific scope | administrative tag MAY be advertised with level-specific scope | |||
| (Level-1 and/or Level-2) or with domain-wide scope, but MUST NOT be | (Level-1 and/or Level-2) or with domain-wide scope, but MUST NOT be | |||
| advertised in both scopes. Hence implementations MUST NOT allow | advertised in both scopes. Hence implementations MUST NOT allow | |||
| configuring the same per-node administrative tag values in both | configuring the same per-node administrative tag values in both | |||
| 'domain-wide' and 'level-wide' scopes. However the same | 'domain-wide' and 'level-wide' scopes. However the same | |||
| administrative tag value MAY be allowed under multiple levels with | administrative tag value MAY be allowed under multiple levels with | |||
| 'level-wide' scope. | 'level-wide' scope. | |||
| In deployments using multi-topology routing [RFC5120], since multiple | The format of per-node Administrative Tag sub-TLV (see Section 3.1) | |||
| topologies within same IS-IS level do not use seprate Router | does not include a topology identifier. Therefore it is not possible | |||
| Capability TLVs (i.e. they share the same flooding scope) a given | to indicate a topology specific context when advertising per-node | |||
| per-node administrative tag cannot be associated with different | admin tags. Hence, in deployments using multi-topology routing | |||
| charateristic or attribute under different topology. | [RFC5120], advertising a separate set of per-node administrative tags | |||
| Implementations, in addition to letting user configuring a set of | for each topology SHOULD NOT be supported. | |||
| 'level-wide' and 'domain-wide' per-node administrative tags for each | ||||
| level, MAY also allow configuring a set of 'level-wide' and 'domain- | ||||
| wide' tags for each topology. Operators may like to associate a | ||||
| single per-node administrative tag with same attribute across all | ||||
| topologies under a specific (or all) levels. The same should be | ||||
| provisioned under specific 'level-wide' (or 'domain-wide') | ||||
| configurations. However advertising the same tag value across | ||||
| multiple topologies will lead to same inconsistencies as with the | ||||
| case of advertising same tag value across 'domain-wide' and 'level- | ||||
| wide' flooding scope. Hence such implementations that allow | ||||
| configuring topology-specific per-node administrative tags, MUST NOT | ||||
| allow configuring the same topology-specific per-node administrative | ||||
| tag across different topologies. They MUST only allow disjoint sets | ||||
| of topology-specific 'level-wide' and 'domain-wide' per-node | ||||
| administrative tags across different topologies. | ||||
| 3. TLV format | 3. TLV format | |||
| 3.1. Per-node Admin Tag sub-TLV | 3.1. Per-node Admin Tag sub-TLV | |||
| The new Per-node Administrative Tag sub-TLV, like other ISIS | The new Per-node Administrative Tag sub-TLV, like other ISIS | |||
| Capability sub-TLVs, is formatted as Type/Length/Value (TLV)triplets. | Capability sub-TLVs, is formatted as Type/Length/Value (TLV)triplets. | |||
| Figure 1 below shows the format of the new sub-TLV. | Figure 1 below shows the format of the new sub-TLV. | |||
| 0 1 2 3 | 0 1 2 3 | |||
| skipping to change at page 5, line 33 ¶ | skipping to change at page 5, line 33 ¶ | |||
| dependent on the number of tags advertised. | dependent on the number of tags advertised. | |||
| Value: A sequence of multiple 4 octets defining the | Value: A sequence of multiple 4 octets defining the | |||
| administrative tags. | administrative tags. | |||
| Figure 1: IS-IS Per-node Administrative Tag sub-TLV | Figure 1: IS-IS Per-node Administrative Tag sub-TLV | |||
| The 'Per-node Admin Tag' sub-TLV may be generated more than once by | The 'Per-node Admin Tag' sub-TLV may be generated more than once by | |||
| an originating router. This MAY happen if a node carries more than | an originating router. This MAY happen if a node carries more than | |||
| 63 per-node administrative groups and a single sub-TLV does not | 63 per-node administrative groups and a single sub-TLV does not | |||
| provide sufficient space. As such occurence of the 'Per-node Admin | provide sufficient space. As such occurrence of the 'Per-node Admin | |||
| Tag' sub-TLV does not cancel previous announcements, but rather is | Tag' sub-TLV does not cancel previous announcements, but rather is | |||
| cumulative. | cumulative. | |||
| 4. Elements of Procedure | 4. Elements of Procedure | |||
| Meaning of the Per-node administrative tags is generally opaque to | Meaning of the Per-node administrative tags is generally opaque to | |||
| IS-IS. Router advertising the per-node administrative tag (or tags) | IS-IS. Router advertising the per-node administrative tag (or tags) | |||
| may be configured to do so without knowing (or even explicitly | may be configured to do so without knowing (or even explicitly | |||
| supporting) functionality implied by the tag. | supporting) functionality implied by the tag. | |||
| skipping to change at page 6, line 33 ¶ | skipping to change at page 6, line 33 ¶ | |||
| different scopes. Implementations MUST NOT allow configuring the | different scopes. Implementations MUST NOT allow configuring the | |||
| same tag value across domain-wide and 'level-wide' scopes. The same | same tag value across domain-wide and 'level-wide' scopes. The same | |||
| tag value MAY be allowed to be configured and advertised under | tag value MAY be allowed to be configured and advertised under | |||
| 'level-wide' scope for all levels. A IS-IS Area Border Router (ABR) | 'level-wide' scope for all levels. A IS-IS Area Border Router (ABR) | |||
| participating in both levels 1 and 2 MAY advertise the same tag value | participating in both levels 1 and 2 MAY advertise the same tag value | |||
| in the level-specific Router Capability TLVs with 'level-wide' scope | in the level-specific Router Capability TLVs with 'level-wide' scope | |||
| generated by it. But the same tag value MUST not be advertised in | generated by it. But the same tag value MUST not be advertised in | |||
| any of level 1 or level 2 Router-Capability TLV with 'domain-wide' | any of level 1 or level 2 Router-Capability TLV with 'domain-wide' | |||
| flooding scope (refer to [RFC4971] for more details). | flooding scope (refer to [RFC4971] for more details). | |||
| The per-node administrative tags sub-TLV don't need to be extended to | ||||
| advertise newer per-node attributes or capabilities in future. | ||||
| Future IS-IS protocol extensions MUST NOT require use of per-node | Future IS-IS protocol extensions MUST NOT require use of per-node | |||
| administrative tags or define well-known tag values to advertise | administrative tags or define well-known tag values to advertise | |||
| well-known capabilities. Per-node administrative tags are for | well-known capabilities. Per-node administrative tags are for | |||
| generic use and do not require IANA registry. Theny future IS-IS | generic use and do not require IANA registry. | |||
| extensions requiring well known values to advertise well-known | ||||
| capabilities MAY define and use new Router Capability sub-TLVs | ||||
| tailored to the needs of the specific solution (refer to [RFC4971] | ||||
| for more details). | ||||
| Being part of the Router Capability TLV, the per-node administrative | Being part of the Router Capability TLV, the per-node administrative | |||
| tag sub-TLV MUST be reasonably small and stable. In particular, but | tag sub-TLV MUST be reasonably small and stable. In particular, but | |||
| not limited to, implementations supporting the per-node | not limited to, implementations supporting the per-node | |||
| administrative tags MUST NOT associate advertised tags to changes in | administrative tags MUST NOT associate advertised tags to changes in | |||
| the network topology (both within and outside the IS-IS domain) or | the network topology (both within and outside the IS-IS domain) or | |||
| reachability of routes. | reachability of routes. | |||
| 5. Applications | 5. Applications | |||
| skipping to change at page 12, line 15 ¶ | skipping to change at page 12, line 15 ¶ | |||
| 7. IANA Considerations | 7. IANA Considerations | |||
| IANA maintains the registry for the Router Capability sub-TLVs. IS- | IANA maintains the registry for the Router Capability sub-TLVs. IS- | |||
| IS Administrative Tags will require new type code for the following | IS Administrative Tags will require new type code for the following | |||
| new sub-TLV defined in this document. | new sub-TLV defined in this document. | |||
| i) Per-Node-Admin-Tag Sub-TLV, Type: TBD | i) Per-Node-Admin-Tag Sub-TLV, Type: TBD | |||
| 8. Acknowledgments | 8. Acknowledgments | |||
| Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri for useful | Many thanks to Les Ginsberg, Dhruv Dhody, Uma Chunduri and Chris | |||
| inputs. Thanks to Chris Bowers for providing useful inputs to remove | Bowers for providing useful inputs. | |||
| ambiguity related to tag-ordering. | ||||
| 9. References | 9. References | |||
| 9.1. Normative References | 9.1. Normative References | |||
| [ISO10589] | [ISO10589] | |||
| "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 | |||
| connectionless-mode Network Service (ISO 8473), ISO/IEC | connectionless-mode Network Service (ISO 8473), ISO/IEC | |||
| End of changes. 14 change blocks. | ||||
| 49 lines changed or deleted | 30 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||