draft-psarkar-idr-bgp-ls-node-admin-tag-extension-03.txt   draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04.txt 
Inter-Domain Routing P. Sarkar, Ed. Inter-Domain Routing P. Sarkar, Ed.
Internet-Draft H. Gredler Internet-Draft H. Gredler
Intended status: Standards Track Juniper Networks, Inc. Intended status: Standards Track Individual Contributor
Expires: May 13, 2016 S. Litkowski Expires: November 14, 2016 S. Litkowski
Orange Orange
November 10, 2015 May 13, 2016
Advertising Per-node Admin Tags in BGP Link-State Advertisements Advertising Node Admin Tags in BGP Link-State Advertisements
draft-psarkar-idr-bgp-ls-node-admin-tag-extension-03 draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04
Abstract Abstract
This document describes the protocol extensions to collect per-node This document describes the protocol extensions to collect node
administrative tags adevertised in IGP Link State advertisements and administrative tags adevertised in IGP Link State advertisements and
disseminate the same in BGP Link-State advertisement protocol, to disseminate the same in BGP Link-State advertisement protocol, to
facilitate inter-AS TE applications that may need the same per-node facilitate inter-AS TE applications that may need the same node
administrative tags to associate a subset of network devices spanning administrative tags to associate a subset of network devices spanning
across more than one AS with a specific functionality. across more than one AS with a specific functionality.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 May 13, 2016. This Internet-Draft will expire on November 14, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4 2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4
3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4
3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5 3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5
4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7
5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Manageability Considerations . . . . . . . . . . . . . . . . 9 7. Manageability Considerations . . . . . . . . . . . . . . . . 9
7.1. Operational Considerations . . . . . . . . . . . . . . . 9 7.1. Operational Considerations . . . . . . . . . . . . . . . 9
7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9
8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Advertising Per-node Administrative Tags in Link State protocols like Advertising Node Administrative Tags in Link State protocols like IS-
IS-IS [I-D.ietf-isis-node-admin-tag] and OSPF IS [I-D.ietf-isis-node-admin-tag] and OSPF
[I-D.ietf-ospf-node-admin-tag] allows adding an optional operational [I-D.ietf-ospf-node-admin-tag] allows adding an optional operational
capability, that allows tagging and grouping of the nodes in a IGP capability, that allows tagging and grouping of the nodes in a IGP
domain. This, among other applications, allows simple management and domain. This, among other applications, allows simple management and
easy control over route and path selection, based on local configured easy control over route and path selection, based on local configured
policies. However per-node administrative tags advertised in IGP policies. However node administrative tags advertised in IGP
advertisements let network operators associate nodes within a single advertisements let network operators associate nodes within a single
AS (if not a single area). This limits the use of such per-node AS (if not a single area). This limits the use of such node
administrative tags and applications that need to associate a subset administrative tags and applications that need to associate a subset
of network devices spanning across multiple AS with a specific of network devices spanning across multiple AS with a specific
functionality cannot use them. functionality cannot use them.
To address the need for applications that require visibility into To address the need for applications that require visibility into
LSDB across IGP areas, or even across ASes, the BGP-LS address- LSDB across IGP areas, or even across ASes, the BGP-LS address-
family/sub-address-family have been defined that allows BGP to carry family/sub-address-family have been defined that allows BGP to carry
LSDB information. The BGP Network Layer Reachability Information LSDB information. The BGP Network Layer Reachability Information
(NLRI) encoding format for BGP-LS and a new BGP Path Attribute called (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called
BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The
skipping to change at page 3, line 45 skipping to change at page 3, line 45
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP | | BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker | | Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
^ ^ ^ ^ ^ ^
| | | | | |
IGP IGP IGP IGP IGP IGP
Figure 1: Link State info collection Figure 1: Link State info collection
For the purpose of advertising per-node administrative tags within For the purpose of advertising node administrative tags within BGP
BGP Link-State advertisements, a new Node Attribute TLV to be carried Link-State advertisements, a new Node Attribute TLV to be carried in
in the corresponding BGP-LS Node NLRI is proposed. For more details the corresponding BGP-LS Node NLRI is proposed. For more details on
on the Node Attribute TLVs please refer to section 3.3.1 in the Node Attribute TLVs please refer to section 3.3.1 in
[I-D.ietf-idr-ls-distribution] [I-D.ietf-idr-ls-distribution]
2. Per-Node Administrative Tag 2. Per-Node Administrative Tag
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 entire routing domain. The new sub- identify a group of nodes in the entire routing domain. The new sub-
TLV specifies one or more administrative tag values. A BGP Link- TLV specifies one or more administrative tag values. A BGP Link-
State speaker that also participates in the IGP link state State speaker that also participates in the IGP link state
advertisements exchange may learn one or more per-node administrative advertisements exchange may learn one or more node administrative
tags advertised by another router in the same IGP domain. Such BGP- tags advertised by another router in the same IGP domain. Such BGP-
LS speaker shall encode the same set of per-node administrative tags LS speaker shall encode the same set of node administrative tags in
in the corresponding Node Attribute TLV representing the network the corresponding Node Attribute TLV representing the network device
device that originated the per-node administrative tags. that originated the node administrative tags.
The per-node administrative tags advertised in IGP link state The node administrative tags advertised in IGP link state
advertisements will have either per-area(or levels in IS-IS)scope or advertisements will have either per-area(or levels in IS-IS)scope or
'global' scope. Operator may choose to a set of per-node 'global' scope. Operator may choose to a set of node administrative
administrative tags across areas (or levels in IS-IS) and another tags across areas (or levels in IS-IS) and another advertise set of
advertise set of per-node administrative tags within the specific node administrative tags within the specific area (or level). But
area (or level). But evidently two areas within the same AS or two evidently two areas within the same AS or two different may use the
different may use the same per-node administrative tag for different same node administrative tag for different purposes. In such case
purposes. In such case applications will need to distinguish between applications will need to distinguish between the per-area(or level)
the per-area(or level) scoped administrative tags originated from a scoped administrative tags originated from a specific node against
specific node against those originated from the same node with those originated from the same node with 'global' scope.
'global' scope.
A BGP-LS router in a given AS while copying the per-node A BGP-LS router in a given AS while copying the node administrative
administrative tags learnt from IGP link-state advertisements, MUST tags learnt from IGP link-state advertisements, MUST also copy the
also copy the scope associated with the per-node administrative tags. scope associated with the node administrative tags. Refer to
Refer to Section 3.1 for how to encode the associated scope of a per- Section 3.1 for how to encode the associated scope of a node
node administrative tags as well. administrative tags as well.
To be able to distinguish between the significance of a per-area(or To be able to distinguish between the significance of a per-area(or
level) administrative tag learnt in one area, from that advertised in level) administrative tag learnt in one area, from that advertised in
another area, or another AS, any applications receiving such a BGP-LS another area, or another AS, any applications receiving such a BGP-LS
advertisements MUST consider the scope associated with each per-node advertisements MUST consider the scope associated with each node
administrative tag with 'per-area (or per-level) along with the administrative tag with 'per-area (or per-level) along with the
area(or level in IS-IS) associated with corresponding IGP link state area(or level in IS-IS) associated with corresponding IGP link state
advertisement and the AS number associated with the originating node. advertisement and the AS number associated with the originating node.
The area(or level) associated with corresponding IGP link state The area(or level) associated with corresponding IGP link state
advertisement and the AS number associated with the originating node advertisement and the AS number associated with the originating node
can be derived from appropriate node attributes (already defined in can be derived from appropriate node attributes (already defined in
BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the
corresponding Node NLRI. corresponding Node NLRI.
3. BGP-LS Extensions for Per-Node Administrative Tags 3. BGP-LS Extensions for Per-Node Administrative Tags
skipping to change at page 5, line 4 skipping to change at page 4, line 52
advertisement and the AS number associated with the originating node advertisement and the AS number associated with the originating node
can be derived from appropriate node attributes (already defined in can be derived from appropriate node attributes (already defined in
BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the
corresponding Node NLRI. corresponding Node NLRI.
3. BGP-LS Extensions for Per-Node Administrative Tags 3. BGP-LS Extensions for Per-Node Administrative Tags
The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI.
The corresponding BGP-LS attribute is a node attribute, a link The corresponding BGP-LS attribute is a node attribute, a link
attribute or a prefix attribute. BGP-LS attribute or a prefix attribute. BGP-LS
[I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state [I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state
information to BGP-LS NLRI and BGP-LS attribute. This document adds information to BGP-LS NLRI and BGP-LS attribute. This document adds
an new Node Attribute TLV called 'Node Admin Tag TLV' to encode per- an new Node Attribute TLV called 'Node Admin Tag TLV' to encode node
node administrative tags information. administrative tags information.
[I-D.ietf-isis-node-admin-tag] defines the 'Per-node Admin Tag' sub- [I-D.ietf-isis-node-admin-tag] defines the 'Node Admin Tag' sub-TLV
TLV in the Router Capability TLV (type 242) in IS-IS Link State PDUs in the Router Capability TLV (type 242) in IS-IS Link State PDUs to
to encode per-node administrative tags. Similarly encode node administrative tags. Similarly
[I-D.ietf-isis-node-admin-tag] defines the 'Per-node Administrative [I-D.ietf-isis-node-admin-tag] defines the 'Node Administrative Tag'
Tag' TLV in OSPF Router Information LSAs to encode per-node TLV in OSPF Router Information LSAs to encode node administrative
administrative tags in OSPF Link State update packets. The per-node tags in OSPF Link State update packets. The node administrative tags
administrative tags TLVs learnt from the IGP link state TLVs learnt from the IGP link state advertisements of a specific node
advertisements of a specific node will all be inserted in a new Node will all be inserted in a new Node Admin Tag TLV and added to the
Admin Tag TLV and added to the corresponding Node are mapped to the corresponding Node are mapped to the corresponding BGP-LS Node NLRI.
corresponding BGP-LS Node NLRI. Per-node administrative tags from Node administrative tags from IGP advertisements are mapped to the
IGP advertisements are mapped to the corresponding Node Admin Tag TLV corresponding Node Admin Tag TLV in the following way.
in the following way.
+----------+---------------+----------+---------------+-------------+ +----------+---------------+----------+---------------+-------------+
| TLV Code | Description | Length | IS-IS TLV | OSPF | | TLV Code | Description | Length | IS-IS TLV | OSPF |
| Point | | | /sub-TLV | LSA/TLV | | Point | | | /sub-TLV | LSA/TLV |
+----------+---------------+----------+---------------+-------------+ +----------+---------------+----------+---------------+-------------+
| TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD | | TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD |
| | Tag TLV | | | [2] | | | Tag TLV | | | [2] |
+----------+---------------+----------+---------------+-------------+ +----------+---------------+----------+---------------+-------------+
Table 1: Node Admin Tag TLV Mapping from IGP Table 1: Node Admin Tag TLV Mapping from IGP
skipping to change at page 6, line 22 skipping to change at page 6, line 22
| Administrative Tag #1 | | Administrative Tag #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #2 | | Administrative Tag #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// // // //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #N | | Administrative Tag #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : A 2-octet field specifiying code-point of the new Type : A 2-octet field specifiying code-point of the new
sub-TLV type. Code-point: TBA (suggested 1040) TLV type. Code-point: TBA (suggested 1040)
Length: A 2-octet field that indicates the length of the value Length: A 2-octet field that indicates the length of the value
portion in octets and will be a multiple of 4 octets portion in octets and will be a multiple of 4 octets
dependent on the number of tags advertised. dependent on the number of tags advertised.
Value: A 2-octet 'Flags' field, followed by a sequence of multiple Value: A 2-octet 'Flags' field, followed by a sequence of multiple
4 octets defining the administrative tags. 4 octets defining the administrative tags.
Flags: A 2-octet field that carries flags associated with Flags: A 2-octet field that carries flags associated with
all the administrative flags encoded in this TLV. all the administrative flags encoded in this TLV.
skipping to change at page 7, line 7 skipping to change at page 7, line 7
all administrative flags encoded in this all administrative flags encoded in this
TLV has per-area(or level in IS-IS) scope, TLV has per-area(or level in IS-IS) scope,
and should not be mixed with ones with same and should not be mixed with ones with same
value but with 'global' scope (L bit reset value but with 'global' scope (L bit reset
to 0). to 0).
Figure 2: BGP Link-State Node Administrative Tag TLV Figure 2: BGP Link-State Node Administrative Tag TLV
This new type of 'Node Admin Tag' TLVs can ONLY be added to the Node This new type of 'Node Admin Tag' TLVs can ONLY be added to the Node
Attribute associated with the Node NLRI that originates the Attribute associated with the Node NLRI that originates the
corresponding per-node administrative tags in IGP domain. corresponding node administrative tags in IGP domain.
All the per-node administrative tags with 'per-area' (or per-level) All the node administrative tags with 'per-area' (or per-level)
scope, originated by a single node in IGP domain SHALL be re- scope, originated by a single node in IGP domain SHALL be re-
originated in a single 'Node Admin Tag' TLV and inserted in the Node originated in a single 'Node Admin Tag' TLV and inserted in the Node
NLRI generated for the same node. Similarly, all the per-node NLRI generated for the same node. Similarly, all the node
administrative tags with 'global' scope originated by the same node administrative tags with 'global' scope originated by the same node
in IGP domain SHALL be re-originated in another 'Node Admin Tag' TLV in IGP domain SHALL be re-originated in another 'Node Admin Tag' TLV
and inserted in the same Node NLRI generated for the originating and inserted in the same Node NLRI generated for the originating
node. Multiple instances of a TLV may be generated by the BGP-lS node. Multiple instances of a TLV may be generated by the BGP-lS
router for a given node in the IGP domain. This MAY happen if the router for a given node in the IGP domain. This MAY happen if the
original node's link state advertisement carries more than 16383 per- original node's link state advertisement carries more than 16383 node
node administrative groups and a single TLV does not provide administrative groups and a single TLV does not provide sufficient
sufficient space. As such multiple occurence of the 'Node Admin Tag' space. As such multiple occurence of the 'Node Admin Tag' TLVs under
TLVs under a single BGP LS NLRI is cumulative. a single BGP LS NLRI is cumulative.
While copying per-node administrative tags from IGP link-state While copying node administrative tags from IGP link-state
advertisements to corresponding BGP-LS advertisements, the said BGP- advertisements to corresponding BGP-LS advertisements, the said BGP-
LS speaker MAY run all the per-node administrative flags through a LS speaker MAY run all the node administrative flags through a
locally configured policy that selects which ones should be exported locally configured policy that selects which ones should be exported
and which ones not. And then the per-node administrative tag is and which ones not. And then the node administrative tag is copied
copied to the BGP-LS advertisement if it is permitted to do so by the to the BGP-LS advertisement if it is permitted to do so by the said
said policy. policy.
4. Elements of Procedure 4. Elements of Procedure
Meaning of the Per-node administrative tags is generally opaque to Meaning of the Node administrative tags is generally opaque to BGP
BGP Link-State protocol. Router advertising the per-node Link-State protocol. Router advertising the node administrative tag
administrative tag (or tags) may be configured to do so without (or tags) may be configured to do so without knowing (or even
knowing (or even explicitly supporting) functionality implied by the explicitly supporting) functionality implied by the tag.
tag.
Interpretation of tag values is specific to the administrative domain Interpretation of tag values is specific to the administrative domain
of a particular network operator. The meaning of a per-node of a particular network operator. The meaning of a node
administrative tag is defined by the network local policy and is administrative tag is defined by the network local policy and is
controlled via the configuration. However multiple administrative controlled via the configuration. However multiple administrative
domain owners may agree on a common meaning implied by a domain owners may agree on a common meaning implied by a
administrative tag for mutual benefit. administrative tag for mutual benefit.
The semantics of the tag order has no meaning. There is no implied The semantics of the tag order has no meaning. There is no implied
meaning to the ordering of the tags that indicates a certain meaning to the ordering of the tags that indicates a certain
operation or set of operations that need to be performed based on the operation or set of operations that need to be performed based on the
ordering. ordering.
Each tag SHOULD be treated as an independent identifier that MAY be Each tag SHOULD be treated as an independent identifier that MAY be
used in policy to perform a policy action. Per-node administrative used in policy to perform a policy action. Node administrative tags
tags carried by the Node Admin Tag TLV SHOULD be used to indicate a carried by the Node Admin Tag TLV SHOULD be used to indicate a
independent characteristics of the node in IGP domain that originated independent characteristics of the node in IGP domain that originated
it. The TLV SHOULD be considered as an unordered list. Whilst it. The TLV SHOULD be considered as an unordered list. Whilst
policies may be implemented based on the presence of multiple tags policies may be implemented based on the presence of multiple tags
(e.g., if tag A AND tag B are present), they MUST NOT be reliant upon (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon
the order of the tags (i.e., all policies should be considered the order of the tags (i.e., all policies should be considered
commutative operations, such that tag A preceding or following tag B commutative operations, such that tag A preceding or following tag B
does not change their outcome). does not change their outcome).
For more details on guidance on usage of per-node administrative tags For more details on guidance on usage of node administrative tags
please refer to section 4 [3] in [I-D.ietf-isis-node-admin-tag]. please refer to section 4 [3] in [I-D.ietf-isis-node-admin-tag].
5. Applications 5. Applications
[I-D.ietf-isis-node-admin-tag] and [I-D.ietf-ospf-node-admin-tag] [I-D.ietf-isis-node-admin-tag] and [I-D.ietf-ospf-node-admin-tag]
present some applications of node administrative tags. present some applications of node administrative tags.
The policy-based Explicit routing use case can be extended to inter- The policy-based Explicit routing use case can be extended to inter-
area or inter-AS scenarios where an end to end path needs to avoid or area or inter-AS scenarios where an end to end path needs to avoid or
include nodes that have particular properties. Following are some include nodes that have particular properties. Following are some
skipping to change at page 8, line 41 skipping to change at page 8, line 40
country C. country C.
2. Legacy node avoidance : in some specific cases, it is interesting 2. Legacy node avoidance : in some specific cases, it is interesting
for service-provider to force some traffic to avoid legacy nodes for service-provider to force some traffic to avoid legacy nodes
in the network. For example, legacy nodes may not be carrier in the network. For example, legacy nodes may not be carrier
class (no high availability), and service provider wants to class (no high availability), and service provider wants to
ensure that critical traffic only uses nodes that are providing ensure that critical traffic only uses nodes that are providing
high availability. high availability.
In case of inter-AS Traffic-Engineering applications, different ASes In case of inter-AS Traffic-Engineering applications, different ASes
SHOULD share their admin tag policies. They MAY also need to agree SHOULD share their administrative tag policies. They MAY also need
upon some common tagging policy for specific applications. to agree upon some common tagging policy for specific applications.
For more details on some possible applications with per-node For more details on some possible applications with node
administrative tags please refer to section 5 [4] in administrative tags please refer to section 5 [4] in
[I-D.ietf-isis-node-admin-tag]. [I-D.ietf-isis-node-admin-tag].
6. IANA Considerations 6. IANA Considerations
This document requests assigning code-points from the registry for This document requests assigning code-points from the registry for
BGP-LS attribute TLVs based on table Table 2. BGP-LS attribute TLVs based on table Table 2.
7. Manageability Considerations 7. Manageability Considerations
skipping to change at page 11, line 22 skipping to change at page 11, line 14
[3] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- [3] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag-
00#section-4 00#section-4
[4] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- [4] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag-
00#section-5 00#section-5
Authors' Addresses Authors' Addresses
Pushpasis Sarkar (editor) Pushpasis Sarkar (editor)
Juniper Networks, Inc. Individual Contributor
Electra, Exora Business Park
Bangalore, KA 560103
India
Email: psarkar@juniper.net; pushpasis.ietf@gmail.com Email: pushpasis.ietf@gmail.com
Hannes Gredler Hannes Gredler
Juniper Networks, Inc. Individual Contributor
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: hannes@gredler.at Email: hannes@gredler.at
Stephane Litkowski Stephane Litkowski
Orange Orange
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
 End of changes. 39 change blocks. 
88 lines changed or deleted 78 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/