< draft-ietf-ospf-mrt-01.txt   draft-ietf-ospf-mrt-02.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: April 20, 2016 Juniper Networks Expires: November 19, 2016 Juniper Networks
J. Tantsura J. Tantsura
Ericsson Individual
Z. Li Z. Li
Huawei Technologies Huawei Technologies
October 18, 2015 May 18, 2016
OSPF Extensions to Support Maximally Redundant Trees OSPF Extensions to Support Maximally Redundant Trees
draft-ietf-ospf-mrt-01 draft-ietf-ospf-mrt-02
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 April 20, 2016. This Internet-Draft will expire on November 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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 Profile TLV in Router Information LSA . . . . . . . . . . 6
5.1. Advertising MRT Capability in OSPFv2 . . . . . . . . . . 6 6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 7
5.2. Advertising MRT Capability in OSPFv3 . . . . . . . . . . 7 6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 7
5.3. MRT Profile TLV in Router Information LSA . . . . . . . . 8 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 8
6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 10 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9
6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 10 8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 10
7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 10 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 12 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 12.1. MRT Profile and Controlled Convergence TLVs . . . . . . 11
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. M-bit . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. MRT Profile and Controlled Convergence TLVs . . . . . . 14 13.2. Informative References . . . . . . . . . . . . . . . . . 12
12.3. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
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 6, line 9 skipping to change at page 6, line 5
Profile in a given area. First, the associated MRT Island is Profile in a given area. First, the associated MRT Island is
determined. Then, the GADAG Root is selected. Finally, the actual determined. Then, the GADAG Root is selected. Finally, the actual
MRT algorithm is run to compute the transit MRT-Red and MRT-Blue MRT algorithm is run to compute the transit MRT-Red and MRT-Blue
topologies. Additionally, the router MAY choose to compute MRT-FRR topologies. Additionally, the router MAY choose to compute MRT-FRR
alternates or make other use of the MRT computation results. alternates or make other use of the MRT computation results.
Prefixes can be attached and detached and have their associated MRT- Prefixes can be attached and detached and have their associated MRT-
Red and MRT-Blue next-hops computed without requiring a new MRT Red and MRT-Blue next-hops computed without requiring a new MRT
computation. computation.
5. MRT Capability Advertisement 5. MRT Profile TLV in Router Information LSA
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
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.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 one
multiple MRT Profiles, for a non-default MRT Profile, and/or to or more MRT Profiles. The MRT Profile TLV is advertised within the
indicate a non-default GADAG Root Selection Priority. The MRT OSPF router information LSA which is defined for both OSPFv2 and
Profile TLV is advertised within the OSPF router information LSA OSPFv3 in [RFC7770]. The RI LSA MUST have area scope.
which is defined for both OSPFv2 and OSPFv3 in [RFC4970]. The RI LSA
MUST have area scope.
Note that the presence of the MRT Profile TLV indicates support for a Note that the presence of the MRT Profile TLV indicates support for a
given MRT profile in the default topology (MT-ID = 0). The given MRT profile in the default topology (MT-ID = 0). The
extensions in this document do not define a method to advertise extensions in this document do not define a method to advertise
support for MRT profiles in topologies with non-zero MT-ID. 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 |
skipping to change at page 9, line 34 skipping to change at page 6, line 38
TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA) TYPE: TBA-MRT-OSPF-1 (To Be Allocated by IANA)
LENGTH: 4 * (number of Profiles) LENGTH: 4 * (number of Profiles)
Profile ID : 1 byte Profile ID : 1 byte
GADAG Priority: 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 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 defined in [I-D.ietf-rtgwg-mrt-frr-architecture]. A Profile ID value
of 0 corresponds to the default MRT profile. 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. An implementation SHOULD
are supported, then the length of this TLV varies. The ordering of send a default value of 128 for the GADAG Root Selection Priority if
the profiles inside the TLV is not significant. Multiple appearances another value is not explicitly configured.
of this TLV is not an error.
Lack of support for the default MRT profile is indicated by the The length of this TLV depends on the number of MRT profiles
presence of an MRT Profile TLV with a non-zero Profile ID value, and supported. The ordering of the profiles inside the TLV is not
the absence of an MRT Profile TLV with a zero Profile ID value. significant. Multiple appearances of this TLV is not an error.
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 the same Profile ID for the same router, it MUST treat
the advertising router as NOT supporting the MRT Profile associated
with that Profile ID. This is the case even if the multiple
appearances of the same Profile 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 for the same router.
6. Advertising MRT-ineligible links for MRT 6. Advertising MRT-ineligible links for MRT
Due to administrative 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 [I-D.ietf-ospf-prefix-link-attr]. 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 For OSPFv3, this sub-TLV 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 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
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV TYPE: TBA-MRT-OSPF-2 in OSPFv2 Extended Link TLV
TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV TBA-MRT-OSPF-3 in OSPFv3 Router-Link TLV
(To Be Allocated by IANA) (To Be Allocated by IANA)
LENGTH: 0 LENGTH: 0
skipping to change at page 10, line 48 skipping to change at page 8, line 27
This zero-length sub-TLV can appear in the OSPFv2 Extended Link 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 or the OSPFv3 Router-Link TLV. Its presence indicates that the
associated link MUST NOT be used in the MRT calculation for all associated link MUST NOT be used in the MRT calculation for all
profiles. 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, some proposals to avoid micro-
forwarding loops during convergence[RFC5715] requires determining the forwarding loops during convergence[RFC5715] require 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].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 32 skipping to change at page 9, line 29
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
network scale or real-time measurements, or both. Advertisements network scale or real-time measurements, or both. Advertisements
SHOULD be dampened to avoid frequent communication of small changes SHOULD be dampened to avoid frequent communication of small changes
in the FIB compute/install time. in the FIB compute/install time.
A router receiving the Controlled Convergence sub-TLV SHOULD estimate A router receiving the Controlled Convergence TLV SHOULD estimate the
the network convergence time as the maximum of the FIB compute/ network convergence time as the maximum of the FIB compute/install
install times advertised by the routers in an area, including itself. times advertised by the routers in an area, including itself. In
In order to account for routers that do not advertise the Controlled order to account for routers that do not advertise the Controlled
Convergence sub-TLV, a router MAY use a locally configured minimum Convergence TLV, a router MAY use a locally configured minimum
network convergence time as a lower bound on the computed network network convergence time as a lower bound on the computed network
convergence time. A router MAY use a locally configured maximum convergence time. A router MAY use a locally configured maximum
network convergence time as an upper bound on the computed network network convergence time as an upper bound on the computed network
convergence time. convergence time.
8. Backwards Compatibility 8. Backwards Compatibility
The MRT capability bit, the MRT Profile, the MRT-Ineligible Link, and The MRT Profile TLV, the MRT-Ineligible Link sub-TLV, the OSPFv3 MRT-
the OSPFv3 MRT-Ineligible Link TLVs are defined in this document. Ineligible Link sub-TLV, and the Controlled Convergence TLV are
They should not introduce any interoperability issues. Routers that defined in this document. A router that does not understand the MRT
do not support the MRT capability bit in the router LSA SHOULD Profile TLV will ignore it. A router that does not advertise an MRT
silently ignore it. Routers that do not support the new MRT-related Profile TLV with a Profile ID may do so either because it doesn't
TLVs SHOULD silently ignore them. 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 Profile TLV will treat either case in
the same manner, by excluding the router not advertising the MRT
Profile from the particular MRT Island.
8.1. Handling MRT Capability Changes The MRT-Ineligible Link sub-TLVs will be ignored by a router that
doesn't understand MRT, and a router supporting MRT must support
receipt of the MRT-Ineligible Link sub-TLVs.
When a router changes from supporting MRT to not supporting MRT, it Finally, applications that utilize the Controlled Convergence TLV can
is possible that Router Information LSAs with MRT-related TLVs remain use local configuration to account for routers that do not understand
in the neighbors' database briefly. Such MRT-related TLVs SHOULD be the Controlled Convergence TLV.
ignored when the associated Router LSA from that router does not have
the M-bit set in its Router LSA.
When a router changes from not supporting MRT to supporting MRT, it 8.1. Handling MRT Capability Changes
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
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 the Router LSA is to properly When a router that is running a version of software supporting MRT is
handle the MRT capability changes in case of software version downgraded to software that does not support MRT, it is important
downgrade. Without the M-bit mechanism, routers would need to rely that the routers still running MRT do not continue to use the Router
only on the presence or absence of the MRT Profile TLV in the Router Information LSA (RI LSA) containing the MRT Profile TLV advertised by
Information LSA to determine which other routers support MRT. This the downgraded router before the downgrade. As long as the
could lead the to following scenario. Router A is running a software downgraded router supports Opaque LSAs, the downgraded router will
version supporting MRT and has MRT enabled with profile 0. purge the old RI LSA containing the MRT Profile TLV that it
Therefore, router A advertises the MRT Profile TLV in the Router originated before the downgrade. This will occur when the downgraded
Information LSA, and other routers in the network store that RI LSA. router receives the self-originated RI LSA after restarting, as
Router A is downgraded to a version of software supporting neither described in Section 13.4 and 14.1 of [RFC2328]. This behavior is
MRT nor the Router Information LSA. When router A restarts, it will clearly required when the downgraded router supports the RI LSA.
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 It is also reasonable to expect this behavior even when the software
the software downgrade, router A originates a Router LSA with the on the downgraded router does not understand the RI LSA. Although
M-bit set. After the software downgrade, router A will originate a this precise behavior is not explicitly described in [RFC2328] , it
new Router LSA with the M-bit unset. The M bit in router LSA ensures is reasonable to infer from the documents. As long as the downgraded
the latest MRT capability information is available for computation router supports Opaque LSAs, it is required to flood link-state type
when there is a downgrade to a version that doesn't support MRT and 10 (area-local scope) Opaque LSAs, even those that it does not
RI LSA. understand [RFC5250]. So, when a restarting router receives a self-
originated link-state type 10 Opaque LSA whose Option Type it does
not recognize, it can (in principle) flood it or purge it. Purging
an unknown self-originated Opaque LSA is the most reasonable thing to
do.
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
skipping to change at page 13, line 18 skipping to change at page 11, line 12
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. Acknowledgements 11. Acknowledgements
The authors would like to thank Anil Kumar SN for his suggestions and The authors would like to thank Anil Kumar SN for his suggestions and
review. review.
12. IANA Considerations 12. IANA Considerations
12.1. M-bit 12.1. MRT Profile and Controlled Convergence TLVs
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 [RFC7770]: MRT Profile TLV (TBA-MRT-OSPF-1),
and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested and Controlled Convergence TLV (TBA-MRT-OSPF-4). The requested
entries in the OSPF Router Information (RI) TLVs registry are shown entries in the OSPF Router Information (RI) TLVs registry are shown
below. below.
Type Value Capabilities Reference Type Value Capabilities Reference
------------- ---------------------- ------------ ------------- ---------------------- ------------
TBA-MRT-OSPF-1 MRT Profile TLV [This draft] TBA-MRT-OSPF-1 MRT Profile TLV [This draft]
TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft] TBA-MRT-OSPF-4 Controlled Convergence TLV [This draft]
12.3. MRT-Ineligible Link sub-TLV 12.2. MRT-Ineligible Link sub-TLV
IANA is requested to allocate a value from the OSPF Extended Link 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 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 MRT-Ineligible Link sub-TLV (TBA-MRT-OSPF-2). The OSPF Extended Link
TLV sub-TLV registry after implementing the above request is shown TLV sub-TLV registry after implementing the above request is shown
below. below.
Value Description Reference Value Description Reference
------------- ---------------------- ------------ ------------- ---------------------- ------------
0 Reserved [prefix-link-attr-draft] 0 Reserved [prefix-link-attr-draft]
skipping to change at page 14, line 45 skipping to change at page 12, line 7
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). The OSPFv3 Extended-LSA Ineligible Link sub-TLV (TBA-MRT-OSPF-3). The OSPFv3 Extended-LSA
sub-TLV registry has not yet been created by IANA. sub-TLV registry has not yet been created by IANA.
13. References 13. References
13.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-08 LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09
(work in progress), October 2015. (work in progress), November 2015.
[I-D.ietf-ospf-prefix-link-attr] [I-D.ietf-ospf-prefix-link-attr]
Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W., Psenak, P., Gredler, H., rjs@rob.sh, r., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work Advertisement", draft-ietf-ospf-prefix-link-attr-13 (work
in progress), August 2015. in progress), August 2015.
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Envedi, 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
skipping to change at page 15, line 22 skipping to change at page 12, line 33
Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar,
A., Tantsura, J., and R. White, "An Architecture for IP/ A., Tantsura, J., and R. White, "An Architecture for IP/
LDP Fast-Reroute Using Maximally Redundant Trees", draft- LDP Fast-Reroute Using Maximally Redundant Trees", draft-
ietf-rtgwg-mrt-frr-architecture-07 (work in progress), ietf-rtgwg-mrt-frr-architecture-07 (work in progress),
October 2015. October 2015.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>. <http://www.rfc-editor.org/info/rfc2328>.
[RFC4940] Kompella, K. and B. Fenner, "IANA Considerations for [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF", BCP 130, RFC 4940, DOI 10.17487/RFC4940, July 2007, OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
<http://www.rfc-editor.org/info/rfc4940>. July 2008, <http://www.rfc-editor.org/info/rfc5250>.
[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, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>. <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 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
skipping to change at page 16, line 36 skipping to change at page 14, line 4
Email: akatlas@juniper.net Email: akatlas@juniper.net
Shraddha Hegde Shraddha Hegde
Juniper Networks Juniper Networks
Embassy Business Park Embassy Business Park
Bangalore, KA 560093 Bangalore, KA 560093
India India
Email: shraddha@juniper.net Email: shraddha@juniper.net
Chris Bowers Chris Bowers
Juniper Networks Juniper Networks
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA USA
Email: cbowers@juniper.net Email: cbowers@juniper.net
Jeff Tantsura Jeff Tantsura
Ericsson Individual
300 Holger Way
San Jose, CA 95134
USA USA
Email: jeff.tantsura@ericsson.com Email: jefftant.ietf@gmail.com
Zhenbin Li Zhenbin Li
Huawei Technologies Huawei Technologies
Huawei Bld., No.156 Beiqing Rd. Huawei Bld., No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: lizhenbin@huawei.com Email: lizhenbin@huawei.com
 End of changes. 33 change blocks. 
253 lines changed or deleted 114 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/