One document matched: draft-atlas-mpls-ldp-mrt-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2328 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml">
<!ENTITY RFC4915 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4915.xml">
<!ENTITY RFC4970 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4970.xml">
<!ENTITY RFC5340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY RFC5561 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5561.xml">
<!ENTITY RFC5715 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5715.xml">
<!ENTITY I-D.ietf-rtgwg-mrt-frr-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtgwg-mrt-frr-architecture.xml">
<!ENTITY I-D.atlas-rtgwg-mrt-mc-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-rtgwg-mrt-mc-arch.xml">
<!ENTITY I-D.ietf-mpls-ldp-multi-topology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-multi-topology.xml">
<!ENTITY I-D.wijnands-mpls-mldp-node-protection SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wijnands-mpls-mldp-node-protection.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="no" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-atlas-mpls-ldp-mrt-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="LDP Extensions to Support MRT">LDP Extensions to Support Maximally Redundant Trees</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Alia Atlas" initials="A.K.A." surname="Atlas">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>akatlas@juniper.net</email>
</address>
</author>
<author fullname="Kishore Tiruveedhula" initials="K." surname="Tiruveedhula">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>10 Technology Park Drive</street>
<city>Westford</city>
<region>MA</region>
<code>01886</code>
<country>USA</country>
</postal>
<email>kishoret@juniper.net</email>
</address>
</author>
<author fullname="Chris Bowers" initials="C." surname="Bowers">
<organization>Juniper Networks</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>USA</country>
</postal>
<email>cbowers@juniper.net</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<author fullname="IJsbrand Wijnands" initials="IJ.W." surname="Wijnands">
<organization>Cisco Systems, Inc.</organization>
<address>
<email>ice@cisco.com</email>
</address>
</author>
<date day="4" month="July" year="2014"/>
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Routing</area>
<workgroup>MPLS Working Group</workgroup>
<abstract>
<t>This document specifies extensions to LDP to support the
creation of label-switched paths for Maximally Redundant Trees
(MRT). A prime use of MRTs is for unicast and multicast IP/LDP
Fast-Reroute (MRT-FRR).</t>
<t>The sole protocol extension to LDP is simply the ability to
advertise an MRT Capability. This document describes that
extension and the associated behavior expected for LSRs and LERs
advertising the MRT Capability.</t>
<t>MRT-FRR uses LDP multi-topology extensions and requires three
different multi-topology IDs to be allocated from the LDP MT-ID
space.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes the LDP signaling extension and
associated behavior necessary to support the architecture that
defines how IP/LDP Fast-Reroute can use MRTs <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/>. It is necessary
to read the architecture in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> to understand how
and why the LDP extensions for behavior are needed.</t>
<t>At least one common standardized algorithm, such as the
lowpoint algorithm explained and fully documented in <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>, is required so
that the routers supporting MRT computation consistently compute
the same MRTs. LDP depends on the IGP to compute the MRTs and
alternates. Extensions to OSPF are defined in <xref
target="I-D.atlas-ospf-mrt"/>. Extension to IS-IS are defined in
<xref target="I-D.li-isis-mrt"/></t>
<t>MRT can also be used to protect multicast traffic via either
global protection or local protection.<xref
target="I-D.atlas-rtgwg-mrt-mc-arch"/> An MRT path can be used
to provide node-protection for mLDP traffic via the mechanisms
described in <xref
target="I-D.wijnands-mpls-mldp-node-protection"/>; an MRT path
can also be use to provide link protection for mLDP traffic.</t>
<t>For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR)
creates two alternate destination-based trees separate from the
primary next-hop forwarding used during stable operation. LDP
uses the multi-topology extensions <xref
target="I-D.ietf-mpls-ldp-multi-topology"/> to signal FECs for
these two new forwarding topologies, known as MRT-Blue and
MRT-Red.</t>
<t>In order to create MRT paths and support IP/LDP Fast-Reroute,
a new capability extension is needed for LDP. An LDP
implementation supporting MRT must also follow the described
rules for originating and managing FECs related to MRT, as
indicated by their multi-topology ID. Network reconvergence is
described in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> and the
worst-cast network convergence time can be flooded via the
extension in Section 7 of <xref
target="I-D.atlas-ospf-mrt"/>.</t>
<t>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; an MRT Island is formed of connected supporting
routers and the MRTs are computed inside that island.</t>
</section><!-- End of Introduction !-->
<section title="Requirements Language">
<t>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 <xref
target="RFC2119"/></t>
</section>
<section title="Terminology">
<t>For ease of reading, some of the terminology defined in <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> is repeated here.</t>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="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. The
two MRTs are referred to as MRT-Blue and MRT-Red.</t>
<t hangText="MRT Island: "> From the computing router, the set of
routers that support a particular MRT profile and are connected
via MRT-eligible links.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Rainbow MRT: "> It is useful to have an MT-ID that
refers to the multiple MRT topologies and to the default
topology. This is referred to as the Rainbow MRT MT-ID and is
used by LDP to reduce signaling and permit the same label to
always be advertised to all peers for the same (MT-ID, Prefix).</t>
</list></t>
</section>
<section title="Overview of LDP Signaling Extensions for MRT">
<t>Routers need to know which of their neighbors support MRT.
Supporting MRT indicates several different aspects of behavior, as
listed below.
<list style="numbers">
<t>Support for Multi-Topology (MT) - this MAY also be indicated via
the Multi-Capability MT Capability <xref
target="I-D.ietf-mpls-ldp-multi-topology"/>.</t>
<t>Understand the Rainbow MRT MT-ID and apply the associated labels
to all relevant MT-IDs.</t>
<t>Advertise the Rainbow MRT MT-ID to the appropriate neighbors for
the associated prefix.</t>
<t>If acting as LDP egress for a prefix in the default topology, also advertise and act as egress
for the same prefix in MRT-Red and MRT-Blue.</t>
<t>For a FEC learned from a neighbor that does not support MRT,
originate FECS for MRT-Red and MRT-Blue with the same prefix.
This MRT Island egress behavior is to support an MRT Island
that does not include all routers in the area/level.</t>
</list></t>
<section title="MRT Capability Advertisement">
<t>It is not possible to support MRT without supporting the LDP
multi-topology extensions, but it is possible that the only use of the
multi-topology extensions is for MRT. In that case, a router MAY not
negotiate the multi-topology capability and only negotiate the MRT
Capability with its LDP peer. Negotiation of the MT capability is not
required with negotiation of the MRT capability.</t>
<t>[EDITOR NOTE: How do we deal with different abilities for IPv4 and
IPv6? The MT capability has the Wildcard FEC to indicate this. Do we
just assume??]</t>
<t>A new MRT Capability Parameter TLV is defined, which is defined in
accordance with LDP Capability definition guidelines<xref
target="RFC5561"/>.</t>
<t>The LDP MRT capability can be advertised during the LDP session
initialization or after the LDP session is established. Advertisement
of the MRT capability indicates support of the procedures for
establishing the MRT-Blue and MRT-Red LSP paths detailed in this document.
If the peer has not advertised the MRT capability, then it
indicates that LSR does not support MRT procedures.</t>
<t> If a router advertises the LDP MRT capability to its peer, but
the peer has not advertised the MRT capability, then the router
MUST NOT advertise MRT-related FEC-label bindings to that peer,
until that peer starts to advertise the MRT capability.</t>
<t>The following is the format of the MRT Capability Parameter.</t>
<figure title="MRT Capability TLV Format">
<artwork align="center"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| MRT Capability (IANA) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>Where:
<list style="hanging">
<t hangText="U- and F-bits: "> MUST be 1 and 0, respectively, as per
Section 3. (Signaling Extensions) of LDP Capabilities <xref
target="RFC5561"/>.</t>
<t hangText="MRT Capability: "> TBA-MRT-LDP-1 (To Be Allocated by IANA)</t>
<t hangText="S-bit: "> MUST be 1 if used in LDP "Initialization"
message. MAY be set to 0 or 1 in dynamic "Capability" message to
advertise or withdraw the capability respectively.</t>
<t hangText="Length: "> The length (in octets) of TLV. Its value is
1.</t>
</list></t>
</section>
<section anchor="sec_rainbow" title="Behavior Related to the Rainbow MRT MT-ID">
<t>In Section 10.1 of <xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>,
the need to advertise
different MPLS labels to different neighbors for the same FEC is
described. This can be shortly summarized as either advertising MRT
MT-ID differentiated labels to a neighbor or just advertising the same
MPLS label for the default topology, for MRT-Red and MRT-Blue.
MRT-supporting neighbors in the same domain as the default SPT
next-hop get the differentiated MPLS labels; all other neighbors do
not.</t>
<t>A second use for the Rainbow MRT MT-ID is for an egress LER to send
the Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
penultimate-hop-popping for all three types of FECs (IP Prefix FEC,
MRT-Blue MT-IP Prefix FEC, and MRT-Red MT-IP Prefix FEC).</t>
<t>The use of the Rainbow-FEC by the ABR for non-best-area
advertisements is RECOMMENDED. An ABR MAY advertise the label
for the default topology in separate MRT-Blue and MRT-Red advertisements.
An LSR advertising the MRT capability MUST recognize the Rainbow
MRT MT-ID and associate the advertised label with the specific prefix
with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles
that advertise LDP as the forwarding mechanism.</t>
<t> The value of the Rainbow MRT MT-ID (TBA-MRT-LDP-2)
will be assigned by IANA from the LDP MT-ID space. Prototype experiments have
used the value 3999.</t>
</section>
<section title="MRT-Blue and MRT-Red FECs">
<t>To provide MRT support in LDP, the MT Prefix FEC is used.
<xref target="I-D.ietf-rtgwg-mrt-frr-architecture"/>
contains the IANA request for the MRT-Red and MRT-Blue MT-IDs
associated with the Default MRT Profile.</t>
<t>The MT Prefix FEC encoding is defined in <xref
target="I-D.ietf-mpls-ldp-multi-topology"/> and is used without
alteration for signaling MRT-Blue, MRT-Red and Rainbow MRT FECs.</t>
</section>
</section>
<section title="LDP MRT FEC Advertisements">
<t>This sections describes how and when labels for MRT-Red and
MRT-Blue FECs are advertised. The associated LSPs must be created
before a failure occurs, in order to provide protection paths which
are immediately usable by a PLR.</t>
<section title="Downstream Unsolicited Mode">
<t>If the upstream session is negotiated with the MRT capability, the
Egress LER advertises via a Rainbow MRT FEC an allocated MPLS label;
this may be Explicit Null, Implicit Null, or another value.</t>
<t>Based on the MRT algorithm <xref
target="I-D.ietf-rtgwg-mrt-frr-algorithm"/>, the IGP computes the
MRT-Red and MRT-Blue disjoint paths at Ingress and Transit LSRs. Once
the IGP computes the MRT-Red and MRT-Blue next-hops, LDP will
advertise the Label Mapping for the MRT-Blue and MRT-Red FECs. If a
label is received from a downstream LSR for an MRT-Red or MRT-Blue FEC
where the downstream LSR is capable of MRT, the MRT-Red FEC or
MRT-Blue FEC label is swapped according to the received downstream
label. An LSR may also choose to use the MRT-Red or MRT-Blue path as
an alternate for doing fast-reroute for the local traffic.</t>
<t>When a downstream router is not capable of MRT, the LSR is an MRT
Island Border Router (IBR) and SHOULD advertise Label Bindings for the
MRT-Red FEC and MRT-Blue FEC as well as the associated normal
topology. The normal topology's primary next-hops will be used to
forward traffic received for the MRT-Red FEC or the MRT-Blue FEC where
the FEC's destination is outside the MRT Island. This functionality
is critical for partial deployment scenarios.</t>
</section>
<section title="Downstream On Demand Mode">
<t>After the IGP computes the MRT-Red and MRT-Blue paths, the IGP MAY
also decide to use either the MRT-Red or MRT-Blue path as a
fast-reroute alternate for the particular FEC. If so, then when in
Downstream On Demand Mode, the LSR sends a Label Request for either
the MRT-Red or MRT-Blue FEC to the downstream LSR. The downstream LSR
responds by either sending a Label Mapping if available or by sending
a Label Request to its downstream LSR. Once a Label Mapping is
received, the associated label may be used as a fast-reroute
alternate to forward IP and LDP traffic.</t>
<t>A Label Mapping may be available in the following circumstances:
<list style="symbols">
<t>The LSR is acting as Egress</t>
<t>A Label Mapping was already received from its downstream router</t>
<t>A Label Mapping for the default topology FEC was received and the
downstream router is not capable of MRT or is in a different MRT
Island.</t>
</list></t>
</section>
<section title="Inter-Area">
<t>As discussed in <xref target="sec_rainbow"/>, the Rainbow MRT FEC
is defined to facilitate signaling the same label for multiple
topologies. Section 9 of <xref
target="I-D.ietf-rtgwg-mrt-frr-architecture"/> recommends that traffic
leaving an OSPF area or IS-IS level SHOULD use the default topology's
shortest-path-tree next-hops instead of remaining on the MRT-Red or
MRT-Blue paths. If an LDP peer is in the same OSPF area or IS-IS
level as the primary next-hop, then LDP SHOULD advertise different
label values for a given set of MRT-Red FEC, MRT-Blue FEC, and FEC,
unless Explicit-Null or Implicit-Null is appropriate. If an LDP peer
is in a different OSPF area or IS-IS level from the primary next-hop,
then LDP SHOULD either advertise the same label value for the given
set of MRT-Red FEC, MRT-Blue FEC, and FEC or advertise a single label
for the Rainbow MRT FEC, whose behavior is defined in <xref
target="sec_rainbow"/>.</t>
</section>
</section>
<section title="Security Considerations">
<t>This LDP extension is not believed to introduce new security
concerns. It relies upon the security architecture already provided
for LDP.</t>
</section>
<section title="IANA Considerations">
<t>Please allocate a value for the new LDP Capability TLV from the
LDP registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1).
</t>
<t>Please allocate a value from the LDP Multi-Topology (MT) ID Name Space
<xref target="I-D.ietf-mpls-ldp-multi-topology"/>: Rainbow MRT MT-ID (TBA-MRT-LDP-2).
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Ross Callon for his suggestions.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC5561;
&I-D.ietf-mpls-ldp-multi-topology;
<reference anchor="I-D.ietf-rtgwg-mrt-frr-architecture">
<front>
<title>An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees</title>
<author fullname="Alia K. Atlas" initials="A." surname="Atlas"/>
<author fullname="Robert Kebler" initials="R.K." surname="Kebler"/>
<author fullname="Chris Bowers" initials="C." surname="Bowers"/>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi"/>
<author fullname="András Császár" initials="A.C." surname="Császár"/>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"/>
<author fullname="Maciek Konstantynowicz" initials="M.K." surname="Konstantynowicz"/>
<author fullname="Russ White" initials="R.W." surname="White"/>
<date month="July" day="4" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-rtgwg-mrt-frr-architecture-04"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-rtgwg-mrt-frr-architecture-04.txt"/>
</reference>
</references>
<references title="Informative References">
&RFC2119;
&RFC4915;
&RFC5715;
&I-D.atlas-rtgwg-mrt-mc-arch;
&I-D.wijnands-mpls-mldp-node-protection;
<reference anchor="I-D.ietf-rtgwg-mrt-frr-algorithm">
<front>
<title>Algorithms for computing Maximally Redundant Trees for IP/LDP Fast-Reroute</title>
<author fullname="Gábor Sándor Enyedi" initials="G.S.E." surname="Enyedi"/>
<author fullname="András Császár" initials="A.C." surname="Császár"/>
<author fullname="Alia K. Atlas" initials="A." surname="Atlas"/>
<author fullname="Chris Bowers" initials="C." surname="Bowers"/>
<author fullname="Abishek Gopalan" initials="A.G." surname="Gopalan"/>
<date month="July" day="4" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-rtgwg-mrt-frr-algorithm-01"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-rtgwg-mrt-frr-algorithm-01.txt"/>
</reference>
<reference anchor="I-D.atlas-ospf-mrt">
<front>
<title>OSPF Extensions to Support Maximally Redundant Trees</title>
<author fullname="Alia K. Atlas" initials="A." surname="Atlas"/>
<author fullname="Shraddha Hegde" initials="S." surname="Hegde"/>
<author fullname="Chris Bowers" initials="C." surname="Bowers"/>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"/>
<date month="July" day="4" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-atlas-ospf-mrt-02"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-atlas-ospf-mrt-02.txt"/>
</reference>
<reference anchor="I-D.li-isis-mrt">
<front>
<title>Intermediate System to Intermediate System (IS-IS) Extensions for Maximally Redundant Trees(MRT)</title>
<author fullname="Zhenbin Li" initials="Z. " surname="Li"/>
<author fullname="Nan Wu" initials="N. " surname="Wu"/>
<author fullname="Quintin Zhao" initials="Q." surname="Zhao"/>
<author fullname="Alia K. Atlas" initials="A." surname="Atlas"/>
<author fullname="Chris Bowers" initials="C." surname="Bowers"/>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura"/>
<date month="July" day="4" year="2014"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-li-isis-mrt-01"/>
<format type="TXT"
target="http://www.ietf.org/internet-drafts/draft-li-isis-mrt-01.txt"/>
</reference>
</references>
<!-- Change Log
v00 2013-07-02 AKA Initial version
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:42 |