< draft-ietf-ospf-mrt-00.txt   draft-ietf-ospf-mrt-01.txt >
OSPF Working Group A. Atlas OSPF Working Group A. Atlas
Internet-Draft S. Hegde Internet-Draft S. Hegde
Intended status: Standards Track C. Bowers Intended status: Standards Track C. Bowers
Expires: July 23, 2015 Juniper Networks Expires: April 20, 2016 Juniper Networks
J. Tantsura J. Tantsura
Ericsson Ericsson
Z. Li Z. Li
Huawei Technologies Huawei Technologies
January 19, 2015 October 18, 2015
OSPF Extensions to Support Maximally Redundant Trees OSPF Extensions to Support Maximally Redundant Trees
draft-ietf-ospf-mrt-00 draft-ietf-ospf-mrt-01
Abstract Abstract
This document specifies extensions to OSPF to support the distributed This document specifies extensions to OSPF to support the distributed
computation of Maximally Redundant Trees (MRT). Some example uses of computation of Maximally Redundant Trees (MRT). Some example uses of
the MRTs include IP/LDP Fast-Reroute and global protection or live- the MRTs include IP/LDP Fast-Reroute and global protection or live-
live for multicast traffic. The extensions indicate what MRT live for multicast traffic. The extensions indicate what MRT
profile(s) each router supports. Different MRT profiles can be profile(s) each router supports. Different MRT profiles can be
defined to support different uses and to allow transitioning of defined to support different uses and to allow transitioning of
capabilities. An extension is introduced to flood MRT-Ineligible capabilities. An extension is introduced to flood MRT-Ineligible
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 23, 2015. This Internet-Draft will expire on April 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of OSPF Extensions for MRT . . . . . . . . . . . . . 4 4. Overview of OSPF Extensions for MRT . . . . . . . . . . . . . 4
4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4 4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4
4.2. GADAG Root Selection . . . . . . . . . . . . . . . . . . 5 4.2. GADAG Root Selection . . . . . . . . . . . . . . . . . . 5
4.3. Triggering an MRT Computation . . . . . . . . . . . . . . 5 4.3. Triggering an MRT Computation . . . . . . . . . . . . . . 5
5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 6 5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 6
5.1. Advertising MRT Capability in OSPFv2 . . . . . . . . . . 6 5.1. Advertising MRT Capability in OSPFv2 . . . . . . . . . . 6
5.2. Advertising MRT Capability in OSPFv3 . . . . . . . . . . 7 5.2. Advertising MRT Capability in OSPFv3 . . . . . . . . . . 7
5.3. MRT Profile TLV in Router Information LSA . . . . . . . . 8 5.3. MRT Profile TLV in Router Information LSA . . . . . . . . 8
6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 9 6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 10
6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 10 6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 10
7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11
8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 12 8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 12
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. M-bit . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12.2. MRT Profile and Controlled Convergence TLVs . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 12.3. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
13.1. Normative References . . . . . . . . . . . . . . . . . . 14
13.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes the OSPF extensions necessary to support the This document describes the OSPF extensions necessary to support the
architecture that defines how IP/LDP Fast-Reroute can use MRTs architecture that defines how IP/LDP Fast-Reroute can use MRTs
[I-D.ietf-rtgwg-mrt-frr-architecture]. At least one common [I-D.ietf-rtgwg-mrt-frr-architecture]. At least one common
standardized algorithm (such as the lowpoint algorithm explained and standardized algorithm (such as the lowpoint algorithm explained and
fully documented in [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required fully documented in [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required
so that the routers supporting MRT computation consistently compute so that the routers supporting MRT computation consistently compute
the same MRTs. MRT can also be used to protect multicast traffic via the same MRTs. MRT can also be used to protect multicast traffic via
skipping to change at page 7, line 42 skipping to change at page 7, line 42
| Link ID | | Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data | | Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
M-bit in OSPFv2 Router LSA M-bit in OSPFv2 Router LSA
M bit: When set, the router supports MRT. If no separate MRT M bit: When set, the router supports MRT. If no separate MRT
Profile TLV is advertised in the associated Router Information Profile TLV is advertised in the associated Router Information
LSA, then the router supports the default MRT Profile and has a LSA, then the router supports the default MRT Profile for the
GADAG Root Selection Priority of 128. default MT topology and has a GADAG Root Selection Priority of
128.
5.2. Advertising MRT Capability in OSPFv3 5.2. Advertising MRT Capability in OSPFv3
Similarly, the M-bit is defined in the OSPFv3 Router LSA as shown Similarly, the M-bit is defined in the OSPFv3 Router LSA [RFC5340] as
below. Since there can be multiple router LSAs, the M-bit needs to shown below. Since there can be multiple router LSAs in OSPFv3, the
be set on all of them. M-bit SHOULD be set in all of them. However, in the case of a
mismatch, the values in the LSA with the lowest Link State ID take
precedence.
0 1 2 3 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 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 |0|0|1| 1 | | LS Age |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 44 skipping to change at page 8, line 44
| Neighbor Interface ID | | Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID | | Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
M-bit in OSPFv3 Router LSA M-bit in OSPFv3 Router LSA
M bit: When set, the router supports MRT. If no separate MRT M bit: When set, the router supports MRT. If no separate MRT
Profile TLV is advertised in the associated Router Information Profile TLV is advertised in the associated Router Information
LSA, then the router supports the default MRT Profile and has a LSA, then the router supports the default MRT Profile for the
GADAG Root Selection Priority of 128. default MT topology and has a GADAG Root Selection Priority of
128.
5.3. MRT Profile TLV in Router Information LSA 5.3. MRT Profile TLV in Router Information LSA
A router may advertise an MRT Profile TLV to indicate support for A router may advertise an MRT Profile TLV to indicate support for
multiple MRT Profiles, for a non-default MRT Profile, and/or to multiple MRT Profiles, for a non-default MRT Profile, and/or to
indicate a non-default GADAG Root Selection Priority. The MRT indicate a non-default GADAG Root Selection Priority. The MRT
Profile TLV is advertised within the OSPF router information LSA Profile TLV is advertised within the OSPF router information LSA
which is defined for both OSPFv2 and OSPFv3 in [RFC4970]. The RI LSA which is defined for both OSPFv2 and OSPFv3 in [RFC4970]. The RI LSA
MUST have area scope. MUST have area scope.
Note that the presence of the MRT Profile TLV indicates support for a
given MRT profile in the default topology (MT-ID = 0). The
extensions in this document do not define a method to advertise
support for MRT profiles in topologies with non-zero MT-ID.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(1) |GADAG Priority | Reserved | | Profile ID(1) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .............. | | .............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(n) |GADAG Priority | Reserved | | Profile ID(n) |GADAG Priority | Reserved |
skipping to change at page 9, line 43 skipping to change at page 10, line 7
are supported, then the length of this TLV varies. The ordering of are supported, then the length of this TLV varies. The ordering of
the profiles inside the TLV is not significant. Multiple appearances the profiles inside the TLV is not significant. Multiple appearances
of this TLV is not an error. of this TLV is not an error.
Lack of support for the default MRT profile is indicated by the Lack of support for the default MRT profile is indicated by the
presence of an MRT Profile TLV with a non-zero Profile ID value, and presence of an MRT Profile TLV with a non-zero Profile ID value, and
the absence of an MRT Profile TLV with a zero Profile ID value. the absence of an MRT Profile TLV with a zero Profile ID value.
6. Advertising MRT-ineligible links for MRT 6. Advertising MRT-ineligible links for MRT
Due to adminstrative policy, some otherwise eligible links in the Due to administrative policy, some otherwise eligible links in the
network topology may need to be excluded from the network graph upon network topology may need to be excluded from the network graph upon
which the MRT algorithm is run. Since the same network graph must be which the MRT algorithm is run. Since the same network graph must be
used across the area, it is critical for OSPF to flood which links to used across the area, it is critical for OSPF to flood which links to
exclude from the MRT calculation. This is done by introducing a new exclude from the MRT calculation. This is done by introducing a new
MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in
the Extended Link TLV defined in the Extended Link TLV defined in [I-D.ietf-ospf-prefix-link-attr].
[I-D.ietf-ospf-segment-routing-extensions]. For OSPFv3, this sub-TLV For OSPFv3, this sub-TLV is carried in the Router-Link TLV defined in
is carried in the Router-Link TLV defined in
[I-D.ietf-ospf-ospfv3-lsa-extend]. [I-D.ietf-ospf-ospfv3-lsa-extend].
If a link is marked by administrative policy as MRT-Ineligible, then If a link is marked by administrative policy as MRT-Ineligible, then
a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router- a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router-
Link TLV) for that link, including the MRT-Ineligible Link sub-TLV. Link TLV) for that link, including the MRT-Ineligible Link sub-TLV.
The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area
wide scope. wide scope.
6.1. MRT-Ineligible Link sub-TLV 6.1. MRT-Ineligible Link sub-TLV
skipping to change at page 12, line 11 skipping to change at page 12, line 11
do not support the MRT capability bit in the router LSA SHOULD do not support the MRT capability bit in the router LSA SHOULD
silently ignore it. Routers that do not support the new MRT-related silently ignore it. Routers that do not support the new MRT-related
TLVs SHOULD silently ignore them. TLVs SHOULD silently ignore them.
8.1. Handling MRT Capability Changes 8.1. Handling MRT Capability Changes
When a router changes from supporting MRT to not supporting MRT, it When a router changes from supporting MRT to not supporting MRT, it
is possible that Router Information LSAs with MRT-related TLVs remain is possible that Router Information LSAs with MRT-related TLVs remain
in the neighbors' database briefly. Such MRT-related TLVs SHOULD be in the neighbors' database briefly. Such MRT-related TLVs SHOULD be
ignored when the associated Router LSA from that router does not have ignored when the associated Router LSA from that router does not have
the MRT capability set in its Router LSA. the M-bit set in its Router LSA.
When a router changes from not supporting MRT to supporting MRT, it When a router changes from not supporting MRT to supporting MRT, it
will flood its Router LSA(s) with the M-bit set and may send an will flood its Router LSA(s) with the M-bit set and may send an
updated Router Information LSA. If a Router LSA is received with the updated Router Information LSA. If a Router LSA is received with the
M-bit newly set, an MRT computation SHOULD be scheduled but MAY be M-bit newly set, an MRT computation SHOULD be scheduled but MAY be
delayed up to 60 seconds to allow reception of updated related Router delayed up to 60 seconds to allow reception of updated related Router
Information LSAs. In general, when changes in MRT-related Information LSAs. In general, when changes in MRT-related
information is received, an MRT computation SHOULD be triggered. information are received, an MRT computation SHOULD be triggered.
The rationale behind using the M bit in router LSA is to handle the The rationale behind using the M-bit in the Router LSA is to properly
MRT capability changes gracefully in case of version upgrade/ handle the MRT capability changes in case of software version
downgrade. The M bit in router LSA ensures the latest "MRT downgrade. Without the M-bit mechanism, routers would need to rely
capability" information is available for computation when there is a only on the presence or absence of the MRT Profile TLV in the Router
downgrade to the version that doesn't support MRT and RI LSA. Information LSA to determine which other routers support MRT. This
could lead the to following scenario. Router A is running a software
version supporting MRT and has MRT enabled with profile 0.
Therefore, router A advertises the MRT Profile TLV in the Router
Information LSA, and other routers in the network store that RI LSA.
Router A is downgraded to a version of software supporting neither
MRT nor the Router Information LSA. When router A restarts, it will
not originate the RI LSA, since it doesn't support it. However, the
other routers in the network will still have a RI LSA from router A
indicating support for MRT with profile 0. This is an undesirable
state.
Requiring the M-bit in the Router LSA avoids this scenario. Before
the software downgrade, router A originates a Router LSA with the
M-bit set. After the software downgrade, router A will originate a
new Router LSA with the M-bit unset. The M bit in router LSA ensures
the latest MRT capability information is available for computation
when there is a downgrade to a version that doesn't support MRT and
RI LSA.
9. Implementation Status 9. Implementation Status
[RFC Editor: please remove this section prior to publication.] [RFC Editor: please remove this section prior to publication.]
Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on
implementation status. implementation status.
10. Security Considerations 10. Security Considerations
This OSPF extension is not believed to introduce new security This OSPF extension is not believed to introduce new security
concerns. It relies upon the security architecture already provided concerns. It relies upon the security architecture already provided
for Router LSAs and Router Information LSAs. for Router LSAs and Router Information LSAs.
11. IANA Considerations 11. Acknowledgements
The authors would like to thank Anil Kumar SN for his suggestions and
review.
12. IANA Considerations
12.1. M-bit
IANA is requested to allocate the M-bit(value 0x20 in the router
properties field of the Router-LSA) [RFC2328] [RFC4940] from the
OSPFv2 Router Properties Registry. The contents of the OSPFv2 Router
Properties Registry after implementing the above request is shown
below.
Value Description Reference
----- ----------- ---------
0x01 B-bit [RFC2328]
0x02 E-bit [RFC2328]
0x04 V-bit [RFC2328]
0x08 W-bit [RFC1584]
0x10 Nt-bit [RFC3101]
0x20 M-bit [This draft]
This document also defines the corresponding M-bit for OSPFv3 Router-
LSAs. [RFC4940] created several IANA registries for OSPFv2 and
OSPFv3, including the OSPFv2 Router Properties Registry above.
However, it did not create a corresponding OSPFv3 Router Properties
Registry. [RFC5340] discusses the corresponding OSPFv2 bits which
were already defined at the time, and it indicates that those bits
have the same meaning in OSPFv3 as in OSPFv2. Therefore, it would be
reasonable to assume that the OSPFv2 Router Properties Registry also
applies to OSPFv3. This documents requests that IANA make this
assumption explicit in the following way.
IANA is requested to rename the "OSPFv2 Router Properties Registry"
to the "OSPF Router Properties Registry (both v2 and v3)". The
following text should remain in this document.
The IANA registry "OSPF Router Properties Registry (both v2 and v3)"
applies to the 8-bit field following the length field in the Router-
LSA in both OSPFv2 and OSPFv3.
12.2. MRT Profile and Controlled Convergence TLVs
IANA is requested to allocate values for the following OSPF Router IANA is requested to allocate values for the following OSPF Router
Information TLV Types [RFC4970]: MRT Profile TLV (TBA-MRT-OSPF-1), Information TLV Types [RFC4970]: MRT Profile TLV (TBA-MRT-OSPF-1),
and Controlled Convergence TLV (TBA-MRT-OSPF-4). and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested
entries in the OSPF Router Information (RI) TLVs registry are shown
below.
IANA is requested to allocate a value from the OSPF Extended Link LSA Type Value Capabilities Reference
sub-TLV registry [I-D.ietf-ospf-segment-routing-extensions] for the ------------- ---------------------- ------------
MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). TBA-MRT-OSPF-1 MRT Profile TLV [This draft]
TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft]
12.3. MRT-Ineligible Link sub-TLV
IANA is requested to allocate a value from the OSPF Extended Link TLV
sub-TLV registry defined in [I-D.ietf-ospf-prefix-link-attr] for the
MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). The OSPF Extended Link
TLV sub-TLV registry after implementing the above request is shown
below.
Value Description Reference
------------- ---------------------- ------------
0 Reserved [prefix-link-attr-draft]
TBA-MRT-OSPF-2 MRT-Ineligible Link sub-TLV [This draft]
2-32767 Unassigned [prefix-link-attr-draft]
32768-33023 Reserved for Experimental Use [prefix-link-attr-draft]
33024-65535 Reserved [prefix-link-attr-draft]
IANA is requested to allocate a value from the OSPFv3 Extended-LSA IANA is requested to allocate a value from the OSPFv3 Extended-LSA
sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT- sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT-
Ineligible Link sub-TLV (TBA-MRT-OSPF-3). Ineligible Link sub-TLV (TBA-MRT-OSPF-3). The OSPFv3 Extended-LSA
sub-TLV registry has not yet been created by IANA.
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-ospf-ospfv3-lsa-extend] [I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-05 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-08
(work in progress), November 2014. (work in progress), October 2015.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Extensions for Segment Routing", draft-ietf-ospf-segment- Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work
routing-extensions-03 (work in progress), December 2014. in progress), August 2015.
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-01 (work in progress), July 2014. algorithm-06 (work in progress), October 2015.
[I-D.ietf-rtgwg-mrt-frr-architecture] [I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Enyedi, G., Csaszar, Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., Konstantynowicz, M., and R. White, "An A., Tantsura, J., and R. White, "An Architecture for IP/
Architecture for IP/LDP Fast-Reroute Using Maximally LDP Fast-Reroute Using Maximally Redundant Trees", draft-
Redundant Trees", draft-rtgwg-mrt-frr-architecture-04 ietf-rtgwg-mrt-frr-architecture-07 (work in progress),
(work in progress), July 2014. October 2015.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for
Shaffer, "Extensions to OSPF for Advertising Optional OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007,
Router Capabilities", RFC 4970, July 2007. <http://www.rfc-editor.org/info/rfc4940>.
[RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
2007, <http://www.rfc-editor.org/info/rfc4970>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
12.2. Informative References 13.2. Informative References
[I-D.atlas-bryant-shand-lf-timers] [I-D.atlas-bryant-shand-lf-timers]
K, A. and S. Bryant, "Synchronisation of Loop Free Timer K, A. and S. Bryant, "Synchronisation of Loop Free Timer
Values", draft-atlas-bryant-shand-lf-timers-04 (work in Values", draft-atlas-bryant-shand-lf-timers-04 (work in
progress), February 2008. progress), February 2008.
[I-D.atlas-rtgwg-mrt-mc-arch] [I-D.atlas-rtgwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
Envedi, "An Architecture for Multicast Protection Using Envedi, "An Architecture for Multicast Protection Using
Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-
arch-02 (work in progress), July 2013. arch-02 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D. [RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", RFC 3137, McPherson, "OSPF Stub Router Advertisement", RFC 3137,
June 2001. DOI 10.17487/RFC3137, June 2001,
<http://www.rfc-editor.org/info/rfc3137>.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
4915, June 2007. RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010. Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
 End of changes. 35 change blocks. 
64 lines changed or deleted 170 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/