wdiff draft-ietf-ospf-mrt-01.txt draft-ietf-ospf-mrt-02.txt

OSPF Working Group A. Atlas
Internet-Draft S. Hegde
Intended status: Standards Track C. Bowers
Expires: April 20, November 19, 2016 Juniper Networks
J. Tantsura
Ericsson
Individual
Z. Li
Huawei Technologies
October
May 18, 2015 2016

OSPF Extensions to Support Maximally Redundant Trees
draft-ietf-ospf-mrt-01
draft-ietf-ospf-mrt-02

Abstract

This document specifies extensions to OSPF to support the distributed
computation of Maximally Redundant Trees (MRT). Some example uses of
the MRTs include IP/LDP Fast-Reroute and global protection or live-
live for multicast traffic. The extensions indicate what MRT
profile(s) each router supports. Different MRT profiles can be
defined to support different uses and to allow transitioning of
capabilities. An extension is introduced to flood MRT-Ineligible
links, due to administrative policy.

The need for a mechanism to allow routers to advertise a worst-case
FIB compute/install time is well understood for controlling
convergence. This specification introduces the Controlled
Convergence TLV to be carried in the Router Information LSA.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 20, November 19, 2016.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Overview of OSPF Extensions for MRT . . . . . . . . . . . . . 4
4.1. Supporting MRT Profiles . . . . . . . . . . . . . . . . . 4
4.2. GADAG Root Selection . . . . . . . . . . . . . . . . . . 5
4.3. Triggering an MRT Computation . . . . . . . . . . . . . . 5
5. MRT Capability Advertisement . . . . . . . . . . . . . . . . 6
5.1. Advertising MRT Capability in OSPFv2 . . . . . . . . . . 6
5.2. Advertising MRT Capability in OSPFv3 . . . . . . . . . . 7
5.3. MRT Profile TLV in Router Information LSA . . . . . . . . 8 . . 6
6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 10 7
6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 10 7
7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10 8
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 9
8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 12 10
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 11
12.1. M-bit . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.2. MRT Profile and Controlled Convergence TLVs . . . . . . 14
12.3. 11
12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 14 11
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 14 11
13.2. Informative References . . . . . . . . . . . . . . . . . 15 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 13

1. Introduction

This document describes the OSPF extensions necessary to support the
architecture that defines how IP/LDP Fast-Reroute can use MRTs
[I-D.ietf-rtgwg-mrt-frr-architecture]. At least one common
standardized algorithm (such as the lowpoint algorithm explained and
fully documented in [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required
so that the routers supporting MRT computation consistently compute
the same MRTs. MRT can also be used to protect multicast traffic via
either global protection or local
protection.[I-D.atlas-rtgwg-mrt-mc-arch]

IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
node failures in an arbitrary network topology where the failure
doesn't split the network. It can also be deployed incrementally
inside an OSPF area; an MRT Island is formed of connected supporting
routers and the MRTs are computed inside that island.

In the default MRT profile, a supporting router both computes the
MRTs and creates the necessary transit forwarding state necessary to
provide the two additional forwarding topologies, known as MRT-Blue
and MRT-Red.

2. Requirements Language

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 [RFC2119]

3. Terminology

For ease of reading, some of the terminology defined in
[I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here.

network graph: A graph that reflects the network topology where all
links connect exactly two nodes and broadcast links have been
transformed into the standard pseudo-node representation.

Redundant Trees (RT): A pair of trees where the path from any node
X to the root R along the first tree is node-disjoint with the
path from the same node X to the root along the second tree.
These can be computed in 2-connected graphs.

Maximally Redundant Trees (MRT): A pair of trees where the path
from any node X to the root R along the first tree and the path
from the same node X to the root along the second tree share the
minimum number of nodes and the minimum number of links. Each
such shared node is a cut-vertex. Any shared links are cut-links.
Any RT is an MRT but many MRTs are not RTs.

MRT Island: From the computing router, the set of routers that
support a particular MRT profile and are connected via MRT-
eligible links.

GADAG: Generalized Almost Directed Acyclic Graph - a graph that is
the combination of the ADAGs of all blocks. Transforming a
network graph into a GADAG is part of the MRT algorithm.

MRT-Red: MRT-Red is used to describe one of the two MRTs; it is
used to described the associated forwarding topology and MT-ID.
Specifically, MRT-Red is the decreasing MRT where links in the
GADAG are taken in the direction from a higher topologically
ordered node to a lower one.

MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is
used to described the associated forwarding topology and MT-ID.
Specifically, MRT-Blue is the increasing MRT where links in the
GADAG are taken in the direction from a lower topologically
ordered node to a higher one.

4. Overview of OSPF Extensions for MRT

There are two separate aspects that need to be advertised in OSPF.
Both derive from the need for all routers supporting an MRT profile
to compute the same pair of MRTs to each destination. By executing
the same algorithm on the same network graph, distributed routers
will compute the same MRTs. Convergence considerations are discussed
in [I-D.ietf-rtgwg-mrt-frr-architecture].

The first aspect that must be advertised is which MRT profile(s) are
supported and the associated GADAG Root Selection Priority. The
second aspect that must be advertised is any links that are not
eligible, due to administrative policy, to be part of the MRTs. This
must be advertised consistently across the area so that all routers
in the MRT Island use the same network graph.

4.1. Supporting MRT Profiles

An MRT Profile defines the exact MRT Algorithm, the MRT-Red LDP MT-
ID, the MRT-Blue LDP MT-ID, and the forwarding mechanisms supported
for the transit MRT-Red and MRT-Blue forwarding topologies. Finally,
the MRT Profile defines exact behavioral rules such as:

o how reconvergence is handled,

o inter-area forwarding behavior,

A router that advertises support for an MRT Profile MUST provide the
specified forwarding mechanism for its MRT-Red and MRT-Blue
forwarding topologies. A router that advertises support for an MRT
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
topologies as is provided by the algorithm specified in the MRT
Profile.

A router MAY indicate support for multiple MRT Profiles. A router
computes its local MRT Island for each separate MRT Profile that the
router supports. Supporting multiple MRT Profiles also provides a
mechanism for transitioning from one profile to another. Different
uses of MRT forwarding topologies may behave better on different MRT
profiles.

The default MRT Profile is defined in
[I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to
support IP/LDP unicast and multicast fast-reroute.

4.2. GADAG Root Selection

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. Therefore, it is important to provide an operator with control
over which router will play the role of GADAG root. A measure of the
centrality of a node may help determine how good a choice a
particular node is.

The GADAG Root Selection Policy (defined as part of an MRT profile)
may make use of the GADAG Root Selection Priority value advertised in
the MRT Profile TLV of the Router Information LSA. For example, the
GADAG Root Selection Policy for the default MRT profile is the
following: Among the routers in the MRT Island and with the highest
priority advertised, an implementation MUST pick the router with the
highest Router ID to be the GADAG root.

4.3. Triggering an MRT Computation

When an MRT Computation is triggered, it is triggered for a given MRT
Profile in a given area. First, the associated MRT Island is
determined. Then, the GADAG Root is selected. Finally, the actual
MRT algorithm is run to compute the transit MRT-Red and MRT-Blue
topologies. Additionally, the router MAY choose to compute MRT-FRR
alternates or make other use of the MRT computation results.

Prefixes can be attached and detached and have their associated MRT-
Red and MRT-Blue next-hops computed without requiring a new MRT
computation.

5. MRT Capability Advertisement

A router that supports MRT indicates this by setting a newly defined
M bit in the Router LSA. If the router provides no other information
via a separate MRT Profile TLV, then the router supports the default
MRT Profile with a GADAG Root Selection Priority of 128.

In addition, a router can advertise a newly-defined MRT Profile TLV
within the scope of the OSPF router information LSA [RFC4970]. This
TLV also includes the GADAG Root Selection Priority.

5.1. Advertising MRT Capability in OSPFv2

A new M-bit is defined in the Router-LSA (defined in [RFC2328] and
updated in [RFC4915]), as pictured below.

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 | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|*|*|M|N|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # MT-ID | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |

M-bit in OSPFv2 Router LSA

M bit: When set, the router supports MRT. If no separate MRT
Profile TLV is advertised in the associated Router Information
LSA, then the router supports the default MRT Profile for the
default MT topology and has a GADAG Root Selection Priority of
128.

5.2. Advertising MRT Capability in OSPFv3

Similarly, the M-bit is defined in the OSPFv3 Router LSA [RFC5340] as
shown below. Since there can be multiple router LSAs in OSPFv3, the
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 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 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0|M|Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |

M-bit in OSPFv3 Router LSA

5.3. MRT Profile TLV in Router Information LSA

A router may advertise an MRT Profile TLV to indicate support for
multiple MRT Profiles, for a non-default one
or more MRT Profile, and/or to
indicate a non-default GADAG Root Selection Priority. Profiles. The MRT Profile TLV is advertised within the
OSPF router information LSA which is defined for both OSPFv2 and
OSPFv3 in [RFC4970]. [RFC7770]. The RI LSA 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 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(1) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| .............. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Profile ID(n) |GADAG Priority | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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 Default MRT profile.

The GADAG Priority is the GADAG Root Selection Priority associated
with the advertising router in the MRT Island for the associated MRT
Profile, as indicated by the Profile ID. If multiple MRT Profiles
are supported, then An implementation SHOULD
send a default value of 128 for the GADAG Root Selection Priority if
another value is not explicitly configured.

The length of this TLV varies. depends on the number of MRT profiles
supported. The ordering of the profiles inside the TLV is not
significant. Multiple appearances of this TLV is not an error.

Lack

An advertising router MUST NOT advertise the same Profile ID multiple
times in one or more TLVs. If a receiving router receives multiple
appearances of support the same Profile ID for the default MRT profile is indicated by same router, it MUST treat
the advertising router as NOT supporting the
presence of an MRT Profile TLV associated
with a non-zero that Profile ID value, and ID. This is the case even if the absence multiple
appearances of an MRT the same Profile TLV with a zero ID have the same GADAG Priority
values. However, other Profile IDs advertised by the same
advertising router that are not repeated should continue to be
honored by the receiving router. The receiving router SHOULD also
log an error message regarding the multiple appearances of the same
Profile ID value. for the same router.

6. Advertising MRT-ineligible links for MRT

Due to administrative policy, some otherwise eligible links in the
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
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
MRT-Ineligible Link sub-TLV. For OSPFv2, this sub-TLV is carried in
the Extended Link TLV defined in [I-D.ietf-ospf-prefix-link-attr].
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
a router MUST flood the OSPFv2 Extended Link TLV (or OSPFv3 Router-
Link TLV) for that link, including the MRT-Ineligible Link sub-TLV.
The OSPVv2 Extended Link TLV and OSPFv3 Router-Link TLV have area
wide scope.

Note that a router that advertises support for MRT with the MRT
Profile TLV MUST also support receipt of the MRT-Ineligible Link sub-
TLVs. This ensures that all routers participating in a given MRT
Island have the same view of the links included in the MRT Island.

6.1. MRT-Ineligible Link sub-TLV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV
TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV
(To Be Allocated by IANA)
LENGTH: 0

MRT-Ineligible Link sub-TLV

This zero-length sub-TLV can appear in the OSPFv2 Extended Link TLV
or the OSPFv3 Router-Link TLV. Its presence indicates that the
associated link MUST NOT be used in the MRT calculation for all
profiles.

7. Worst-Case Network Convergence Time

As part of converging the network after a single failure,
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
be using their new SPTs. Similarly, any work on avoiding some proposals to avoid micro-
forwarding loops during convergence[RFC5715] requires require determining the
maximum among all routers in the area of the worst-case route
computation and FIB installation time. More details on the specific
reasoning and need for flooding it are given in
[I-D.atlas-bryant-shand-lf-timers].

TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA)
LENGTH: 4
FIB compute/install time: This is the worst-case time the router
may take to compute and install all OSPF routes in the area
after a change to a stable network. The value is
in milliseconds.

Controlled Convergence TLV in Router Information LSA

The Controlled Convergence TLV is carried in the Router Information
LSA and flooded with area-wide scope. The FIB compute/install time
value sent by a router SHOULD be an estimate taking into account
network scale or real-time measurements, or both. Advertisements
SHOULD be dampened to avoid frequent communication of small changes
in the FIB compute/install time.

A router receiving the Controlled Convergence sub-TLV TLV SHOULD estimate the
network convergence time as the maximum of the FIB compute/
install compute/install
times advertised by the routers in an area, including itself. In
order to account for routers that do not advertise the Controlled
Convergence sub-TLV, TLV, a router MAY use a locally configured minimum
network convergence time as a lower bound on the computed network
convergence time. A router MAY use a locally configured maximum
network convergence time as an upper bound on the computed network
convergence time.

8. Backwards Compatibility

The MRT capability bit, the MRT Profile, Profile TLV, the MRT-Ineligible Link, and Link sub-TLV, the OSPFv3 MRT-Ineligible MRT-
Ineligible Link TLVs sub-TLV, and the Controlled Convergence TLV are
defined in this document.
They should A router that does not introduce any interoperability issues. Routers understand the MRT
Profile TLV will ignore it. A router that does not advertise an MRT
Profile TLV with a Profile ID may do so either because it doesn't
understand the MRT Profile TLV, or because it understands these
extensions, but chooses not to advertise support for any MRT profile.
Routers that support the MRT capability bit Profile TLV will treat either case in
the same manner, by excluding the router not advertising the MRT
Profile from the particular MRT Island.

The MRT-Ineligible Link sub-TLVs will be ignored by a router LSA SHOULD
silently ignore it. Routers that
doesn't understand MRT, and a router supporting MRT must support
receipt of the MRT-Ineligible Link sub-TLVs.

Finally, applications that utilize the Controlled Convergence TLV can
use local configuration to account for routers that do not support understand
the new MRT-related
TLVs SHOULD silently ignore them. Controlled Convergence TLV.

8.1. Handling MRT Capability Changes

When a router changes from that is running a version of software supporting MRT is
downgraded to software that does not supporting support MRT, it is possible that Router Information LSAs with MRT-related TLVs remain
in the neighbors' database briefly. Such MRT-related TLVs SHOULD be
ignored when the associated Router LSA from important
that router does not have the M-bit set in its Router LSA.

When a router changes from not supporting routers still running MRT do not continue to supporting MRT, it
will flood its Router LSA(s) with use the M-bit set and may send an
updated Router
Information LSA. If a Router LSA is received with (RI LSA) containing the
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
Information LSAs. In general, when changes in MRT-related
information are received, an MRT computation SHOULD be triggered.

The rationale behind using the M-bit in Profile TLV advertised by
the Router LSA is to properly
handle downgraded router before the MRT capability changes in case of software version downgrade. Without As long as the M-bit mechanism, routers would need to rely
only on
downgraded router supports Opaque LSAs, the presence or absence of downgraded router will
purge the old RI LSA containing the MRT Profile TLV in that it
originated before the Router
Information LSA to determine which other routers support MRT. downgrade. This
could lead will occur when the to following scenario. Router A is running a software
version supporting MRT and has MRT enabled with profile 0.
Therefore, downgraded
router A advertises receives the MRT Profile TLV self-originated RI LSA after restarting, as
described in the Router
Information LSA, Section 13.4 and other routers in 14.1 of [RFC2328]. This behavior is
clearly required when the downgraded router supports the network store that RI LSA.
Router A

It is downgraded also reasonable to a version of expect this behavior even when the software supporting neither
MRT nor
on the Router Information LSA. When downgraded router A restarts, it will does not originate the RI LSA, since it doesn't support it. However, understand the
other routers in the network will still have a RI LSA from router A
indicating support for MRT with profile 0. This LSA. Although
this precise behavior is an undesirable
state.

Requiring the M-bit not explicitly described in [RFC2328] , it
is reasonable to infer from the Router LSA avoids this scenario. Before documents. As long as the software downgrade, downgraded
router A originates supports Opaque LSAs, it is required to flood link-state type
10 (area-local scope) Opaque LSAs, even those that it does not
understand [RFC5250]. So, when a Router LSA with the
M-bit set. After the software downgrade, restarting router A will originate receives a
new Router self-
originated link-state type 10 Opaque LSA with the M-bit unset. The M bit in router whose Option Type it does
not recognize, it can (in principle) flood it or purge it. Purging
an unknown self-originated Opaque LSA ensures
the latest MRT capability information is available for computation
when there is a downgrade the most reasonable thing to a version that doesn't support MRT and
RI LSA.
do.

9. Implementation Status

[RFC Editor: please remove this section prior to publication.]

Please see [I-D.ietf-rtgwg-mrt-frr-architecture] for details on
implementation status.

10. Security Considerations

This OSPF extension is not believed to introduce new security
concerns. It relies upon the security architecture already provided
for Router LSAs and Router Information LSAs.

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
Information TLV Types [RFC4970]: [RFC7770]: MRT Profile TLV (TBA-MRT-OSPF-1),
and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested
entries in the OSPF Router Information (RI) TLVs registry are shown
below.

Type Value Capabilities Reference
------------- ---------------------- ------------
TBA-MRT-OSPF-1 MRT Profile TLV [This draft]
TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft]

12.3.

12.2. 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
sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT-
Ineligible Link sub-TLV (TBA-MRT-OSPF-3). The OSPFv3 Extended-LSA
sub-TLV registry has not yet been created by IANA.

13. References

13.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-08 draft-ietf-ospf-ospfv3-lsa-extend-09
(work in progress), October November 2015.

[I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work
in progress), August 2015.

[I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast- Reroute", draft-ietf-rtgwg-mrt-frr-
algorithm-06 (work in progress), October 2015.

[I-D.ietf-rtgwg-mrt-frr-architecture]
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-07 (work in progress),
October 2015.

[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.

[RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for
OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007,
<http://www.rfc-editor.org/info/rfc4940>.

[RFC4970] Lindem,

[RFC5250] Berger, L., Bryskin, I., Zinin, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to R. Coltun, "The
OSPF for Advertising Optional
Router Capabilities", Opaque LSA Option", RFC 4970, 5250, DOI 10.17487/RFC4970, 10.17487/RFC5250,
July
2007, <http://www.rfc-editor.org/info/rfc4970>. 2008, <http://www.rfc-editor.org/info/rfc5250>.

[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.

[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>.

13.2. Informative References

[I-D.atlas-bryant-shand-lf-timers]
K, A. and S. Bryant, "Synchronisation of Loop Free Timer
Values", draft-atlas-bryant-shand-lf-timers-04 (work in
progress), February 2008.

[I-D.atlas-rtgwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
Envedi, "An Architecture for Multicast Protection Using
Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-
arch-02 (work in progress), July 2013.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
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.
McPherson, "OSPF Stub Router Advertisement", RFC 3137,
DOI 10.17487/RFC3137, June 2001,
<http://www.rfc-editor.org/info/rfc3137>.

[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
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
Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>.

Authors' Addresses

Alia Atlas
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA

Email: akatlas@juniper.net

Shraddha Hegde
Juniper Networks
Embassy Business Park
Bangalore, KA 560093
India

Email: shraddha@juniper.net
Chris Bowers
Juniper Networks
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
USA

Email: cbowers@juniper.net

Jeff Tantsura
Ericsson
300 Holger Way
San Jose, CA 95134
Individual
USA

Email: jeff.tantsura@ericsson.com jefftant.ietf@gmail.com

Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China

Email: lizhenbin@huawei.com