< draft-atlas-ospf-mrt-02.txt   draft-atlas-ospf-mrt-03.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: January 5, 2015 Juniper Networks Expires: January 22, 2015 Juniper Networks
J. Tantsura J. Tantsura
Ericsson Ericsson
Z. Li Z. Li
Huawei Technologies Huawei Technologies
July 4, 2014 July 21, 2014
OSPF Extensions to Support Maximally Redundant Trees OSPF Extensions to Support Maximally Redundant Trees
draft-atlas-ospf-mrt-02 draft-atlas-ospf-mrt-03
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 January 5, 2015. This Internet-Draft will expire on January 22, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
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 . . . . . . . . . . 9
6.1. MRT-Ineligible Links TLV for OSPFv2 . . . . . . . . . . . 9 6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 10
6.2. MRT-Ineligible Link TLV for OSPFv3 . . . . . . . . . . . 10 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10
7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 11 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . 12
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
skipping to change at page 4, line 39 skipping to change at page 4, line 39
The first aspect that must be advertised is which MRT profile(s) are The first aspect that must be advertised is which MRT profile(s) are
supported and the associated GADAG Root Selection Priority. The supported and the associated GADAG Root Selection Priority. The
second aspect that must be advertised is any links that are not second aspect that must be advertised is any links that are not
eligible, due to administrative policy, to be part of the MRTs. This eligible, due to administrative policy, to be part of the MRTs. This
must be advertised consistently across the area so that all routers must be advertised consistently across the area so that all routers
in the MRT Island use the same network graph. in the MRT Island use the same network graph.
4.1. Supporting MRT Profiles 4.1. Supporting MRT Profiles
An MRT Profile defines the exact MRT Algorithm, the MRT-Red MT-ID, An MRT Profile defines the exact MRT Algorithm, the MRT-Red LDP MT-
the MRT-Blue MT-ID, and the forwarding mechanisms supported for the ID, the MRT-Blue LDP MT-ID, and the forwarding mechanisms supported
transit MRT-Red and MRT-Blue forwarding topologies. Finally, the MRT for the transit MRT-Red and MRT-Blue forwarding topologies. Finally,
Profile defines exact behavioral rules such as: the MRT Profile defines exact behavioral rules such as:
o how reconvergence is handled, o how reconvergence is handled,
o inter-area forwarding behavior, o inter-area forwarding behavior,
A router that advertises support for an MRT Profile MUST provide the A router that advertises support for an MRT Profile MUST provide the
specified forwarding mechanism for its MRT-Red and MRT-Blue specified forwarding mechanism for its MRT-Red and MRT-Blue
forwarding topologies. A router that advertises support for an MRT forwarding topologies. A router that advertises support for an MRT
Profile MUST implement an algorithm that produces the same set of Profile MUST implement an algorithm that produces the same set of
MRT-Red and MRT-Blue next-hops for its MRT-Red and MRT-Blue MRT-Red and MRT-Blue next-hops for its MRT-Red and MRT-Blue
topologies as is provided by the algorithm specified in the MRT topologies as is provided by the algorithm specified in the MRT
Profile. Profile.
A router MAY indicate support for multiple MRT Profiles. A router A router MAY indicate support for multiple MRT Profiles. A router
computes its local MRT Island for each separate MRT Profile that the computes its local MRT Island for each separate MRT Profile that the
router supports. The MT-IDs used in one supported MRT Profile MUST router supports. Supporting multiple MRT Profiles also provides a
NOT overlap with those MT-IDs used in a different supported MRT mechanism for transitioning from one profile to another. Different
Profile. Supporting multiple MRT Profiles provides a mechanism for uses of MRT forwarding topologies may behave better on different MRT
transitioning from one profile to another. Different uses of MRT profiles.
forwarding topologies may behave better on different MRT profiles.
The default MRT Profile is defined in The default MRT Profile is defined in
[I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to [I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to
support IP/LDP unicast and multicast fast-reroute. support IP/LDP unicast and multicast fast-reroute.
4.2. GADAG Root Selection 4.2. GADAG Root Selection
One aspect of the MRT algorithms is that the selection of the GADAG One aspect of the MRT algorithms is that the selection of the GADAG
root can affect the alternates and the traffic through that GADAG root can affect the alternates and the traffic through that GADAG
root. Therefore, it is important to provide an operator with control root. Therefore, it is important to provide an operator with control
skipping to change at page 9, line 5 skipping to change at page 9, line 4
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 and has a
GADAG Root Selection Priority of 128. 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
[RFC4970]; the RI LSA MUST have area scope. which is defined for both OSPFv2 and OSPFv3 in [RFC4970]. The RI LSA
MUST have area scope.
TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA)
LENGTH: 4 * (number of Profiles)
VALUE:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID |GADAG Priority | Reserved | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(1) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(n) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Profile ID 0: default MRT Profile TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA)
LENGTH: 4 * (number of Profiles)
Profile ID : 1 byte
GADAG Priority: 1 byte
MRT Profile TLV in Router Information LSA MRT Profile TLV in Router Information LSA
Each Profile ID listed indicates support for a given MRT Profile, as
defined in [I-D.ietf-rtgwg-mrt-frr-architecture]. A Profile ID value
of 0 corresponds to the default MRT profile.
The GADAG Priority is the GADAG Root Selection Priority associated The GADAG Priority is the GADAG Root Selection Priority associated
with the advertising router in the MRT Island for the associated MRT with the advertising router in the MRT Island for the associated MRT
Profile, as indicated by the Profile ID. If multiple MRT Profiles Profile, as indicated by the Profile ID. If multiple MRT Profiles
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 adminstrative 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 Links TLV to be carried in the Router Information LSA. MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in
the Extended Link TLV defined in
[I-D.ietf-ospf-segment-routing-extensions]. For OSPFv3, this sub-TLV
is carried in the Router-Link TLV defined in
[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 that link in either the MRT-Ineligible TLV or a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router-
OSPFv3 MRT-Ineligible TLV in the Router Information LSA. Link TLV) for that link, including the MRT-Ineligible Link sub-TLV.
The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area
6.1. MRT-Ineligible Links TLV for OSPFv2 wide scope.
MRT-Ineligible links are specified by the Link ID, Link Data, and 6.1. MRT-Ineligible Link sub-TLV
Type fields, as normally sent in the Router-LSA. See Section A4.1.2
of [RFC2328] for descriptions of these fields.
TYPE: TBA-MRT-OSPF-2 (To Be Allocated by IANA)
LENGTH: 12 * (# of links)
VALUE:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MRT-Ineligible Links TLV in Router Information LSA TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV
TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV
Multiple links can be flooded as MRT-ineligible by listing them (To Be Allocated by IANA)
inside the same TLV. The ordering of the links in the TLV is not LENGTH: 0
relevant. Multiple appearances of this TLV is not an error.
6.2. MRT-Ineligible Link TLV for OSPFv3
Since links are differently represented in OSPFv2 and OSPFv3, an
OSPFv3 MRT-Ineligible Link TLV is defined.
An OSPFv3 MRT-Ineligible Link is defined by its Interface ID,
Neighbor Interface ID, Neighbor Router ID, and Type fields. See
Appendix A4.1.3 [RFC5340] for the description of these fields.
TYPE: TBA-MRT-OSPF-3 (To Be Allocated by IANA)
LENGTH: 16 * (# of links)
VALUE:
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPFv3 MRT-Ineligible Links TLV in Router Information LSA MRT-Ineligible Link sub-TLV
Multiple links can be flooded as MRT-ineligible by listing them This zero-length sub-TLV can appear in the OSPFv2 Extended Link TLV
inside the same TLV. The ordering of the links in the TLV is not or the OSPFv3 Router-Link TLV. Its presence indicates that the
relevant. Multiple appearances of this TLV is not an error. associated link MUST NOT be used in the MRT calculation for all
profiles.
7. Worst-Case Network Convergence Time 7. Worst-Case Network Convergence Time
As part of converging the network after a single failure, As part of converging the network after a single failure,
Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the Section 12.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the
need to wait for a configured or advertised period for all routers to need to wait for a configured or advertised period for all routers to
be using their new SPTs. Similarly, any work on avoiding micro- be using their new SPTs. Similarly, any work on avoiding micro-
forwarding loops during convergence[RFC5715] requires determining the forwarding loops during convergence[RFC5715] requires determining the
maximum among all routers in the area of the worst-case route maximum among all routers in the area of the worst-case route
computation and FIB installation time. More details on the specific computation and FIB installation time. More details on the specific
reasoning and need for flooding it are given in reasoning and need for flooding it are given in
[I-D.atlas-bryant-shand-lf-timers]. [I-D.atlas-bryant-shand-lf-timers].
TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA)
LENGTH: 4
VALUE:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | FIB compute/install time | | Reserved | FIB compute/install time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA)
LENGTH: 4
FIB compute/install time: This is the worst-case time the router FIB compute/install time: This is the worst-case time the router
may take to compute and install all OSPF routes in the area may take to compute and install all OSPF routes in the area
after a change to a stable network. The value is after a change to a stable network. The value is
in milliseconds. in milliseconds.
Controlled Convergence TLV in Router Information LSA Controlled Convergence TLV in Router Information LSA
The Controlled Convergence TLV is carried in the Router Information The Controlled Convergence TLV is carried in the Router Information
LSA and flooded with area-wide scope. The FIB compute/install time LSA and flooded with area-wide scope. The FIB compute/install time
value sent by a router SHOULD be an estimate taking into account value sent by a router SHOULD be an estimate taking into account
skipping to change at page 13, line 7 skipping to change at page 12, line 42
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. IANA Considerations
Please allocate values for the following OSPF Router Information TLV IANA is requested to allocate values for the following OSPF Router
Types [RFC4970]: MRT Profile TLV (TBA-MRT-OSPF-1), MRT-Ineligible Information TLV Types [RFC4970]: MRT Profile TLV (TBA-MRT-OSPF-1),
Link TLV (TBA-MRT-OSPF-2), OSPFv3 MRT-Ineligible Link TLV (TBA-MRT- and Controlled Convergence TLV (TBA-MRT-OSPF-4).
OSPF-3), and Controlled Convergence TLV (TBA-MRT-OSPF-4).
IANA is requested to allocate a value from the OSPF Extended Link LSA
sub-TLV registry [I-D.ietf-ospf-segment-routing-extensions] for the
MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2).
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-
Ineligible Link sub-TLV (TBA-MRT-OSPF-3).
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-ospf-ospfv3-lsa-extend]
Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-03
(work in progress), May 2014.
[I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-01 (work in progress), July 2014.
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Enyedi, 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-rtgwg-mrt-frr-
algorithm-01 (work in progress), July 2014. algorithm-01 (work in progress), July 2014.
[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., Enyedi, G., Csaszar,
A., Tantsura, J., Konstantynowicz, M., and R. White, "An A., Tantsura, J., Konstantynowicz, M., and R. White, "An
Architecture for IP/LDP Fast-Reroute Using Maximally Architecture for IP/LDP Fast-Reroute Using Maximally
 End of changes. 25 change blocks. 
82 lines changed or deleted 79 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/