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