1<?xml version="1.0" encoding="US-ASCII"?>
2<!-- This template is for creating an Internet Draft using xml2rfc,
3    which is available here: http://xml.resource.org. -->
4<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
5<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
6<!-- used by XSLT processors -->
7<!-- For a complete list and description of processing instructions (PIs),
8    please see http://xml.resource.org/authoring/README.html. -->
9<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
10    (Here they are set differently than their defaults in xml2rfc v1.32) -->
11<?rfc strict="yes" ?>
12<!-- give errors regarding ID-nits and DTD validation -->
13<!-- control the table of contents (ToC) -->
14<?rfc toc="yes"?>
15<!-- generate a ToC -->
16<?rfc tocdepth="4"?>
17<!-- the number of levels of subsections in ToC. default: 3 -->
18<!-- control references -->
19<?rfc symrefs="yes"?>
20<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
21<?rfc sortrefs="yes" ?>
22<!-- sort the reference entries alphabetically -->
23<!-- control vertical white space
24    (using these PIs as follows is recommended by the RFC Editor) -->
25<?rfc compact="yes" ?>
26<!-- do not start each main section on a new page -->
27<?rfc subcompact="no" ?>
28<!-- keep one blank line between list items -->
29<!-- end of list of popular I-D processing instructions -->
30<rfc category="std" docName="draft-ietf-ospf-segment-routing-msd-25"
31     ipr="trust200902">
32  <front>
33    <title abbrev="">Signaling MSD (Maximum SID Depth) using OSPF</title>
34
35
36      <author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
37      <organization>Apstra, Inc.</organization>
38      <address>
39 <email>jefftant.ietf@gmail.com</email>
40      </address>
41    </author>
42
43    <author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
44      <organization>Huawei Technologies</organization>
45      <address>
46      <email>uma.chunduri@huawei.com</email>
47      </address>
48    </author>
49
50   <author fullname="Sam Aldrin" initials="S.A." surname="Aldrin">
51      <organization>Google, Inc</organization>
52      <address>
53 <email>aldrin.ietf@gmail.com</email>
54      </address>
55    </author>
56
57    <author fullname="Peter Psenak" initials="P.P." surname="Psenak">
58      <organization>Cisco Systems</organization>
59      <address>
60 <email>ppsenak@cisco.com</email>
61      </address>
62    </author>
63
64    <date day="17" month="October" year="2018" />
65
66    <area>Routing</area>
67
68    <workgroup>OSPF Working Group</workgroup>
69
70    <keyword>Internet-Draft</keyword>
71
72    <keyword>BGP-LS</keyword>
73
74    <keyword>SID</keyword>
75
76    <keyword>MSD </keyword>
77
78    <keyword>OSPF</keyword>
79
80   <abstract>
81 <t>This document defines a way for an Open Shortest Path First (OSPF) Router to advertise multiple
82 types of supported Maximum SID(Segment Identifier) Depths (MSDs) at node and/or link
83 granularity. Such advertisements allow entities (e.g., centralized
84 controllers) to determine whether a particular SID stack can be supported
85 in a given network. This document defines only one type of MSD,  
86    but defines an encoding that can support other MSD types.
87    Here the term OSPF means both OSPFv2 and  OSPFv3.</t>
88
89    </abstract>
90  </front>
91
92  <middle>
93   <section title="Introduction">
94      <t>When Segment Routing (SR) paths are computed by a centralized
95      controller, it is critical that the controller learns the Maximum SID (Segment Identifier)
96      Depth (MSD) that can be imposed at each node/link on a given SR path 
97      to ensure that the Segment Identifier (SID) stack depth of a computed path
98      doesn't exceed the number of SIDs the node is capable of imposing.</t>
99
100      <t><xref target="I-D.ietf-pce-segment-routing"/> defines how to signal
101      MSD in the Path Computation Element communication Protocol (PCEP).
102       However, if PCEP is not supported/configured on
103      the head-end of an SR tunnel or a Binding-SID anchor node and controller
104      does not participate in IGP routing, it has no way to learn the MSD of
105      nodes and links. BGP-LS (Distribution of Link-State and TE Information using
106     Border Gateway Protocol) <xref target="RFC7752"/> defines a way to expose topology and associated
107      attributes and capabilities of the nodes in that topology to a
108      centralized controller. MSD signaling by BGP-LS has been defined in
109      <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd"/>. Typically,
110      BGP-LS is configured on a small number of nodes that do not necessarily
111      act as head-ends. In order for BGP-LS to signal MSD for all the nodes
112      and links in the network MSD is relevant, MSD capabilities SHOULD be
113      advertised by every OSPF router in the network.</t>
114
115      <t>Other types of MSD are known to be useful. For example,
116   <xref target="I-D.ietf-ospf-mpls-elc"/> defines Readable Label Depth
117      Capability (RLDC) that is used by a head-end to insert an Entropy Label
118      (EL) at a depth that could be read by transit nodes.</t>
119
120      <t>This document defines an extension to OSPF used to advertise one or
121      more types of MSD at node and/or link granularity.
122      In the future it is expected, that new MSD-types will be defined to signal additional capabilities
123      e.g., entropy labels, SIDs that can be imposed through recirculation, or
124      SIDs associated with another dataplane e.g., IPv6. </t>
125
126      <t>MSD advertisements MAY be useful even if Segment Routing itself is
127      not enabled. For example, in a non-SR MPLS network, MSD defines the
128      maximum label depth.</t>
129
130 <section title="Terminology">
131
132  <t>This memo makes use of the terms defined in <xref target="RFC7770"/></t>
133
134 <t>BGP-LS: Distribution of Link-State and TE Information using
135 Border Gateway Protocol</t>
136
137 <t>OSPF: Open Shortest Path First</t>
138
139 <t>MSD: Maximum SID Depth - the number of SIDs supported by a node or
140        a link on a node</t>
141
142        <t>SID: Segment Identifier as defined in <xref target="RFC8402"/></t>
143
144        <t>Label Imposition: Imposition is the act of modifying and/or adding
145        labels to the outgoing label stack associated with a packet. This
146        includes:</t>
147
148        <t><list style="symbols">
149            <t>replacing the label at the top of the label stack with a new
150            label</t>
151
152            <t>pushing one or more new labels onto the label stack</t>
153          </list></t>
154
155        <t>The number of labels imposed is then the sum of the number of
156        labels which are replaced and the number of labels which are pushed.
157        See <xref target="RFC3031"/> for further details.</t>
158
159 <t>PCC: Path Computation Client</t>
160
161 <t>PCE: Path Computation Element</t>
162
163 <t>PCEP: Path Computation Element Protocol</t>
164
165 <t>SR: Segment Routing</t>
166
167        <t>SID: Segment Identifier</t>
168
169        <t>LSA: Link state advertisement</t>
170
171        <t>RI: OSPF Router Information LSA</t>
172
173 </section>
174
175 <section title="Requirements Language">
176     <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL                                                                                                
177      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
178      "MAY", and "OPTIONAL" in this document are to be interpreted as
179      described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
180      when, and only when, they appear in all capitals, as shown here.</t>
181    </section>
182    </section>
183    <section anchor="NODE_LEVEL" title="Node MSD Advertisement">
184      <t>The node MSD TLV within the body of the OSPF RI Opaque LSA <xref target="RFC7770"/> is defined to carry the provisioned SID depth
185      of the router originating the RI LSA. Node MSD is the smallest MSD supported by the node on the set of interfaces configured 
186      for use by the advertising IGP instance.
187      MSD values may be learned via a hardware API or may be provisioned.
188      </t>
189      <figure align="center" anchor="Node_MSD_TLV"
190       title="Node MSD TLV">
191          <preamble></preamble>
192
193   <artwork align="left">
194       0                   1                   2                   3
195       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
196
197      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
198      |    Type                       |  Length                       |
199      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
200      |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... | 
201      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
202
203          </artwork>
204
205          <postamble></postamble>
206  </figure>
207      <t>Type: 12</t>
208      <t>Length: variable (multiple of 2 octets) and represents the total length of value field in octets. </t>
209      <t>Value: consists of one or more pairs of a 1 octet MSD-type and 1 octet MSD-Value. </t>
210      <t>MSD-Type: one of the values defined in the IGP MSD-Types registry
211         defined in <xref target="I-D.ietf-isis-segment-routing-msd"/>.</t>
212   
213     
214   <t>MSD-Value: a number in the range of 0-255. For all MSD-Types, 0 represents lack of the ability to 
215         impose MSD stack of any depth; any other value represents that of the node. This value MUST 
216         represent the lowest value supported by any link configured for use by the
217         advertising OSPF instance.</t>
218      <t>This TLV is applicable to OSPFv2 and to OSPFv3 and is optional. 
219         The scope of the advertisement is specific to the deployment.</t>
220         
221      <t> When multiple Node MSD TLVs are received from a given router, the
222        receiver MUST use the first occurrence of the TLV in the Router
223        Information LSA.  If the Node MSD TLV appears in multiple Router
224        Information LSAs that have different flooding scopes, the Node
225        MSD TLV in the Router Information LSA with the area-scoped
226        flooding scope MUST be used.  If the Node MSD TLV appears in
227        multiple Router Information LSAs that have the same flooding scope,
228        the Node MSD TLV in the Router Information (RI) LSA with the
229        numerically smallest Instance ID MUST be used and other
230        instances of the Node MSD TLV MUST be ignored.
231 
232        The RI LSA can be advertised at any of the defined opaque flooding
233        scopes (link, area, or Autonomous System (AS)).  For the purpose of
234        Node MSD TLV advertisement, area-scoped flooding is RECOMMENDED. </t>
235
236    </section>
237
238    <section anchor="LINK_LEVEL" title="Link MSD sub-TLV">
239      <t>The link sub-TLV is defined to carry the MSD of the interface associated with the link. 
240        MSD values may be learned via a hardware API or may be provisioned.</t>
241    <figure align="center" anchor="Link_MSD_sub_TLV"
242       title="Link MSD Sub-TLV">
243          <preamble></preamble>
244
245   <artwork align="left">
246
247       0                   1                   2                   3
248       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
249
250      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
251      |    Type                       |  Length                       |
252      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
253      |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... | 
254      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
255
256
257
258          </artwork>
259
260          <postamble></postamble>
261  </figure>
262
263  <t>Type:</t>
264     <t>For OSPFv2, the Link level MSD-Value is advertised as an optional Sub-TLV
265     of the OSPFv2 Extended Link TLV as defined in <xref target="RFC7684"/>, and has a type of 6.</t>
266     <t>For OSPFv3, the Link level MSD-Value is advertised as an optional Sub-TLV of the E-Router-LSA TLV as
267     defined in <xref target="RFC8362"/>, and has a type of 9.
268     </t>
269      <t>Length: variable and same as defined in <xref target="NODE_LEVEL"> </xref>.</t>
270      <t>Value: consists of one or more pairs of a 1 octet MSD-type and 1 octet MSD-Value. </t>
271      <t>MSD-Type: one of the values defined in the MSD-Types registry
272         defined in <xref target="I-D.ietf-isis-segment-routing-msd"/>.</t> 
273         <t>MSD-Value field contains Link MSD of the router originating the corresponding LSA as specified 
274         for OSPFv2 and OSPFv3.  Link MSD is a number in the range of 0-255. 
275         For all MSD-Types, 0 represents lack of the ability to impose MSD stack of any depth; 
276        any other value represents that of the particular link when used as an outgoing interface.</t>
277
278
279      <t>If this sub-TLV is advertised multiple times in the same OSPFv2 Extended
280        Link Opaque LSA/E-Router-LSA, only the first instance of the TLV MUST be used by
281        receiving OSPF routers. This situation SHOULD be logged as an error.</t>
282 
283  <t> If this sub-TLV is advertised multiple times for the same link in
284   different OSPF Extended Link Opaque LSAs/E-Router-LSAs originated by the same
285  OSPF router, the OSPFv2 Extended Link TLV in the OSPFv2 Extended
286   Link Opaque LSA with the smallest Opaque ID or in the OSPFv3 E-Router-LSA with the smallest Link State ID MUST be used by receiving
287   OSPF routers. This situation MAY be logged as a warning.
288</t>
289
290
291      </section>
292
293  <section anchor="Confict_resolution"
294             title="Procedures for Defining and Using Node and Link MSD Advertisements">
295      <t>When Link MSD is present for a given MSD-type, the value of the Link
296      MSD MUST take precedence over the Node MSD. When a Link MSD-type is not
297      signaled but the Node MSD-type is, then the Node MSD-type value MUST be
298      considered as the MSD value for that link.</t>
299
300      <t>In order to increase flooding efficiency, it is RECOMMENDED that
301      routers with homogenous link MSD values advertise just the Node MSD
302      value.</t>
303
304      <t>The meaning of the absence of both Node and Link MSD advertisements
305      for a given MSD-type is specific to the MSD-type. Generally it can only
306      be inferred that the advertising node does not support advertisement of
307      that MSD-type. However, in some cases the lack of advertisement might
308      imply that the functionality associated with the MSD-type is not
309      supported. The correct interpretation MUST be specified when an MSD-type is
310      defined in <xref target="I-D.ietf-isis-segment-routing-msd"/>.</t>
311
312      <!---->
313    </section>
314
315      <!---->
316    <section anchor="IANA" title="IANA Considerations">
317    <t>This specification updates several existing OSPF registries.</t>
318      <t>IANA has allocated TLV type 12 from the OSPF Router
319       Information (RI) TLVs Registry as defined by <xref target="RFC7770"/>.
320
321<figure align="center" anchor="Node_MSD"
322       title="RI Node MSD">
323          <preamble/>
324
325   <artwork align="left">
326
327   Value     Description                      Reference
328   -----     ---------------                  -------------
329   12        Node MSD                         This document
330
331          </artwork>
332          <postamble/>
333  </figure>
334
335       IANA has allocated sub-TLV type 6 from
336       the OSPFv2 Extended Link TLV Sub-TLVs registry. 
337<figure align="center" anchor="OSPFv2_Link_MSD"
338       title="OSPFv2 Link MSD">
339          <preamble/>
340
341
342   <artwork align="left">
343
344   Value     Description                      Reference
345   -----     ---------------                  -------------
346   6         OSPFv2 Link MSD                   This document
347
348          </artwork>
349          <postamble/>
350  </figure>
351
352       IANA has allocated sub-TLV type 9 from the OSPFv3 Extended-LSA Sub-TLV registry.
353
354          <figure align="center" anchor="OSPFv3_Link_MSD"
355       title="OSPFv3 Link MSD">
356          <preamble/>
357
358
359   <artwork align="left">
360
361   Value     Description                      Reference
362   -----     ---------------                  -------------
363   9         OSPFv3 Link MSD                  This document
364
365          </artwork>
366          <postamble/>
367  </figure>
368     </t>
369</section>
370
371 <section anchor="Security" title="Security Considerations">
372    <t>Security concerns for OSPF are addressed in <xref target="RFC7474"/>,  <xref target="RFC4552"/> and <xref target="RFC7166"/>.
373   Further security analysis for OSPF protocol is done in <xref target="RFC6863"/>. 
374   Security considerations, as specified by <xref target="RFC7770"/>, <xref target="RFC7684"/> and  <xref target="RFC8362"/> are applicable to this document.</t>
375   <t>Implementations MUST assure that malformed TLV and Sub-TLV defined in
376   this document are detected and do not provide a vulnerability for
377   attackers to crash the OSPF router or routing process.  Reception
378   of malformed TLV or Sub-TLV SHOULD be counted and/or logged for
379   further analysis.  Logging of malformed TLVs and Sub-TLVs SHOULD be
380   rate-limited to prevent a Denial of Service (DoS) attack (distributed
381   or otherwise) from overloading the OSPF control plane.</t>
382
383   <t>Advertisement of an incorrect MSD value may have negative
384      consequences. If the value is smaller than supported, path computation
385      may fail to compute a viable path. If the value is larger than
386      supported, an attempt to instantiate a path that can't be supported by
387      the head-end (the node performing the SID imposition) may occur.</t>
388
389      <t>The presence of this information also may inform an attacker of how
390      to induce any of the aforementioned conditions.</t>
391
392    <t>There's no  Denial of Service risk specific to this extension, and it is not vulnerable to replay attacks.</t>
393
394 <!---->
395 </section>
396
397
398        <section anchor="Contributors" title="Contributors">
399
400      <t>The following people contributed to this document:</t>
401      <t>Les Ginsberg</t>
402      <t>Email: ginsberg@cisco.com</t>
403    </section>
404
405
406     <section anchor="Acknowledgments" title="Acknowledgments">
407     <t>The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal Mizrahi, Stephane Litkowski and Bruno Decraene
408 for their reviews and valuable comments.  </t>
409    <!---->
410    </section>
411
412  </middle>
413
414  <back>
415    <references title="Normative References">
416      <?rfc include="reference.I-D.ietf-isis-segment-routing-msd"?>
417      <?rfc include="reference.RFC.2119"?>
418      <?rfc include="reference.RFC.8174"?>
419      <?rfc include="reference.RFC.7770"?>
420      <?rfc include="reference.RFC.8362"?>
421      <?rfc include="reference.RFC.7684"?>
422      <?rfc include="reference.RFC.3031"?>
423      <?rfc include="reference.RFC.8402"?>
424      <!---->
425    </references>
426
427    <references title="Informative References">
428      <?rfc include="reference.I-D.ietf-pce-segment-routing"?>
429      <?rfc include="reference.I-D.ietf-idr-bgp-ls-segment-routing-msd"?>
430      <?rfc include="reference.I-D.ietf-ospf-mpls-elc"?>
431      <?rfc include="reference.RFC.7752"?>
432      <?rfc include="reference.RFC.6863"?>
433      <?rfc include="reference.RFC.7474"?>
434      <?rfc include="reference.RFC.4552"?>
435      <?rfc include="reference.RFC.7166"?>
436      <!---->
437    </references>
438  </back>
439</rfc>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference anchor='I-D.ietf-isis-segment-routing-msd'>
4<front>
5<title>Signaling MSD (Maximum SID Depth) using IS-IS</title>
6
7<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
8    <organization />
9</author>
10
11<author initials='U' surname='Chunduri' fullname='Uma Chunduri'>
12    <organization />
13</author>
14
15<author initials='S' surname='Aldrin' fullname='Sam Aldrin'>
16    <organization />
17</author>
18
19<author initials='L' surname='Ginsberg' fullname='Les Ginsberg'>
20    <organization />
21</author>
22
23<date month='October' day='9' year='2018' />
24
25<abstract><t>This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID (Segment ID) stack can be supported in a given network.  This document only defines one type of MSD (Base MPLS Imposition), but defines an encoding that can support other MSD types.  This document focuses on MSD use in a Segment Routing enabled network, but MSD may also be useful when Segment Routing is not enabled.</t></abstract>
26
27</front>
28
29<seriesInfo name='Internet-Draft' value='draft-ietf-isis-segment-routing-msd-19' />
30<format type='TXT'
31        target='http://www.ietf.org/internet-drafts/draft-ietf-isis-segment-routing-msd-19.txt' />
32</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
4<front>
5<title>Key words for use in RFCs to Indicate Requirement Levels</title>
6<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
7<date year='1997' month='March' />
8<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>
9</front>
10<seriesInfo name='BCP' value='14'/>
11<seriesInfo name='RFC' value='2119'/>
12<seriesInfo name='DOI' value='10.17487/RFC2119'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
4<front>
5<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
6<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
7<date year='2017' month='May' />
8<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>
9</front>
10<seriesInfo name='BCP' value='14'/>
11<seriesInfo name='RFC' value='8174'/>
12<seriesInfo name='DOI' value='10.17487/RFC8174'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7770' target='https://www.rfc-editor.org/info/rfc7770'>
4<front>
5<title>Extensions to OSPF for Advertising Optional Router Capabilities</title>
6<author initials='A.' surname='Lindem' fullname='A. Lindem' role='editor'><organization /></author>
7<author initials='N.' surname='Shen' fullname='N. Shen'><organization /></author>
8<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'><organization /></author>
9<author initials='R.' surname='Aggarwal' fullname='R. Aggarwal'><organization /></author>
10<author initials='S.' surname='Shaffer' fullname='S. Shaffer'><organization /></author>
11<date year='2016' month='February' />
12<abstract><t>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain.  This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities.  The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose.  In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique LSA type function code.  In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).  This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.</t></abstract>
13</front>
14<seriesInfo name='RFC' value='7770'/>
15<seriesInfo name='DOI' value='10.17487/RFC7770'/>
16</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8362' target='https://www.rfc-editor.org/info/rfc8362'>
4<front>
5<title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
6<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></author>
7<author initials='A.' surname='Roy' fullname='A. Roy'><organization /></author>
8<author initials='D.' surname='Goethals' fullname='D. Goethals'><organization /></author>
9<author initials='V.' surname='Reddy Vallem' fullname='V. Reddy Vallem'><organization /></author>
10<author initials='F.' surname='Baker' fullname='F. Baker'><organization /></author>
11<date year='2018' month='April' />
12<abstract><t>OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340.  Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs.  This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs.  Backward-compatibility mechanisms are also described.</t><t>This document updates RFC 5340, &quot;OSPF for IPv6&quot;, and RFC 5838, &quot;Support of Address Families in OSPFv3&quot;, by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.</t></abstract>
13</front>
14<seriesInfo name='RFC' value='8362'/>
15<seriesInfo name='DOI' value='10.17487/RFC8362'/>
16</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7684' target='https://www.rfc-editor.org/info/rfc7684'>
4<front>
5<title>OSPFv2 Prefix/Link Attribute Advertisement</title>
6<author initials='P.' surname='Psenak' fullname='P. Psenak'><organization /></author>
7<author initials='H.' surname='Gredler' fullname='H. Gredler'><organization /></author>
8<author initials='R.' surname='Shakir' fullname='R. Shakir'><organization /></author>
9<author initials='W.' surname='Henderickx' fullname='W. Henderickx'><organization /></author>
10<author initials='J.' surname='Tantsura' fullname='J. Tantsura'><organization /></author>
11<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></author>
12<date year='2015' month='November' />
13<abstract><t>OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328.  This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links.  Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs.  The OSPFv2 Opaque LSAs are optional and fully backward compatible.</t></abstract>
14</front>
15<seriesInfo name='RFC' value='7684'/>
16<seriesInfo name='DOI' value='10.17487/RFC7684'/>
17</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC3031' target='https://www.rfc-editor.org/info/rfc3031'>
4<front>
5<title>Multiprotocol Label Switching Architecture</title>
6<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></author>
7<author initials='A.' surname='Viswanathan' fullname='A. Viswanathan'><organization /></author>
8<author initials='R.' surname='Callon' fullname='R. Callon'><organization /></author>
9<date year='2001' month='January' />
10<abstract><t>This document specifies the architecture for Multiprotocol Label Switching (MPLS).  [STANDARDS-TRACK]</t></abstract>
11</front>
12<seriesInfo name='RFC' value='3031'/>
13<seriesInfo name='DOI' value='10.17487/RFC3031'/>
14</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8402' target='https://www.rfc-editor.org/info/rfc8402'>
4<front>
5<title>Segment Routing Architecture</title>
6<author initials='C.' surname='Filsfils' fullname='C. Filsfils' role='editor'><organization /></author>
7<author initials='S.' surname='Previdi' fullname='S. Previdi' role='editor'><organization /></author>
8<author initials='L.' surname='Ginsberg' fullname='L. Ginsberg'><organization /></author>
9<author initials='B.' surname='Decraene' fullname='B. Decraene'><organization /></author>
10<author initials='S.' surname='Litkowski' fullname='S. Litkowski'><organization /></author>
11<author initials='R.' surname='Shakir' fullname='R. Shakir'><organization /></author>
12<date year='2018' month='July' />
13<abstract><t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called &quot;segments&quot;.  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>
14</front>
15<seriesInfo name='RFC' value='8402'/>
16<seriesInfo name='DOI' value='10.17487/RFC8402'/>
17</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference anchor='I-D.ietf-pce-segment-routing'>
4<front>
5<title>PCEP Extensions for Segment Routing</title>
6
7<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
8    <organization />
9</author>
10
11<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
12    <organization />
13</author>
14
15<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
16    <organization />
17</author>
18
19<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
20    <organization />
21</author>
22
23<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
24    <organization />
25</author>
26
27<date month='October' day='13' year='2018' />
28
29<abstract><t>Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE).  It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs).  A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE).  This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks.</t></abstract>
30
31</front>
32
33<seriesInfo name='Internet-Draft' value='draft-ietf-pce-segment-routing-14' />
34<format type='TXT'
35        target='http://www.ietf.org/internet-drafts/draft-ietf-pce-segment-routing-14.txt' />
36</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference anchor='I-D.ietf-idr-bgp-ls-segment-routing-msd'>
4<front>
5<title>Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State</title>
6
7<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
8    <organization />
9</author>
10
11<author initials='U' surname='Chunduri' fullname='Uma Chunduri'>
12    <organization />
13</author>
14
15<author initials='G' surname='Mirsky' fullname='Gregory Mirsky'>
16    <organization />
17</author>
18
19<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
20    <organization />
21</author>
22
23<date month='August' day='13' year='2018' />
24
25<abstract><t>This document defines a way for a Border Gateway Protocol Link-State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity.  Such advertisements allow logically centralized entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network.</t></abstract>
26
27</front>
28
29<seriesInfo name='Internet-Draft' value='draft-ietf-idr-bgp-ls-segment-routing-msd-02' />
30<format type='TXT'
31        target='http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ls-segment-routing-msd-02.txt' />
32</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference anchor='I-D.ietf-ospf-mpls-elc'>
4<front>
5<title>Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF</title>
6
7<author initials='X' surname='Xu' fullname='Xiaohu Xu'>
8    <organization />
9</author>
10
11<author initials='S' surname='Kini' fullname='Sriganesh Kini'>
12    <organization />
13</author>
14
15<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
16    <organization />
17</author>
18
19<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
20    <organization />
21</author>
22
23<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
24    <organization />
25</author>
26
27<date month='September' day='24' year='2018' />
28
29<abstract><t>Multiprotocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL).  An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it has the capability of processing ELs, referred to as Entropy Label Capability (ELC), on that tunnel.  In addition, it would be useful for ingress LSRs to know each LSR's capability of reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD), in the cases where stacked LSPs are used for whatever reasons.  This document defines mechanisms to signal these two capabilities using OSPF.  These mechanisms are useful when the label advertisement is also done via OSPF.  In addition, this document introduces the Non-IGP Functional Capabilities TLV for advertising OSPF router's actual non-IGP functional capabilities.  ELC is one of such non-IGP functional capabilities.</t></abstract>
30
31</front>
32
33<seriesInfo name='Internet-Draft' value='draft-ietf-ospf-mpls-elc-07' />
34<format type='TXT'
35        target='http://www.ietf.org/internet-drafts/draft-ietf-ospf-mpls-elc-07.txt' />
36</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7752' target='https://www.rfc-editor.org/info/rfc7752'>
4<front>
5<title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
6<author initials='H.' surname='Gredler' fullname='H. Gredler' role='editor'><organization /></author>
7<author initials='J.' surname='Medved' fullname='J. Medved'><organization /></author>
8<author initials='S.' surname='Previdi' fullname='S. Previdi'><organization /></author>
9<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
10<author initials='S.' surname='Ray' fullname='S. Ray'><organization /></author>
11<date year='2016' month='March' />
12<abstract><t>In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information.  This is information typically distributed by IGP routing protocols within the network.</t><t>This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol.  This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format.  The mechanism is applicable to physical and virtual IGP links.  The mechanism described is subject to policy control.</t><t>Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t></abstract>
13</front>
14<seriesInfo name='RFC' value='7752'/>
15<seriesInfo name='DOI' value='10.17487/RFC7752'/>
16</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC6863' target='https://www.rfc-editor.org/info/rfc6863'>
4<front>
5<title>Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide</title>
6<author initials='S.' surname='Hartman' fullname='S. Hartman'><organization /></author>
7<author initials='D.' surname='Zhang' fullname='D. Zhang'><organization /></author>
8<date year='2013' month='March' />
9<abstract><t>This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the &quot;Keying and Authentication for                     Routing Protocols (KARP) Design Guidelines&quot; (RFC 6518).  Key components of solutions to gaps identified in this document are already underway.</t></abstract>
10</front>
11<seriesInfo name='RFC' value='6863'/>
12<seriesInfo name='DOI' value='10.17487/RFC6863'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7474' target='https://www.rfc-editor.org/info/rfc7474'>
4<front>
5<title>Security Extension for OSPFv2 When Using Manual Key Management</title>
6<author initials='M.' surname='Bhatia' fullname='M. Bhatia'><organization /></author>
7<author initials='S.' surname='Hartman' fullname='S. Hartman'><organization /></author>
8<author initials='D.' surname='Zhang' fullname='D. Zhang'><organization /></author>
9<author initials='A.' surname='Lindem' fullname='A. Lindem' role='editor'><organization /></author>
10<date year='2015' month='April' />
11<abstract><t>The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying.  Additionally, the existing cryptographic authentication mechanism does not cover the IP header.  This omission can be exploited to carry out various types of attacks.</t><t>This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets.  Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.</t></abstract>
12</front>
13<seriesInfo name='RFC' value='7474'/>
14<seriesInfo name='DOI' value='10.17487/RFC7474'/>
15</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC4552' target='https://www.rfc-editor.org/info/rfc4552'>
4<front>
5<title>Authentication/Confidentiality for OSPFv3</title>
6<author initials='M.' surname='Gupta' fullname='M. Gupta'><organization /></author>
7<author initials='N.' surname='Melam' fullname='N. Melam'><organization /></author>
8<date year='2006' month='June' />
9<abstract><t>This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header.  [STANDARDS-TRACK]</t></abstract>
10</front>
11<seriesInfo name='RFC' value='4552'/>
12<seriesInfo name='DOI' value='10.17487/RFC4552'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7166' target='https://www.rfc-editor.org/info/rfc7166'>
4<front>
5<title>Supporting Authentication Trailer for OSPFv3</title>
6<author initials='M.' surname='Bhatia' fullname='M. Bhatia'><organization /></author>
7<author initials='V.' surname='Manral' fullname='V. Manral'><organization /></author>
8<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></author>
9<date year='2014' month='March' />
10<abstract><t>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets.  This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)).  In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used.  This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.</t><t>The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.</t></abstract>
11</front>
12<seriesInfo name='RFC' value='7166'/>
13<seriesInfo name='DOI' value='10.17487/RFC7166'/>
14</reference>
  • <?xml version="1.0" encoding="US-ASCII"?>
  • <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
  • <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  • <?rfc strict="yes" ?>
  • <?rfc toc="yes"?>
  • <?rfc tocdepth="4"?>
  • <?rfc symrefs="yes"?>
  • <?rfc sortrefs="yes" ?>
  • <?rfc compact="yes" ?>
  • <?rfc subcompact="no" ?>
  • <rfc category="std" docName="draft-ietf-ospf-segment-routing-msd-25" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" {http://www.w3.org/XML/1998/namespace}lang="en" number="8476" consensus="yes">
    • <front>
      • <title abbrev="" "Signaling MSD Using OSPF" >
        • Signaling MSD (Maximum Maximum SID Depth) using Depth (MSD) Using OSPF
        • </title>
      • <author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
        • <organization>
          • Apstra, Inc.
          • </organization>
        • <address>
          • <email>
            • jefftant.ietf@gmail.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
        • <organization>
          • Huawei Technologies
          • </organization>
        • <address>
          • <email>
            • uma.chunduri@huawei.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Sam Aldrin" initials="S.A." surname="Aldrin">
        • <organization>
          • Google, Inc Inc.
          • </organization>
        • <address>
          • <email>
            • aldrin.ietf@gmail.com
            • </email>
          • </address>
        • </author>
      • <author fullname="Peter Psenak" initials="P.P." surname="Psenak">
        • <organization>
          • Cisco Systems
          • </organization>
        • <address>
          • <email>
            • ppsenak@cisco.com
            • </email>
          • </address>
        • </author>
      • <date day="17" month="October" "December" year="2018"/>
      • <area>
        • Routing
        • </area>
      • <workgroup>
        • OSPF Working Group
        • </workgroup>
      • <keyword>
        • Internet-Draft
        • </keyword>
      • <keyword>
        • BGP-LS
        • </keyword>
      • <keyword>
        • SID
        • </keyword>
      • <keyword>
        • MSDMSD
        • </keyword>
      • <keyword>
        • OSPF
        • </keyword>
      • <abstract>
        • <t>
          • This document defines a way for an Open Shortest Path First (OSPF) Router router to advertise multiple types of supported Maximum SID(Segment Identifier) SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID Segment Identifier (SID) stack can be supported in a given network. This document defines only one type of MSD, refers to the Signaling MSD as defined in RFC 8491, but it defines an encoding that can support other MSD types. Here Here, the term OSPF "OSPF" means both OSPFv2 and OSPFv3.
          • </t>
        • </abstract>
      • </front>
    • <middle>
      • <section title="Introduction" numbered="true" toc="default">
        • <t>
          • When Segment Routing (SR) paths are computed by a centralized controller, it is critical that the controller learns learn the Maximum SID (Segment Identifier) Depth (MSD) that can be imposed at each node/link on a given SR path to ensure path. This ensures that the Segment Identifier (SID) stack depth of a computed path doesn't exceed the number of SIDs the node is capable of imposing.
          • </t>
        • <t>
          • <xref target="I-D.ietf-pce-segment-routing" "PCEP-EXT" format="default" pageno="false"/> defines how to signal MSD in the Path Computation Element communication Communication Protocol (PCEP). However, if PCEP is not supported/configured on the head-end of an SR tunnel or a Binding-SID anchor node node, and the controller does not participate in IGP routing, it has no way to learn of learning the MSD of nodes and links. BGP-LS BGP‑LS (Distribution of Link-State and TE Information using Border Gateway Protocol) Using BGP) <xref target="RFC7752" format="default" pageno="false"/> defines a way to expose topology and associated attributes and capabilities of the nodes in that topology to a centralized controller. MSD signaling by BGP-LS has been defined in <xref target="I-D.ietf-idr-bgp-ls-segment-routing-msd" "MSD-BGP" format="default" pageno="false"/>. Typically, BGP-LS is configured on a small number of nodes that do not necessarily act as head-ends. In order for BGP-LS to signal MSD for all the nodes and links in the network for which MSD is relevant, MSD capabilities SHOULD be advertised by every OSPF router in the network.
          • </t>
        • <t>
          • Other types of MSD MSDs are known to be useful. For example, <xref target="I-D.ietf-ospf-mpls-elc" "ELC-ISIS" format="default" pageno="false"/> defines Entropy Readable Label Depth Capability (RLDC) that (ERLD), which is used by a head-end head‑end to insert an Entropy Label (EL) at a depth that could where it can be read by transit nodes.
          • </t>
        • <t>
          • This document defines an extension to OSPF used to advertise one or more types of MSD MSDs at node and/or link granularity. In the future future, it is expected, expected that new MSD-types MSD-Types will be defined to signal additional capabilities capabilities, e.g., entropy labels, ELs, SIDs that can be imposed through recirculation, or SIDs associated with another dataplane e.g., data plane such as IPv6.
          • </t>
        • <t>
          • MSD advertisements MAY be useful even if Segment Routing SR itself is not enabled. For example, in a non-SR MPLS network, MSD defines the maximum label depth.
          • </t>
        • <section title="Terminology" numbered="true" toc="default">
          • <t>
            • This memo makes use of the terms defined in <xref target="RFC7770" format="default" pageno="false"/> "false"/>.
            • </t>
          • <t>
            • <list style="hanging" hangIndent="9">
              • <t hangText="BGP-LS:">
                • BGP-LS: Distribution of Link-State and TE Information using Border Gateway Protocol Using BGP
                • </t>
              • <t hangText="OSPF:">
                • OSPF: Open Shortest Path First
                • </t>
              • <t hangText="MSD:">
                • MSD: Maximum SID Depth - the number of SIDs supported by a node or a link on a node
                • </t>
              • <t hangText="SID:">
                • SID: Segment Identifier as defined in <xref target="RFC8402" format="default" pageno="false"/>
                • </t>
              • <t>
                • Label Imposition: Imposition is the act of modifying and/or adding labels to the outgoing label stack associated with a packet. This includes:
                • </t>
              • <t hangText="Label Imposition:">
                • Imposition is the act of modifying and/or adding labels to the outgoing label stack associated with a packet. This includes:
                • <list style="symbols">
                  • <t>
                    • replacing the label at the top of the label stack with a new label
                    • </t>
                  • <t>
                    • pushing one or more new labels onto the label stack
                    • </t>
                  • </list>
                • </t>
              • </list>
            • </t>
          • <t>
            • The number of labels imposed is then the sum of the number of labels which that are replaced and the number of labels which that are pushed. See <xref target="RFC3031" format="default" pageno="false"/> for further details.
            • </t>
          • <t>
            • PCC: Path Computation Client
            • </t>
          • <t>
            • PCE: Path Computation Element
            • </t>
          • <t>
            • <list style="hanging" hangIndent="9">
              • <t hangText="PCEP:">
                • PCEP: Path Computation Element Communication Protocol
                • </t>
              • <t hangText="SR:">
                • SR: Segment Routing
                • </t>
              • <t>
                • SID: Segment Identifier
                • </t>
              • <t hangText="LSA:">
                • LSA: Link state advertisement State Advertisement
                • </t>
              • <t hangText="RI:">
                • RI: OSPF Router Information LSA
                • </t>
              • </list>
            • </t>
          • </section>
        • <section title="Requirements Language" numbered="true" toc="default">
          • <t>
            • The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL   NOT", "SHOULD", "SHOULD   NOT", "RECOMMENDED", "NOT   RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP   14 <xref target="RFC2119" format="default" pageno="false"/> <xref target="RFC8174" format="default" pageno="false"/> when, and only when, they appear in all capitals, as shown here.
            • </t>
          • </section>
        • </section>
      • <section anchor="NODE_LEVEL" title="Node MSD Advertisement" numbered="true" toc="default">
        • <t>
          • The node Node MSD TLV within the body of the OSPF RI Opaque LSA <xref target="RFC7770" format="default" pageno="false"/> is defined to carry the provisioned SID depth of the router originating the RI LSA. Node MSD is the smallest MSD supported by the node on the set of interfaces configured for use by the advertising IGP instance. MSD values may be learned via a hardware API or may be provisioned.
          • </t>
        • <figure align="center" anchor="Node_MSD_TLV" title="Node MSD TLV" suppress-title="false" alt="" width="" height="">
          • <preamble/>
          • <artwork align="left" {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" alt="" width="" height="">

            •                       0                   1                   2                   3
                                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    Type                       |  Length                       |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... | 
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        
            • </artwork>
          • <postamble/>
          • </figure>
        • <t>
          • Type: 12
          • </t>
        • <t>
          • Length: variable (multiple of 2 octets) and octets); represents the total length of the value field in octets.
          • </t>
        • <t>
          • Value: consists of one or more pairs of a 1 octet MSD-type 1‑octet MSD-Type and 1 octet 1‑octet MSD-Value.
          • </t>
        • <t>
          • MSD-Type: one of the values defined in the IGP MSD-Types "IGP MSD-Types" registry defined in <xref target="I-D.ietf-isis-segment-routing-msd" "RFC8491" format="default" pageno="false"/>.
          • </t>
        • <t>
          • MSD-Value: a number in the range of 0-255. For all MSD-Types, 0 represents the lack of the ability to impose an MSD stack of any depth; any other value represents that of the node. This value MUST represent the lowest value supported by any link configured for use by the advertising OSPF instance.
          • </t>
        • <t>
          • This TLV is applicable to OSPFv2 and optional and is applicable to OSPFv3 both OSPFv2 and is optional. OSPFv3. The scope of the advertisement is specific to the deployment.
          • </t>
        • <t>
          • When multiple Node MSD TLVs are received from a given router, the receiver MUST use the first occurrence of the TLV in the Router Information (RI) LSA. If the Node MSD TLV appears in multiple Router Information RI LSAs that have different flooding scopes, the Node MSD TLV in the Router Information RI LSA with the area-scoped flooding scope MUST be used. If the Node MSD TLV appears in multiple Router Information RI LSAs that have the same flooding scope, the Node MSD TLV in the Router Information (RI) RI LSA with the numerically smallest Instance ID MUST be used and other instances of the Node MSD TLV MUST be ignored. The RI LSA can be advertised at any of the defined opaque flooding scopes (link, area, or Autonomous System (AS)). For the purpose of Node MSD TLV advertisement, area-scoped flooding is RECOMMENDED.
          • </t>
        • </section>
      • <section anchor="LINK_LEVEL" title="Link MSD sub-TLV" Sub-TLV" numbered="true" toc="default">
        • <t>
          • The link Link MSD sub-TLV is defined to carry the MSD of the interface associated with the link. MSD values may be learned via a hardware API or may be provisioned.
          • </t>
        • <figure align="center" anchor="Link_MSD_sub_TLV" title="Link MSD Sub-TLV" suppress-title="false" alt="" width="" height="">
          • <preamble/>
          • <artwork align="left" {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" alt="" width="" height="">

            •
                      0                   1                   2                   3
                                    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    Type                       |  Length                       |
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... | 
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                        
            • </artwork>
          • <postamble/>
          • </figure>
        • <t>
          • Type:
          • </t>
        • <t>
          • <list>
            • <t>
              • For OSPFv2, the Link level link-level MSD-Value is advertised as an optional Sub-TLV sub-TLV of the OSPFv2 Extended Link TLV as defined in <xref target="RFC7684" format="default" pageno="false"/>, "false"/> and has a type of 6.
              • </t>
            • <t>
              • For OSPFv3, the Link level link-level MSD-Value is advertised as an optional Sub-TLV sub-TLV of the E-Router-LSA TLV as defined in <xref target="RFC8362" format="default" pageno="false"/>, "false"/> and has a type of 9.
              • </t>
            • </list>
          • </t>
        • <t>
          • Length: variable and variable; same as defined in <xref target="NODE_LEVEL" format="default" pageno="false"></xref>.
          • </t>
        • <t>
          • Value: consists of one or more pairs of a 1 octet MSD-type 1‑octet MSD-Type and 1 octet 1‑octet MSD-Value.
          • </t>
        • <t>
          • MSD-Type: one of the values defined in the MSD-Types "IGP MSD-Types" registry defined in <xref target="I-D.ietf-isis-segment-routing-msd" "RFC8491" format="default" pageno="false"/>.
          • </t>
        • <t>
          • The MSD-Value field contains the Link MSD of the router originating the corresponding LSA as specified for OSPFv2 and OSPFv3. The Link MSD is a number in the range of 0-255. For all MSD-Types, 0 represents the lack of the ability to impose an MSD stack of any depth; any other value represents that of the particular link when used as an outgoing interface.
          • </t>
        • <t>
          • If this sub-TLV is advertised multiple times in the same OSPFv2 Extended Link Opaque LSA/E-Router-LSA, only the first instance of the TLV MUST be used by receiving OSPF routers. This situation SHOULD be logged as an error.
          • </t>
        • <t>
          • If this sub-TLV is advertised multiple times for the same link in different OSPF Extended Link Opaque LSAs/E-Router-LSAs LSAs / E-Router-LSAs originated by the same OSPF router, the OSPFv2 Extended Link TLV sub-TLV in the OSPFv2 Extended Link Opaque LSA with the smallest Opaque ID or in the OSPFv3 E-Router-LSA with the smallest Link State ID MUST be used by receiving OSPF routers. This situation MAY SHOULD be logged as a warning. an error.
          • </t>
        • </section>
      • <section anchor="Confict_resolution" title="Procedures for Defining and Using Node and Link MSD Advertisements" numbered="true" toc="default">
        • <t>
          • When Link MSD is present for a given MSD-type, MSD-Type, the value of the Link MSD MUST take precedence over the Node MSD. When a Link MSD-type MSD‑Type is not signaled but the Node MSD-type MSD-Type is, then the Node MSD-type MSD‑Type value MUST be considered as the MSD value for that link.
          • </t>
        • <t>
          • In order to increase flooding efficiency, it is RECOMMENDED that routers with homogenous link Link MSD values advertise just the Node MSD value.
          • </t>
        • <t>
          • The meaning of the absence of both Node and Link MSD advertisements for a given MSD-type MSD-Type is specific to the MSD-type. Generally MSD-Type. Generally, it can only be inferred that the advertising node does not support advertisement of that MSD-type. MSD-Type. However, in some cases the lack of advertisement might imply that the functionality associated with the MSD-type MSD-Type is not supported. The Per <xref target="RFC8491" format="default" pageno="false"/>, the correct interpretation MUST be specified when an MSD-type MSD-Type is defined in <xref target="I-D.ietf-isis-segment-routing-msd" format="default" pageno="false"/>. defined.
          • </t>
        • <---->
        • </section>
      • <---->
      • <section anchor="IANA" title="IANA Considerations" numbered="true" toc="default">
        • <t>
          • This specification updates several existing OSPF registries.
          • </t>
        • <t>
          • IANA has allocated TLV type 12 from the OSPF "OSPF Router Information (RI) TLVs Registry TLVs" registry as defined by <xref target="RFC7770" format="default" pageno="false"/>.
          • <figure align="center" anchor="Node_MSD" title="RI Node MSD" suppress-title="false" alt="" width="" height="">
            • <preamble/>
            • <artwork align="left" {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" alt="" width="" height="">

              •
                   Value     Description                      Reference
                   -----     ---------------                  -------------
                   12        Node MSD                         This document

                          
              • </artwork>
            • <postamble/>
            • </figure>
          • IANA has allocated sub-TLV type 6 from the OSPFv2 "OSPFv2 Extended Link TLV Sub-TLVs Sub-TLVs" registry.
          • <figure align="center" anchor="OSPFv2_Link_MSD" title="OSPFv2 Link MSD" suppress-title="false" alt="" width="" height="">
            • <preamble/>
            • <artwork align="left" {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" alt="" width="" height="">

              •
                   Value     Description                      Reference
                   -----     ---------------                  -------------
                   6         OSPFv2 Link MSD                                    This document

                          
              • </artwork>
            • <postamble/>
            • </figure>
          • IANA has allocated sub-TLV type 9 from the OSPFv3 "OSPFv3 Extended-LSA Sub-TLV Sub‑TLVs" registry.
          • <figure align="center" anchor="OSPFv3_Link_MSD" title="OSPFv3 Link MSD" suppress-title="false" alt="" width="" height="">
            • <preamble/>
            • <artwork align="left" {http://www.w3.org/XML/1998/namespace}space="preserve" name="" type="" alt="" width="" height="">

              •
                   Value     Description                      Reference
                   -----     ---------------                  -------------
                   9         OSPFv3 Link MSD                  This document

                          
              • </artwork>
            • <postamble/>
            • </figure>
          • </t>
        • </section>
      • <section anchor="Security" title="Security Considerations" numbered="true" toc="default">
        • <t>
          • Security concerns for OSPF are addressed in <xref target="RFC7474" format="default" pageno="false"/>, <xref target="RFC4552" format="default" pageno="false"/> "false"/>, and <xref target="RFC7166" format="default" pageno="false"/>. Further security analysis for the OSPF protocol is done in <xref target="RFC6863" format="default" pageno="false"/>. Security considerations, considerations as specified by <xref target="RFC7770" format="default" pageno="false"/>, <xref target="RFC7684" format="default" pageno="false"/> "false"/>, and <xref target="RFC8362" format="default" pageno="false"/> are applicable to this document.
          • </t>
        • <t>
          • Implementations MUST assure ensure that malformed TLV TLVs and Sub-TLV sub-TLVs defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPF router or routing process. Reception of malformed TLV TLVs or Sub-TLV sub-TLVs SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs sub-TLVs SHOULD be rate-limited rate‑limited to prevent a Denial of Service Denial-of-Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane.
          • </t>
        • <t>
          • Advertisement of an incorrect MSD value may have negative consequences. If the value is smaller than supported, path computation may fail to compute a viable path. If the value is larger than supported, an attempt to instantiate a path that can't be supported by the head-end (the node performing the SID imposition) may occur.
          • </t>
        • <t>
          • The presence of this information may also may inform an attacker of how to induce any of the aforementioned conditions.
          • </t>
        • <t>
          • There's no Denial of Service DoS risk specific to this extension, and it is not vulnerable to replay attacks.
          • </t>
        • <---->
        • </section>
      • <section anchor="Contributors" title="Contributors" numbered="true" toc="default">
        • <t>
          • The following people contributed to this document:
          • </t>
        • <t>
          • Les Ginsberg
          • </t>
        • <t>
          • Email: ginsberg@cisco.com
          • </t>
        • </section>
      • <section anchor="Acknowledgments" title="Acknowledgments" numbered="true" toc="default">
        • <t>
          • The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal Mizrahi, Stephane Litkowski and Bruno Decraene for their reviews and valuable comments.
          • </t>
        • <---->
        • </section>
      • </middle>
    • <back>
      • <references title="Normative References">
        • <reference anchor="I-D.ietf-isis-segment-routing-msd" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
              • Signaling MSD (Maximum SID Depth) using IS-IS
              • </title>
            • <author initials="J" surname="Tantsura" fullname="Jeff Tantsura" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
              • </author>
            • <author initials="U" surname="Chunduri" fullname="Uma Chunduri" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
              • </author>
            • <author initials="S" surname="Aldrin" fullname="Sam Aldrin" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
              • </author>
            • <author initials="L" surname="Ginsberg" fullname="Les Ginsberg" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
              • </author>
            • <date month="October" day="9" year="2018" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml">
                • This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular SID (Segment ID) stack can be supported in a given network. This document only defines one type of MSD (Base MPLS Imposition), but defines an encoding that can support other MSD types. This document focuses on MSD use in a Segment Routing enabled network, but MSD may also be useful when Segment Routing is not enabled.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="Internet-Draft" value="draft-ietf-isis-segment-routing-msd-19" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
          • <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-isis-segment-routing-msd-19.txt" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-isis-segment-routing-msd.xml"/>
          • </reference>
        • <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml">
              • Key words for use in RFCs to Indicate Requirement Levels
              • </title>
            • <author initials="S." surname="Bradner" fullname="S. Bradner" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml"/>
              • </author>
            • <date year="1997" month="March" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml">
                • 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="BCP" value="14" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml"/>
          • <seriesInfo name="RFC" value="2119" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC2119" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.2119.xml"/>
          • </reference>
        • <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml">
              • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
              • </title>
            • <author initials="B." surname="Leiba" fullname="B. Leiba" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml"/>
              • </author>
            • <date year="2017" month="May" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml">
                • 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>
            • </front>
          • <seriesInfo name="BCP" value="14" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml"/>
          • <seriesInfo name="RFC" value="8174" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC8174" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8174.xml"/>
          • </reference>
        • <reference anchor="RFC7770" target="https://www.rfc-editor.org/info/rfc7770" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • Extensions to OSPF for Advertising Optional Router Capabilities
              • </title>
            • <author initials="A." surname="Lindem" fullname="A. Lindem" role="editor" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
              • </author>
            • <author initials="N." surname="Shen" fullname="N. Shen" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
              • </author>
            • <author initials="JP." surname="Vasseur" fullname="JP. Vasseur" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
              • </author>
            • <author initials="R." surname="Aggarwal" fullname="R. Aggarwal" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
              • </author>
            • <author initials="S." surname="Shaffer" fullname="S. Shaffer" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
              • </author>
            • <date year="2016" month="February" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml">
                • It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7770" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7770" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7770.xml"/>
          • </reference>
        • <reference anchor="RFC8362" target="https://www.rfc-editor.org/info/rfc8362" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • OSPFv3 Link State Advertisement (LSA) Extensibility
              • </title>
            • <author initials="A." surname="Lindem" fullname="A. Lindem" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
              • </author>
            • <author initials="A." surname="Roy" fullname="A. Roy" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
              • </author>
            • <author initials="D." surname="Goethals" fullname="D. Goethals" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
              • </author>
            • <author initials="V." surname="Reddy Vallem" fullname="V. Reddy Vallem" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
              • </author>
            • <author initials="F." surname="Baker" fullname="F. Baker" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
              • </author>
            • <date year="2018" month="April" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
                • OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described.
                • </t>
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml">
                • This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="8362" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC8362" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8362.xml"/>
          • </reference>
        • <reference anchor="RFC7684" target="https://www.rfc-editor.org/info/rfc7684" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • OSPFv2 Prefix/Link Attribute Advertisement
              • </title>
            • <author initials="P." surname="Psenak" fullname="P. Psenak" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
              • </author>
            • <author initials="H." surname="Gredler" fullname="H. Gredler" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
              • </author>
            • <author initials="R." surname="Shakir" fullname="R. Shakir" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
              • </author>
            • <author initials="W." surname="Henderickx" fullname="W. Henderickx" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
              • </author>
            • <author initials="J." surname="Tantsura" fullname="J. Tantsura" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
              • </author>
            • <author initials="A." surname="Lindem" fullname="A. Lindem" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
              • </author>
            • <date year="2015" month="November" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml">
                • OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328. This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links. Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs. The OSPFv2 Opaque LSAs are optional and fully backward compatible.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7684" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7684" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7684.xml"/>
          • </reference>
        • <reference anchor="RFC3031" target="https://www.rfc-editor.org/info/rfc3031" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
              • Multiprotocol Label Switching Architecture
              • </title>
            • <author initials="E." surname="Rosen" fullname="E. Rosen" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml"/>
              • </author>
            • <author initials="A." surname="Viswanathan" fullname="A. Viswanathan" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml"/>
              • </author>
            • <author initials="R." surname="Callon" fullname="R. Callon" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml"/>
              • </author>
            • <date year="2001" month="January" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml">
                • This document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="3031" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC3031" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.3031.xml"/>
          • </reference>
        • <reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • Segment Routing Architecture
              • </title>
            • <author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
              • </author>
            • <author initials="S." surname="Previdi" fullname="S. Previdi" role="editor" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
              • </author>
            • <author initials="L." surname="Ginsberg" fullname="L. Ginsberg" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
              • </author>
            • <author initials="B." surname="Decraene" fullname="B. Decraene" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
              • </author>
            • <author initials="S." surname="Litkowski" fullname="S. Litkowski" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
              • </author>
            • <author initials="R." surname="Shakir" fullname="R. Shakir" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
              • </author>
            • <date year="2018" month="July" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
                • 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 {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
                • 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 {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml">
                • 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>
            • </front>
          • <seriesInfo name="RFC" value="8402" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC8402" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8402.xml"/>
          • </reference>
        • <reference anchor="RFC8491" target="https://www.rfc-editor.org/info/rfc8491" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
              • Signaling Maximum SID Depth (MSD) Using IS-IS
              • </title>
            • <author initials="J." surname="Tantsura" fullname="J. Tantsura" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
              • </author>
            • <author initials="U." surname="Chunduri" fullname="U. Chunduri" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
              • </author>
            • <author initials="S." surname="Aldrin" fullname="S. Aldrin" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
              • </author>
            • <author initials="L." surname="Ginsberg" fullname="L. Ginsberg" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
              • </author>
            • <date year="2018" month="November" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml">
                • This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network. This document only defines one type of MSD: Base MPLS Imposition. However, it defines an encoding that can support other MSD types. This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="8491" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC8491" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.8491.xml"/>
          • </reference>
        • <---->
        • </references>
      • <references title="Informative References">
        • <-- draft-ietf-pce-segment-routing (Waiting for Writeup) -->
        • <reference anchor="I-D.ietf-pce-segment-routing" "PCEP-EXT" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • PCEP Extensions for Segment Routing
              • </title>
            • <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
              • </author>
            • <author initials="C" surname="Filsfils" fullname="Clarence Filsfils" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
              • </author>
            • <author initials="J" surname="Tantsura" fullname="Jeff Tantsura" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
              • </author>
            • <author initials="W" surname="Henderickx" fullname="Wim Henderickx" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
              • </author>
            • <author initials="J" surname="Hardwick" fullname="Jonathan Hardwick" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
              • </author>
            • <date month="October" day="13" year="2018" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml">
                • Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by Link- State Interior Gateway Protocols (IGPs). A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic Engineering (TE) paths, as well as a PCC to request a path subject to certain constraints and optimization criteria in SR networks.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="Internet-Draft" "Work in Progress," value="draft-ietf-pce-segment-routing-14" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
          • <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-pce-segment-routing-14.txt" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-pce-segment-routing.xml"/>
          • </reference>
        • <-- draft-ietf-idr-bgp-ls-segment-routing-msd (I-D Exists) -->
        • <reference anchor="I-D.ietf-idr-bgp-ls-segment-routing-msd" "MSD-BGP" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
              • Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State
              • </title>
            • <author initials="J" surname="Tantsura" fullname="Jeff Tantsura" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
              • </author>
            • <author initials="U" surname="Chunduri" fullname="Uma Chunduri" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
              • </author>
            • <author initials="G" surname="Mirsky" fullname="Gregory Mirsky" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
              • </author>
            • <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
              • </author>
            • <date month="August" day="13" year="2018" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml">
                • This document defines a way for a Border Gateway Protocol Link-State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow logically centralized entities (e.g., centralized controllers) to determine whether a particular SID stack can be supported in a given network.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="Internet-Draft" "Work in Progress," value="draft-ietf-idr-bgp-ls-segment-routing-msd-02" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
          • <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ls-segment-routing-msd-02.txt" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-msd.xml"/>
          • </reference>
        • <-- draft-ietf-ospf-mpls-elc (I-D Exists) -->
        • <reference anchor="I-D.ietf-ospf-mpls-elc" "ELC-ISIS" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF
              • </title>
            • <author initials="X" surname="Xu" fullname="Xiaohu Xu" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
              • </author>
            • <author initials="S" surname="Kini" fullname="Sriganesh Kini" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
              • </author>
            • <author initials="S" surname="Sivabalan" fullname="Siva Sivabalan" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
              • </author>
            • <author initials="C" surname="Filsfils" fullname="Clarence Filsfils" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
              • </author>
            • <author initials="S" surname="Litkowski" fullname="Stephane Litkowski" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
              • </author>
            • <date month="September" day="24" year="2018" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
                • Multiprotocol Label Switching (MPLS) has defined a mechanism to load balance traffic flows using Entropy Labels (EL). An ingress Label Switching Router (LSR) cannot insert ELs for packets going into a given tunnel unless an egress LSR has indicated via signaling that it has the capability of processing ELs, referred to as Entropy Label Capability (ELC), on that tunnel. In addition, it would be useful for ingress LSRs to know each LSR's capability of reading the maximum label stack depth and performing EL-based load-balancing, referred to as Entropy Readable Label Depth (ERLD), in the cases where stacked LSPs are used for whatever reasons. This document defines mechanisms to signal these two capabilities using OSPF. These mechanisms are useful when the label advertisement is also done via OSPF. In addition, this document introduces the Non-IGP Functional Capabilities TLV for advertising OSPF router's actual non-IGP functional capabilities. ELC is one of such non-IGP functional capabilities.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="Internet-Draft" "Work in Progress," value="draft-ietf-ospf-mpls-elc-07" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
          • <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ospf-mpls-elc-07.txt" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml"/>
          • </reference>
        • <reference anchor="RFC7752" target="https://www.rfc-editor.org/info/rfc7752" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
              • </title>
            • <author initials="H." surname="Gredler" fullname="H. Gredler" role="editor" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
              • </author>
            • <author initials="J." surname="Medved" fullname="J. Medved" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
              • </author>
            • <author initials="S." surname="Previdi" fullname="S. Previdi" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
              • </author>
            • <author initials="A." surname="Farrel" fullname="A. Farrel" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
              • </author>
            • <author initials="S." surname="Ray" fullname="S. Ray" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
              • </author>
            • <date year="2016" month="March" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
                • In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
                • </t>
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
                • This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
                • </t>
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml">
                • Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7752" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7752" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7752.xml"/>
          • </reference>
        • <reference anchor="RFC6863" target="https://www.rfc-editor.org/info/rfc6863" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
              • Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide
              • </title>
            • <author initials="S." surname="Hartman" fullname="S. Hartman" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml"/>
              • </author>
            • <author initials="D." surname="Zhang" fullname="D. Zhang" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml"/>
              • </author>
            • <date year="2013" month="March" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml">
                • This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the "Keying and Authentication for Routing Protocols (KARP) Design Guidelines" (RFC 6518). Key components of solutions to gaps identified in this document are already underway.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="6863" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC6863" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.6863.xml"/>
          • </reference>
        • <reference anchor="RFC7474" target="https://www.rfc-editor.org/info/rfc7474" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
              • Security Extension for OSPFv2 When Using Manual Key Management
              • </title>
            • <author initials="M." surname="Bhatia" fullname="M. Bhatia" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
              • </author>
            • <author initials="S." surname="Hartman" fullname="S. Hartman" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
              • </author>
            • <author initials="D." surname="Zhang" fullname="D. Zhang" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
              • </author>
            • <author initials="A." surname="Lindem" fullname="A. Lindem" role="editor" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
              • </author>
            • <date year="2015" month="April" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
                • The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying. Additionally, the existing cryptographic authentication mechanism does not cover the IP header. This omission can be exploited to carry out various types of attacks.
                • </t>
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml">
                • This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets. Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7474" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7474" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7474.xml"/>
          • </reference>
        • <reference anchor="RFC4552" target="https://www.rfc-editor.org/info/rfc4552" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
              • Authentication/Confidentiality for OSPFv3
              • </title>
            • <author initials="M." surname="Gupta" fullname="M. Gupta" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml"/>
              • </author>
            • <author initials="N." surname="Melam" fullname="N. Melam" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml"/>
              • </author>
            • <date year="2006" month="June" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml">
                • This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK]
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="4552" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC4552" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.4552.xml"/>
          • </reference>
        • <reference anchor="RFC7166" target="https://www.rfc-editor.org/info/rfc7166" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
          • <front {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
            • <title {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
              • Supporting Authentication Trailer for OSPFv3
              • </title>
            • <author initials="M." surname="Bhatia" fullname="M. Bhatia" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml"/>
              • </author>
            • <author initials="V." surname="Manral" fullname="V. Manral" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml"/>
              • </author>
            • <author initials="A." surname="Lindem" fullname="A. Lindem" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
              • <organization {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml"/>
              • </author>
            • <date year="2014" month="March" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml"/>
            • <abstract {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
                • Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.
                • </t>
              • <t {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml">
                • The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.
                • </t>
              • </abstract>
            • </front>
          • <seriesInfo name="RFC" value="7166" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml"/>
          • <seriesInfo name="DOI" value="10.17487/RFC7166" {http://www.w3.org/XML/1998/namespace}base="/a/inc-work/refs/bibxml/reference.RFC.7166.xml"/>
          • </reference>
        • <---->
        • </references>
      • <section anchor="Acknowledgements" title="Acknowledgements" numbered="no" toc="default">
        • <t>
          • The authors would like to thank Acee Lindem, Ketan Talaulikar, Tal Mizrahi, Stephane Litkowski, and Bruno Decraene for their reviews and valuable comments.
          • </t>
        • </section>
      • <section anchor="Contributors" title="Contributors" numbered="no" toc="default">
        • <t>
          • The following person contributed to this document:
          • </t>
        • <t>
          • Les Ginsberg
          • </t>
        • <t>
          • Email: ginsberg@cisco.com
          • </t>
        • </section>
      • </back>
    • </rfc>
1<?xml version="1.0" encoding="US-ASCII"?>
2
3<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
4<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
5
6<?rfc strict="yes" ?>
7<?rfc toc="yes"?>
8<?rfc tocdepth="4"?>
9<?rfc symrefs="yes"?>
10<?rfc sortrefs="yes" ?>
11<?rfc compact="yes" ?>
12<?rfc subcompact="no" ?>
13
14<rfc category="std" number="8476" ipr="trust200902"
15     submissionType="IETF" consensus="yes">
16
17  <front>
18    <title abbrev="Signaling MSD Using OSPF">Signaling Maximum SID Depth (MSD) Using OSPF</title>
19
20      <author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
21      <organization>Apstra, Inc.</organization>
22      <address>
23        <email>jefftant.ietf@gmail.com</email>
24      </address>
25    </author>
26
27    <author fullname="Uma Chunduri" initials="U.C." surname="Chunduri">
28      <organization>Huawei Technologies</organization>
29      <address>
30      <email>uma.chunduri@huawei.com</email>
31      </address>
32    </author>
33
34   <author fullname="Sam Aldrin" initials="S.A." surname="Aldrin">
35      <organization>Google, Inc.</organization>
36      <address>
37        <email>aldrin.ietf@gmail.com</email>
38      </address>
39    </author>
40
41    <author fullname="Peter Psenak" initials="P.P." surname="Psenak">
42      <organization>Cisco Systems</organization>
43      <address>
44        <email>ppsenak@cisco.com</email>
45      </address>
46    </author>
47
48    <date month="December" year="2018" />
49
50    <keyword>BGP-LS</keyword>
51    <keyword>SID</keyword>
52    <keyword>MSD</keyword>
53    <keyword>OSPF</keyword>
54
55   <abstract>
56        <t>This document defines a way for an Open Shortest Path First (OSPF)
57 router to advertise multiple
58        types of supported Maximum SID Depths (MSDs) at node and/or link
59        granularity. Such advertisements allow entities (e.g., centralized
60        controllers) to determine whether a particular Segment
61   Identifier (SID) stack can be supported
62        in a given network. This document only refers to the Signaling MSD as
63 defined in RFC 8491, but it defines an encoding that can support
64        other MSD types. Here, the term "OSPF" means both OSPFv2 and OSPFv3.
65        </t>
66
67    </abstract>
68  </front>
69
70  <middle>
71          <section title="Introduction">
72      <t>When Segment Routing (SR) paths are computed by a centralized
73      controller, it is critical that the controller learn the Maximum SID 
74      Depth (MSD) that can be imposed at each node/link on a given SR path.
75      This ensures that the Segment Identifier (SID) stack depth of a computed
76      path doesn't exceed the number of SIDs the node is capable of
77      imposing.</t>
78
79      <t><xref target="PCEP-EXT"/> defines how to signal MSD in the
80      Path Computation Element Communication Protocol (PCEP). However, if PCEP
81      is not supported/configured on the head-end of an SR tunnel or a
82      Binding-SID anchor node, and the controller does not participate in IGP
83      routing, it has no way of learning the MSD of nodes and
84      links. BGP&nbhy;LS (Distribution of Link-State and TE Information Using
85      BGP) <xref target="RFC7752"/> defines a way to
86      expose topology and associated attributes and capabilities of the nodes
87      in that topology to a centralized controller. MSD signaling by BGP-LS
88      has been defined in <xref target="MSD-BGP"/>. Typically, BGP-LS is
89      configured on a small number of nodes that do not necessarily act as
90      head-ends. In order for BGP-LS to signal MSD for all the nodes and links
91      in the network for which MSD is relevant, MSD capabilities SHOULD be
92      advertised by every OSPF router in the network.</t>
93
94      <t>Other types of MSDs are known to be useful. For example,
95      <xref target="ELC-ISIS"/> defines Entropy Readable Label Depth (ERLD),
96      which is used by a head&nbhy;end to insert an Entropy Label (EL) at a
97      depth where it can be read by transit nodes.</t>
98
99      <t>This document defines an extension to OSPF used to advertise one or
100      more types of MSDs at node and/or link granularity.
101      In the future, it is expected that new MSD-Types will be defined to
102      signal additional capabilities, e.g., ELs, SIDs that can be
103      imposed through recirculation, or SIDs associated with another data
104      plane such as IPv6. </t>
105
106      <t>MSD advertisements MAY be useful even if SR itself is
107      not enabled. For example, in a non-SR MPLS network, MSD defines the
108      maximum label depth.</t>
109
110        <section title="Terminology">
111
112  <t>This memo makes use of the terms defined in <xref target="RFC7770"/>.</t>
113
114<t><list style="hanging" hangIndent="9">
115    <t hangText="BGP-LS:">Distribution of Link-State and TE Information Using
116    BGP</t>
117
118    <t hangText="OSPF:">Open Shortest Path First</t>
119
120    <t hangText="MSD:">Maximum SID Depth - the number of SIDs supported by a
121    node or a link on a node</t>
122
123    <t hangText="SID:">Segment Identifier as defined in <xref
124    target="RFC8402"/></t>
125
126    <t hangText="Label Imposition:">Imposition is the act of modifying and/or
127    adding labels to the outgoing label stack associated with a packet. This
128    includes:
129
130        <list style="symbols">
131            <t>replacing the label at the top of the label stack with a new
132            label</t>
133
134            <t>pushing one or more new labels onto the label stack</t>
135        </list></t></list></t>
136
137    <t>The number of labels imposed is then the sum of the number of
138    labels that are replaced and the number of labels that are
139    pushed.  See <xref target="RFC3031"/> for further details.</t>
140
141   <t><list style="hanging" hangIndent="9">
142        <t hangText="PCEP:">Path Computation Element Communication Protocol</t>
143
144        <t hangText="SR:">Segment Routing</t>
145
146        <t hangText="LSA:">Link State Advertisement</t>
147
148        <t hangText="RI:">Router Information</t>
149      </list></t>
150
151        </section>
152
153        <section title="Requirements Language">
154        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
155        "SHALL&nbsp;NOT", "SHOULD", "SHOULD&nbsp;NOT", "RECOMMENDED",
156        "NOT&nbsp;RECOMMENDED", "MAY", and "OPTIONAL" in this document
157        are to be interpreted as described in BCP&nbsp;14
158        <xref target="RFC2119"/> <xref target="RFC8174"/> when,
159        and only when, they appear in all capitals, as shown here.</t>
160    </section>
161    </section>
162    <section anchor="NODE_LEVEL" title="Node MSD Advertisement">
163      <t>The Node MSD TLV within the body of the OSPF RI Opaque LSA <xref
164      target="RFC7770"/> is defined to carry the provisioned SID depth of the
165      router originating the RI LSA. Node MSD is the smallest MSD supported
166      by the node on the set of interfaces configured for use by the
167      advertising IGP instance. MSD values may be learned via a hardware API
168      or may be provisioned.
169      </t>
170      <figure align="center" anchor="Node_MSD_TLV"
171              title="Node MSD TLV">
172          <artwork align="left">
173   0                   1                   2                   3
174   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
175  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
176  |    Type                       |  Length                       |
177  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
178  |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... | 
179  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
180          </artwork>
181  </figure>
182
183      <t>Type: 12</t>
184      <t>Length: variable (multiple of 2 octets); represents the total
185      length of the value field in octets.</t>
186      <t>Value: consists of one or more pairs of a 1&nbhy;octet MSD-Type and
187      1&nbhy;octet MSD-Value.</t>
188      <t>MSD-Type: one of the values defined in the "IGP MSD-Types" registry
189      defined in <xref target="RFC8491"/>.</t>
190      <t>MSD-Value: a number in the range of 0-255. For all MSD-Types, 0
191      represents the lack of ability to impose an MSD stack of any depth; any
192      other value represents that of the node. This value MUST represent the
193      lowest value supported by any link configured for use by the advertising
194      OSPF instance.</t>
195      <t>This TLV is optional and is applicable to both OSPFv2 and OSPFv3.
196      The scope of the advertisement is specific to the deployment.</t>
197         
198      <t>When multiple Node MSD TLVs are received from a given router, the
199        receiver MUST use the first occurrence of the TLV in the Router
200        Information (RI) LSA.  If the Node MSD TLV appears in multiple RI
201        LSAs that have different flooding scopes, the Node
202        MSD TLV in the RI LSA with the area-scoped
203        flooding scope MUST be used.  If the Node MSD TLV appears in
204        multiple RI LSAs that have the same flooding scope,
205        the Node MSD TLV in the RI LSA with the
206        numerically smallest Instance ID MUST be used and other
207        instances of the Node MSD TLV MUST be ignored.
208 
209        The RI LSA can be advertised at any of the defined opaque flooding
210        scopes (link, area, or Autonomous System (AS)).  For the purpose of
211        Node MSD TLV advertisement, area-scoped flooding is RECOMMENDED. </t>
212
213    </section>
214
215    <section anchor="LINK_LEVEL" title="Link MSD Sub-TLV">
216      <t>The Link MSD sub-TLV is defined to carry the MSD of the interface
217      associated with the link. MSD values may be learned via a hardware API
218      or may be provisioned.</t>
219
220    <figure align="center" anchor="Link_MSD_sub_TLV"
221              title="Link MSD Sub-TLV">
222          <artwork align="left">
223   0                   1                   2                   3
224   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
225  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
226  |    Type                       |  Length                       |
227  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
228  |    MSD-Type   |  MSD-Value    |  MSD-Type...  |  MSD-Value... | 
229  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
230          </artwork>
231  </figure>
232
233  <t>Type:</t>
234  <t><list> 
235     <t>For OSPFv2, the link-level MSD-Value is advertised as an
236     optional sub-TLV of the OSPFv2 Extended Link TLV as defined in
237     <xref target="RFC7684"/> and has a type of 6.</t>
238     <t>For OSPFv3, the link-level MSD-Value is advertised as an
239     optional sub-TLV of the E-Router-LSA TLV as defined in <xref
240     target="RFC8362"/> and has a type of 9.
241     </t>
242   </list></t>
243  <t>Length: variable; same as defined in <xref target="NODE_LEVEL">
244  </xref>.</t>
245  <t>Value: consists of one or more pairs of a 1&nbhy;octet MSD-Type and
246  1&nbhy;octet MSD-Value. </t>
247
248  <t>MSD-Type: one of the values defined in the "IGP MSD-Types" registry
249  defined in <xref target="RFC8491"/>.</t> 
250  <t>The MSD-Value field contains the Link MSD of the router originating
251  the corresponding LSA as specified for OSPFv2 and OSPFv3.  The Link MSD
252  is a number in the range of 0-255. For all MSD-Types, 0 represents the
253  lack of ability to impose an MSD stack of any depth; any other value
254  represents that of the particular link when used as an outgoing
255  interface.</t>
256
257  <t>
258  If this sub-TLV is advertised multiple times for the same link in
259  different OSPF Extended Link Opaque LSAs / E-Router-LSAs originated
260  by the same OSPF router, the sub-TLV in the OSPFv2 Extended Link
261  Opaque LSA with the smallest Opaque ID or in the OSPFv3
262  E-Router-LSA with the smallest Link State ID MUST be used by
263  receiving OSPF routers.  This situation SHOULD be logged as an error.
264  </t>
265
266             </section>
267
268             <section anchor="Confict_resolution"
269             title="Procedures for Defining and Using Node and Link MSD Advertisements">
270      <t>When Link MSD is present for a given MSD-Type, the value of the Link
271      MSD MUST take precedence over the Node MSD. When a Link MSD&nbhy;Type
272      is not signaled but the Node MSD-Type is, then the Node MSD&nbhy;Type
273      value MUST be considered as the MSD value for that link.</t>
274
275      <t>In order to increase flooding efficiency, it is RECOMMENDED that
276      routers with homogenous Link MSD values advertise just the Node MSD
277      value.</t>
278
279      <t>The meaning of the absence of both Node and Link MSD advertisements
280      for a given MSD-Type is specific to the MSD-Type. Generally, it can only
281      be inferred that the advertising node does not support advertisement of
282      that MSD-Type. However, in some cases the lack of advertisement might
283      imply that the functionality associated with the MSD-Type is not
284      supported. Per <xref target="RFC8491"/>, the correct interpretation MUST
285      be specified when an MSD-Type is defined.</t>
286
287    </section>
288
289    <section anchor="IANA" title="IANA Considerations">
290    <t>This specification updates several existing OSPF registries.</t>
291      <t>IANA has allocated TLV type 12 from the "OSPF Router
292      Information (RI) TLVs" registry as defined by <xref target="RFC7770"/>.
293
294    <figure align="center" anchor="Node_MSD"
295              title="RI Node MSD">
296          <artwork align="left">
297   Value     Description                      Reference
298   -----     ---------------                  -------------
299   12        Node MSD                         This document
300          </artwork>
301  </figure>
302
303  IANA has allocated sub-TLV type 6 from
304  the "OSPFv2 Extended Link TLV Sub-TLVs" registry.
305
306  <figure align="center" anchor="OSPFv2_Link_MSD"
307              title="OSPFv2 Link MSD">
308
309          <artwork align="left">
310   Value     Description                      Reference
311   -----     ---------------                  -------------
312   6         OSPFv2 Link MSD                  This document
313          </artwork>
314  </figure>
315
316  IANA has allocated sub-TLV type 9 from the "OSPFv3 Extended-LSA
317  Sub&nbhy;TLVs" registry.
318
319  <figure align="center" anchor="OSPFv3_Link_MSD"
320      title="OSPFv3 Link MSD">
321  <artwork align="left">
322   Value     Description                      Reference
323   -----     ---------------                  -------------
324   9         OSPFv3 Link MSD                  This document
325          </artwork>
326  </figure>
327     </t>
328</section>
329
330  <section anchor="Security" title="Security Considerations">
331    <t>Security concerns for OSPF are addressed in <xref target="RFC7474"/>,
332    <xref target="RFC4552"/>, and <xref target="RFC7166"/>.
333    Further security analysis for the OSPF protocol is done in <xref
334    target="RFC6863"/>. Security considerations as specified by <xref
335    target="RFC7770"/>, <xref target="RFC7684"/>, and <xref target="RFC8362"/>
336    are applicable to this document.</t>
337
338   <t>Implementations MUST ensure that malformed TLVs and sub-TLVs defined in
339   this document are detected and do not provide a vulnerability for
340   attackers to crash the OSPF router or routing process.  Reception
341   of malformed TLVs or sub-TLVs SHOULD be counted and/or logged for
342   further analysis.  Logging of malformed TLVs and sub-TLVs SHOULD be
343   rate&nbhy;limited to prevent a Denial-of-Service (DoS) attack (distributed
344   or otherwise) from overloading the OSPF control plane.</t>
345
346   <t>Advertisement of an incorrect MSD value may have negative
347   consequences. If the value is smaller than supported, path computation
348   may fail to compute a viable path. If the value is larger than
349   supported, an attempt to instantiate a path that can't be supported by
350   the head-end (the node performing the SID imposition) may occur.</t>
351
352   <t>The presence of this information may also inform an attacker of how
353   to induce any of the aforementioned conditions.</t>
354
355   <t>There's no DoS risk specific to this extension, and it is
356   not vulnerable to replay attacks.</t>
357
358                </section>
359
360  </middle>
361
362  <back>
363    <references title="Normative References">
364      <?rfc include="reference.RFC.2119"?>
365      <?rfc include="reference.RFC.8174"?>
366      <?rfc include="reference.RFC.7770"?>
367      <?rfc include="reference.RFC.8362"?>
368      <?rfc include="reference.RFC.7684"?>
369      <?rfc include="reference.RFC.3031"?>
370      <?rfc include="reference.RFC.8402"?>
371      <?rfc include="reference.RFC.8491"?>
372    </references>
373
374    <references title="Informative References">
375
376<!-- draft-ietf-pce-segment-routing (Waiting for Writeup) -->
377<reference anchor='PCEP-EXT'>
378<front>
379<title>PCEP Extensions for Segment Routing</title>
380<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
381    <organization />
382</author>
383<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
384    <organization />
385</author>
386<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
387    <organization />
388</author>
389<author initials='W' surname='Henderickx' fullname='Wim Henderickx'>
390    <organization />
391</author>
392<author initials='J' surname='Hardwick' fullname='Jonathan Hardwick'>
393    <organization />
394</author>
395<date month='October' year='2018' />
396</front>
397<seriesInfo name='Work in Progress,' value='draft-ietf-pce-segment-routing-14' />
398</reference>
399
400<!-- draft-ietf-idr-bgp-ls-segment-routing-msd (I-D Exists) -->
401<reference anchor='MSD-BGP'>
402<front>
403<title>Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-State</title>
404<author initials='J' surname='Tantsura' fullname='Jeff Tantsura'>
405    <organization />
406</author>
407<author initials='U' surname='Chunduri' fullname='Uma Chunduri'>
408    <organization />
409</author>
410<author initials='G' surname='Mirsky' fullname='Gregory Mirsky'>
411    <organization />
412</author>
413<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
414    <organization />
415</author>
416<date month='August' year='2018' />
417</front>
418<seriesInfo name='Work in Progress,' value='draft-ietf-idr-bgp-ls-segment-routing-msd-02' />
419</reference>
420
421<!-- draft-ietf-ospf-mpls-elc (I-D Exists) -->
422<reference anchor='ELC-ISIS'>
423<front>
424<title>Signaling Entropy Label Capability and Entropy Readable Label-stack Depth Using OSPF</title>
425<author initials='X' surname='Xu' fullname='Xiaohu Xu'>
426    <organization />
427</author>
428<author initials='S' surname='Kini' fullname='Sriganesh Kini'>
429    <organization />
430</author>
431<author initials='S' surname='Sivabalan' fullname='Siva Sivabalan'>
432    <organization />
433</author>
434<author initials='C' surname='Filsfils' fullname='Clarence Filsfils'>
435    <organization />
436</author>
437<author initials='S' surname='Litkowski' fullname='Stephane Litkowski'>
438    <organization />
439</author>
440<date month='September' year='2018' />
441</front>
442<seriesInfo name='Work in Progress,' value='draft-ietf-ospf-mpls-elc-07' />
443</reference>
444
445      <?rfc include="reference.RFC.7752"?>
446      <?rfc include="reference.RFC.6863"?>
447      <?rfc include="reference.RFC.7474"?>
448      <?rfc include="reference.RFC.4552"?>
449      <?rfc include="reference.RFC.7166"?>
450
451    </references>
452
453     <section anchor="Acknowledgements" title="Acknowledgements" numbered="no">
454       <t>The authors would like to thank Acee Lindem, Ketan Talaulikar,
455       Tal Mizrahi, Stephane Litkowski, and Bruno Decraene for their reviews
456       and valuable comments.</t>
457    </section>
458
459        <section anchor="Contributors" title="Contributors" numbered="no">
460
461             <t>The following person contributed to this document:</t>
462             <t>Les Ginsberg</t>
463             <t>Email: ginsberg@cisco.com</t>
464    </section>
465
466  </back>
467</rfc>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC2119' target='https://www.rfc-editor.org/info/rfc2119'>
4<front>
5<title>Key words for use in RFCs to Indicate Requirement Levels</title>
6<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
7<date year='1997' month='March' />
8<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>
9</front>
10<seriesInfo name='BCP' value='14'/>
11<seriesInfo name='RFC' value='2119'/>
12<seriesInfo name='DOI' value='10.17487/RFC2119'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8174' target='https://www.rfc-editor.org/info/rfc8174'>
4<front>
5<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
6<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
7<date year='2017' month='May' />
8<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>
9</front>
10<seriesInfo name='BCP' value='14'/>
11<seriesInfo name='RFC' value='8174'/>
12<seriesInfo name='DOI' value='10.17487/RFC8174'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7770' target='https://www.rfc-editor.org/info/rfc7770'>
4<front>
5<title>Extensions to OSPF for Advertising Optional Router Capabilities</title>
6<author initials='A.' surname='Lindem' fullname='A. Lindem' role='editor'><organization /></author>
7<author initials='N.' surname='Shen' fullname='N. Shen'><organization /></author>
8<author initials='JP.' surname='Vasseur' fullname='JP. Vasseur'><organization /></author>
9<author initials='R.' surname='Aggarwal' fullname='R. Aggarwal'><organization /></author>
10<author initials='S.' surname='Shaffer' fullname='S. Shaffer'><organization /></author>
11<date year='2016' month='February' />
12<abstract><t>It is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain.  This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities.  The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose.  In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID.  In OSPFv3, the RI LSA will be implemented with a unique LSA type function code.  In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)).  This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.</t></abstract>
13</front>
14<seriesInfo name='RFC' value='7770'/>
15<seriesInfo name='DOI' value='10.17487/RFC7770'/>
16</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8362' target='https://www.rfc-editor.org/info/rfc8362'>
4<front>
5<title>OSPFv3 Link State Advertisement (LSA) Extensibility</title>
6<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></author>
7<author initials='A.' surname='Roy' fullname='A. Roy'><organization /></author>
8<author initials='D.' surname='Goethals' fullname='D. Goethals'><organization /></author>
9<author initials='V.' surname='Reddy Vallem' fullname='V. Reddy Vallem'><organization /></author>
10<author initials='F.' surname='Baker' fullname='F. Baker'><organization /></author>
11<date year='2018' month='April' />
12<abstract><t>OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340.  Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs.  This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs.  Backward-compatibility mechanisms are also described.</t><t>This document updates RFC 5340, &quot;OSPF for IPv6&quot;, and RFC 5838, &quot;Support of Address Families in OSPFv3&quot;, by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support.</t></abstract>
13</front>
14<seriesInfo name='RFC' value='8362'/>
15<seriesInfo name='DOI' value='10.17487/RFC8362'/>
16</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7684' target='https://www.rfc-editor.org/info/rfc7684'>
4<front>
5<title>OSPFv2 Prefix/Link Attribute Advertisement</title>
6<author initials='P.' surname='Psenak' fullname='P. Psenak'><organization /></author>
7<author initials='H.' surname='Gredler' fullname='H. Gredler'><organization /></author>
8<author initials='R.' surname='Shakir' fullname='R. Shakir'><organization /></author>
9<author initials='W.' surname='Henderickx' fullname='W. Henderickx'><organization /></author>
10<author initials='J.' surname='Tantsura' fullname='J. Tantsura'><organization /></author>
11<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></author>
12<date year='2015' month='November' />
13<abstract><t>OSPFv2 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisements (LSAs) as described in RFC 2328.  This document defines OSPFv2 Opaque LSAs based on Type-Length-Value (TLV) tuples that can be used to associate additional attributes with prefixes or links.  Depending on the application, these prefixes and links may or may not be advertised in the fixed-format LSAs.  The OSPFv2 Opaque LSAs are optional and fully backward compatible.</t></abstract>
14</front>
15<seriesInfo name='RFC' value='7684'/>
16<seriesInfo name='DOI' value='10.17487/RFC7684'/>
17</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC3031' target='https://www.rfc-editor.org/info/rfc3031'>
4<front>
5<title>Multiprotocol Label Switching Architecture</title>
6<author initials='E.' surname='Rosen' fullname='E. Rosen'><organization /></author>
7<author initials='A.' surname='Viswanathan' fullname='A. Viswanathan'><organization /></author>
8<author initials='R.' surname='Callon' fullname='R. Callon'><organization /></author>
9<date year='2001' month='January' />
10<abstract><t>This document specifies the architecture for Multiprotocol Label Switching (MPLS).  [STANDARDS-TRACK]</t></abstract>
11</front>
12<seriesInfo name='RFC' value='3031'/>
13<seriesInfo name='DOI' value='10.17487/RFC3031'/>
14</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8402' target='https://www.rfc-editor.org/info/rfc8402'>
4<front>
5<title>Segment Routing Architecture</title>
6<author initials='C.' surname='Filsfils' fullname='C. Filsfils' role='editor'><organization /></author>
7<author initials='S.' surname='Previdi' fullname='S. Previdi' role='editor'><organization /></author>
8<author initials='L.' surname='Ginsberg' fullname='L. Ginsberg'><organization /></author>
9<author initials='B.' surname='Decraene' fullname='B. Decraene'><organization /></author>
10<author initials='S.' surname='Litkowski' fullname='S. Litkowski'><organization /></author>
11<author initials='R.' surname='Shakir' fullname='R. Shakir'><organization /></author>
12<date year='2018' month='July' />
13<abstract><t>Segment Routing (SR) leverages the source routing paradigm.  A node steers a packet through an ordered list of instructions, called &quot;segments&quot;.  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>
14</front>
15<seriesInfo name='RFC' value='8402'/>
16<seriesInfo name='DOI' value='10.17487/RFC8402'/>
17</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC8491' target='https://www.rfc-editor.org/info/rfc8491'>
4<front>
5<title>Signaling Maximum SID Depth (MSD) Using IS-IS</title>
6<author initials='J.' surname='Tantsura' fullname='J. Tantsura'><organization /></author>
7<author initials='U.' surname='Chunduri' fullname='U. Chunduri'><organization /></author>
8<author initials='S.' surname='Aldrin' fullname='S. Aldrin'><organization /></author>
9<author initials='L.' surname='Ginsberg' fullname='L. Ginsberg'><organization /></author>
10<date year='2018' month='November' />
11<abstract><t>This document defines a way for an Intermediate System to Intermediate System (IS-IS) router to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment ID (SID) stack can be supported in a given network.  This document only defines one type of MSD: Base MPLS Imposition.  However, it defines an encoding that can support other MSD types.  This document focuses on MSD use in a network that is Segment Routing (SR) enabled, but MSD may also be useful when SR is not enabled.</t></abstract>
12</front>
13<seriesInfo name='RFC' value='8491'/>
14<seriesInfo name='DOI' value='10.17487/RFC8491'/>
15</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7752' target='https://www.rfc-editor.org/info/rfc7752'>
4<front>
5<title>North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP</title>
6<author initials='H.' surname='Gredler' fullname='H. Gredler' role='editor'><organization /></author>
7<author initials='J.' surname='Medved' fullname='J. Medved'><organization /></author>
8<author initials='S.' surname='Previdi' fullname='S. Previdi'><organization /></author>
9<author initials='A.' surname='Farrel' fullname='A. Farrel'><organization /></author>
10<author initials='S.' surname='Ray' fullname='S. Ray'><organization /></author>
11<date year='2016' month='March' />
12<abstract><t>In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information.  This is information typically distributed by IGP routing protocols within the network.</t><t>This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol.  This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format.  The mechanism is applicable to physical and virtual IGP links.  The mechanism described is subject to policy control.</t><t>Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).</t></abstract>
13</front>
14<seriesInfo name='RFC' value='7752'/>
15<seriesInfo name='DOI' value='10.17487/RFC7752'/>
16</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC6863' target='https://www.rfc-editor.org/info/rfc6863'>
4<front>
5<title>Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design Guide</title>
6<author initials='S.' surname='Hartman' fullname='S. Hartman'><organization /></author>
7<author initials='D.' surname='Zhang' fullname='D. Zhang'><organization /></author>
8<date year='2013' month='March' />
9<abstract><t>This document analyzes OSPFv2 and OSPFv3 according to the guidelines set forth in Section 4.2 of the &quot;Keying and Authentication for                     Routing Protocols (KARP) Design Guidelines&quot; (RFC 6518).  Key components of solutions to gaps identified in this document are already underway.</t></abstract>
10</front>
11<seriesInfo name='RFC' value='6863'/>
12<seriesInfo name='DOI' value='10.17487/RFC6863'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7474' target='https://www.rfc-editor.org/info/rfc7474'>
4<front>
5<title>Security Extension for OSPFv2 When Using Manual Key Management</title>
6<author initials='M.' surname='Bhatia' fullname='M. Bhatia'><organization /></author>
7<author initials='S.' surname='Hartman' fullname='S. Hartman'><organization /></author>
8<author initials='D.' surname='Zhang' fullname='D. Zhang'><organization /></author>
9<author initials='A.' surname='Lindem' fullname='A. Lindem' role='editor'><organization /></author>
10<date year='2015' month='April' />
11<abstract><t>The current OSPFv2 cryptographic authentication mechanism as defined in RFCs 2328 and 5709 is vulnerable to both inter-session and intra- session replay attacks when using manual keying.  Additionally, the existing cryptographic authentication mechanism does not cover the IP header.  This omission can be exploited to carry out various types of attacks.</t><t>This document defines changes to the authentication sequence number mechanism that will protect OSPFv2 from both inter-session and intra- session replay attacks when using manual keys for securing OSPFv2 protocol packets.  Additionally, we also describe some changes in the cryptographic hash computation that will eliminate attacks resulting from OSPFv2 not protecting the IP header.</t></abstract>
12</front>
13<seriesInfo name='RFC' value='7474'/>
14<seriesInfo name='DOI' value='10.17487/RFC7474'/>
15</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC4552' target='https://www.rfc-editor.org/info/rfc4552'>
4<front>
5<title>Authentication/Confidentiality for OSPFv3</title>
6<author initials='M.' surname='Gupta' fullname='M. Gupta'><organization /></author>
7<author initials='N.' surname='Melam' fullname='N. Melam'><organization /></author>
8<date year='2006' month='June' />
9<abstract><t>This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header.  [STANDARDS-TRACK]</t></abstract>
10</front>
11<seriesInfo name='RFC' value='4552'/>
12<seriesInfo name='DOI' value='10.17487/RFC4552'/>
13</reference>
1<?xml version='1.0' encoding='UTF-8'?>
2
3<reference  anchor='RFC7166' target='https://www.rfc-editor.org/info/rfc7166'>
4<front>
5<title>Supporting Authentication Trailer for OSPFv3</title>
6<author initials='M.' surname='Bhatia' fullname='M. Bhatia'><organization /></author>
7<author initials='V.' surname='Manral' fullname='V. Manral'><organization /></author>
8<author initials='A.' surname='Lindem' fullname='A. Lindem'><organization /></author>
9<date year='2014' month='March' />
10<abstract><t>Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets.  This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)).  In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used.  This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication.</t><t>The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures.</t></abstract>
11</front>
12<seriesInfo name='RFC' value='7166'/>
13<seriesInfo name='DOI' value='10.17487/RFC7166'/>
14</reference>