1<?xml version='1.0' encoding='utf-8'?>
2<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
3<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-isis-l2bundles-07.txt" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">
4  <!-- xml2rfc v2v3 conversion 2.23.0 -->
5  <front>
6    <title abbrev="isis-l2bundles">Advertising L2 Bundle Member Link
7    Attributes in IS-IS</title>
8    <seriesInfo name="Internet-Draft" value="draft-ietf-isis-l2bundles-07.txt"/>
9    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
10      <organization>Cisco Systems</organization>
11      <address>
12        <postal>
13          <street>510 McCarthy Blvd.</street>
14          <city>Milpitas</city>
15          <code>95035</code>
16          <region>CA</region>
17          <country>USA</country>
18        </postal>
19        <email>ginsberg@cisco.com</email>
20      </address>
21    </author>
22    <author fullname="Ahmed Bashandy" initials="A" surname="Bashandy">
23      <organization>Cisco Systems</organization>
24      <address>
25        <postal>
26          <street>170 West Tasman Drive</street>
27          <city>San Jose</city>
28          <code>95134</code>
29          <region>Ca</region>
30          <country>US</country>
31        </postal>
32      </address>
33    </author>
34    <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
35      <organization>Cisco Systems</organization>
36      <address>
37        <postal>
38          <street/>
39          <city/>
40          <code/>
41          <region/>
42          <country/>
43        </postal>
44        <email>cf@cisco.com</email>
45      </address>
46    </author>
47    <author fullname="Mohan Nanduri" initials="M" surname="Nanduri">
48      <organization>eBay</organization>
49      <address>
50        <postal>
51          <street/>
52          <city/>
53          <code/>
54          <country/>
55        </postal>
56        <email>mnanduri@ebay.com</email>
57      </address>
58    </author>
59    <author fullname="Ebben Aries" initials="E" surname="Aries">
60      <organization>Private Contributer</organization>
61      <address>
62        <postal>
63          <street/>
64          <city/>
65          <code/>
66          <country/>
67        </postal>
68        <email>exa@dscp.org</email>
69      </address>
70    </author>
71    <date day="25" month="May" year="2017"/>
72    <area>Routing Area</area>
73    <workgroup>Networking Working Group</workgroup>
74    <keyword>Sample</keyword>
75    <abstract>
76      <t>There are deployments where the Layer 3 interface on which IS-IS
77      operates is a Layer 2 interface bundle. Existing IS-IS advertisements
78      only support advertising link attributes of the Layer 3 interface. If
79      entities external to IS-IS wish to control traffic flows on the
80      individual physical links which comprise the Layer 2 interface bundle
81      link attribute information about the bundle members is required.</t>
82      <t>This document introduces the ability for IS-IS to advertise the link
83      attributes of layer 2 (L2) bundle members.</t>
84    </abstract>
85    <note>
86      <name>Requirements Language</name>
87      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
88      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
89      document are to be interpreted as described in RFC 2119 [RFC2119].</t>
90    </note>
91  </front>
92  <middle>
93    <section numbered="true" toc="default">
94      <name>Introduction</name>
95      <t>There are deployments where the Layer 3 interface on which an IS-IS
96      adjacency is established is a Layer 2 interface bundle, for instance a
97      Link Aggregation Group (LAG) [IEEE802.1AX]. This reduces the number of
98      adjacencies which need to be maintained by the routing protocol in cases
99      where there are parallel links between the neighbors. Entities external
100      to IS-IS such as Path Computation Elements (PCE) [RFC4655] may wish to
101      control traffic flows on individual members of the underlying Layer 2
102      bundle. In order to do so link attribute information about individual
103      bundle members is required. The protocol extensions defined in this
104      document provide the means to advertise this information.</t>
105      <t>This document introduces a new TLV to advertise link attribute
106      information for each of the L2 bundle members which comprise the Layer 3
107      interface on which IS-IS operates.</t>
108      <t>[SR-ISIS] introduces a new link attribute - adjacency segment
109      identifier (Adj-SID) - which can be used as an instruction to forwarding
110      to send traffic over a specific link. This document introduces
111      additional sub-TLVs to advertise Adj-SIDs for L2 Bundle members.</t>
112      <t>Note that the new advertisements defined in this document are
113      intended to be provided to external (to IS-IS) entities. The following
114      items are intentionally not defined and/or are outside the scope of this
115      document:</t>
116      <ul spacing="normal">
117        <li>What link attributes will be advertised. This is determined by
118          the needs of the external entities.</li>
119        <li>A minimum or default set of link attributes.</li>
120        <li>How these attributes are configured</li>
121        <li>How the advertisements are used</li>
122        <li>What impact the use of these advertisements may have on traffic
123          flow in the network</li>
124        <li>How the advertisements are passed to external entities</li>
125      </ul>
126    </section>
127    <section numbered="true" toc="default">
128      <name>L2 Bundle Member Attributes TLV</name>
129      <t>A new TLV is introduced to advertise L2 Bundle member attributes.
130      Although much of the information is identical to and uses the same
131      sub-TLVs included in Extended IS-Neighbor advertisements (TLVs 22 and
132      222), a new TLV is used so that changes to the advertisement of the L2
133      Bundle member link attributes does not trigger unnecessary action by the
134      [ISO10589] Decision process.</t>
135      <t>Advertisement of this information implies that the identified link is
136      a member of the L2 Bundle associated with the identified Parent L3
137      Neighbor and that the member link is operationally up. Therefore
138      advertisements MUST be withdrawn if the link becomes operationally down
139      or it is no longer a member of the identified L2 Bundle.</t>
140      <t>This new TLV utilizes the sub-TLV space defined for TLVs 22, 23, 141,
141      222, and 223.</t>
142      <t>The following new TLV is introduced:</t>
143      <artwork name="" type="" align="left" alt=""><![CDATA[    L2 Bundle Member Attributes
144    Type: 25 (suggested - to be assigned by IANA)
145    Length: Number of octets to follow
146
147    Parent L3 Neighbor Descriptor
148     L3 Neighbor System ID + pseudonode ID (7 octets)
149     Flags: 1 octet field of following flags:
150
151          0 1 2 3 4 5 6 7
152         +-+-+-+-+-+-+-+-+
153         |P|             |
154         +-+-+-+-+-+-+-+-+
155
156        where:
157
158        P-flag: When set to 1 one of the sub-TLVs described
159        in Section 2.1 immediately follows the flags field.
160        If the P-flag is set to 0, then none of the sub-TLVs
161        described in Section 2.1 are present.
162
163        Other bits: MUST be zero when originated and ignored when
164         received.
165
166   One or more of the following:
167    L2 Bundle Attribute Descriptors
168      Length of L2 Bundle Attribute Descriptor (1 octet)
169        NOTE: This includes all fields described below.
170
171      Number of L2 Bundle Member Descriptors (1 octet)
172      L2 Bundle Member Link Local Identifiers
173        (4 * Number of L2 Bundle Member Descriptors octets)
174 
175        NOTE: An L2 Bundle Member Descriptor is a Link Local
176        Identifier as defined in [RFC4202].
177
178      sub-TLV(s)
179      
180      A sub-TLV may define an attribute common to all of
181      the bundle members listed or a sub-TLV may define an
182      attribute unique to each bundle member. Use of these 
183      two classes of sub-TLVs is described in the following
184      sections.
185
186]]></artwork>
187      <t>NOTE: Only one Parent L3 Neighbor Descriptor is present in a
188      given TLV. Multiple L2 Bundle Attribute Descriptors may be present in a
189      single TLV.</t>
190      <section numbered="true" toc="default">
191        <name>Parallel L3 Adjacencies</name>
192        <t>When there exist multiple L3 adjacencies to the same neighbor
193        additional information is required to uniquely identify the L3
194        Neighbor. One and only one of the following three sub-TLVs is used to
195        uniquely identify the L3 adjacency:</t>
196        <ul spacing="normal">
197          <li>IPv4 Interface Address (sub-TLV 6 defined in [RFC5305])</li>
198          <li>IPv6 Interface Address (sub-TLV 12 defined in [RFC6119])</li>
199          <li>Link Local/Remote Identifiers (sub-TLV 4 defined in
200            [RFC5307])</li>
201        </ul>
202        <t>When the P-bit is set in the flags field in the Parent L3 Neighbor
203        Descriptor one and only one of the above sub-TLVs MUST be present. The
204        chosen sub-TLV MUST immediately follow the flags field described in
205        Section 2.</t>
206        <t>These sub-TLVs MAY be omitted if no parallel adjacencies to the
207        neighbor exist.</t>
208      </section>
209      <section numbered="true" toc="default">
210        <name>Shared Attribute sub-TLVs</name>
211        <t>These sub-TLVs advertise a single copy of an attribute (e.g. link
212        bandwidth). The attribute applies to all of the L2 Bundle Members in
213        the set advertised under the preceding  L2 Bundle Member
214        Attribute Descriptor. No more than one copy of a given sub-TLV in this
215        category may appear in the set of sub-TLVs under the preceding L2
216        Bundle Member Attribute Descriptor. If multiple copies of a given
217        sub-TLV are present all copies MUST be ignored.</t>
218        <t>The set of L2 Bundle Member Descriptors which may be advertised
219        under a single L2 Bundle Member Attribute Descriptor is therefore
220        limited to bundle members which share the set of attributes advertised
221        in the shared attribute sub-TLVs.</t>
222        <t>All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23,
223        141, 222, and 223 registry are in the category of shared attribute
224        sub-TLVs unless otherwise specified in this document.</t>
225      </section>
226    </section>
227    <section numbered="true" toc="default">
228      <name>Advertising L2 Bundle Member Adj-SIDs</name>
229      <t>[SR-ISIS] defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies.
230      However these sub-TLVs only support a advertisement of a single Adj-SID.
231      As it is expected that each L2 Bundle member will have unique Adj-SIDs
232      in many deployments it is desirable to define a new sub-TLV which allows
233      more efficient encoding of a set of Adj-SIDs in a single sub-TLV. Two
234      new sub-TLVs are therefore introduced to support advertising Adj-SIDs
235      for L2 Bundle members. The format of the new sub-TLVs is similar to that
236      used for L3 adjacencies, but is optimized to allow advertisement of a
237      set of Adj-SIDs (one per L2 Bundle Member) in a single sub-TLV.</t>
238      <t>The two new sub-TLVs defined in the following sections do not fall
239      into the category of shared attribute sub-TLVs.</t>
240      <section numbered="true" toc="default">
241        <name>L2 Bundle Member Adjacency Segment Identifier sub-TLV</name>
242        <t>This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members
243        associated with a parent L3 adjacency which is Point-to-Point. The
244        following format is defined for this sub-TLV:</t>
245        <artwork name="" type="" align="left" alt=""><![CDATA[     Type: 41 (suggested value to be assigned by IANA) (1 octet)
246     Length: variable (1 octet)
247
248  
249     Flags: 1 octet field of following flags:
250
251          0 1 2 3 4 5 6 7
252         +-+-+-+-+-+-+-+-+
253         |F|*|V|L|S|P|   |
254         +-+-+-+-+-+-+-+-+
255
256        where:
257
258         NOTE: The flags are deliberately kept congruent to the flags 
259         in the L3 ADJ-SID defined in [SR-ISIS].
260         * indicates a flag used in the L3 Adj-SID sub-TLV but which is
261         NOT used in this sub-TLV. These bits SHOULD be sent as 0 and 
262         MUST be ignored on receipt.
263
264         F-Flag: Address-Family flag.  If unset, then the Adj-SID refers
265         to an L2 Bundle Member with outgoing IPv4 encapsulation. If set
266         then the Adj-SID refers to an L2 Bundle Member with outgoing
267         IPv6 encapsulation.
268
269         V-Flag: Value flag.  If set, then the Adj-SID carries a value.
270         By default the flag is SET.
271
272         L-Flag: Local Flag.  If set, then the value/index carried by
273         the Adj-SID has local significance.  By default the flag is
274         SET.
275
276         S-Flag.  Set Flag.  When set, the S-Flag indicates that the
277         Adj-SID refers to a set of L2 Bundle Members (and therefore
278         MAY be assigned to other L2 Bundle Members as well).
279
280         P-Flag.  Persistent flag.  When set, the P-Flag indicates that
281         the Adj-SID is persistently allocated, i.e., the Adj-SID value
282         remains consistent across router restart and/or interface flap.
283
284         Other bits: MUST be zero when originated and ignored when
285         received.
286
287    Weight: 1 octet.  The value represents the weight of the Adj-SID
288        for the purpose of load balancing.  The use of the weight is
289        defined in [SR-ARCH].
290
291    NOTE: Flags and weight are shared by all L2 Bundle Members
292    listed in the L2 Bundle Attribute Descriptor.
293
294    L2 Bundle Member Adj-SID Descriptors. There MUST be one descriptor
295     for each of the L2 Bundle Members advertised under the preceding
296     L2 Bundle Member Attribute Descriptor. Each descriptor consists 
297     of one of the following fields:
298
299      SID/Index/Label: according to the V and L flags, it contains
300        either:
301
302        *  A 3 octet local label where the 20 rightmost bits are used
303           for encoding the label value.  In this case the V and L 
304           flags MUST be set.
305
306        *  A 4 octet index defining the offset in the SID/Label space
307           advertised by this router. See [SR-ISIS].
308           In this case V and L flags MUST be unset.
309
310
311]]></artwork>
312      </section>
313      <section numbered="true" toc="default">
314        <name>L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV</name>
315        <t>This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members
316        associated with a parent L3 adjacency which is a LAN adjacency. In LAN
317        subnetworks, the Designated Intermediate System (DIS) is elected and
318        originates the Pseudonode-LSP (PN-LSP) including all neighbors of the
319        DIS. When Segment Routing is used, each router in the LAN MAY
320        advertise the Adj-SID of each of its neighbors on the LAN. Similarly,
321        for each L2 Bundle Member a router MAY advertise an Adj-SID to each
322        neighbor on the LAN.</t>
323        <t>The following format is defined for this sub-TLV:</t>
324        <artwork name="" type="" align="left" alt=""><![CDATA[     Type: 42 (suggested value to be assigned by IANA) (1 octet)
325     Length: variable (1 octet)
326     Neighbor System ID: 6 octets
327
328 
329     Flags: 1 octet field of following flags:
330
331          0 1 2 3 4 5 6 7
332         +-+-+-+-+-+-+-+-+
333         |F|*|V|L|S|P|   |
334         +-+-+-+-+-+-+-+-+
335
336        where:
337
338         NOTE: The flags are deliberately kept congruent to the flags 
339         in the L3 LAN_ADJ-SID defined in [SR-ISIS].
340         * indicates a flag used in the L3 Adj-SID sub-TLV but which is
341         NOT used in this sub-TLV. These bits SHOULD be sent as 0 and 
342         MUST be ignored on receipt.
343
344         F-Flag: Address-Family flag.  If unset, then the Adj-SID refers
345         to an L2 Bundle Member with outgoing IPv4 encapsulation. If set
346         then the Adj-SID refers to an L2 Bundle Member with outgoing
347         IPv6 encapsulation.
348
349         V-Flag: Value flag.  If set, then the Adj-SID carries a value.
350         By default the flag is SET.
351
352         L-Flag: Local Flag.  If set, then the value/index carried by
353         the Adj-SID has local significance.  By default the flag is
354         SET.
355
356         S-Flag.  Set Flag.  When set, the S-Flag indicates that the
357         Adj-SID refers to a set of L2 Bundle Members (and therefore
358         MAY be assigned to other L2 Bundle Members as well).
359
360         P-Flag.  Persistent flag.  When set, the P-Flag indicates that
361         the Adj-SID is persistently allocated, i.e., the Adj-SID value
362         remains consistent across router restart and/or interface flap.
363
364         Other bits: MUST be zero when originated and ignored when
365         received.
366
367    Weight: 1 octet.  The value represents the weight of the Adj-SID
368    for the purpose of load balancing.  The use of the weight is
369    defined in [SR-ARCH].
370
371    NOTE: Flags and weight are shared by all L2 Bundle Members
372    listed in the L2 Bundle Attribute Descriptor.
373
374    L2 Bundle Member LAN Adj-SID Descriptors. There MUST be one
375    descriptor for each of the L2 Bundle Members advertised 
376    under the preceding L2 Bundle Member Attribute Descriptor.
377    Each descriptor consists of one of the following fields:
378
379      SID/Index/Label: according to the V and L flags, it contains
380        either:
381
382        *  A 3 octet local label where the 20 rightmost bits are used
383           for encoding the label value.  In this case the V and L 
384           flags MUST be set.
385
386        *  A 4 octet index defining the offset in the SID/Label space
387           advertised by this router. See [SR-ISIS].
388           In this case V and L flags MUST be unset.
389 
390
391]]></artwork>
392      </section>
393    </section>
394    <section anchor="IANA" numbered="true" toc="default">
395      <name>IANA Considerations</name>
396      <t>This document adds the following new TLV to the IS-IS TLV Codepoints
397      registry.</t>
398      <t>Value: 25 (suggested - to be assigned by IANA)</t>
399      <t>Name: L2 Bundle Member Attributes</t>
400      <t>The name of the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry
401      needs to be changed to Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
402      registry. An additional column needs to be added to the registry to
403      indicate which sub-TLVs may appear in the new L2 Bundle Member
404      Attributes TLV. The column for TLV 25 has one of the following three
405      values:</t>
406      <artwork name="" type="" align="left" alt=""><![CDATA[y - sub-TLV may appear in TLV 25 but MUST NOT be shared by multiple 
407    L2 Bundle Members
408y(s) - sub-TLV may appear in TLV 25 and MAY be shared by multiple 
409    L2 Bundle Members
410n - sub-TLV MUST NOT appear in TLV 25]]></artwork>
411      <t>The following table indicates the appropriate settings for all
412      currently defined sub-TLVs as regards their use in the new L2 Bundle
413      Member Attributes TLV.</t>
414      <artwork name="" type="" align="left" alt=""><![CDATA[    3 Administrative group (color) y(s)
415    4 Link Local/Remote Identifiers y(s)
416    6 IPv4 interface address y(s)
417    8 IPv4 neighbor address y(s)
418    9 Maximum link bandwidth y(s)
419    10 Maximum reservable link bandwidth y(s)
420    11 Unreserved bandwidth y(s)
421    12 IPv6 Interface Address y(s)
422    13 IPv6 Neighbor Address y(s)
423    14 Extended Administrative Group y(s)
424    18 TE Default metric y(s)
425    19 Link-attributes y(s)
426    20 Link Protection Type y(s)
427    21 Interface Switching Capability Descriptor y(s)
428    22 Bandwidth Constraints y(s)
429    23 Unconstrained TE LSP Count y(s)
430    24 Remote AS number n
431    25 IPv4 remote ASBR Identifier n
432    26 IPv6 remote ASBR Identifier n
433    27 Interface Adjustment Capability Descriptor (IACD) y(s)
434    28 MTU n
435    29 SPB-Metric y(s)
436    30 SPB-A-OALG y(s)
437    33 Unidirectional Link Delay y
438    34 Min/Max Unidirectional Link Delay y
439    35 Unidirectional Delay Variation y
440    36 Unidirectional Link Loss y
441    37 Unidirectional Residual Bandwidth y
442    38 Unidirectional Available Bandwidth y
443    39 Unidirectional Utilized Bandwidth y
444    40 RTM Capability n
445
446]]></artwork>
447      <t>This document adds the following new sub-TLVs to the sub-TLVs for
448      TLVs 22, 23, 25, 141, 222, and 223 registry.</t>
449      <t>Value: 41 (suggested - to be assigned by IANA)</t>
450      <t>Name: L2 Bundle Member Adj-SID</t>
451      <t>This sub-TLV is allowed in the following TLVs:</t>
452      <artwork name="" type="" align="left" alt=""><![CDATA[ 22 23 25 141 222 223
453 n  n  y   n   n   n
454]]></artwork>
455      <t>Value: 42 (suggested to be assigned by IANA)</t>
456      <t>Name: L2 Bundle Member LAN Adj-SID</t>
457      <t>This sub-TLV is allowed in the following TLVs:</t>
458      <artwork name="" type="" align="left" alt=""><![CDATA[ 22 23 25 141 222 223
459 n  n  y   n   n   n
460]]></artwork>
461    </section>
462    <section anchor="Security" numbered="true" toc="default">
463      <name>Security Considerations</name>
464      <t>The IS-IS protocol has supported the advertisement of link attribute
465      information, including link identifiers, for many years. The
466      advertisements defined in this document are identical to existing
467      advertisements defined in [RFC4202], [RFC5305], [RFC7810], and [SR-ISIS]
468      - but are associated with L2 links which are part of a bundle interface
469      on which the IS-IS protocol operates. There are therefore no new
470      security issues introduced by the extensions in this document.</t>
471      <t>As always, if the protocol is used in an environment where
472      unauthorized access to the physical links on which IS-IS PDUs are sent
473      occurs then attacks are possible. The use of authentication as defined
474      in [RFC5304] and [RFC5310] is recommended to prevent such attacks.</t>
475    </section>
476    <section numbered="true" toc="default">
477      <name>Contributors</name>
478      <t>The following people gave a substantial contribution to the content
479      of this document and should be considered as co-authors:</t>
480      <artwork name="" type="" align="left" alt=""><![CDATA[Stefano Previdi
481Cisco Systems
482Via Del Serafico 200
483Rome  0144
484Italy
485
486Email: sprevidi@cisco.com]]></artwork>
487    </section>
488    <section anchor="Acknowledgements" numbered="true" toc="default">
489      <name>Acknowledgements</name>
490      <t>The authors would like to thank Jon Mitchell for his careful
491      review.</t>
492    </section>
493  </middle>
494  <back>
495    <references>
496      <name>References</name>
497      <references>
498        <name>Normative References</name>
499        <reference anchor="ISO10589">
500          <front>
501            <title>Intermediate system to Intermediate system intra-domain
502          routeing information exchange protocol for use in conjunction with
503          the protocol for providing the connectionless-mode Network Service
504          (ISO 8473)</title>
505            <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
506            <author>
507              <organization abbrev="ISO">International Organization for
508            Standardization</organization>
509            </author>
510            <date month="Nov" year="2002"/>
511          </front>
512        </reference>
513        <reference anchor="IEEE802.1AX">
514          <front>
515            <title>IEEE Standard for Local and Metropolitan Area Networks - Link
516          Aggregation.</title>
517            <author>
518              <organization abbrev="IEEE">Institute of Electrical and
519            Electronics Engineers</organization>
520            </author>
521            <date month="Nov" year="2008"/>
522          </front>
523        </reference>
524        <reference anchor="SR-ISIS">
525          <front>
526            <title>IS-IS Extensions for Segment Routing,
527          draft-ietf-isis-segment-routing-extensions-12(work in
528          progress)</title>
529            <author fullname="Previdi S., et al,"/>
530            <date month="April" year="2017"/>
531          </front>
532        </reference>
533        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
534          <front>
535            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
536            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
537            <seriesInfo name="RFC" value="2119"/>
538            <seriesInfo name="BCP" value="14"/>
539            <author initials="S." surname="Bradner" fullname="S. Bradner">
540              <organization/>
541            </author>
542            <date year="1997" month="March"/>
543            <abstract>
544              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
545            </abstract>
546          </front>
547        </reference>
548        <reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202">
549          <front>
550            <title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
551            <seriesInfo name="DOI" value="10.17487/RFC4202"/>
552            <seriesInfo name="RFC" value="4202"/>
553            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
554              <organization/>
555            </author>
556            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
557              <organization/>
558            </author>
559            <date year="2005" month="October"/>
560            <abstract>
561              <t>This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS).  This document enhances the routing extensions required to support MPLS Traffic Engineering (TE).  [STANDARDS-TRACK]</t>
562            </abstract>
563          </front>
564        </reference>
565        <reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5304">
566          <front>
567            <title>IS-IS Cryptographic Authentication</title>
568            <seriesInfo name="DOI" value="10.17487/RFC5304"/>
569            <seriesInfo name="RFC" value="5304"/>
570            <author initials="T." surname="Li" fullname="T. Li">
571              <organization/>
572            </author>
573            <author initials="R." surname="Atkinson" fullname="R. Atkinson">
574              <organization/>
575            </author>
576            <date year="2008" month="October"/>
577            <abstract>
578              <t>This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.  The base specification includes an authentication mechanism that allows for multiple authentication algorithms.  The base specification only specifies the algorithm for cleartext passwords.  This document replaces RFC 3567.</t>
579              <t>This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.  [STANDARDS-TRACK]</t>
580            </abstract>
581          </front>
582        </reference>
583        <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305">
584          <front>
585            <title>IS-IS Extensions for Traffic Engineering</title>
586            <seriesInfo name="DOI" value="10.17487/RFC5305"/>
587            <seriesInfo name="RFC" value="5305"/>
588            <author initials="T." surname="Li" fullname="T. Li">
589              <organization/>
590            </author>
591            <author initials="H." surname="Smit" fullname="H. Smit">
592              <organization/>
593            </author>
594            <date year="2008" month="October"/>
595            <abstract>
596              <t>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE).  This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP).  This information describes additional details regarding the state of the network that are useful for traffic engineering computations.  [STANDARDS-TRACK]</t>
597            </abstract>
598          </front>
599        </reference>
600        <reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5307">
601          <front>
602            <title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
603            <seriesInfo name="DOI" value="10.17487/RFC5307"/>
604            <seriesInfo name="RFC" value="5307"/>
605            <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
606              <organization/>
607            </author>
608            <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
609              <organization/>
610            </author>
611            <date year="2008" month="October"/>
612            <abstract>
613              <t>This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).  [STANDARDS-TRACK]</t>
614            </abstract>
615          </front>
616        </reference>
617        <reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5310">
618          <front>
619            <title>IS-IS Generic Cryptographic Authentication</title>
620            <seriesInfo name="DOI" value="10.17487/RFC5310"/>
621            <seriesInfo name="RFC" value="5310"/>
622            <author initials="M." surname="Bhatia" fullname="M. Bhatia">
623              <organization/>
624            </author>
625            <author initials="V." surname="Manral" fullname="V. Manral">
626              <organization/>
627            </author>
628            <author initials="T." surname="Li" fullname="T. Li">
629              <organization/>
630            </author>
631            <author initials="R." surname="Atkinson" fullname="R. Atkinson">
632              <organization/>
633            </author>
634            <author initials="R." surname="White" fullname="R. White">
635              <organization/>
636            </author>
637            <author initials="M." surname="Fanto" fullname="M. Fanto">
638              <organization/>
639            </author>
640            <date year="2009" month="February"/>
641            <abstract>
642              <t>This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.</t>
643              <t>Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future.  [STANDARDS-TRACK]</t>
644            </abstract>
645          </front>
646        </reference>
647        <reference anchor="RFC6119" target="https://www.rfc-editor.org/info/rfc6119">
648          <front>
649            <title>IPv6 Traffic Engineering in IS-IS</title>
650            <seriesInfo name="DOI" value="10.17487/RFC6119"/>
651            <seriesInfo name="RFC" value="6119"/>
652            <author initials="J." surname="Harrison" fullname="J. Harrison">
653              <organization/>
654            </author>
655            <author initials="J." surname="Berger" fullname="J. Berger">
656              <organization/>
657            </author>
658            <author initials="M." surname="Bartlett" fullname="M. Bartlett">
659              <organization/>
660            </author>
661            <date year="2011" month="February"/>
662            <abstract>
663              <t>This document specifies a method for exchanging IPv6 traffic  engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to  calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]</t>
664            </abstract>
665          </front>
666        </reference>
667        <reference anchor="RFC7810" target="https://www.rfc-editor.org/info/rfc7810">
668          <front>
669            <title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
670            <seriesInfo name="DOI" value="10.17487/RFC7810"/>
671            <seriesInfo name="RFC" value="7810"/>
672            <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
673              <organization/>
674            </author>
675            <author initials="S." surname="Giacalone" fullname="S. Giacalone">
676              <organization/>
677            </author>
678            <author initials="D." surname="Ward" fullname="D. Ward">
679              <organization/>
680            </author>
681            <author initials="J." surname="Drake" fullname="J. Drake">
682              <organization/>
683            </author>
684            <author initials="Q." surname="Wu" fullname="Q. Wu">
685              <organization/>
686            </author>
687            <date year="2016" month="May"/>
688            <abstract>
689              <t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t>
690              <t>This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion.  The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t>
691              <t>Note that this document only covers the mechanisms with which network-performance information is distributed.  The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t>
692            </abstract>
693          </front>
694        </reference>
695      </references>
696      <references>
697        <name>Informational References</name>
698        <reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655">
699          <front>
700            <title>A Path Computation Element (PCE)-Based Architecture</title>
701            <seriesInfo name="DOI" value="10.17487/RFC4655"/>
702            <seriesInfo name="RFC" value="4655"/>
703            <author initials="A." surname="Farrel" fullname="A. Farrel">
704              <organization/>
705            </author>
706            <author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur">
707              <organization/>
708            </author>
709            <author initials="J." surname="Ash" fullname="J. Ash">
710              <organization/>
711            </author>
712            <date year="2006" month="August"/>
713            <abstract>
714              <t>Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks.  Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t>
715              <t>This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.  This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.  This memo provides information for the Internet community.</t>
716            </abstract>
717          </front>
718        </reference>
719        <reference anchor="SR-ARCH">
720          <front>
721            <title>Segment Routing Architecture,
722          draft-ietf-spring-segment-routing-11(work in progress)</title>
723            <author fullname="Filsfils C., et al,"/>
724            <date month="February" year="2017"/>
725          </front>
726        </reference>
727      </references>
728    </references>
729    <section numbered="true" toc="default">
730      <name>Example Encoding</name>
731      <t/>
732      <t>Below is an example encoding of L2 Bundle advertisements in a case
733      where we have two parallel adjacencies to the same neighbor whose
734      system-id is 1234.1234.1234.00. The two L2 bundles have the following
735      sets of attributes:</t>
736      <artwork name="" type="" align="left" alt=""><![CDATA[L3 Adjacency #1
737L3 IPv4 local link address: 192.0.2.1
738Four bundle members with the following attributes:
739
740--------------------------------------------------
741Num | Link Local ID | Bandwidth | Adj-SID/Weight |
742--------------------------------------------------
7431   | 0x11111111    | 1G        | 0x11111/1      |
744--------------------------------------------------
7452   | 0x11112222    | 1G        | 0x11112/1      |
746--------------------------------------------------
7473   | 0x11113333    | 10G       | 0x11113/1      |
748--------------------------------------------------
7494   | 0x11114444    | 10G       | 0x11114/1      |
750--------------------------------------------------
751
752L3 Adjacency #2
753L3 IPv4 local link address: 192.0.2.2
754Three bundle members with the following attributes:
755
756--------------------------------------------------
757Num | Link Local ID | Bandwidth | Adj-SID/Weight |
758--------------------------------------------------
7591   | 0x22221111    | 10G       | 22221/1        |
760--------------------------------------------------
7612   | 0x22222222    | 10G       | 22222/1        |
762--------------------------------------------------
7633   | 0x22223333    | 10G       | 22223/1        |
764--------------------------------------------------
765]]></artwork>
766      <t>This requires two TLVs, one for each L3 adjacency.</t>
767      <t>TLV for Adjacency #1:</t>
768      <artwork name="" type="" align="left" alt=""><![CDATA[
769
770 0                   1
771 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
772+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
773|  Type(25)     |Len: 64        |
774+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
775
776Parent L3 Neighbor Descriptor
777 0                   1                   2                   3 
778 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 
779+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
780| Neighbor System-ID octets 1-4: 1234.1234                      |
781+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
782| System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
783+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
784
785IPv4 Interface Address sub-TLV
786 0                   1
787 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
788+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
789|  Type(6))     | Length(4)     |
790+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
791| IPv4 address:192.0.2.1                                          |
792+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
793
794L2 Bundle Attribute Descriptors
795 0                   1                   2                   3 
796 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 
797+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
798|Len:9+6+10 = 25| # Desc: 2     |
799+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
800| Link Local Identifier Bundle Member #1: 0x11111111            |
801+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
802| Link Local Identifier Bundle Member #2: 0x11112222            |
803+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
804
805
806Maximum Link Bandwidth sub-TLV
807 0                   1                   2                   3 
808 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 
809+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
810|  Type(9)       | Length(4)    |
811+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
812| Bandwidth Value: 1G/8                                         |
813+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
814
815L2 Bundle Member Adjacency Segment Identifier sub-TLV
816 0                   1                   2                   3 
817 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 
818+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
819|  Type(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
820+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
821| Local Label Bundle Member #1: 0x11111         |
822+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
823| Local Label Bundle Member #2: 0x11112         |
824+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
825
826L2 Bundle Attribute Descriptors
827 0                   1                   2                   3 
828 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 
829+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
830|Len:9+6+10 = 25| # Desc: 2     |
831+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
832| Link Local Identifier Bundle Member #3: 0x11113333            |
833+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
834| Link Local Identifier Bundle Member #4: 0x11114444            |
835+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
836
837
838Maximum Link Bandwidth sub-TLV
839 0                   1                   2                   3 
840 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 
841+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
842|  Type(9)       | Length(4)    |
843+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
844| Bandwidth Value: 10G/8                                        |
845+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
846
847L2 Bundle Member Adjacency Segment Identifier sub-TLV
848 0                   1                   2                   3 
849 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 
850+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
851|  Type(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
852+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
853| Local Label Bundle Member #3: 0x11113         |
854+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
855| Local Label Bundle Member #4: 0x11114         |
856+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
857
858
859
860]]></artwork>
861      <t>TLV for Adjacency #2</t>
862      <artwork name="" type="" align="left" alt=""><![CDATA[
8630                   1
864 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
865+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
866|  Type(25)     | Len: 46       |
867+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
868
869Parent L3 Neighbor Descriptor
870 0                   1                   2                   3 
871 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 
872+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
873| Neighbor System-ID octets 1-4: 1234.1234                      |
874+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
875| System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
876+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
877
878IPv4 Interface Address sub-TLV
879 0                   1
880 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
881+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
882|  Type(6))     | Length(4)     |
883+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
884| IPv4 address: 192.0.2.2                                         |
885+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
886
887L2 Bundle Attribute Descriptors
888 0                   1                   2                   3 
889 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 
890+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
891|Len:13+6+13=32 | # Desc: 3     |
892+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
893| Link Local Identifier Bundle Member #1: 0x22221111            |
894+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
895| Link Local Identifier Bundle Member #2: 0x22222222            |
896+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
897| Link Local Identifier Bundle Member #3: 0x22223333            |
898+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
899
900
901Maximum Link Bandwidth sub-TLV
902 0                   1                   2                   3 
903 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 
904+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
905|  Type(9)       | Length(4)    |
906+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
907| Bandwidth Value: 10G/8                                        |
908+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
909
910L2 Bundle Member Adjacency Segment Identifier sub-TLV
911 0                   1                   2                   3 
912 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 
913+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
914|  Type(41)     | Length(11)    |0|0|1|1|0|0|0|0| Weight: 1     |
915+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
916| Local Label Bundle Member #1: 0x22221         |
917+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
918| Local Label Bundle Member #2: 0x22222         |
919+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
920| Local Label Bundle Member #3: 0x22223         |
921+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
922]]></artwork>
923    </section>
924  </back>
925</rfc>
  • <?xml version="1.0" encoding="utf-8"?>
  • <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
  • <rfc category="std" docName="draft-ietf-isis-l2bundles-07.txt" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" consensus="true" number="9999">
    • <-- xml2rfc v2v3 conversion 2.23.0 -->
    • <front>
      • <title abbrev="isis-l2bundles" "isis l2bundles" >
        • Advertising L2 Bundle Member Link Attributes in IS-IS
        • </title>
      • <seriesInfo name="Internet-Draft" "RFC" value="draft-ietf-isis-l2bundles-07.txt" "9999" />
      • <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
        • <organization>
          • Cisco Systems
          • </organization>
        • <address>
          • <postal>
            • <street>
              • 510 McCarthy Blvd.
              • </street>
            • <city>
              • Milpitas
              • </city>
            • <code>
              • 95035
              • </code>
            • <region>
              • CA
              • </region>
            • <country>
              • USA
              • </country>
            • </postal>
          • <email>
            • ginsberg@cisco.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Ahmed Bashandy" initials="A" surname="Bashandy">
        • <organization>
          • Cisco Systems
          • </organization>
        • <address>
          • <postal>
            • <street>
              • 170 West Tasman Drive
              • </street>
            • <city>
              • San Jose
              • </city>
            • <code>
              • 95134
              • </code>
            • <region>
              • Ca
              • </region>
            • <country>
              • US
              • </country>
            • </postal>
          • </address>
        • </author>
      • <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
        • <organization>
          • Cisco Systems
          • </organization>
        • <address>
          • <postal>
            • <street/>
            • <city/>
            • <code/>
            • <region/>
            • <country/>
            • </postal>
          • <email>
            • cf@cisco.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Mohan Nanduri" initials="M" surname="Nanduri">
        • <organization>
          • eBay
          • </organization>
        • <address>
          • <postal>
            • <street/>
            • <city/>
            • <code/>
            • <country/>
            • </postal>
          • <email>
            • mnanduri@ebay.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Ebben Aries" initials="E" surname="Aries">
        • <organization>
          • Private Contributer
          • </organization>
        • <address>
          • <postal>
            • <street/>
            • <city/>
            • <code/>
            • <country/>
            • </postal>
          • <email>
            • exa@dscp.org
            • </email>
          • </address>
        • </author>
      • <date day="25" month="May" "July" year="2017" "2019" />
      • <area>
        • Routing Area
        • </area>
      • <workgroup>
        • Networking Working Group
        • </workgroup>
      • <keyword>
        • Sample
        • </keyword>
      • <abstract>
        • <t>
          • There are deployments where the Layer 3 interface on which IS-IS operates is a Layer 2 interface bundle. Existing IS-IS advertisements only support advertising link attributes of the Layer 3 interface. If entities external to IS-IS wish to control traffic flows on the individual physical links which comprise the Layer 2 interface bundle link attribute information about the bundle members is required.
          • </t>
        • <t>
          • This document introduces the ability for IS-IS to advertise the link attributes of layer 2 (L2) bundle members.
          • </t>
        • </abstract>
      • <note>
        • <name>
          • Requirements Language
          • </name>
        • <t>
          • The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">REQUIRED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">RECOMMENDED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">NOT RECOMMENDED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14>", and "OPTIONAL" "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC2119"/> <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8174"/> when, and only when, they appear in RFC 2119 [RFC2119]. all capitals, as shown here.
          • </t>
        • </note>
      • </front>
    • <middle>
      • <section numbered="true" toc="default">
        • <name>
          • Introduction
          • </name>
        • <t>
          • There are deployments where the Layer 3 interface on which an IS-IS adjacency is established is a Layer 2 interface bundle, for instance a Link Aggregation Group (LAG) [IEEE802.1AX]. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="IEEE802.1AX"/>. This reduces the number of adjacencies which need to be maintained by the routing protocol in cases where there are parallel links between the neighbors. Entities external to IS-IS such as Path Computation Elements (PCE) [RFC4655] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4655"/> may wish to control traffic flows on individual members of the underlying Layer 2 bundle. In order to do so link attribute information about individual bundle members is required. The protocol extensions defined in this document provide the means to advertise this information.
          • </t>
        • <t>
          • This document introduces a new TLV to advertise link attribute information for each of the L2 bundle members which comprise the Layer 3 interface on which IS-IS operates.
          • </t>
        • <t>
          • [SR-ISIS] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/> introduces a new link attribute - adjacency segment identifier (Adj-SID) - which can be used as an instruction to forwarding to send traffic over a specific link. This document introduces additional sub-TLVs to advertise Adj-SIDs for L2 Bundle members.
          • </t>
        • <t>
          • Note that the new advertisements defined in this document are intended to be provided to external (to IS-IS) entities. The following items are intentionally not defined and/or are outside the scope of this document:
          • </t>
        • <ul spacing="normal">
          • <li>
            • What link attributes will be advertised. This is determined by the needs of the external entities.
            • </li>
          • <li>
            • A minimum or default set of link attributes.
            • </li>
          • <li>
            • How these attributes are configured
            • </li>
          • <li>
            • How the advertisements are used
            • </li>
          • <li>
            • What impact the use of these advertisements may have on traffic flow in the network
            • </li>
          • <li>
            • How the advertisements are passed to external entities
            • </li>
          • </ul>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • L2 Bundle Member Attributes TLV
          • </name>
        • <t>
          • A new TLV is introduced to advertise L2 Bundle member attributes. Although much of the information is identical to and uses the same sub-TLVs included in Extended IS-Neighbor advertisements (TLVs 22 and 222), a new TLV is used so that changes to the advertisement of the L2 Bundle member link attributes does not trigger unnecessary action by the [ISO10589] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="ISO10589"/> Decision process.
          • </t>
        • <t>
          • Advertisement of this information implies that the identified link is a member of the L2 Bundle associated with the identified Parent L3 Neighbor and that the member link is operationally up. Therefore advertisements MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be withdrawn if the link becomes operationally down or it is no longer a member of the identified L2 Bundle.
          • </t>
        • <t>
          • This new TLV utilizes the sub-TLV space defined for TLVs 22, 23, 141, 222, and 223.
          • </t>
        • <t>
          • The following new TLV is introduced:
          • </t>
        • <ul empty="true" spacing="normal">
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">L2 Bundle Member Attributes</t><ul xmlns:xi="http://www.w3.org/2001/XInclude" empty="true"><li>Type: 25 (suggested - to be assigned by IANA)</li><li>Length: Number of octets to follow</li></ul>
            • </li>
          • </ul>
        • <ul empty="true">
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">Parent L3 Neighbor Descriptor</t><ul xmlns:xi="http://www.w3.org/2001/XInclude" empty="true"><li>L3 Neighbor System ID + pseudonode ID (7 octets)</li><li><t>Flags: 1 octet field of following flags:</t><artwork name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| | +-+-+-+-+-+-+-+-+ ]]></artwork><t>where:</t><dl><dt>P-flag:</dt><dd>When set to 1 one of the sub-TLVs described in Section 2.1 immediately follows the flags field. If the P-flag is set to 0, then none of the sub-TLVs described in Section 2.1 are present.</dd><dt>Other bits:</dt><dd><bcp14>MUST</bcp14></dd></dl></li></ul>
            • </li>
          • </ul>
        • <artwork name="" type="" align="left" alt="">
          • <ul empty="true">
            • <li>
              •     L2 Bundle Member Attributes
                    Type: 25 (suggested - to be assigned by IANA)
                    Length: Number of octets to follow

                    Parent L3 Neighbor Descriptor
                     L3 Neighbor System ID + pseudonode ID (7 octets)
                     Flags: 1 octet field of following flags:

                          0 1 2 3 4 5 6 7
                         +-+-+-+-+-+-+-+-+
                         |P|             |
                         +-+-+-+-+-+-+-+-+

                        where:

                        P-flag: When set to 1 one of the sub-TLVs described
                        in Section 2.1 immediately follows the flags field.
                        If the P-flag is set to 0, then none of the sub-TLVs
                        described in Section 2.1 are present.

                        Other bits: MUST be zero when originated and ignored when
                         received.

                   One or more of the following:
                    L2 Bundle Attribute Descriptors
                      Length of L2 Bundle Attribute Descriptor (1 octet)
                        NOTE: This includes all fields described below.

                      Number of L2 Bundle Member Descriptors (1 octet)
                      L2 Bundle Member Link Local Identifiers
                        (4 * Number of L2 Bundle Member Descriptors octets)
                 
                        NOTE: An L2 Bundle Member Descriptor is a Link Local
                        Identifier as defined in [RFC4202].

                      sub-TLV(s)
                      
                      A sub-TLV may define an attribute common to all of
                      the bundle members listed or a sub-TLV may define an
                      attribute unique to each bundle member. Use of these 
                      two classes of sub-TLVs is described in the following
                      
                sections.*<t xmlns:xi="http://www.w3.org/2001/XInclude">One or more of the following:</t><ul xmlns:xi="http://www.w3.org/2001/XInclude" empty="true"><li><t>L2 Bundle Attribute Descriptors</t><ul empty="true"><li><t>Length of L2 Bundle Attribute Descriptor (1 octet)</t><ul empty="true"><li>NOTE: This includes all fields described below.</li></ul><t>Number of L2 Bundle Member Descriptors (1 octet)</t><t>L2 Bundle Member Link Local Identifiers</t><ul empty="true"><li>(4 * Number of L2 Bundle Member Descriptors octets)</li><li>NOTE: An L2 Bundle Member Descriptor is a Link Local Identifier as defined in <xref target="RFC4202"/></li></ul><t>sub-TLV(s)</t><t>A sub-TLV may define an attribute common to all of the bundle members listed or a sub-TLV may define an attribute unique to each bundle member. Use of these two classes of sub-TLVs is described in the following sections.</t></li></ul></li></ul>

              • </li>
            • </ul>
          • </artwork>
        • <t>
          • NOTE: Only one Parent L3 Neighbor Descriptor is present in a given TLV. Multiple L2 Bundle Attribute Descriptors may be present in a single TLV.
          • </t>
        • <section numbered="true" toc="default">
          • <name>
            • Parallel L3 Adjacencies
            • </name>
          • <t>
            • When there exist multiple L3 adjacencies to the same neighbor additional information is required to uniquely identify the L3 Neighbor. One and only one of the following three sub-TLVs is used to uniquely identify the L3 adjacency:
            • </t>
          • <ul spacing="normal">
            • <li>
              • IPv4 Interface Address (sub-TLV 6 defined in [RFC5305]) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5305"/>)
              • </li>
            • <li>
              • IPv6 Interface Address (sub-TLV 12 defined in [RFC6119]) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6119"/>)
              • </li>
            • <li>
              • Link Local/Remote Identifiers (sub-TLV 4 defined in [RFC5307]) <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5307"/>)
              • </li>
            • </ul>
          • <t>
            • When the P-bit is set in the flags field in the Parent L3 Neighbor Descriptor one and only one of the above sub-TLVs MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be present. The chosen sub-TLV MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> immediately follow the flags field described in Section 2.
            • </t>
          • <t>
            • These sub-TLVs MAY <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> be omitted if no parallel adjacencies to the neighbor exist.
            • </t>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • Shared Attribute sub-TLVs
            • </name>
          • <t>
            • These sub-TLVs advertise a single copy of an attribute (e.g. link bandwidth). The attribute applies to all of the L2 Bundle Members in the set advertised under the preceding  L2 Bundle Member Attribute Descriptor. No more than one copy of a given sub-TLV in this category may appear in the set of sub-TLVs under the preceding L2 Bundle Member Attribute Descriptor. If multiple copies of a given sub-TLV are present all copies MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be ignored.
            • </t>
          • <t>
            • The set of L2 Bundle Member Descriptors which may be advertised under a single L2 Bundle Member Attribute Descriptor is therefore limited to bundle members which share the set of attributes advertised in the shared attribute sub-TLVs.
            • </t>
          • <t>
            • All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry are in the category of shared attribute sub-TLVs unless otherwise specified in this document.
            • </t>
          • </section>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Advertising L2 Bundle Member Adj-SIDs
          • </name>
        • <t>
          • [SR-ISIS] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/> defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies. However these sub-TLVs only support a advertisement of a single Adj-SID. As it is expected that each L2 Bundle member will have unique Adj-SIDs in many deployments it is desirable to define a new sub-TLV which allows more efficient encoding of a set of Adj-SIDs in a single sub-TLV. Two new sub-TLVs are therefore introduced to support advertising Adj-SIDs for L2 Bundle members. The format of the new sub-TLVs is similar to that used for L3 adjacencies, but is optimized to allow advertisement of a set of Adj-SIDs (one per L2 Bundle Member) in a single sub-TLV.
          • </t>
        • <t>
          • The two new sub-TLVs defined in the following sections do not fall into the category of shared attribute sub-TLVs.
          • </t>
        • <section numbered="true" toc="default">
          • <name>
            • L2 Bundle Member Adjacency Segment Identifier sub-TLV
            • </name>
          • <t>
            • This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members associated with a parent L3 adjacency which is Point-to-Point. The following format is defined for this sub-TLV:
            • </t>
          • <ul empty="true" spacing="normal">
            • <li>
              • <t xmlns:xi="http://www.w3.org/2001/XInclude">Type: 41 (suggested value to be assigned by IANA) (1 octet)</t>
              • </li>
            • <li>
              • <t xmlns:xi="http://www.w3.org/2001/XInclude">Length: variable (1 octet)</t>
              • </li>
            • <li>
              • <t xmlns:xi="http://www.w3.org/2001/XInclude">Flags: 1 octet field of following flags:</t><artwork xmlns:xi="http://www.w3.org/2001/XInclude" name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|*|V|L|S|P| | +-+-+-+-+-+-+-+-+ ]]></artwork>
              • </li>
            • </ul>
          • <-- SG: Moved <aside> up because it can't be used within a list item. -->
          • <aside>
            • <t>
              • NOTE: The flags are deliberately kept congruent to the flags in the L3 ADJ-SID defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/>. * indicates a flag used in the L3 Adj-SID sub-TLV but which is NOT used in this sub-TLV. These bits <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14> be sent as 0 and <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be ignored on receipt.
              • </t>
            • </aside>
          • <artwork name="" type="" align="left" alt="">
            • <ul empty="true" spacing="normal">
              • <li>
                •      Type: 41 (suggested value to be assigned by IANA) (1 octet)
                       Length: variable (1 octet)

                    
                       Flags: 1 octet field of following flags:

                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |F|*|V|L|S|P|   |
                           +-+-+-+-+-+-+-+-+

                          where:

                           NOTE: The flags are deliberately kept congruent to the flags 
                           in the L3 ADJ-SID defined in [SR-ISIS].
                           * indicates a flag used in the L3 Adj-SID sub-TLV but which is
                           NOT used in this sub-TLV. These bits SHOULD be sent as 0 and 
                           MUST be ignored on receipt.

                           F-Flag: Address-Family flag.  If unset, then the Adj-SID refers
                           to an L2 Bundle Member with outgoing IPv4 encapsulation. If set
                           then the Adj-SID refers to an L2 Bundle Member with outgoing
                           IPv6 encapsulation.

                           V-Flag: Value flag.  If set, then the Adj-SID carries a value.
                           By default the flag is SET.

                           L-Flag: Local Flag.  If set, then the value/index carried by
                           the Adj-SID has local significance.  By default the flag is
                           SET.

                           S-Flag.  Set Flag.  When set, the S-Flag indicates that the
                           Adj-SID refers to a set of L2 Bundle Members (and therefore
                           MAY be assigned to other L2 Bundle Members as well).

                           P-Flag.  Persistent flag.  When set, the P-Flag indicates that
                           the Adj-SID is persistently allocated, i.e., the Adj-SID value
                           remains consistent across router restart and/or interface flap.

                           Other bits: MUST be zero when originated and ignored when
                           received.

                      Weight: 1 octet.  The value represents the weight of the Adj-SID
                          for the purpose of load balancing.  The use of the weight is
                          defined in [SR-ARCH].

                      NOTE: Flags and weight are shared by all L2 Bundle Members
                      listed in the L2 Bundle Attribute Descriptor.

                      L2 Bundle Member Adj-SID Descriptors. There MUST be one descriptor
                       for each of the L2 Bundle Members advertised under the preceding
                       L2 Bundle Member Attribute Descriptor. Each descriptor consists 
                       of one of the following fields:

                        SID/Index/Label: according to the V and L flags, it contains
                          either:

                          *  A 3 octet local label where the 20 rightmost bits are used
                             for encoding the label value.  In this case the V and L 
                             flags MUST be set.

                          *  A 4 octet index defining the offset in the SID/Label space
                             advertised by this router. See [SR-ISIS].
                             In this case V and L flags MUST be 
                  unset.*<t xmlns:xi="http://www.w3.org/2001/XInclude">where:</t><dl xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><dt>F-Flag:</dt><dd>Address-Family flag. If unset, then the Adj-SID refers to an L2 Bundle Member with outgoing IPv4 encapsulation. If set then the Adj-SID refers to an L2 Bundle Member with outgoing IPv6 encapsulation.</dd><dt>V-Flag:</dt><dd>Value flag. If set, then the Adj-SID carries a value. By default the flag is SET.</dd><dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET.</dd><dt>S-Flag.</dt><dd>Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of L2 Bundle Members (and therefore <bcp14>MAY</bcp14></dd><dt>P-Flag.</dt><dd>Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap.</dd><dt>Other bits:</dt><dd><bcp14>MUST</bcp14></dd></dl>


                • </li>
              • </ul>
            • <dl>
              • <dt>
                • Weight:
                • </dt>
              • <dd>
                • 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8402"/>.
                • </dd>
              • </dl>
            • <aside>
              • <t>
                • NOTE: Flags and weight are shared by all L2 Bundle Members listed in the L2 Bundle Attribute Descriptor.
                • </t>
              • </aside>
            • <dl>
              • <dt>
                • L2 Bundle Member Adj-SID Descriptors.
                • </dt>
              • <dd>
                • <t>
                  • There <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be one descriptor for each of the L2 Bundle Members advertised under the preceding L2 Bundle Member Attribute Descriptor. Each descriptor consists of one of the following fields:
                  • </t>
                • <dl>
                  • <dt>
                    • SID/Index/Label:
                    • </dt>
                  • <dd>
                    • <t>
                      • according to the V and L flags, it contains either:
                      • </t>
                    • <ul empty="true" spacing="normal">
                      • <li>
                        • A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be set.
                        • </li>
                      • <li>
                        • A 4 octet index defining the offset in the SID/Label space advertised by this router. See <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/>. In this case V and L flags <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be unset.
                        • </li>
                      • </ul>
                    • </dd>
                  • </dl>
                • </dd>
              • </dl>
            • </artwork>
          • </section>
        • <section numbered="true" toc="default">
          • <name>
            • L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV
            • </name>
          • <t>
            • This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members associated with a parent L3 adjacency which is a LAN adjacency. In LAN subnetworks, the Designated Intermediate System (DIS) is elected and originates the Pseudonode-LSP (PN-LSP) including all neighbors of the DIS. When Segment Routing is used, each router in the LAN MAY <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> advertise the Adj-SID of each of its neighbors on the LAN. Similarly, for each L2 Bundle Member a router MAY <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> advertise an Adj-SID to each neighbor on the LAN.
            • </t>
          • <t>
            • The following format is defined for this sub-TLV:
            • </t>
          • <t>
            • Type: 42 (suggested value to be assigned by IANA) (1 octet)
            • </t>
          • <t>
            • Length: variable (1 octet)
            • </t>
          • <t>
            • Neighbor System ID: 6 octets
            • </t>
          • <ul empty="true" spacing="normal">
            • <li>
              • <t xmlns:xi="http://www.w3.org/2001/XInclude">Flags: 1 octet field of following flags:</t><artwork xmlns:xi="http://www.w3.org/2001/XInclude" name="" type="" align="left" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F|*|V|L|S|P| | +-+-+-+-+-+-+-+-+ ]]></artwork>
              • </li>
            • </ul>
          • <aside>
            • <t>
              • NOTE: The flags are deliberately kept congruent to the flags in the L3 LAN_ADJ-SID defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/>. * indicates a flag used in the L3 Adj-SID sub-TLV but which is NOT used in this sub-TLV. These bits <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14> be sent as 0 and <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be ignored on receipt.
              • </t>
            • </aside>
          • <artwork name="" type="" align="left" alt="">
            • <ul empty="true" spacing="normal">
              • <li>
                • <t xmlns:xi="http://www.w3.org/2001/XInclude">where:</t><dl xmlns:xi="http://www.w3.org/2001/XInclude"><dt>F-Flag:</dt><dd>Address-Family flag. If unset, then the Adj-SID refers to an L2 Bundle Member with outgoing IPv4 encapsulation. If set then the Adj-SID refers to an L2 Bundle Member with outgoing IPv6 encapsulation.</dd><dt>V-Flag:</dt><dd>Value flag. If set, then the Adj-SID carries a value. By default the flag is SET.</dd><dt>L-Flag:</dt><dd>Local Flag. If set, then the value/index carried by the Adj-SID has local significance. By default the flag is SET.</dd><dt>S-Flag.</dt><dd>Set Flag. When set, the S-Flag indicates that the Adj-SID refers to a set of L2 Bundle Members (and therefore <bcp14>MAY</bcp14></dd><dt>P-Flag.</dt><dd>Persistent flag. When set, the P-Flag indicates that the Adj-SID is persistently allocated, i.e., the Adj-SID value remains consistent across router restart and/or interface flap.</dd><dt>Other bits:</dt><dd><bcp14>MUST</bcp14></dd></dl>      Type: 42 (suggested value to be assigned by IANA) (1 octet)
                       Length: variable (1 octet)
                       Neighbor System ID: 6 octets

                   
                       Flags: 1 octet field of following flags:

                            0 1 2 3 4 5 6 7
                           +-+-+-+-+-+-+-+-+
                           |F|*|V|L|S|P|   |
                           +-+-+-+-+-+-+-+-+

                          where:

                           NOTE: The flags are deliberately kept congruent to the flags 
                           in the L3 LAN_ADJ-SID defined in [SR-ISIS].
                           * indicates a flag used in the L3 Adj-SID sub-TLV but which is
                           NOT used in this sub-TLV. These bits SHOULD be sent as 0 and 
                           MUST be ignored on receipt.

                           F-Flag: Address-Family flag.  If unset, then the Adj-SID refers
                           to an L2 Bundle Member with outgoing IPv4 encapsulation. If set
                           then the Adj-SID refers to an L2 Bundle Member with outgoing
                           IPv6 encapsulation.

                           V-Flag: Value flag.  If set, then the Adj-SID carries a value.
                           By default the flag is SET.

                           L-Flag: Local Flag.  If set, then the value/index carried by
                           the Adj-SID has local significance.  By default the flag is
                           SET.

                           S-Flag.  Set Flag.  When set, the S-Flag indicates that the
                           Adj-SID refers to a set of L2 Bundle Members (and therefore
                           MAY be assigned to other L2 Bundle Members as well).

                           P-Flag.  Persistent flag.  When set, the P-Flag indicates that
                           the Adj-SID is persistently allocated, i.e., the Adj-SID value
                           remains consistent across router restart and/or interface flap.

                           Other bits: MUST be zero when originated and ignored when
                           received.

                      Weight: 1 octet.  The value represents the weight of the Adj-SID
                      for the purpose of load balancing.  The use of the weight is
                      defined in [SR-ARCH].

                      NOTE: Flags and weight are shared by all L2 Bundle Members
                      listed in the L2 Bundle Attribute Descriptor.

                      L2 Bundle Member LAN Adj-SID Descriptors. There MUST be one
                      descriptor for each of the L2 Bundle Members advertised 
                      under the preceding L2 Bundle Member Attribute Descriptor.
                      Each descriptor consists of one of the following fields:

                        SID/Index/Label: according to the V and L flags, it contains
                          either:

                          *  A 3 octet local label where the 20 rightmost bits are used
                             for encoding the label value.  In this case the V and L 
                             flags MUST be set.

                          *  A 4 octet index defining the offset in the SID/Label space
                             advertised by this router. See [SR-ISIS].
                             In this case V and L flags MUST be unset.
                   

                • </li>
              • </ul>
            • <dl>
              • <dt>
                • Weight:
                • </dt>
              • <dd>
                • 1 octet. The value represents the weight of the Adj-SID for the purpose of load balancing. The use of the weight is defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8402"/>.
                • </dd>
              • </dl>
            • <aside>
              • <t>
                • NOTE: Flags and weight are shared by all L2 Bundle Members listed in the L2 Bundle Attribute Descriptor.
                • </t>
              • </aside>
            • <dl>
              • <dt>
                • L2 Bundle Member LAN Adj-SID Descriptors.
                • </dt>
              • <dd>
                • <t>
                  • There <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be one descriptor for each of the L2 Bundle Members advertised under the preceding L2 Bundle Member Attribute Descriptor. Each descriptor consists of one of the following fields:
                  • </t>
                • <dl>
                  • <dt>
                    • SID/Index/Label:
                    • </dt>
                  • <dd>
                    • <t>
                      • according to the V and L flags, it contains either:
                      • </t>
                    • <ul>
                      • <li>
                        • A 3 octet local label where the 20 rightmost bits are used for encoding the label value. In this case the V and L flags <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be set.
                        • </li>
                      • <li>
                        • A 4 octet index defining the offset in the SID/Label space advertised by this router. See <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/>. In this case V and L flags <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be unset.
                        • </li>
                      • </ul>
                    • </dd>
                  • </dl>
                • </dd>
              • </dl>
            • </artwork>
          • </section>
        • </section>
      • <section anchor="IANA" numbered="true" toc="default">
        • <name>
          • IANA Considerations
          • </name>
        • <t>
          • This document adds the following new TLV to the IS-IS TLV Codepoints registry.
          • </t>
        • <ul empty="true">
          • <tli>
            • Value: <t xmlns:xi="http://www.w3.org/2001/XInclude">Value: 25 (suggested - to be assigned by IANA) IANA)</t>
            • </t>
          • <tli>
            • Name: <t xmlns:xi="http://www.w3.org/2001/XInclude">Name: L2 Bundle Member Attributes Attributes</t>
            • </t>
          • </ul>
        • <t>
          • The name of the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry needs to be changed to Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 registry. An additional column needs to be added to the registry to indicate which sub-TLVs may appear in the new L2 Bundle Member Attributes TLV. The column for TLV 25 has one of the following three values:
          • </t>
        • <artwork name="" type="" align="left" alt="">
          • <dl>
            • <dt>
              • y:
              • </dt>
            • <dd>
              • sub-TLV may appear in TLV 25 but <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> NOT be shared by multiple L2 Bundle Members
              • </dd>
            • <dt>
              • y(s):
              • </dt>
            • <dd>
              • y - sub-TLV may appear in TLV 25 but MUST NOT be shared by multiple 
                    L2 Bundle Members
                y(s) - sub-TLV may appear in TLV 25 and MAY be shared by multiple 
                    L2 Bundle Members
                n - 
                sub-TLV MUST NOT appear in TLV 25 may appear in TLV 25 and <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> be shared by multiple L2 Bundle Members
              • </dd>
            • <dt>
              • n:
              • </dt>
            • <dd>
              • sub-TLV <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> NOT appear in TLV 25
              • </dd>
            • </dl>
          • </artwork>
        • <t>
          • The following table indicates the appropriate settings for all currently defined sub-TLVs as regards their use in the new L2 Bundle Member Attributes TLV.
          • </t>
        • <artwork name="" type="" align="left" alt="">
          • <table anchor="iana-table">
            • <name>
              • Appropriate Settings for All Defined Sub-TLVs as regards their use in the new L2 Bundle Member Attributes TLV
              • </name>
            • <thead>
              • <tr>
                • <th>
                  • Type
                  • </th>
                • <th>
                  • Description
                  • </th>
                • <th>
                  • 25
                  • </th>
                • </tr>
              • </thead>
            • <tbody>
              • <tr>
                • <td>
                  • 3
                  • </td>
                • <td>
                  • Administrative group (color)
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 4
                  • </td>
                • <td>
                  • Link Local/Remote Identifiers
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 6
                  • </td>
                • <td>
                  • IPv4 interface address
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 8
                  • </td>
                • <td>
                  • IPv4 neighbor address
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 9
                  • </td>
                • <td>
                  • Maximum link bandwidth
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 10
                  • </td>
                • <td>
                  • Maximum reservable link bandwidth
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 11
                  • </td>
                • <td>
                  • Unreserved bandwidth
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 12
                  • </td>
                • <td>
                  • IPv6 Interface Address
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 13
                  • </td>
                • <td>
                  • IPv6 Neighbor Address
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 14
                  • </td>
                • <td>
                  • Extended Administrative Group
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 18
                  • </td>
                • <td>
                  • TE Default metric
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 19
                  • </td>
                • <td>
                  • Link-attributes
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 20
                  • </td>
                • <td>
                  • Link Protection Type
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 21
                  • </td>
                • <td>
                  • Interface Switching Capability Descriptor
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 22
                  • </td>
                • <td>
                  • Bandwidth Constraints
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 23
                  • </td>
                • <td>
                  • Unconstrained TE LSP Count
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 24
                  • </td>
                • <td>
                  • Remote AS number
                  • </td>
                • <td>
                  • n
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 25
                  • </td>
                • <td>
                  • IPv4 remote ASBR Identifier
                  • </td>
                • <td>
                  • n
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 26
                  • </td>
                • <td>
                  • IPv6 remote ASBR Identifier
                  • </td>
                • <td>
                  • n
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 27
                  • </td>
                • <td>
                  • Interface Adjustment Capability Descriptor (IACD)
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 28
                  • </td>
                • <td>
                  • MTU n
                  • </td>
                • <td>
                  • n
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 29
                  • </td>
                • <td>
                  • SPB-Metric
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 30
                  • </td>
                • <td>
                  • SPB-A-OALG
                  • </td>
                • <td>
                  • y(s)
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 33
                  • </td>
                • <td>
                  • Unidirectional Link Delay
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 34
                  • </td>
                • <td>
                  • Min/Max Unidirectional Link Delay
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 35
                  • </td>
                • <td>
                  • Unidirectional Delay Variation
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 36
                  • </td>
                • <td>
                  • Unidirectional Link Loss
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 37
                  • </td>
                • <td>
                  • Unidirectional Residual Bandwidth
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 38
                  • </td>
                • <td>
                  • Unidirectional Available Bandwidth
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 39
                  • </td>
                • <td>
                  • Unidirectional Utilized Bandwidth
                  • </td>
                • <td>
                  • y
                  • </td>
                • </tr>
              • <tr>
                • <td>
                  • 40
                  • </td>
                • <td>
                  • RTM Capability
                  • </td>
                • <td>
                  •     3 Administrative group (color) y(s)
                        4 Link Local/Remote Identifiers y(s)
                        6 IPv4 interface address y(s)
                        8 IPv4 neighbor address y(s)
                        9 Maximum link bandwidth y(s)
                        10 Maximum reservable link bandwidth y(s)
                        11 Unreserved bandwidth y(s)
                        12 IPv6 Interface Address y(s)
                        13 IPv6 Neighbor Address y(s)
                        14 Extended Administrative Group y(s)
                        18 TE Default metric y(s)
                        19 Link-attributes y(s)
                        20 Link Protection Type y(s)
                        21 Interface Switching Capability Descriptor y(s)
                        22 Bandwidth Constraints y(s)
                        23 Unconstrained TE LSP Count y(s)
                        24 Remote AS number n
                        25 IPv4 remote ASBR Identifier n
                        26 IPv6 remote ASBR Identifier n
                        27 Interface Adjustment Capability Descriptor (IACD) y(s)
                        28 MTU n
                        29 SPB-Metric y(s)
                        30 SPB-A-OALG y(s)
                        33 Unidirectional Link Delay y
                        34 Min/Max Unidirectional Link Delay y
                        35 Unidirectional Delay Variation y
                        36 Unidirectional Link Loss y
                        37 Unidirectional Residual Bandwidth y
                        38 Unidirectional Available Bandwidth y
                        39 Unidirectional Utilized Bandwidth y
                        40 RTM Capability 
                    n

                  • </td>
                • </tr>
              • </tbody>
            • </table>
          • </artwork>
        • <t>
          • This document adds the following new sub-TLVs to the sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 registry.
          • </t>
        • <ul empty="true">
          • <tli>
            • Value: <t xmlns:xi="http://www.w3.org/2001/XInclude">Value: 41 (suggested - to be assigned by IANA) IANA)</t>
            • </t>
          • <tli>
            • Name: <t xmlns:xi="http://www.w3.org/2001/XInclude">Name: L2 Bundle Member Adj-SID Adj-SID</t>
            • </t>
          • <tli>
            • This <t xmlns:xi="http://www.w3.org/2001/XInclude">This sub-TLV is allowed in the following TLVs: TLVs:</t>
            • </t>
          • </ul>
        • <artwork name="" type="" align="left" alt="">
          • <table anchor="table2">
            • <thead>
              • <tr>
                • <th>
                  • 22
                  • </th>
                • <th>
                  • 23
                  • </th>
                • <th>
                  • 25
                  • </th>
                • <th>
                  • 141
                  • </th>
                • <th>
                  • 222
                  • </th>
                • <th>
                  •  22 23 25 141 222  223
                     n  n  y   n   n   n
                  • </th>
                • </tr>
              • </thead>
            • <tbody>
              • <tr>
                • <td>
                  • n
                  • </td>
                • <td>
                  • n
                  • </td>
                • <td>
                  • y
                  • </td>
                • <td>
                  • n
                  • </td>
                • <td>
                  • n
                  • </td>
                • <td>
                  • n
                  • </td>
                • </tr>
              • </tbody>
            • </table>
          • </artwork>
        • <tli>
          • Value: <t xmlns:xi="http://www.w3.org/2001/XInclude">Value: 42 (suggested to be assigned by IANA) IANA)</t>
          • </t>
        • <tli>
          • Name: <t xmlns:xi="http://www.w3.org/2001/XInclude">Name: L2 Bundle Member LAN Adj-SID Adj-SID</t>
          • </t>
        • <tli>
          • This <t xmlns:xi="http://www.w3.org/2001/XInclude">This sub-TLV is allowed in the following TLVs: TLVs:</t>
          • </t>
        • <artwork name="" type="" align="left" alt="">
          • <table anchor="table3">
            • <thead>
              • <tr>
                • <th>
                  • 22
                  • </th>
                • <th>
                  • 23
                  • </th>
                • <th>
                  • 25
                  • </th>
                • <th>
                  • 141
                  • </th>
                • <th>
                  • 222
                  • </th>
                • <th>
                  •  22 23 25 141 222  223
                     n  n  y   n   n   n
                  • </th>
                • </tr>
              • </thead>
            • <tbody>
              • <tr>
                • <td>
                  • n
                  • </td>
                • <td>
                  • n
                  • </td>
                • <td>
                  • y
                  • </td>
                • <td>
                  • n
                  • </td>
                • <td>
                  • n
                  • </td>
                • <td>
                  • n
                  • </td>
                • </tr>
              • </tbody>
            • </table>
          • </artwork>
        • </section>
      • <section anchor="Security" numbered="true" toc="default">
        • <name>
          • Security Considerations
          • </name>
        • <t>
          • The IS-IS protocol has supported the advertisement of link attribute information, including link identifiers, for many years. The advertisements defined in this document are identical to existing advertisements defined in [RFC4202], [RFC5305], [RFC7810], <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4202"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5305"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC7810"/>, and [SR-ISIS] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SR-ISIS"/> - but are associated with L2 links which are part of a bundle interface on which the IS-IS protocol operates. There are therefore no new security issues introduced by the extensions in this document.
          • </t>
        • <t>
          • As always, if the protocol is used in an environment where unauthorized access to the physical links on which IS-IS PDUs are sent occurs then attacks are possible. The use of authentication as defined in [RFC5304] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5304"/> and [RFC5310] <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5310"/> is recommended to prevent such attacks.
          • </t>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Contributors
          • </name>
        • <t>
          • The following people gave a substantial contribution to the content of this document and should be considered as co-authors:
          • </t>
        • <artwork name="" type="" align="left" alt="">

          • Stefano Previdi
            Cisco Systems
            Via Del Serafico 200
            Rome  0144
            Italy

            Email: sprevidi@cisco.com
          • </artwork>
        • </section>
      • <section anchor="Acknowledgements" numbered="true" toc="default">
        • <name>
          • Acknowledgements
          • </name>
        • <t>
          • The authors would like to thank Jon Mitchell for his careful review.
          • </t>
        • </section>
      • </middle>
    • <back>
      • <references>
        • <name>
          • References
          • </name>
        • <references>
          • <name>
            • Normative References
            • </name>
          • <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)
                • </title>
              • <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
              • <author>
                • <organization abbrev="ISO">
                  • International Organization for Standardization
                  • </organization>
                • </author>
              • <date month="Nov" year="2002"/>
              • </front>
            • </reference>
          • <reference anchor="IEEE802.1AX">
            • <front>
              • <title>
                • IEEE Standard for Local and Metropolitan Area Networks - Link Aggregation.
                • </title>
              • <author>
                • <organization abbrev="IEEE">
                  • Institute of Electrical and Electronics Engineers
                  • </organization>
                • </author>
              • <date month="Nov" year="2008"/>
              • </front>
            • </reference>
          • <reference anchor="SR-ISIS">
            • <front>
              • <title>
                • IS-IS Extensions for Segment Routing, draft-ietf-isis-segment-routing-extensions-12(work in progress) Routing
                • </title>
              • <author initials="S" surname="Previdi" fullname="Stefano Previdi">
                • <organization/>
                • </author>
              • <author initials="L" surname="Ginsberg" fullname="Les Ginsberg">
                • <organization/>
                • </author>
              • <author initials="C" surname="Filsfils" fullname="Clarence Filsfils">
                • <organization/>
                • </author>
              • <author initials="A" surname="Bashandy" fullname="Ahmed Bashandy">
                • <organization/>
                • </author>
              • <author initials="H" surname="Gredler" fullname="Hannes Gredler">
                • <organization/>
                • </author>
              • <author fullname="Previdi S., et al," "Bruno Decraene" initials="B" surname="Decraene">
                • <organization/>
                • </author>
              • <date month="April" "May" year="2017" "2019" day="19"/>
              • <abstract>
                • <t>
                  • Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="Work in Progress" value="draft-ietf-isis-segment-routing-extensions-25"/>
            • <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-isis-segment-routing-extensions-25.txt"/>
            • </reference>
          • <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
            • <front>
              • <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
                • <front>
                  • <title>
                    • Key words for use in RFCs to Indicate Requirement Levels
                    • </title>
                  • <author initials="S." surname="Bradner" fullname="S. Bradner">
                    • <organization/>
                    • </author>
                  • <date year="1997" month="March"/>
                  • <abstract>
                    • <t>
                      • In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                      • </t>
                    • </abstract>
                  • </front>
                • <seriesInfo name="DOI" "BCP" value="10.17487/RFC2119" "14" />
                • <seriesInfo name="RFC" value="2119"/>
                • <seriesInfo name="BCP" "DOI" value="14" "10.17487/RFC2119" />
                • </reference>
              • <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
                • <front>
                  • <title>
                    • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
                    • </title>
                  • <author initials="S." "B." surname="Bradner" "Leiba" fullname="S. Bradner" "B. Leiba" >
                    • <organization/>
                    • </author>
                  • <date year="1997" "2017" month="March" "May" />
                  • <abstract>
                    • <t>
                      • In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for*RFC improvements. 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                      • </t>
                    • </abstract>
                  • </front>
                • <seriesInfo name="BCP" value="14"/>
                • <seriesInfo name="RFC" value="8174"/>
                • <seriesInfo name="DOI" value="10.17487/RFC8174"/>
                • </reference>
              • </front>
            • </reference>
          • <reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml">
            • <front>
              • <title>
                • Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC4202"/>
              • <seriesInfo name="RFC" value="4202"/>
              • <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
                • <organization/>
                • </author>
              • <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
                • <organization/>
                • </author>
              • <date year="2005" month="October"/>
              • <abstract>
                • <t>
                  • This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS). This document enhances the routing extensions required to support MPLS Traffic Engineering (TE). [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="4202"/>
            • <seriesInfo name="DOI" value="10.17487/RFC4202"/>
            • </reference>
          • <reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5304" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml">
            • <front>
              • <title>
                • IS-IS Cryptographic Authentication
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5304"/>
              • <seriesInfo name="RFC" value="5304"/>
              • <author initials="T." surname="Li" fullname="T. Li">
                • <organization/>
                • </author>
              • <author initials="R." surname="Atkinson" fullname="R. Atkinson">
                • <organization/>
                • </author>
              • <date year="2008" month="October"/>
              • <abstract>
                • <t>
                  • This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.
                  • </t>
                • <t>
                  • This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5304"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5304"/>
            • </reference>
          • <reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml">
            • <front>
              • <title>
                • IS-IS Extensions for Traffic Engineering
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5305"/>
              • <seriesInfo name="RFC" value="5305"/>
              • <author initials="T." surname="Li" fullname="T. Li">
                • <organization/>
                • </author>
              • <author initials="H." surname="Smit" fullname="H. Smit">
                • <organization/>
                • </author>
              • <date year="2008" month="October"/>
              • <abstract>
                • <t>
                  • This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5305"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5305"/>
            • </reference>
          • <reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5307" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml">
            • <front>
              • <title>
                • IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5307"/>
              • <seriesInfo name="RFC" value="5307"/>
              • <author initials="K." surname="Kompella" fullname="K. Kompella" role="editor">
                • <organization/>
                • </author>
              • <author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
                • <organization/>
                • </author>
              • <date year="2008" month="October"/>
              • <abstract>
                • <t>
                  • This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS). [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5307"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5307"/>
            • </reference>
          • <reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5310" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml">
            • <front>
              • <title>
                • IS-IS Generic Cryptographic Authentication
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5310"/>
              • <seriesInfo name="RFC" value="5310"/>
              • <author initials="M." surname="Bhatia" fullname="M. Bhatia">
                • <organization/>
                • </author>
              • <author initials="V." surname="Manral" fullname="V. Manral">
                • <organization/>
                • </author>
              • <author initials="T." surname="Li" fullname="T. Li">
                • <organization/>
                • </author>
              • <author initials="R." surname="Atkinson" fullname="R. Atkinson">
                • <organization/>
                • </author>
              • <author initials="R." surname="White" fullname="R. White">
                • <organization/>
                • </author>
              • <author initials="M." surname="Fanto" fullname="M. Fanto">
                • <organization/>
                • </author>
              • <date year="2009" month="February"/>
              • <abstract>
                • <t>
                  • This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.
                  • </t>
                • <t>
                  • Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5310"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5310"/>
            • </reference>
          • <reference anchor="RFC6119" target="https://www.rfc-editor.org/info/rfc6119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml">
            • <front>
              • <title>
                • IPv6 Traffic Engineering in IS-IS
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6119"/>
              • <seriesInfo name="RFC" value="6119"/>
              • <author initials="J." surname="Harrison" fullname="J. Harrison">
                • <organization/>
                • </author>
              • <author initials="J." surname="Berger" fullname="J. Berger">
                • <organization/>
                • </author>
              • <author initials="M." surname="Bartlett" fullname="M. Bartlett">
                • <organization/>
                • </author>
              • <date year="2011" month="February"/>
              • <abstract>
                • <t>
                  • This document specifies a method for exchanging IPv6 traffic engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6119"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6119"/>
            • </reference>
          • <reference anchor="RFC7810" target="https://www.rfc-editor.org/info/rfc7810" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7810.xml">
            • <front>
              • <title>
                • IS-IS Traffic Engineering (TE) Metric Extensions
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC7810"/>
              • <seriesInfo name="RFC" value="7810"/>
              • <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
                • <organization/>
                • </author>
              • <author initials="S." surname="Giacalone" fullname="S. Giacalone">
                • <organization/>
                • </author>
              • <author initials="D." surname="Ward" fullname="D. Ward">
                • <organization/>
                • </author>
              • <author initials="J." surname="Drake" fullname="J. Drake">
                • <organization/>
                • </author>
              • <author initials="Q." surname="Wu" fullname="Q. Wu">
                • <organization/>
                • </author>
              • <date year="2016" month="May"/>
              • <abstract>
                • <t>
                  • In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.
                  • </t>
                • <t>
                  • This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.
                  • </t>
                • <t>
                  • Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="7810"/>
            • <seriesInfo name="DOI" value="10.17487/RFC7810"/>
            • </reference>
          • </references>
        • <references>
          • <name>
            • Informational References
            • </name>
          • <reference anchor="RFC4655" "RFC8402" target="https://www.rfc-editor.org/info/rfc4655" "https://www.rfc-editor.org/info/rfc8402" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
            • <front>
              • <title>
                • A Path Computation Element (PCE)-Based Segment Routing Architecture
                • </title>
              • <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
                • <organization/>
                • </author>
              • <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
                • <organization/>
                • </author>
              • <author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
                • <organization/>
                • </author>
              • <seriesInfo name="DOI" value="10.17487/RFC4655"/>
              • <seriesInfo name="RFC" value="4655"/>
              • <author initials="A." "B." surname="Farrel" "Decraene" fullname="A. Farrel" "B. Decraene" >
                • <organization/>
                • </author>
              • <author initials="J.-P." "S." surname="Vasseur" "Litkowski" fullname="J.-P. Vasseur" "S. Litkowski" >
                • <organization/>
                • </author>
              • <author initials="J." "R." surname="Ash" "Shakir" fullname="J. Ash" "R. Shakir" >
                • <organization/>
                • </author>
              • <date year="2006" "2018" month="August" "July" />
              • <abstract>
                • <t>
                  • Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network*Segment domains. Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
                  • </t>
                • <t>
                  • SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
                  • </t>
                • <t>
                  • This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet*SR community. can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8402"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8402"/>
            • </reference>
          • <reference anchor="SR-ARCH" "RFC4655" target="https://www.rfc-editor.org/info/rfc4655" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml">
            • <front>
              • <title>
                • Segment Routing Architecture, draft-ietf-spring-segment-routing-11(work in progress) A Path Computation Element (PCE)-Based Architecture
                • </title>
              • <author initials="A." surname="Farrel" fullname="A. Farrel">
                • <organization/>
                • </author>
              • <author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur">
                • <organization/>
                • </author>
              • <author fullname="Filsfils C., et al," "J. Ash" initials="J." surname="Ash">
                • <organization/>
                • </author>
              • <date month="February" "August" year="2017" "2006" />
              • <abstract>
                • <t>
                  • Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.
                  • </t>
                • <t>
                  • This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="4655"/>
            • <seriesInfo name="DOI" value="10.17487/RFC4655"/>
            • </reference>
          • </references>
        • </references>
      • <section numbered="true" toc="default">
        • <name>
          • Example Encoding
          • </name>
        • <t/>
        • <t>
          • Below is an example encoding of L2 Bundle advertisements in a case where we have two parallel adjacencies to the same neighbor whose system-id is 1234.1234.1234.00. The two L2 bundles have the following sets of attributes:
          • </t>
        • <t>
          • L3 Adjacency #1
          • </t>
        • <t>
          • L3 IPv4 local link address: 192.0.2.1
          • </t>
        • <t>
          • Four bundle members with the following attributes:
          • </t>
        • <table anchor="table4">
          • <thead>
            • <tr>
              • <th>
                • Num
                • </th>
              • <th>
                • Link Local ID
                • </th>
              • <th>
                • Bandwidth
                • </th>
              • <th>
                • Adj-SID/Weight
                • </th>
              • </tr>
            • </thead>
          • <tbody>
            • <tr>
              • <td>
                • 1
                • </td>
              • <td>
                • 0x11111111
                • </td>
              • <td>
                • 1G
                • </td>
              • <td>
                • 0x11111/1
                • </td>
              • </tr>
            • <tr>
              • <td>
                • 2
                • </td>
              • <td>
                • 0x11112222
                • </td>
              • <td>
                • 1G
                • </td>
              • <td>
                • 0x11112/1
                • </td>
              • </tr>
            • <tr>
              • <td>
                • 3
                • </td>
              • <td>
                • 0x11113333
                • </td>
              • <td>
                • 10G
                • </td>
              • <td>
                • 0x11113/1
                • </td>
              • </tr>
            • <tr>
              • <td>
                • 4
                • </td>
              • <td>
                • 0x11114444
                • </td>
              • <td>
                • 10G
                • </td>
              • <td>
                • 0x11114/1
                • </td>
              • </tr>
            • </tbody>
          • </table>
        • <t>
          • L3 Adjacency #2
          • </t>
        • <t>
          • L3 IPv4 local link address: 192.0.2.2
          • </t>
        • <t>
          • Three bundle members with the following attributes:
          • </t>
        • <table anchor="table5">
          • <thead>
            • <tr>
              • <th>
                • Num
                • </th>
              • <th>
                • Link Local ID
                • </th>
              • <th>
                • Bandwidth
                • </th>
              • <th>
                • Adj-SID/Weight
                • </th>
              • </tr>
            • </thead>
          • <tbody>
            • <tr>
              • <td>
                • 1
                • </td>
              • <td>
                • 0x22221111
                • </td>
              • <td>
                • 10G
                • </td>
              • <td>
                • 22221/1
                • </td>
              • </tr>
            • <tr>
              • <td>
                • 2
                • </td>
              • <td>
                • 0x22222222
                • </td>
              • <td>
                • 10G
                • </td>
              • <td>
                • 22222/1
                • </td>
              • </tr>
            • <tr>
              • <td>
                • 3
                • </td>
              • <td>
                • 0x22223333
                • </td>
              • <td>
                • 10G
                • </td>
              • <td>
                • 22223/1
                • </td>
              • </tr>
            • </tbody>
          • </table>
        • <t>
          • This requires two TLVs, one for each L3 adjacency.
          • </t>
        • <t>
          • <strong xmlns:xi="http://www.w3.org/2001/XInclude">TLV for Adjacency #1:</strong>
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   0                   1  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Type(25)     |Len: 64        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • Parent L3 Neighbor Descriptor
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Neighbor System-ID octets 1-4: 1234.1234                      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
          • </artwork>
        • <t>
          • IPv4 Interface Address sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   0                   1  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Type(6))     | Length(4)     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | IPv4 address:192.0.2.1                                          | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
          • </artwork>
        • <t>
          • L2 Bundle Attribute Descriptors
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Len:9+6+10 = 25| # Desc: 2     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Link Local Identifier Bundle Member #1: 0x11111111            | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Local Identifier Bundle Member #2: 0x11112222            | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • Maximum Link Bandwidth sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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(9)       | Length(4)    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Bandwidth Value: 1G/8                                         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • L2 Bundle Member Adjacency Segment Identifier sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #1: 0x11111         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #2: 0x11112         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • L2 Bundle Attribute Descriptors
          • </t>
        • <artwork name="" type="" align="left" alt="">
          • L3 Adjacency #1
            L3 IPv4 local link address: 192.0.2.1
            Four bundle members with the following attributes:

            --------------------------------------------------
            Num | Link Local ID | Bandwidth | Adj-SID/Weight |
            --------------------------------------------------
            1   | 0x11111111    | 1G        | 0x11111/1      |
            --------------------------------------------------
            2   | 0x11112222    | 1G        | 0x11112/1      |
            --------------------------------------------------
            3   | 0x11113333    | 10G       | 0x11113/1      |
            --------------------------------------------------
            4   | 0x11114444    | 10G       | 0x11114/1      |
            --------------------------------------------------

            L3 Adjacency #2
            L3 IPv4 local link address: 192.0.2.2
            Three bundle members with the following attributes:

            --------------------------------------------------
            Num | Link Local ID | Bandwidth | Adj-SID/Weight |
            --------------------------------------------------

             0                    1                   2               | 0x22221111       10G       | 22221/1        |
            --------------------------------------------------
            2   | 0x22222222    | 10G       | 
            22222/1   
             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 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |Len:9+6+10 = 25| # Desc: 2
                 |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

            --------------------------------------------------
            3   | 0x22223333
            | Link Local Identifier Bundle Member #3: 0x11113333     | 10G          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | 22223/1  Link Local Identifier Bundle Member #4: 0x11114444             |
            -------------------------------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          • </artwork>
        • <t>
          • Maximum Link Bandwidth sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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(9)       | Length(4)    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Bandwidth Value: 10G/8                                        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • This requires two TLVs, one for each L3 adjacency. L2 Bundle Member Adjacency Segment Identifier sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #3: 0x11113         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local Label Bundle Member #4: 0x11114         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • <strong xmlns:xi="http://www.w3.org/2001/XInclude">TLV for Adjacency #2</strong>
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •  0                   1  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Type(25)     | Len: 46       | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • Parent L3 Neighbor Descriptor
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Neighbor System-ID octets 1-4: 1234.1234                      | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
          • </artwork>
        • <t>
          • TLV for Adjacency #1: IPv4 Interface Address sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   0                   1  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  Type(6))     | Length(4)     | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | IPv4 address: 192.0.2.2                                         | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   
          • </artwork>
        • <t>
          • L2 Bundle Attribute Descriptors
          • </t>
        • <artwork name="" type="" align="left" alt="">


          •  0                   1
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |  Type(25)     |Len: 64        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Parent L3 Neighbor Descriptor
             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 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Neighbor System-ID octets 1-4: 1234.1234                      |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

            IPv4 Interface Address sub-TLV
             0                   1
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |  Type(6))     | Length(4)     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | IPv4 address:192.0.2.1                                          |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

            L2 Bundle Attribute Descriptors
             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 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |Len:9+6+10 = 25| # Desc: 2     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Link Local Identifier Bundle Member #1: 0x11111111            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Link Local Identifier Bundle Member #2: 0x11112222            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Maximum Link Bandwidth sub-TLV
             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(9)       | Length(4)    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Bandwidth Value: 1G/8                                         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            L2 Bundle Member Adjacency Segment Identifier sub-TLV
             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(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Local Label Bundle Member #1: 0x11111         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Local Label Bundle Member #2: 0x11112         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            L2 Bundle Attribute Descriptors
             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 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |Len:9+6+10 = 25| # Desc: 2     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Link Local Identifier Bundle Member #3: 0x11113333            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Link Local Identifier Bundle Member #4: 0x11114444            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Maximum Link Bandwidth sub-TLV
             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(9)       | Length(4)    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Bandwidth Value: 10G/8                                        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            L2 Bundle Member Adjacency Segment Identifier sub-TLV
             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 

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |
            |Len:13+6+13=32 | # Desc: 3   Type(41)    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              
            | Length(8)  Link Local Identifier Bundle Member #1: 0x22221111      |0|0|1|1|0|0|0|0| Weight: 1         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |
             Link  Local Label Identifier  Bundle Member #3: 0x11113  #2: 0x22222222             |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |
             Link  Local Label Identifier  Bundle Member #4: 0x11114  #3: 0x22223333             |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          • </artwork>
        • <t>
          • Maximum Link Bandwidth sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">
          •   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(9)       | Length(4)    | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   | Bandwidth Value: 10G/8                                        | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
          • </artwork>
        • <t>
          • TLV for L2 Bundle Member Adjacency #2 Segment Identifier sub-TLV
          • </t>
        • <artwork name="" type="" align="left" alt="">

          • 0                   1
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |  Type(25)     | Len: 46       |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Parent L3 Neighbor Descriptor
             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 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Neighbor System-ID octets 1-4: 1234.1234                      |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

            IPv4 Interface Address sub-TLV
             0                   1
             0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |  Type(6))     | Length(4)     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | IPv4 address: 192.0.2.2                                         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

            L2 Bundle Attribute Descriptors
             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 
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            |Len:13+6+13=32 | # Desc: 3     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Link Local Identifier Bundle Member #1: 0x22221111            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Link Local Identifier Bundle Member #2: 0x22222222            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Link Local Identifier Bundle Member #3: 0x22223333            |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


            Maximum Link Bandwidth sub-TLV
             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(9)       | Length(4)    |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
            | Bandwidth Value: 10G/8                                        |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            L2 Bundle Member Adjacency Segment Identifier sub-TLV
             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(41)     | Length(11)    |0|0|1|1|0|0|0|0| Weight: 1     |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Local Label Bundle Member #1: 0x22221         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Local Label Bundle Member #2: 0x22222         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            | Local Label Bundle Member #3: 0x22223         |
            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          • </artwork>
        • </section>
      • </back>
    • </rfc>
1<?xml version='1.0' encoding='utf-8'?>
2
3<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" consensus="true"
4     number="9999" ipr="trust200902" obsoletes=""
5     updates="" submissionType="IETF" xml:lang="en" tocInclude="true"
6     symRefs="true" sortRefs="true" version="3"> 
7  <!-- xml2rfc v2v3 conversion 2.23.0 -->
8  <front>
9    <title abbrev="isis l2bundles">Advertising L2 Bundle Member Link
10    Attributes in IS-IS</title>
11    <seriesInfo name="RFC" value="9999"/>
12    <author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
13      <organization>Cisco Systems</organization>
14      <address>
15        <postal>
16          <street>510 McCarthy Blvd.</street>
17          <city>Milpitas</city>
18          <code>95035</code>
19          <region>CA</region>
20          <country>USA</country>
21        </postal>
22        <email>ginsberg@cisco.com</email>
23      </address>
24    </author>
25    <author fullname="Ahmed Bashandy" initials="A" surname="Bashandy">
26      <organization>Cisco Systems</organization>
27      <address>
28        <postal>
29          <street>170 West Tasman Drive</street>
30          <city>San Jose</city>
31          <code>95134</code>
32          <region>Ca</region>
33          <country>US</country>
34        </postal>
35      </address>
36    </author>
37    <author fullname="Clarence Filsfils" initials="C" surname="Filsfils">
38      <organization>Cisco Systems</organization>
39      <address>
40        <postal>
41          <street/>
42          <city/>
43          <code/>
44          <region/>
45          <country/>
46        </postal>
47        <email>cf@cisco.com</email>
48      </address>
49    </author>
50    <author fullname="Mohan Nanduri" initials="M" surname="Nanduri">
51      <organization>eBay</organization>
52      <address>
53        <postal>
54          <street/>
55          <city/>
56          <code/>
57          <country/>
58        </postal>
59        <email>mnanduri@ebay.com</email>
60      </address>
61    </author>
62    <author fullname="Ebben Aries" initials="E" surname="Aries">
63      <organization>Private Contributer</organization>
64      <address>
65        <postal>
66          <street/>
67          <city/>
68          <code/>
69          <country/>
70        </postal>
71        <email>exa@dscp.org</email>
72      </address>
73    </author>
74    <date month="July" year="2019"/>
75    <area>Routing Area</area>
76    <workgroup>Networking Working Group</workgroup>
77    <keyword>Sample</keyword>
78    <abstract>
79      <t>There are deployments where the Layer 3 interface on which IS-IS
80      operates is a Layer 2 interface bundle. Existing IS-IS advertisements
81      only support advertising link attributes of the Layer 3 interface. If
82      entities external to IS-IS wish to control traffic flows on the
83      individual physical links which comprise the Layer 2 interface bundle
84      link attribute information about the bundle members is required.</t>
85      <t>This document introduces the ability for IS-IS to advertise the link
86      attributes of layer 2 (L2) bundle members.</t>
87    </abstract>
88    <note>
89      <name>Requirements Language</name>
90        <t>
91    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
92    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
93    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
94    described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> 
95    when, and only when, they appear in all capitals, as shown here.
96        </t>
97    </note>
98  </front>
99  <middle>
100    <section numbered="true" toc="default">
101      <name>Introduction</name>
102      <t>There are deployments where the Layer 3 interface on which an IS-IS
103      adjacency is established is a Layer 2 interface bundle, for instance a
104      Link Aggregation Group (LAG) <xref target="IEEE802.1AX"/>. This reduces the number of
105      adjacencies which need to be maintained by the routing protocol in cases
106      where there are parallel links between the neighbors. Entities external
107      to IS-IS such as Path Computation Elements (PCE) <xref target="RFC4655"/> may wish to
108      control traffic flows on individual members of the underlying Layer 2
109      bundle. In order to do so link attribute information about individual
110      bundle members is required. The protocol extensions defined in this
111      document provide the means to advertise this information.</t>
112      <t>This document introduces a new TLV to advertise link attribute
113      information for each of the L2 bundle members which comprise the Layer 3
114      interface on which IS-IS operates.</t>
115      <t><xref target="SR-ISIS"/> introduces a new link attribute - adjacency segment
116      identifier (Adj-SID) - which can be used as an instruction to forwarding
117      to send traffic over a specific link. This document introduces
118      additional sub-TLVs to advertise Adj-SIDs for L2 Bundle members.</t>
119      <t>Note that the new advertisements defined in this document are
120      intended to be provided to external (to IS-IS) entities. The following
121      items are intentionally not defined and/or are outside the scope of this
122      document:</t>
123      <ul spacing="normal">
124        <li>What link attributes will be advertised. This is determined by
125          the needs of the external entities.</li>
126        <li>A minimum or default set of link attributes.</li>
127        <li>How these attributes are configured</li>
128        <li>How the advertisements are used</li>
129        <li>What impact the use of these advertisements may have on traffic
130          flow in the network</li>
131        <li>How the advertisements are passed to external entities</li>
132      </ul>
133    </section>
134    <section numbered="true" toc="default">
135      <name>L2 Bundle Member Attributes TLV</name>
136      <t>A new TLV is introduced to advertise L2 Bundle member attributes.
137      Although much of the information is identical to and uses the same
138      sub-TLVs included in Extended IS-Neighbor advertisements (TLVs 22 and
139      222), a new TLV is used so that changes to the advertisement of the L2
140      Bundle member link attributes does not trigger unnecessary action by the
141      <xref target="ISO10589"/> Decision process.</t>
142      <t>Advertisement of this information implies that the identified link is
143      a member of the L2 Bundle associated with the identified Parent L3
144      Neighbor and that the member link is operationally up. Therefore
145      advertisements <bcp14>MUST</bcp14> be withdrawn if the link becomes operationally down
146      or it is no longer a member of the identified L2 Bundle.</t>
147      <t>This new TLV utilizes the sub-TLV space defined for TLVs 22, 23, 141,
148      222, and 223.</t>
149      <t>The following new TLV is introduced:</t>
150
151<ul empty="true" spacing="normal">
152<li><t>L2 Bundle Member Attributes</t>
153<ul empty="true">
154<li>Type: 25 (suggested - to be assigned by IANA)</li>
155<li>Length: Number of octets to follow</li>
156</ul>
157</li>
158</ul>
159
160<ul empty="true">
161<li><t>Parent L3 Neighbor Descriptor</t>
162<ul empty="true">
163 <li>L3 Neighbor System ID + pseudonode ID (7 octets)</li>
164 <li><t>Flags: 1 octet field of following flags:</t>
165      <artwork name="" type="" align="left" alt=""><![CDATA[
166          0 1 2 3 4 5 6 7 
167         +-+-+-+-+-+-+-+-+
168         |P|             |
169         +-+-+-+-+-+-+-+-+
170      ]]></artwork>
171
172  <t>where:</t>
173
174<dl><dt>P-flag:</dt>
175<dd>When set to 1 one of the sub-TLVs described in Section 2.1 immediately
176follows the flags field. If the P-flag is set to 0, then none of the sub-TLVs
177described in Section 2.1 are present.</dd>
178<dt>Other bits:</dt>
179<dd><bcp14>MUST</bcp14> be zero when originated and ignored when received.</dd>
180</dl>
181  </li>
182</ul>
183</li>
184</ul>
185
186<ul empty="true">
187<li><t>One or more of the following:</t>
188 <ul empty="true">
189 <li><t>L2 Bundle Attribute Descriptors</t>
190  <ul empty="true">
191  <li><t>Length of L2 Bundle Attribute Descriptor (1 octet)</t>
192   <ul empty="true">
193   <li>NOTE: This includes all fields described below.</li>
194   </ul>
195      <t>Number of L2 Bundle Member Descriptors (1 octet)</t>
196      <t>L2 Bundle Member Link Local Identifiers</t>
197      <ul empty="true">
198      <li>(4 * Number of L2 Bundle Member Descriptors octets)</li>
199      <li>NOTE: An L2 Bundle Member Descriptor is a Link Local Identifier as
200      defined in <xref target="RFC4202"/>.</li>
201      </ul>
202      <t>sub-TLV(s)</t>
203      <t>A sub-TLV may define an attribute common to all of
204      the bundle members listed or a sub-TLV may define an
205      attribute unique to each bundle member. Use of these 
206      two classes of sub-TLVs is described in the following
207      sections.</t>
208  </li>
209  </ul>
210 </li>
211 </ul>
212</li>
213</ul>
214
215      <aside><t>NOTE: Only one Parent L3 Neighbor Descriptor is present in a
216      given TLV. Multiple L2 Bundle Attribute Descriptors may be present in a
217      single TLV.</t></aside>
218
219      <section numbered="true" toc="default">
220        <name>Parallel L3 Adjacencies</name>
221        <t>When there exist multiple L3 adjacencies to the same neighbor
222        additional information is required to uniquely identify the L3
223        Neighbor. One and only one of the following three sub-TLVs is used to
224        uniquely identify the L3 adjacency:</t>
225        <ul spacing="normal">
226          <li>IPv4 Interface Address (sub-TLV 6 defined in <xref target="RFC5305"/>)</li>
227          <li>IPv6 Interface Address (sub-TLV 12 defined in <xref target="RFC6119"/>)</li>
228          <li>Link Local/Remote Identifiers (sub-TLV 4 defined in
229            <xref target="RFC5307"/>)</li>
230        </ul>
231        <t>When the P-bit is set in the flags field in the Parent L3 Neighbor
232        Descriptor one and only one of the above sub-TLVs <bcp14>MUST</bcp14> be present. The
233        chosen sub-TLV <bcp14>MUST</bcp14> immediately follow the flags field described in
234        Section 2.</t>
235        <t>These sub-TLVs <bcp14>MAY</bcp14> be omitted if no parallel adjacencies to the
236        neighbor exist.</t>
237      </section>
238      <section numbered="true" toc="default">
239        <name>Shared Attribute sub-TLVs</name>
240        <t>These sub-TLVs advertise a single copy of an attribute (e.g. link
241        bandwidth). The attribute applies to all of the L2 Bundle Members in
242        the set advertised under the preceding  L2 Bundle Member
243        Attribute Descriptor. No more than one copy of a given sub-TLV in this
244        category may appear in the set of sub-TLVs under the preceding L2
245        Bundle Member Attribute Descriptor. If multiple copies of a given
246        sub-TLV are present all copies <bcp14>MUST</bcp14> be ignored.</t>
247        <t>The set of L2 Bundle Member Descriptors which may be advertised
248        under a single L2 Bundle Member Attribute Descriptor is therefore
249        limited to bundle members which share the set of attributes advertised
250        in the shared attribute sub-TLVs.</t>
251        <t>All existing sub-TLVs defined in the IANA Sub-TLVs for TLVs 22, 23,
252        141, 222, and 223 registry are in the category of shared attribute
253        sub-TLVs unless otherwise specified in this document.</t>
254      </section>
255    </section>
256    <section numbered="true" toc="default">
257      <name>Advertising L2 Bundle Member Adj-SIDs</name>
258      <t><xref target="SR-ISIS"/> defines sub-TLVs to advertise Adj-SIDs for L3 adjacencies.
259      However these sub-TLVs only support a advertisement of a single Adj-SID.
260      As it is expected that each L2 Bundle member will have unique Adj-SIDs
261      in many deployments it is desirable to define a new sub-TLV which allows
262      more efficient encoding of a set of Adj-SIDs in a single sub-TLV. Two
263      new sub-TLVs are therefore introduced to support advertising Adj-SIDs
264      for L2 Bundle members. The format of the new sub-TLVs is similar to that
265      used for L3 adjacencies, but is optimized to allow advertisement of a
266      set of Adj-SIDs (one per L2 Bundle Member) in a single sub-TLV.</t>
267      <t>The two new sub-TLVs defined in the following sections do not fall
268      into the category of shared attribute sub-TLVs.</t>
269
270      <section numbered="true" toc="default">
271        <name>L2 Bundle Member Adjacency Segment Identifier sub-TLV</name>
272        <t>This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members
273        associated with a parent L3 adjacency which is Point-to-Point. The
274        following format is defined for this sub-TLV:</t>
275
276<ul empty="true" spacing="normal">
277<li><t>Type: 41 (suggested value to be assigned by IANA) (1 octet)</t></li>
278<li><t>Length: variable (1 octet)</t></li>
279
280<li><t>Flags: 1 octet field of following flags:</t>
281
282<artwork name="" type="" align="left" alt=""><![CDATA[
283          0 1 2 3 4 5 6 7
284         +-+-+-+-+-+-+-+-+
285         |F|*|V|L|S|P|   |
286         +-+-+-+-+-+-+-+-+
287]]></artwork>
288</li>
289</ul>
290
291<!-- SG: Moved <aside> up because it can't be used within a list item. -->
292
293         <aside><t>NOTE: The flags are deliberately kept congruent to the flags 
294         in the L3 ADJ-SID defined in <xref target="SR-ISIS" />.
295         * indicates a flag used in the L3 Adj-SID sub-TLV but which is
296         NOT used in this sub-TLV. These bits <bcp14>SHOULD</bcp14> be sent as 0 and 
297         <bcp14>MUST</bcp14> be ignored on receipt.</t></aside>
298
299<ul empty="true" spacing="normal">
300<li><t>where:</t>
301
302<dl spacing="normal">
303<dt>F-Flag:</dt>
304<dd>Address-Family flag.  If unset, then the Adj-SID refers
305         to an L2 Bundle Member with outgoing IPv4 encapsulation. If set
306         then the Adj-SID refers to an L2 Bundle Member with outgoing
307         IPv6 encapsulation.</dd>
308
309<dt>V-Flag:</dt>
310<dd>Value flag.  If set, then the Adj-SID carries a value.
311         By default the flag is SET.</dd>
312
313<dt>L-Flag:</dt>
314<dd>Local Flag.  If set, then the value/index carried by
315         the Adj-SID has local significance.  By default the flag is
316         SET.</dd>
317
318<dt>S-Flag.</dt>
319<dd>Set Flag.  When set, the S-Flag indicates that the
320         Adj-SID refers to a set of L2 Bundle Members (and therefore
321         <bcp14>MAY</bcp14> be assigned to other L2 Bundle Members as well).</dd>
322
323<dt>P-Flag.</dt>
324<dd>Persistent flag.  When set, the P-Flag indicates that
325         the Adj-SID is persistently allocated, i.e., the Adj-SID value
326         remains consistent across router restart and/or interface flap.</dd>
327
328<dt>Other bits:</dt>
329<dd><bcp14>MUST</bcp14> be zero when originated and ignored when
330         received.</dd>
331</dl>
332</li>
333      </ul>
334
335<dl>
336<dt>Weight:</dt>
337<dd>1 octet.  The value represents the weight of the Adj-SID
338        for the purpose of load balancing.  The use of the weight is
339        defined in <xref target="RFC8402"/>.</dd>
340</dl>
341
342<aside><t>NOTE: Flags and weight are shared by all L2 Bundle Members
343    listed in the L2 Bundle Attribute Descriptor.</t></aside>
344
345<dl>
346<dt>L2 Bundle Member Adj-SID Descriptors.</dt>
347<dd><t>There <bcp14>MUST</bcp14> be one descriptor
348     for each of the L2 Bundle Members advertised under the preceding
349     L2 Bundle Member Attribute Descriptor. Each descriptor consists 
350     of one of the following fields:</t>
351
352  <dl>
353  <dt>SID/Index/Label:</dt>
354  <dd><t>according to the V and L flags, it contains
355        either:</t>
356
357    <ul empty="true" spacing="normal">
358    <li>A 3 octet local label where the 20 rightmost bits are used
359           for encoding the label value.  In this case the V and L 
360           flags <bcp14>MUST</bcp14> be set.</li>
361
362    <li>A 4 octet index defining the offset in the SID/Label space
363           advertised by this router. See <xref target="SR-ISIS"/>.
364           In this case V and L flags <bcp14>MUST</bcp14> be unset.</li>
365    </ul>
366</dd>
367  </dl>
368</dd>
369</dl>
370
371      </section>
372      <section numbered="true" toc="default">
373        <name>L2 Bundle Member LAN Adjacency Segment Identifier sub-TLV</name>
374        <t>This sub-TLV is used to advertise Adj-SIDs for L2 Bundle Members
375        associated with a parent L3 adjacency which is a LAN adjacency. In LAN
376        subnetworks, the Designated Intermediate System (DIS) is elected and
377        originates the Pseudonode-LSP (PN-LSP) including all neighbors of the
378        DIS. When Segment Routing is used, each router in the LAN <bcp14>MAY</bcp14>
379        advertise the Adj-SID of each of its neighbors on the LAN. Similarly,
380        for each L2 Bundle Member a router <bcp14>MAY</bcp14> advertise an Adj-SID to each
381        neighbor on the LAN.</t>
382        <t>The following format is defined for this sub-TLV:</t>
383
384<t>Type: 42 (suggested value to be assigned by IANA) (1 octet)</t>
385<t>Length: variable (1 octet)</t>
386<t>Neighbor System ID: 6 octets</t>
387
388<ul empty="true" spacing="normal">
389<li><t>Flags: 1 octet field of following flags:</t>
390
391<artwork name="" type="" align="left" alt=""><![CDATA[ 
392          0 1 2 3 4 5 6 7
393         +-+-+-+-+-+-+-+-+
394         |F|*|V|L|S|P|   |
395         +-+-+-+-+-+-+-+-+
396]]></artwork>
397</li>
398</ul>
399
400         <aside><t>NOTE: The flags are deliberately kept congruent to the flags 
401         in the L3 LAN_ADJ-SID defined in <xref target="SR-ISIS"/>.
402         * indicates a flag used in the L3 Adj-SID sub-TLV but which is
403         NOT used in this sub-TLV. These bits <bcp14>SHOULD</bcp14> be sent as 0 and 
404         <bcp14>MUST</bcp14> be ignored on receipt.</t></aside>
405
406
407<ul empty="true" spacing="normal">
408<li><t>where:</t>
409
410<dl>
411<dt>F-Flag:</dt>
412<dd>Address-Family flag.  If unset, then the Adj-SID refers
413         to an L2 Bundle Member with outgoing IPv4 encapsulation. If set
414         then the Adj-SID refers to an L2 Bundle Member with outgoing
415         IPv6 encapsulation.</dd>
416
417<dt>V-Flag:</dt>
418<dd>Value flag.  If set, then the Adj-SID carries a value.
419         By default the flag is SET.</dd>
420
421<dt>L-Flag:</dt>
422<dd>Local Flag.  If set, then the value/index carried by
423         the Adj-SID has local significance.  By default the flag is
424         SET.</dd>
425
426<dt>S-Flag.</dt>
427<dd>Set Flag.  When set, the S-Flag indicates that the
428         Adj-SID refers to a set of L2 Bundle Members (and therefore
429         <bcp14>MAY</bcp14> be assigned to other L2 Bundle Members as well).</dd>
430
431<dt>P-Flag.</dt>
432<dd>Persistent flag.  When set, the P-Flag indicates that
433         the Adj-SID is persistently allocated, i.e., the Adj-SID value
434         remains consistent across router restart and/or interface flap.</dd>
435
436<dt>Other bits:</dt>
437<dd><bcp14>MUST</bcp14> be zero when originated and ignored when
438         received.</dd>
439</dl>
440</li>
441</ul>
442
443<dl>
444<dt>Weight:</dt>
445<dd>1 octet.  The value represents the weight of the Adj-SID
446    for the purpose of load balancing.  The use of the weight is
447    defined in <xref target="RFC8402"/>.</dd>
448</dl>
449
450    <aside><t>NOTE: Flags and weight are shared by all L2 Bundle Members
451    listed in the L2 Bundle Attribute Descriptor.</t></aside>
452
453<dl>
454<dt>L2 Bundle Member LAN Adj-SID Descriptors.</dt>
455<dd><t>There <bcp14>MUST</bcp14> be one
456    descriptor for each of the L2 Bundle Members advertised 
457    under the preceding L2 Bundle Member Attribute Descriptor.
458    Each descriptor consists of one of the following fields:</t>
459<dl>
460<dt>SID/Index/Label:</dt>
461<dd><t>according to the V and L flags, it contains
462        either:</t>
463<ul><li>A 3 octet local label where the 20 rightmost bits are used
464           for encoding the label value.  In this case the V and L 
465           flags <bcp14>MUST</bcp14> be set.</li>
466
467    <li>A 4 octet index defining the offset in the SID/Label space
468           advertised by this router. See <xref target="SR-ISIS"/>.
469           In this case V and L flags <bcp14>MUST</bcp14> be unset.</li>
470</ul>
471</dd>
472</dl>
473</dd>
474</dl>
475
476      </section>
477    </section>
478    <section anchor="IANA" numbered="true" toc="default">
479      <name>IANA Considerations</name>
480      <t>This document adds the following new TLV to the IS-IS TLV Codepoints
481      registry.</t>
482<ul empty="true">
483<li><t>Value: 25 (suggested - to be assigned by IANA)</t></li>
484<li><t>Name: L2 Bundle Member Attributes</t></li>
485</ul>
486      <t>The name of the Sub-TLVs for TLVs 22, 23, 141, 222, and 223 registry
487      needs to be changed to Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223
488      registry. An additional column needs to be added to the registry to
489      indicate which sub-TLVs may appear in the new L2 Bundle Member
490      Attributes TLV. The column for TLV 25 has one of the following three
491      values:</t>
492      
493<dl>
494 <dt>y:</dt>
495 <dd>sub-TLV may appear in TLV 25 but <bcp14>MUST</bcp14> NOT be shared by multiple 
496    L2 Bundle Members</dd>
497
498 <dt>y(s):</dt>
499 <dd>sub-TLV may appear in TLV 25 and <bcp14>MAY</bcp14> be shared by multiple 
500    L2 Bundle Members</dd>
501
502 <dt>n:</dt>
503 <dd>sub-TLV <bcp14>MUST</bcp14> NOT appear in TLV 25</dd>
504</dl>
505      <t>The following table indicates the appropriate settings for all
506      currently defined sub-TLVs as regards their use in the new L2 Bundle
507      Member Attributes TLV.</t>
508
509<table anchor="iana-table">
510<name>Appropriate Settings for All Defined Sub-TLVs as regards their use in
511the new L2 Bundle Member Attributes TLV</name>
512  <thead>
513      <tr>
514 <th>Type</th>
515 <th>Description</th>
516 <th>25</th>
517      </tr>
518    </thead>
519    <tbody>
520      <tr>
521 <td>3</td>
522 <td>Administrative group (color)</td>
523 <td>y(s)</td>
524      </tr>
525      <tr>
526 <td>4</td>
527 <td>Link Local/Remote Identifiers</td>
528 <td>y(s)</td>
529      </tr>
530      <tr>
531 <td>6</td>
532 <td>IPv4 interface address</td>
533 <td>y(s)</td>
534      </tr>
535      <tr>
536 <td>8</td>
537 <td>IPv4 neighbor address</td>
538 <td>y(s)</td>
539      </tr>
540      <tr>
541 <td>9</td>
542 <td>Maximum link bandwidth</td>
543 <td>y(s)</td>
544      </tr>
545      <tr>
546 <td>10</td>
547 <td>Maximum reservable link bandwidth</td>
548 <td>y(s)</td>
549      </tr>
550      <tr>
551 <td>11</td>
552 <td>Unreserved bandwidth</td>
553 <td>y(s)</td>
554      </tr>
555      <tr>
556 <td>12</td>
557 <td>IPv6 Interface Address</td>
558 <td>y(s)</td>
559      </tr>
560      <tr>
561 <td>13</td>
562 <td>IPv6 Neighbor Address</td>
563 <td>y(s)</td>
564      </tr>
565      <tr>
566 <td>14</td>
567 <td>Extended Administrative Group</td>
568 <td>y(s)</td>
569      </tr>
570      <tr>
571 <td>18</td>
572 <td>TE Default metric</td>
573 <td>y(s)</td>
574      </tr>
575      <tr>
576 <td>19</td>
577 <td>Link-attributes</td>
578 <td>y(s)</td>
579      </tr>
580      <tr>
581 <td>20</td>
582 <td>Link Protection Type</td>
583 <td>y(s)</td>
584      </tr>
585      <tr>
586 <td>21</td>
587 <td>Interface Switching Capability Descriptor</td>
588 <td>y(s)</td>
589      </tr>
590      <tr>
591 <td>22</td>
592 <td>Bandwidth Constraints</td>
593 <td>y(s)</td>
594      </tr>
595      <tr>
596 <td>23</td>
597 <td>Unconstrained TE LSP Count</td>
598 <td>y(s)</td>
599      </tr>
600      <tr>
601 <td>24</td>
602 <td>Remote AS number</td>
603 <td>n</td>
604      </tr>
605      <tr>
606 <td>25</td>
607 <td>IPv4 remote ASBR Identifier</td>
608 <td>n</td>
609      </tr>
610      <tr>
611 <td>26</td>
612 <td>IPv6 remote ASBR Identifier</td>
613 <td>n</td>
614      </tr>
615      <tr>
616 <td>27</td>
617 <td>Interface Adjustment Capability Descriptor (IACD)</td>
618 <td>y(s)</td>
619      </tr>
620      <tr>
621 <td>28</td>
622 <td>MTU n</td>
623 <td>n</td>
624      </tr>
625      <tr>
626 <td>29</td>
627 <td>SPB-Metric</td>
628 <td>y(s)</td>
629      </tr>
630      <tr>
631 <td>30</td>
632 <td>SPB-A-OALG</td>
633 <td>y(s)</td>
634      </tr>
635      <tr>
636 <td>33</td>
637 <td>Unidirectional Link Delay</td>
638 <td>y</td>
639      </tr>
640      <tr>
641 <td>34</td>
642 <td>Min/Max Unidirectional Link Delay</td>
643 <td>y</td>
644      </tr>
645      <tr>
646 <td>35</td>
647 <td>Unidirectional Delay Variation</td>
648 <td>y</td>
649      </tr>
650      <tr>
651 <td>36</td>
652 <td>Unidirectional Link Loss</td>
653 <td>y</td>
654      </tr>
655      <tr>
656 <td>37</td>
657 <td>Unidirectional Residual Bandwidth</td>
658 <td>y</td>
659      </tr>
660      <tr>
661 <td>38</td>
662 <td>Unidirectional Available Bandwidth</td>
663 <td>y</td>
664      </tr>
665      <tr>
666 <td>39</td>
667 <td>Unidirectional Utilized Bandwidth</td>
668 <td>y</td>
669      </tr>
670      <tr>
671 <td>40</td>
672 <td>RTM Capability</td>
673 <td>n</td>
674      </tr>
675    </tbody>
676      </table>
677
678      <t>This document adds the following new sub-TLVs to the sub-TLVs for
679      TLVs 22, 23, 25, 141, 222, and 223 registry.</t>
680<ul empty="true">
681 <li><t>Value: 41 (suggested - to be assigned by IANA)</t></li>
682 <li><t>Name: L2 Bundle Member Adj-SID</t></li>
683 <li><t>This sub-TLV is allowed in the following TLVs:</t></li>
684</ul>
685
686<table anchor="table2">
687  <thead>
688      <tr>
689        <th>22</th>
690 <th>23</th>
691        <th>25</th>
692        <th>141</th>
693        <th>222</th>
694        <th>223</th>
695      </tr>
696  </thead>
697    <tbody>
698      <tr>
699        <td>n</td>
700        <td>n</td>
701        <td>y</td>
702        <td>n</td>
703        <td>n</td>
704        <td>n</td>
705      </tr>
706    </tbody>
707</table> 
708
709<ul empty="true">
710 <li><t>Value: 42 (suggested to be assigned by IANA)</t></li>
711 <li><t>Name: L2 Bundle Member LAN Adj-SID</t></li>
712 <li><t>This sub-TLV is allowed in the following TLVs:</t></li>
713</ul>
714
715<table anchor="table3">
716  <thead>
717      <tr>
718        <th>22</th>
719        <th>23</th>
720        <th>25</th>
721        <th>141</th>
722        <th>222</th>
723        <th>223</th>
724      </tr>
725  </thead>
726    <tbody>
727      <tr>
728        <td>n</td>
729        <td>n</td>
730        <td>y</td>
731        <td>n</td>
732        <td>n</td>
733        <td>n</td>
734      </tr>
735    </tbody>
736</table>
737
738
739    </section>
740    <section anchor="Security" numbered="true" toc="default">
741      <name>Security Considerations</name>
742      <t>The IS-IS protocol has supported the advertisement of link attribute
743      information, including link identifiers, for many years. The
744      advertisements defined in this document are identical to existing
745      advertisements defined in <xref target="RFC4202"/>, <xref
746      target="RFC5305"/>, <xref target="RFC7810"/>, and <xref target="SR-ISIS"/>
747      - but are associated with L2 links which are part of a bundle interface
748      on which the IS-IS protocol operates. There are therefore no new
749      security issues introduced by the extensions in this document.</t>
750      <t>As always, if the protocol is used in an environment where
751      unauthorized access to the physical links on which IS-IS PDUs are sent
752      occurs then attacks are possible. The use of authentication as defined
753      in <xref target="RFC5304"/> and <xref target="RFC5310"/> is recommended to prevent such attacks.</t>
754    </section>
755
756    <section numbered="true" toc="default">
757      <name>Contributors</name>
758      <t>The following people gave a substantial contribution to the content
759      of this document and should be considered as co-authors:</t>
760      <artwork name="" type="" align="left" alt=""><![CDATA[
761Stefano Previdi
762Cisco Systems
763Via Del Serafico 200
764Rome  0144
765Italy
766
767Email: sprevidi@cisco.com]]></artwork>
768    </section>
769    <section anchor="Acknowledgements" numbered="true" toc="default">
770      <name>Acknowledgements</name>
771      <t>The authors would like to thank Jon Mitchell for his careful
772      review.</t>
773    </section>
774  </middle>
775  <back>
776    <references>
777      <name>References</name>
778      <references>
779        <name>Normative References</name>
780        <reference anchor="ISO10589">
781          <front>
782            <title>Intermediate system to Intermediate system intra-domain
783          routeing information exchange protocol for use in conjunction with
784          the protocol for providing the connectionless-mode Network Service
785          (ISO 8473)</title>
786            <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
787            <author>
788              <organization abbrev="ISO">International Organization for
789            Standardization</organization>
790            </author>
791            <date month="Nov" year="2002"/>
792          </front>
793        </reference>
794        <reference anchor="IEEE802.1AX">
795          <front>
796            <title>IEEE Standard for Local and Metropolitan Area Networks - Link
797          Aggregation.</title>
798            <author>
799              <organization abbrev="IEEE">Institute of Electrical and
800            Electronics Engineers</organization>
801            </author>
802            <date month="Nov" year="2008"/>
803          </front>
804        </reference>
805
806<reference anchor='SR-ISIS'>
807<front>
808<title>IS-IS Extensions for Segment Routing</title>
809
810<author initials='S' surname='Previdi' fullname='Stefano Previdi'>
811    <organization />
812</author>
813
814<author initials='L' surname='Ginsberg' fullname='Les Ginsberg'>
815    <organization />
816</author>
817
818<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
819    <organization />
820</author>
821
822<author initials='A' surname='Bashandy' fullname='Ahmed Bashandy'>
823    <organization />
824</author>
825
826<author initials='H' surname='Gredler' fullname='Hannes Gredler'>
827    <organization />
828</author>
829
830<author initials='B' surname='Decraene' fullname='Bruno Decraene'>
831    <organization />
832</author>
833
834<date month='May' day='19' year='2019' />
835
836<abstract><t>Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments".  These segments are advertised by the link-state routing protocols (IS-IS and OSPF).  This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane.</t></abstract>
837
838</front>
839
840<seriesInfo name='Work in Progress' value='draft-ietf-isis-segment-routing-extensions-25' />
841<format type='TXT'
842        target='http://www.ietf.org/internet-drafts/draft-ietf-isis-segment-routing-extensions-25.txt' />
843</reference>
844
845<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
846<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
847<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml"/>
848<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/>
849<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
850<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml"/>
851<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/>
852<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml"/>
853<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7810.xml"/>
854      </references>
855
856      <references>
857        <name>Informational References</name>
858
859<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
860
861<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml"/>
862
863      </references>
864    </references>
865    <section numbered="true" toc="default">
866      <name>Example Encoding</name>
867      <t/>
868      <t>Below is an example encoding of L2 Bundle advertisements in a case
869      where we have two parallel adjacencies to the same neighbor whose
870      system-id is 1234.1234.1234.00. The two L2 bundles have the following
871      sets of attributes:</t>
872
873<t>L3 Adjacency #1</t>
874<t>L3 IPv4 local link address: 192.0.2.1</t>
875<t>Four bundle members with the following attributes:</t>
876
877<table anchor="table4">
878  <thead>
879      <tr>
880        <th>Num</th>
881        <th>Link Local ID</th>
882        <th>Bandwidth</th>
883        <th>Adj-SID/Weight</th>
884      </tr>
885  </thead>
886    <tbody>
887<tr>
888<td>1</td>
889<td>0x11111111</td>
890<td>1G</td>
891<td>0x11111/1</td>
892</tr>
893
894<tr>
895<td>2</td>
896<td>0x11112222</td>
897<td>1G</td>
898<td>0x11112/1</td>
899</tr>
900
901<tr>
902<td>3</td>
903<td>0x11113333</td>
904<td>10G</td>
905<td>0x11113/1</td>
906</tr>
907
908<tr>
909<td>4</td>
910<td>0x11114444</td>
911<td>10G</td>
912<td>0x11114/1</td>
913</tr>
914</tbody>
915</table>
916
917<t>L3 Adjacency #2</t>
918<t>L3 IPv4 local link address: 192.0.2.2</t>
919<t>Three bundle members with the following attributes:</t>
920
921<table anchor="table5">
922  <thead>
923      <tr>
924        <th>Num</th>
925        <th>Link Local ID</th>
926        <th>Bandwidth</th>
927        <th>Adj-SID/Weight</th>
928      </tr>
929  </thead>
930    <tbody>
931<tr>
932<td>1</td>
933<td>0x22221111</td>
934<td>10G</td>
935<td>22221/1</td>
936</tr>
937
938<tr>
939<td>2</td>
940<td>0x22222222</td>
941<td>10G</td>
942<td>22222/1</td>
943</tr>
944
945<tr>
946<td>3</td>
947<td>0x22223333</td>
948<td>10G</td>
949<td>22223/1</td>
950</tr>
951</tbody>
952</table>
953
954      <t>This requires two TLVs, one for each L3 adjacency.</t>
955      <t><strong>TLV for Adjacency #1:</strong></t>
956      <artwork name="" type="" align="left" alt=""><![CDATA[
957 0                   1
958 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
959+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
960|  Type(25)     |Len: 64        |
961+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
962]]></artwork>
963
964<t>Parent L3 Neighbor Descriptor</t>
965      <artwork name="" type="" align="left" alt=""><![CDATA[
966 0                   1                   2                   3 
967 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 
968+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
969| Neighbor System-ID octets 1-4: 1234.1234                      |
970+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
971| System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
972+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
973]]></artwork>
974
975<t>IPv4 Interface Address sub-TLV</t>
976      <artwork name="" type="" align="left" alt=""><![CDATA[
977 0                   1
978 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
979+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
980|  Type(6))     | Length(4)     |
981+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
982| IPv4 address:192.0.2.1                                          |
983+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
984]]></artwork>
985
986<t>L2 Bundle Attribute Descriptors</t>
987      <artwork name="" type="" align="left" alt=""><![CDATA[
988 0                   1                   2                   3 
989 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 
990+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
991|Len:9+6+10 = 25| # Desc: 2     |
992+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
993| Link Local Identifier Bundle Member #1: 0x11111111            |
994+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
995| Link Local Identifier Bundle Member #2: 0x11112222            |
996+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
997]]></artwork>
998
999<t>Maximum Link Bandwidth sub-TLV</t>
1000      <artwork name="" type="" align="left" alt=""><![CDATA[
1001 0                   1                   2                   3 
1002 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 
1003+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1004|  Type(9)       | Length(4)    |
1005+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1006| Bandwidth Value: 1G/8                                         |
1007+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1008]]></artwork>
1009
1010<t>L2 Bundle Member Adjacency Segment Identifier sub-TLV</t>
1011      <artwork name="" type="" align="left" alt=""><![CDATA[
1012 0                   1                   2                   3 
1013 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 
1014+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1015|  Type(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
1016+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1017| Local Label Bundle Member #1: 0x11111         |
1018+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1019| Local Label Bundle Member #2: 0x11112         |
1020+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1021]]></artwork>
1022
1023<t>L2 Bundle Attribute Descriptors</t>
1024      <artwork name="" type="" align="left" alt=""><![CDATA[
1025 0                   1                   2                   3 
1026 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 
1027+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1028|Len:9+6+10 = 25| # Desc: 2     |
1029+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1030| Link Local Identifier Bundle Member #3: 0x11113333            |
1031+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1032| Link Local Identifier Bundle Member #4: 0x11114444            |
1033+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1034]]></artwork>
1035
1036<t>Maximum Link Bandwidth sub-TLV</t>
1037      <artwork name="" type="" align="left" alt=""><![CDATA[
1038 0                   1                   2                   3 
1039 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 
1040+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1041|  Type(9)       | Length(4)    |
1042+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1043| Bandwidth Value: 10G/8                                        |
1044+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1045]]></artwork>
1046
1047<t>L2 Bundle Member Adjacency Segment Identifier sub-TLV</t>
1048      <artwork name="" type="" align="left" alt=""><![CDATA[
1049 0                   1                   2                   3 
1050 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 
1051+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1052|  Type(41)     | Length(8)     |0|0|1|1|0|0|0|0| Weight: 1     |
1053+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1054| Local Label Bundle Member #3: 0x11113         |
1055+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1056| Local Label Bundle Member #4: 0x11114         |
1057+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1058]]></artwork>
1059
1060      <t><strong>TLV for Adjacency #2</strong></t>
1061      <artwork name="" type="" align="left" alt=""><![CDATA[
10620                   1
1063 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
1064+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1065|  Type(25)     | Len: 46       |
1066+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1067]]></artwork>
1068
1069<t>Parent L3 Neighbor Descriptor</t>
1070      <artwork name="" type="" align="left" alt=""><![CDATA[
1071 0                   1                   2                   3 
1072 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 
1073+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1074| Neighbor System-ID octets 1-4: 1234.1234                      |
1075+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1076| System-ID octets 5-6: 1234    | P-node: 00    |1|0|0|0|0|0|0|0|
1077+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1078]]></artwork>
1079
1080<t>IPv4 Interface Address sub-TLV</t>
1081      <artwork name="" type="" align="left" alt=""><![CDATA[
1082 0                   1
1083 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
1084+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1085|  Type(6))     | Length(4)     |
1086+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1087| IPv4 address: 192.0.2.2                                         |
1088+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1089]]></artwork>
1090
1091<t>L2 Bundle Attribute Descriptors</t>
1092      <artwork name="" type="" align="left" alt=""><![CDATA[
1093 0                   1                   2                   3 
1094 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 
1095+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1096|Len:13+6+13=32 | # Desc: 3     |
1097+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1098| Link Local Identifier Bundle Member #1: 0x22221111            |
1099+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1100| Link Local Identifier Bundle Member #2: 0x22222222            |
1101+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1102| Link Local Identifier Bundle Member #3: 0x22223333            |
1103+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1104]]></artwork>
1105
1106<t>Maximum Link Bandwidth sub-TLV</t>
1107      <artwork name="" type="" align="left" alt=""><![CDATA[
1108 0                   1                   2                   3 
1109 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 
1110+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1111|  Type(9)       | Length(4)    |
1112+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  
1113| Bandwidth Value: 10G/8                                        |
1114+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1115]]></artwork>
1116
1117<t>L2 Bundle Member Adjacency Segment Identifier sub-TLV</t>
1118      <artwork name="" type="" align="left" alt=""><![CDATA[
1119 0                   1                   2                   3 
1120 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 
1121+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1122|  Type(41)     | Length(11)    |0|0|1|1|0|0|0|0| Weight: 1     |
1123+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1124| Local Label Bundle Member #1: 0x22221         |
1125+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1126| Local Label Bundle Member #2: 0x22222         |
1127+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1128| Local Label Bundle Member #3: 0x22223         |
1129+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1130]]></artwork>
1131    </section>
1132  </back>
1133</rfc>
1<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
2<front>
3<title>Key words for use in RFCs to Indicate Requirement Levels</title>
4<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
5<date year="1997" month="March"/>
6<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
7</front>
8<seriesInfo name="BCP" value="14"/>
9<seriesInfo name="RFC" value="2119"/>
10<seriesInfo name="DOI" value="10.17487/RFC2119"/>
11</reference>
1<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
2<front>
3<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
4<author initials="B." surname="Leiba" fullname="B. Leiba"><organization/></author>
5<date year="2017" month="May"/>
6<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
7</front>
8<seriesInfo name="BCP" value="14"/>
9<seriesInfo name="RFC" value="8174"/>
10<seriesInfo name="DOI" value="10.17487/RFC8174"/>
11</reference>
1<reference anchor="RFC4202" target="https://www.rfc-editor.org/info/rfc4202" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4202.xml">
2<front>
3<title>Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
4<author initials="K." surname="Kompella" fullname="K. Kompella" role="editor"><organization/></author>
5<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor"><organization/></author>
6<date year="2005" month="October"/>
7<abstract><t>This document specifies routing extensions in support of carrying link state information for Generalized Multi-Protocol Label Switching (GMPLS).  This document enhances the routing extensions required to support MPLS Traffic Engineering (TE).  [STANDARDS-TRACK]</t></abstract>
8</front>
9<seriesInfo name="RFC" value="4202"/>
10<seriesInfo name="DOI" value="10.17487/RFC4202"/>
11</reference>
1<reference anchor="RFC5304" target="https://www.rfc-editor.org/info/rfc5304" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml">
2<front>
3<title>IS-IS Cryptographic Authentication</title>
4<author initials="T." surname="Li" fullname="T. Li"><organization/></author>
5<author initials="R." surname="Atkinson" fullname="R. Atkinson"><organization/></author>
6<date year="2008" month="October"/>
7<abstract><t>This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.  The base specification includes an authentication mechanism that allows for multiple authentication algorithms.  The base specification only specifies the algorithm for cleartext passwords.  This document replaces RFC 3567.</t><t>This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms.  [STANDARDS-TRACK]</t></abstract>
8</front>
9<seriesInfo name="RFC" value="5304"/>
10<seriesInfo name="DOI" value="10.17487/RFC5304"/>
11</reference>
1<reference anchor="RFC5305" target="https://www.rfc-editor.org/info/rfc5305" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml">
2<front>
3<title>IS-IS Extensions for Traffic Engineering</title>
4<author initials="T." surname="Li" fullname="T. Li"><organization/></author>
5<author initials="H." surname="Smit" fullname="H. Smit"><organization/></author>
6<date year="2008" month="October"/>
7<abstract><t>This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE).  This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP).  This information describes additional details regarding the state of the network that are useful for traffic engineering computations.  [STANDARDS-TRACK]</t></abstract>
8</front>
9<seriesInfo name="RFC" value="5305"/>
10<seriesInfo name="DOI" value="10.17487/RFC5305"/>
11</reference>
1<reference anchor="RFC5307" target="https://www.rfc-editor.org/info/rfc5307" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5307.xml">
2<front>
3<title>IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)</title>
4<author initials="K." surname="Kompella" fullname="K. Kompella" role="editor"><organization/></author>
5<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor"><organization/></author>
6<date year="2008" month="October"/>
7<abstract><t>This document specifies encoding of extensions to the IS-IS routing protocol in support of Generalized Multi-Protocol Label Switching (GMPLS).  [STANDARDS-TRACK]</t></abstract>
8</front>
9<seriesInfo name="RFC" value="5307"/>
10<seriesInfo name="DOI" value="10.17487/RFC5307"/>
11</reference>
1<reference anchor="RFC5310" target="https://www.rfc-editor.org/info/rfc5310" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml">
2<front>
3<title>IS-IS Generic Cryptographic Authentication</title>
4<author initials="M." surname="Bhatia" fullname="M. Bhatia"><organization/></author>
5<author initials="V." surname="Manral" fullname="V. Manral"><organization/></author>
6<author initials="T." surname="Li" fullname="T. Li"><organization/></author>
7<author initials="R." surname="Atkinson" fullname="R. Atkinson"><organization/></author>
8<author initials="R." surname="White" fullname="R. White"><organization/></author>
9<author initials="M." surname="Fanto" fullname="M. Fanto"><organization/></author>
10<date year="2009" month="February"/>
11<abstract><t>This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304.  IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.</t><t>Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future.  [STANDARDS-TRACK]</t></abstract>
12</front>
13<seriesInfo name="RFC" value="5310"/>
14<seriesInfo name="DOI" value="10.17487/RFC5310"/>
15</reference>
1<reference anchor="RFC6119" target="https://www.rfc-editor.org/info/rfc6119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6119.xml">
2<front>
3<title>IPv6 Traffic Engineering in IS-IS</title>
4<author initials="J." surname="Harrison" fullname="J. Harrison"><organization/></author>
5<author initials="J." surname="Berger" fullname="J. Berger"><organization/></author>
6<author initials="M." surname="Bartlett" fullname="M. Bartlett"><organization/></author>
7<date year="2011" month="February"/>
8<abstract><t>This document specifies a method for exchanging IPv6 traffic  engineering information using the IS-IS routing protocol. This information enables routers in an IS-IS network to  calculate traffic-engineered routes using IPv6 addresses. [STANDARDS-TRACK]</t></abstract>
9</front>
10<seriesInfo name="RFC" value="6119"/>
11<seriesInfo name="DOI" value="10.17487/RFC6119"/>
12</reference>
1<reference anchor="RFC7810" target="https://www.rfc-editor.org/info/rfc7810" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7810.xml">
2<front>
3<title>IS-IS Traffic Engineering (TE) Metric Extensions</title>
4<author initials="S." surname="Previdi" fullname="S. Previdi" role="editor"><organization/></author>
5<author initials="S." surname="Giacalone" fullname="S. Giacalone"><organization/></author>
6<author initials="D." surname="Ward" fullname="D. Ward"><organization/></author>
7<author initials="J." surname="Drake" fullname="J. Drake"><organization/></author>
8<author initials="Q." surname="Wu" fullname="Q. Wu"><organization/></author>
9<date year="2016" month="May"/>
10<abstract><t>In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics.</t><t>This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion.  The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance.</t><t>Note that this document only covers the mechanisms with which network-performance information is distributed.  The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document.</t></abstract>
11</front>
12<seriesInfo name="RFC" value="7810"/>
13<seriesInfo name="DOI" value="10.17487/RFC7810"/>
14</reference>
1<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
2<front>
3<title>Segment Routing Architecture</title>
4<author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor"><organization/></author>
5<author initials="S." surname="Previdi" fullname="S. Previdi" role="editor"><organization/></author>
6<author initials="L." surname="Ginsberg" fullname="L. Ginsberg"><organization/></author>
7<author initials="B." surname="Decraene" fullname="B. Decraene"><organization/></author>
8<author initials="S." surname="Litkowski" fullname="S. Litkowski"><organization/></author>
9<author initials="R." surname="Shakir" fullname="R. Shakir"><organization/></author>
10<date year="2018" month="July"/>
11<abstract><t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called "segments".  A segment can represent any instruction, topological or service based.  A segment can have a semantic local to an SR node or global within an SR domain.  SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t><t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane.  A segment is encoded as an MPLS label.  An ordered list of segments is encoded as a stack of labels.  The segment to process is on the top of the stack.  Upon completion of a segment, the related label is popped from the stack.</t><t>SR can be applied to the IPv6 architecture, with a new type of routing header.  A segment is encoded as an IPv6 address.  An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header.  The active segment is indicated by the Destination Address (DA) of the packet.  The next active segment is indicated by a pointer in the new routing header.</t></abstract>
12</front>
13<seriesInfo name="RFC" value="8402"/>
14<seriesInfo name="DOI" value="10.17487/RFC8402"/>
15</reference>
1<reference anchor="RFC4655" target="https://www.rfc-editor.org/info/rfc4655" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4655.xml">
2<front>
3<title>A Path Computation Element (PCE)-Based Architecture</title>
4<author initials="A." surname="Farrel" fullname="A. Farrel"><organization/></author>
5<author initials="J.-P." surname="Vasseur" fullname="J.-P. Vasseur"><organization/></author>
6<author initials="J." surname="Ash" fullname="J. Ash"><organization/></author>
7<date year="2006" month="August"/>
8<abstract><t>Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks.  Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains.</t><t>This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space.  This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed.  This memo provides information for the Internet community.</t></abstract>
9</front>
10<seriesInfo name="RFC" value="4655"/>
11<seriesInfo name="DOI" value="10.17487/RFC4655"/>
12</reference>