One document matched: draft-ietf-ospf-prefix-link-attr-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<rfc category="std" ipr="pre5378Trust200902" docName="draft-ietf-ospf-prefix-link-attr-03.txt">
<front>
<title abbrev="OSPFv2 Prefix/Link Attributes ">OSPFv2 Prefix/Link Attribute Advertisement</title>
<author initials='P.' surname="Psenak" fullname='Peter Psenak'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Apollo Business Center</street>
<street>Mlynske nivy 43</street>
<city>Bratislava</city> <region>821 09</region>
<country>Slovakia</country>
<code></code>
</postal>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author initials='H.' surname="Gredler" fullname='Hannes Gredler'>
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city><region>CA</region>
<country>USA</country>
<code>94089</code>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author initials='R.' surname="Shakir" fullname='Rob Shakir'>
<organization>British Telcom</organization>
<address>
<postal>
<street></street>
<city>London</city>
<country>UK</country>
</postal>
<email>rob.shakir@bt.com</email>
</address>
</author>
<author initials='W.' surname="Henderickx" fullname='Wim Henderickx'>
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>Copernicuslaan</street>
<city>Antwerp</city><region>2018</region>
<country>Belgium</country>
<code>94089</code>
</postal>
<email>wim.henderickx@alcatel-lucent.com</email>
</address>
</author>
<author initials='J.' surname="Tantsura" fullname='Jeff Tantsura'>
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city> <region>CA</region>
<country>USA</country>
<code>95134</code>
</postal>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<author initials='A.' surname="Lindem" fullname='Acee Lindem'>
<organization>Cisco Systems</organization>
<address>
<postal>
<street>301 Midenhall Way</street>
<city>Cary</city> <region>NC</region>
<country>USA</country>
<code>27513</code>
</postal>
<email>acee@cisco.com</email>
</address>
</author>
<date/>
<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 OSPF opaque LSAs based on Type-Length-Value (TLV) tuples that can
be used to associate additional attributes with prefixes or links. Dependent on the
application, these prefixes and links may or not be advertised in
the fixed-format LSAs. The
OSPF opaque LSAs are optional and fully backward compatible.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>OSPFv2 requires functional extension beyond what can readily be done with the
fixed-format Link State Advertisements (LSAs) as described in RFC 2328 <xref target="OSPFV2"/>.
This document defines OSPF opaque LSAs based on Type-Length-Value (TLV) tuples that can
be used to associate additional attributes with prefixes or links. Dependent on the
application, these prefixes and links may or not be advertised in
the fixed-format LSAs. The OSPF opaque LSAs are optional and fully backward compatible.
This is in contrast to the
approach taken in OSPFv3 <xref target="I-D.ietf-ospf-ospfv3-lsa-extend"/> where the
existing LSAs will be replaced by TLV-based extended LSAs.</t>
<t>New requirements such as source/destination routing, route tagging, and segment routing
necessitate this extension.</t>
<t>This specification defines the following OSPFv2 opaque LSAs:
<list style="numbers">
<t>OSPFv2 Extended Prefix LSA - Allows advertisement of additional attributes
for prefixes advertised in Router-LSAs, Network-LSAs,
Network-Summary-LSAs, NSSA-LSAs, and AS-External-LSAs <xref target="OSPFV2"/></t>
<t>OSPFv2 Extended links LSA - Allows advertisement of additional attributes
for links advertised in Router-LSAs.</t>
</list></t>
<t>Additionally, the following TLVs are defined:
<list style="numbers">
<t>OSPFv2 Extended Prefix TLV - Top-level TLV advertising attributes for a prefix in
the OSPFv2 Extended Prefix LSA.</t>
<t>OSPFv2 Extended Link TLV - Top-level TLV advertising attributes for a link in
the OSPFv2 Extended link LSA.</t>
</list></t>
<section title="Requirements notation">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document are to be interpreted as
described in <xref target="RFC-KEYWORDS"/>.</t>
</section>
<section title="Acknowledgments">
<t>We would like to thank Anton Smirnov for his contribution.</t>
<t>Thanks to Tony Przygienda for his review and comments.</t>
</section>
</section>
<section anchor="EXTENDED-PREFIX-LSA" title="OSPFv2 Extended Prefix Opaque LSA">
<t>The OSPFv2 Extended Prefix Opaque LSA will be used to advertise additional
prefix attributes. Opaque LSAs are described in <xref target="OPAQUE"/>.</t>
<t>Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by an
OSPFv2 router. The flooding scope of the OSPFv2 Extended Prefix
Opaque LSA depends on the scope of the advertised prefixes and is
under the control of the advertising router. In some cases (e.g.,
mapping server deployment), the LSA flooding scope may be greater
than the scope of the corresponding prefixes.</t>
<t>The format of the OSPFv2 Extended Prefix Opaque LSA is as follows:</t>
<t><figure title="OSPFv2 Extended Prefix LSA">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque type | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
</artwork>
</figure></t>
<t>The opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7.</t>
<t>The format of the TLVs within the body of the OSPFv2 Extended Prefix LSA is the same as
the format used by the Traffic Engineering Extensions to OSPF <xref target="TE"/>.
The variable TLV section consists of one or more nested Type/Length/Value
(TLV) tuples. Nested TLVs are also referred to as sub-TLVs.
The format of each TLV is:</t>
<t><figure title="TLV Format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure></t>
<t>The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of 0). The TLV
is padded to 4-octet alignment; padding is not included in the length
field (so a 3-octet value would have a length of 3, but the total
size of the TLV would be 8 octets). Nested TLVs are also 32-bit
aligned. For example, a 1-byte value would have the length field set
to 1, and 3 octets of padding would be added to the end of the value
portion of the TLV.</t>
<section anchor="EXTENDED-PREFIX-TLV" title="OSPFv2 Extended Prefix TLV">
<t>The OSPF Extended Prefix TLV is used in order to advertise additional
attributes associated with the prefix. Multiple OSPF Extended Prefix
TLVs MAY be advertised in each OSPFv2 Extended Prefix Opaque LSA. However,
since the opaque LSA type defines the flooding scope, the LSA flooding
scope MUST satisfy the application specific requirements for all
the prefixes included in a single OSPFv2 Extended Prefix Opaque LSA.
The OSPF Extended Prefix TLV has the following format:</t>
<t><figure title="OSPFv2 Extended Prefix TLV">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | Prefix Length | AF | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
</artwork>
</figure></t>
<t><vspace blankLines="1" /><list style="hanging">
<t hangText="Type"><vspace blankLines="0" />
The TLV type. Suggested value is 1.</t>
<t hangText="Length"><vspace blankLines="0" />
Variable dependent on sub-TLVs.</t>
<t hangText="Route Type"><vspace blankLines="0" />
Route type: type of the OSPF route.
If the route type is 0 (Unspecified), the information inside
the OSPF External Prefix TLV applies to the prefix regardless
of prefix's route-type. This is useful when prefix
specific attributes are advertised by an external entity,
which is not aware of the route-type associated with the
prefix. Supported types are:
<list>
<t>0 - Unspecified</t>
<t>1 - Intra-Area</t>
<t>3 - Inter-Area</t>
<t>5 - AS External</t>
<t>7 - NSSA External</t>
</list></t>
<t hangText="Prefix Length"><vspace blankLines="0" />
Length in of the prefix in bits.
</t>
<t hangText="AF"><vspace blankLines="0" />
Address family for the prefix. Currently, the only supported value
is 0 for IPv4 unicast.</t>
<t>Flags: 1 octet field. The following flags are defined: <figure
align="center">
<artwork>
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|A |N | | | | | | |
+--+--+--+--+--+--+--+--+
where:</artwork>
</figure><list style="hanging">
<t>A-Flag: Attach flag. An ABR generating Extended Prefix TLV for inter-area
prefix that is locally connected or attached in other connected area SHOULD
set this flag.</t>
<t>N-Flag: Set when the prefix identifies the advertising router i.e., the
prefix is a host prefix advertising a globally reachable address typically
associated with a loopback address.
The advertising router MAY choose to NOT set this flag even when the above
conditions are met. If the flag is set and the prefix length is NOT a host
prefix then the flag MUST be ignored. The flag is preserved when OSPFv2
Extended Prefix Opaque LSA is propagated between areas.</t>
</list></t>
<t hangText="Address Prefix"><vspace blankLines="0" />
The prefix itself encoded as an even multiple of
32-bit words, padded with zeroed bits as necessary. This
encoding consumes ((PrefixLength + 31) / 32) 32-bit words. The
default route is represented by a prefix of length 0.</t>
</list></t>
<t>If this TLV is advertised multiple times for the same prefix
in the same OSPFv2 Extended Prefix Opaque LSA, only the first
instance is used by receiving OSPFv2 Routers. This situation
SHOULD be logged as an error.</t>
<t>If this TLV is advertised multiple times for the same prefix
in different OSPFv2 Extended Prefix Opaque LSAs originated by the
same OSPF router, the OSPF advertising router is re-originating
Extended Prefix Opaque LSAs for multiple prefixes and is most likely
repacking Extended-Prefix-TLVs in Extended Prefix Opaque LSAs.
In this case, the Extended-Prefix-TLV in the Extended Prefix Opaque
LSA with the smallest Instance is used by receiving OSPFv2 Routers.
This situation MAY be logged as a warning.</t>
<t>It is RECOMMENDED that OSPF routers advertising Extended-Prefix-TLVs
in different Extended Prefix Opaque LSAs re-originate these LSAs
in ascending order of Instance to minimize the disruption.</t>
<t>If this TLV is advertised multiple times for the same prefix
in different OSPFv2 Extended Prefix Opaque LSAs originated by the
different OSPF routers, the application using the information is required
to determine which OSPFv2 Extended Prefix Opaque LSA is used. For
example, the application could prefer the LSA providing the best
path to the prefix.</t>
<t>This document creates a registry for OSPF Extended Prefix sub-TLVs
in <xref target="IANA"/>.</t>
</section>
</section>
<section anchor="EXTENDED-LINK-LSA" title="OSPFv2 Extended Link Opaque LSA">
<t>The OSPFv2 Extended Link Opaque LSA will be used to advertise additional
link attributes. Opaque LSAs are described in <xref target="OPAQUE"/>.</t>
<t>The OSPFv2 Extended Link Opaque LSA has an area flooding scope.
Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a
single router in an area.</t>
<t>The format of the OSPFv2 Extended Link Opaque LSA is as follows:</t>
<t><figure title="OSPFv2 Extended Link LSA">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque type | Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
</artwork>
</figure></t>
<t>The Opaque type used by OSPFv2 Extended Link Opaque LSA is 8.</t>
<t>The format of the TLVs within the body of the OSPFv2 Extended Prefix LSA
is the same as <xref target="EXTENDED-PREFIX-LSA"/>.</t>
<section anchor="EXTENDED-LINK-TLV" title="OSPFv2 Extended Link TLV">
<t>OSPFv2 Extended Link TLV is used in order to advertise various
attributes of the link. It describes a single link and is
constructed of a set of Sub-TLVs. There are no ordering requirements
for the Sub-TLVs. Only one Extended Link TLV SHALL be advertised in
each Extended Link Opaque LSA, allowing for fine granularity changes
in the topology.</t>
<t>The Extended Link TLV has following format:</t>
<t><figure title="OSPFv2 Extended Link TLV">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-TLVs (variable) |
+- -+
| |
</artwork>
</figure></t>
<t><vspace blankLines="1" /><list style="hanging">
<t hangText="Type"><vspace blankLines="0" />
The TLV type. Suggested value is 1.</t>
<t hangText="Length"><vspace blankLines="0" />
Variable dependent on sub-TLVs.</t>
<t hangText="Link-Type"><vspace blankLines="0" />
Link-Type is defined in section A.4.2 of [OSPFV2].</t>
<t hangText="Link-ID"><vspace blankLines="0" />
Link-ID is defined in section A.4.2 of [OSPFV2].</t>
<t hangText="Link Data"><vspace blankLines="0" />
Link-Data is defined in section A.4.2 of [OSPFV2].</t>
</list></t>
<t>This document creates a registry for OSPF Extended Link sub-TLVs
in <xref target="IANA"/>.</t>
</section>
</section>
<section title="Backward Compatibility">
<t>Since opaque OSPFv2 LSAs are optional and backward compatible
<xref target="OPAQUE"/>, the extensions described herein is fully backward
compatible. However, future OSPFv2 extensions utilizing these extensions
must address backward compatibility of the corresponding functionality.</t>
</section>
<section title="Security Considerations">
<t>In general, new LSAs defined in this document are subject to the same
security concerns as those described in <xref target="OSPFV2"/>.
Additionally, implementations must assure that malformed TLV and Sub-TLV
permutations do not result in errors that cause hard OSPF failures.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This specification updates the
Opaque Link-State Advertisements (LSA) Option Types with the following values:
<list style="symbols">
<t>7 (IANA Early Allocation <xref target="RFC7120"/>) -
OSPFv2 Extended Prefix Opaque LSA</t>
<t>8 (IANA Early Allocation <xref target="RFC7120"/>) -
OSPFv2 Extended Link Opaque LSA</t>
</list></t>
<t>This specification also creates four new registries:
<list style="symbols">
<t>OSPF Extended Prefix LSA TLVs</t>
<t>OSPF Extended Prefix TLV Sub-TLVs</t>
<t>OSPF Extended Link LSA TLVs</t>
<t>OSPF Extended Link TLV Sub-TLVs</t>
</list></t>
<section title="OSPF Extended Prefix LSA TLV Registry">
<t>The OSPF Extend Prefix LSA TLV registry will define top-level TLVs
for Extended Prefix LSAs and should be placed in the existing OSPF
IANA registry. New values can be allocated via IETF Consensus or
IESG Approval.</t>
<t>The following initial values are allocated:
<list style="symbols">
<t>0 - Reserved</t>
<t>1 - OSPF Extended Prefix TLV</t>
</list></t>
<t>Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs.</t>
<t>Types in the range 33024-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there MUST
be an IETF specification that specifies IANA Considerations that covers
the range being assigned.</t>
</section>
<section title="OSPF Extended Prefix TLV Sub-TLV Registry">
<t>The OSPF Extended Link LSA sub-TLV registry will define
sub-TLVs at any level of nesting for Extended Link LSAs and should be
placed in the existing OSPF IANA registry. New values can be
allocated via IETF Consensus or IESG Approval.</t>
<t>The following initial values are allocated:
<list style="symbols">
<t>0 - Reserved</t>
</list></t>
<t>Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs.</t>
<t>Types in the range 33024-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there MUST
be an IETF specification that specifies IANA Considerations that covers
the range being assigned.</t>
</section>
<section title="OSPF Extended Link LSA TLV Registry">
<t> The OSPF Extend Link LSA TLV registry will define top-level TLVs for
Extended Link LSAs and should be placed in the existing OSPF IANA
registry. New values can be allocated via IETF Consensus or IESG
Approval.</t>
<t>Following initial values are allocated:
<list style="symbols">
<t>0 - Reserved</t>
<t>1 - OSPFv2 Extended Link TLV</t>
</list></t>
<t>Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs.</t>
<t>Types in the range 33024-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there MUST
be am IETF specification that specifies IANA Considerations that covers
the range being assigned.</t>
</section>
<section title="OSPF Extended Link TLV Sub-TLV Registry">
<t>The OSPF Extended Link sub-TLV registry will define will define
sub-TLVs at any level of nesting for Extended Link LSAs and should
be placed in the existing OSPF IANA registry. New values can be
allocated via IETF Consensus or IESG Approval.</t>
<t>The following initial values are allocated:
<list style="symbols">
<t>0 - Reserved</t>
</list></t>
<t>Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs.
Types in the range 33024-65535 are not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there MUST
be an IETF specification that specifies IANA Considerations that covers
the range being assigned.</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC-KEYWORDS">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="TE">
<front>
<title>Traffic Engineering Extensions to OSPF</title>
<author initials="D." surname="Katz" fullname="Dave Katz">
<organization>Juniper Networks</organization>
</author>
<author initials="D." surname="Yeung" fullname="Derek Yeung">
<organization>Procket Networks</organization>
</author>
<author initials="K." surname="Kompella" fullname="Kireeti Kompella">
<organization>Juniper Networks</organization>
</author>
<date month="September" year="2003" />
</front>
<seriesInfo name="RFC" value="3630" />
</reference>
<reference anchor="OPAQUE">
<front>
<title>The OSPF Opaque LSA Option</title>
<author initials="L." surname="Berger" fullname="Lou Berger">
<organization>LabN</organization>
</author>
<author initials="I." surname="Bryskin" fullname="Igor Bryskin">
<organization>Adva</organization>
</author>
<author initials="A." surname="Zinin" fullname="Alex Zinin">
<organization>Alcatel-Lucent</organization>
</author>
<author initials="R." surname="Coltun" fullname="Rob Colton">
<organization>Acoustra Productions</organization>
</author>
<date month="July" year="2008" />
</front>
<seriesInfo name="RFC" value="5250" />
</reference>
<reference anchor="OSPFV2">
<front>
<title>OSPF Version 2</title>
<author initials="J." surname="Moy" fullname="John Moy">
<organization>Ascend Communications, Inc</organization>
</author>
<date month="April" year="1998" />
</front>
<seriesInfo name="RFC" value="2328" />
</reference>
</references>
<references title="Informative References">
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-ospfv3-lsa-extend.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7120.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 08:40:47 |