-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-psarkar-isis-node-admin-tag.xml
288 lines (244 loc) · 11 KB
/
draft-psarkar-isis-node-admin-tag.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-psarkar-isis-node-admin-tag-01" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Advertising Per-node Admin Tags in IS-IS</title>
<author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar" role="editor">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="H." surname="Raghuveer" fullname="Harish Raghuveer">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Stephane Litkowski" initials="S" surname="Litkowski">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>[email protected]</email>
<!-- <uri/> -->
</address>
</author>
<author fullname="Bruno Decraene" initials="B" surname="Decraene">
<organization>Orange</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>[email protected]</email>
<!-- <uri/> -->
</address>
</author>
<date day="14" month="February" year="2014" />
<area>Routing</area>
<workgroup>IS-IS for IP Internets</workgroup>
<keyword>IGP</keyword>
<keyword>IS-IS</keyword>
<keyword>Admin-Tag</keyword>
<keyword>Traffic Engineering</keyword>
<abstract>
<t> This document describes an extension to IS-IS protocol <xref target="ISO10589"/>,
<xref target="RFC1195"/> to add an optional operational capability, that allows
tagging and grouping ofthe nodes in an IS-IS domain. This allows simple management
and easy control over route and path selection, based on local configured policies.
</t>
<t>This document describes the protocol extensions to disseminate
per-node admin-tags in IS-IS protocols.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t> This document provides mechanisms to advertise per-node administrative tags
in the IS-IS Link State PDU <xref target="RFC1195"/>. In certain path-selection
applications like for example in traffic-engineering or LFA <xref target="RFC5286"/>
selection there is a need to tag the nodes based on their roles in the network
and have policies to prefer or prune a certain group of nodes.
</t>
</section>
<section title='Administrative Tag'>
<t>For the purpose of advertising per-node administrative tags within IS-IS,
a new sub-TLV to the IS-IS Router Capability TLV-242 that is defined in <xref
target="RFC4971"/> is proposed.
Because path selection is a functional set which
applies both to TE and non-TE applications the same has not added as a new
sub-TLV in the Traffic Engingineering TLVs <xref target="RFC5305"/>.
</t>
<t> 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 specifies one or more administrative
tag values. An IS-IS node 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 tag value,
whereas all P-nodes are configured with a different tag value in.
</t>
<t>The new sub-TLV defined will be carried inside the IS-IS Router Capability TLV-242
(defined in <xref target="RFC4971"/>) in the Link State PDUs originated
by the router. Link State PDUs <xref target="ISO10589"/> has level-wise (i.e. L1 or L2)
flooding scope. Choosing the flooding scope to flood the group tags are defined by the
policies and is a local matter. Once a group tag is decided in a specific level the
same will be inserted in the administrative tag sub-TLV in the Link State PDU for the
same level. Implementations should allow configuring both a 'global' and 'per-level'
admin tag. In the absence of a specific admin tag configuration for a specific level
the global admin tag should be copied in to the LSP PDU for the same level.
</t>
</section>
<section title='TLV format'>
<section title='Per-node Admin Tag sub-TLV'>
<t>The new Administrative Tag sub-TLV, like other ISIS Capability sub-TLVs, is formatted as Type/Length/Value
(TLV)triplets. <xref target="isisadmintagtlv"/> below shows the format of the new sub-TLV.
</t>
<figure anchor="isisadmintagtlv" title="IS-IS per-node Administrative Tag sub-TLV">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Tag #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type : TBA
Length: A 8-bit field that indicates the length of the value
portion in octets and will be a multiple of 4 octets
dependent on the number of tags advertised.
Value: A sequence of multiple 4 octets defining the
administrative tags.
</artwork>
</figure>
<t>
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 63 per-node admin groups
and a single sub-TLV does not provide sufficient space. As such occurence of the
'Per-node Admin Tag' sub-TLV does not cancel previous announcements, but rather
is cumulative.
</t>
</section>
<section title='Ordering of tags'>
<t> The semantics of the tag order are implementation-dependent. There is no implied
meaning to the ordering of the tags that indicates a certain operation or set of
operations that need to be performed based on the ordering.
</t>
<t> Each tag SHOULD be treated as an independent identifier that MAY be used in policy
to perform a policy action. Whether or not tag A precedes or succeeds tag B SHOULD not
change the meaning of the tag set.
</t>
</section>
</section>
<section title='Applications'>
<t> Increased deployment of Loop Free Alternates (LFA) <xref target="RFC5286"/> has
exposed some limitations. A recent draft on Operation management of Loop Free Alternates
<xref target="I-D.ietf-rtgwg-lfa-manageability"/> proposes refinements to address
those limitations. One of the proposed refinements is to be able to group the nodes in
IGP domain with administrative tags and engineer the alternate paths based on configured
policies.
</t>
<t> The proposal in this document helps provide the capability to advertise group tags
within IS-IS protocol and perform policy based LFA selection. The policies configured on
each node can then make use of these tags to prefer or prune LFAs via certain group
of nodes.
</t>
</section>
<!-- HG: FIXME: add traffic-engineering reference -->
<section title='Security Considerations' anchor='sec-con'>
<t>
This document does not introduce any further security issues other than those discussed
in <xref target="ISO10589"/> and <xref target="RFC1195"/>.
</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>IANA maintains the registry for the Router Capability sub-TLVs. IS-IS Administrative Tags
will require one new type code for the sub-TLV defined in this document.
</t>
</section>
<section title='Acknowledgments'>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<reference anchor="ISO10589">
<front>
<title>Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode Network Service
(ISO 8473), ISO/IEC 10589:2002, Second Edition.</title>
<author fullname="ISO "International Organization for Standardization""/>
<date month="Nov" year="2002"/>
</front>
</reference>
</references>
<references title='Informative References'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4971.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtgwg-lfa-manageability-00.xml"?>
</references>
</back>
</rfc>