draft-ietf-ospf-mrt-02.txt   draft-ietf-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: November 19, 2016 Juniper Networks Expires: January 1, 2018 Juniper Networks
J. Tantsura J. Tantsura
Individual Individual
Z. Li Z. Li
Huawei Technologies Huawei Technologies
May 18, 2016 June 30, 2017
OSPF Extensions to Support Maximally Redundant Trees OSPF Extensions to Support Maximally Redundant Trees
draft-ietf-ospf-mrt-02 draft-ietf-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 November 19, 2016. This Internet-Draft will expire on January 1, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 Profile TLV in Router Information LSA . . . . . . . . . . 6 5. MRT Profile TLV in Router Information LSA . . . . . . . . . . 5
6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 7 6. Advertising MRT-ineligible links for MRT . . . . . . . . . . 7
6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 7 6.1. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . . 7
7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 8 7. Worst-Case Network Convergence Time . . . . . . . . . . . . . 8
8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9 8. Backwards Compatibility . . . . . . . . . . . . . . . . . . . 9
8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 10 8.1. Handling MRT Capability Changes . . . . . . . . . . . . . 9
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12.1. MRT Profile and Controlled Convergence TLVs . . . . . . 11 12.1. MRT Profile and Controlled Convergence TLVs . . . . . . 10
12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 11 12.2. MRT-Ineligible Link sub-TLV . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
13.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
13.2. Informative References . . . . . . . . . . . . . . . . . 12 13.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
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 [RFC7812]. At least one common standardized algorithm (such as the
standardized algorithm (such as the lowpoint algorithm explained and lowpoint algorithm explained and fully documented in [RFC7811]) is
fully documented in [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required required so that the routers supporting MRT computation consistently
so that the routers supporting MRT computation consistently compute compute the same MRTs. MRT can also be used to protect multicast
the same MRTs. MRT can also be used to protect multicast traffic via traffic via either global protection or local
either global protection or local
protection.[I-D.atlas-rtgwg-mrt-mc-arch] protection.[I-D.atlas-rtgwg-mrt-mc-arch]
IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
node failures in an arbitrary network topology where the failure node failures in an arbitrary network topology where the failure
doesn't split the network. It can also be deployed incrementally doesn't split the network. It can also be deployed incrementally
inside an OSPF area; an MRT Island is formed of connected supporting inside an OSPF area; an MRT Island is formed of connected supporting
routers and the MRTs are computed inside that island. routers and the MRTs are computed inside that island.
In the default MRT profile, a supporting router both computes the In the default MRT profile, a supporting router both computes the
MRTs and creates the necessary transit forwarding state necessary to MRTs and creates the necessary transit forwarding state necessary to
skipping to change at page 3, line 28 skipping to change at page 3, line 27
and MRT-Red. and MRT-Red.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
3. Terminology 3. Terminology
For ease of reading, some of the terminology defined in For ease of reading, some of the terminology defined in [RFC7812] is
[I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here. repeated here.
network graph: A graph that reflects the network topology where all network graph: A graph that reflects the network topology where all
links connect exactly two nodes and broadcast links have been links connect exactly two nodes and broadcast links have been
transformed into the standard pseudo-node representation. transformed into the standard pseudo-node representation.
Redundant Trees (RT): A pair of trees where the path from any node 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 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. path from the same node X to the root along the second tree.
These can be computed in 2-connected graphs. These can be computed in 2-connected graphs.
skipping to change at page 4, line 28 skipping to change at page 4, line 28
GADAG are taken in the direction from a lower topologically GADAG are taken in the direction from a lower topologically
ordered node to a higher one. ordered node to a higher one.
4. Overview of OSPF Extensions for MRT 4. Overview of OSPF Extensions for MRT
There are two separate aspects that need to be advertised in OSPF. There are two separate aspects that need to be advertised in OSPF.
Both derive from the need for all routers supporting an MRT profile Both derive from the need for all routers supporting an MRT profile
to compute the same pair of MRTs to each destination. By executing to compute the same pair of MRTs to each destination. By executing
the same algorithm on the same network graph, distributed routers the same algorithm on the same network graph, distributed routers
will compute the same MRTs. Convergence considerations are discussed will compute the same MRTs. Convergence considerations are discussed
in [I-D.ietf-rtgwg-mrt-frr-architecture]. in [RFC7812].
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
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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. Supporting multiple MRT Profiles also provides a router supports. Supporting multiple MRT Profiles also provides a
mechanism for transitioning from one profile to another. Different mechanism for transitioning from one profile to another. Different
uses of MRT forwarding topologies may behave better on different MRT uses of MRT forwarding topologies may behave better on different MRT
profiles. profiles.
The default MRT Profile is defined in The default MRT Profile is defined in [RFC7812]. Its behavior is
[I-D.ietf-rtgwg-mrt-frr-architecture]. Its behavior is intended to 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
over which router will play the role of GADAG root. A measure of the 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 centrality of a node may help determine how good a choice a
particular node is. particular node is.
skipping to change at page 6, line 37 skipping to change at page 6, line 32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 [RFC7812]. A Profile ID value of 0 corresponds to the
of 0 corresponds to the Default MRT profile. 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. An implementation SHOULD Profile, as indicated by the Profile ID. An implementation SHOULD
send a default value of 128 for the GADAG Root Selection Priority if send a default value of 128 for the GADAG Root Selection Priority if
another value is not explicitly configured. another value is not explicitly configured.
The length of this TLV depends on the number of MRT profiles The length of this TLV depends on the number of MRT profiles
supported. The ordering of the profiles inside the TLV is not supported. The ordering of the profiles inside the TLV is not
significant. Multiple appearances of this TLV is not an error. significant. Multiple appearances of this TLV is not an error.
skipping to change at page 8, line 25 skipping to change at page 8, line 13
MRT-Ineligible Link sub-TLV MRT-Ineligible Link sub-TLV
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 [RFC7812] describes the need to wait for a configured
need to wait for a configured or advertised period for all routers to or advertised period for all routers to be using their new SPTs.
be using their new SPTs. Similarly, some proposals to avoid micro- Similarly, some proposals to avoid micro-forwarding loops during
forwarding loops during convergence[RFC5715] require determining the convergence[RFC5715] require determining the maximum among all
maximum among all routers in the area of the worst-case route routers in the area of the worst-case route computation and FIB
computation and FIB installation time. More details on the specific installation time. More details on the specific reasoning and need
reasoning and need for flooding it are given in 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | FIB compute/install time | | Reserved | FIB compute/install time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA) TYPE: TBA-MRT-OSPF-4 (To Be Allocated by IANA)
skipping to change at page 10, line 43 skipping to change at page 10, line 11
understand [RFC5250]. So, when a restarting router receives a self- understand [RFC5250]. So, when a restarting router receives a self-
originated link-state type 10 Opaque LSA whose Option Type it does originated link-state type 10 Opaque LSA whose Option Type it does
not recognize, it can (in principle) flood it or purge it. Purging not recognize, it can (in principle) flood it or purge it. Purging
an unknown self-originated Opaque LSA is the most reasonable thing to an unknown self-originated Opaque LSA is the most reasonable thing to
do. 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 [RFC7812] for details on implementation status.
implementation status.
10. Security Considerations 10. Security Considerations
This OSPF extension is not believed to introduce new security This OSPF extension is not believed to introduce new security
concerns. It relies upon the security architecture already provided concerns. It relies upon the security architecture already provided
for Router LSAs and Router Information LSAs. for Router LSAs and Router Information LSAs.
11. 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
skipping to change at page 12, line 6 skipping to change at page 11, line 23
IANA is requested to allocate a value from the OSPFv3 Extended-LSA IANA is requested to allocate a value from the OSPFv3 Extended-LSA
sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT- sub-TLV registry [I-D.ietf-ospf-ospfv3-lsa-extend] for the MRT-
Ineligible Link sub-TLV (TBA-MRT-OSPF-3). 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., Roy, A., Goethals, D., Vallem, V., and F.
LSA Extendibility", draft-ietf-ospf-ospfv3-lsa-extend-09 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3-
(work in progress), November 2015. lsa-extend-14 (work in progress), April 2017.
[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]
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, [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>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <http://www.rfc-editor.org/info/rfc5250>. July 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 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <http://www.rfc-editor.org/info/rfc7770>. February 2016, <http://www.rfc-editor.org/info/rfc7770>.
[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
DOI 10.17487/RFC7811, June 2016,
<http://www.rfc-editor.org/info/rfc7811>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<http://www.rfc-editor.org/info/rfc7812>.
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
Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc- Maximally Redundant Trees", draft-atlas-rtgwg-mrt-mc-
arch-02 (work in progress), July 2013. arch-02 (work in progress), July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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 [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, DOI 10.17487/RFC5715, January Convergence", RFC 5715, DOI 10.17487/RFC5715, January
2010, <http://www.rfc-editor.org/info/rfc5715>. 2010, <http://www.rfc-editor.org/info/rfc5715>.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
 End of changes. 21 change blocks. 
66 lines changed or deleted 46 lines changed or added

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