One document matched: draft-psarkar-spring-mpls-anycast-segments-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-psarkar-spring-mpls-anycast-segments-00" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>Anycast Segments in MPLS based SPRING</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar" role="editor">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>psarkar@juniper.net</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<date day="6" month="July" year="2015"/>
<workgroup>SPRING Working Group</workgroup>
<keyword>SPRING</keyword>
<keyword>Anycast Segments</keyword>
<abstract>
<t>Instead of forwarding to a specific device or to all devices in a group,
anycast addresses, let network devices forward a packet to (or steer it
through) one or more topologically nearest devices in a specific group of
network devices. <xref target="I-D.ietf-spring-segment-routing"/> extended
the use of anycast addresses to a SPRING network, wherein a group of
SPRING-capable devices can represent a anycast address, by having the same
SRGB label block provisioned on all the devices and each one of them
advertising the same anycast prefix segment (or Anycast SID).</t>
<t>This document describes a proposal for implementing anycast prefix
segments in SPRING, without the need to have the same SRGB block (label
ranges) provisioned across all the member devices in the group. Each
node can be provisioned with a separate SRGB from the label range
supported by the specfic hardware platform.</t>
</abstract>
<note 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">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction" anchor='intro'>
<t> Anycast is a network addressing scheme and routing methodology in which
packets from a single source device are forwarded to the topologically nearest
node in a group of potential receiving devices, all identified by the same
anycast address. There are various useful usecases of anycast addresses, and
discussion of the same are outside the scope of this document.</t>
<t> <xref target="I-D.ietf-spring-segment-routing"/> extended the use of
anycast addresses to SPRING networks. An operator may combine a group of
SPRING-enabled nodes to form a anycast group, by picking a anycast address
and a segment identifier (hereon referred to as SID) to represent the group,
and then provisioning all the nodes with the same address and SID. Once
provisioned, each device in the group advertises the corresponding anycast
address in it's IGP link-state advertisements along with the SID provisioned.
Source devices on receiving such anycast prefix segment advertisements,
finds out the topologically nearest device that originated the anycast segment
and forwards packets destined to the same on the shortest-path to the nearest
device.</t>
<t> <xref target="I-D.ietf-spring-segment-routing"/> also requires all devices
in a given anycast group to implement the exact same SRGB block. While this
requirement will always be met in SPRING network deployed over IPV6 forwarding
plane <xref target="I-D.previdi-6man-segment-routing-header"/>, the same
may not be easily met in all SPRING deployments over MPLS dataplane
<xref target="I-D.ietf-spring-segment-routing-mpls"/>. </t>
<t> In MPLS-based SPRING deployments the segments on a given source router
are actually mapped to a MPLS labels allocated from the local label pool
carved out by the device for accomodating the SRGB block. In multi-vendor
deployments with various types of devices deployed in the same network
topology, such a anycast group may contain a good combination of devices
from different vendors and have different internal hardware capabilities.
In such environments it is not sufficient to assume that all the devices in
a anycast group will be able to allocate exactly the same range of labels
for implementing the SRGB. In reality, getting a common range of labels
among all the various vendors is not feasible.
</t>
<t> This documents provides mechanisms to implement a anycast segments with
any kind of device in a multi-vendor netwrok deployment without requiring to
provision the same exact range of labels for SRGB on all the devices.</t>
</section>
<section anchor='problem-stmt' title='Problem Statement'>
<t> To better illustrate the problem let us consider an example topology
using anycast segments as shown in
<xref target="example-topology-1"/> below.</t>
<figure anchor="example-topology-1"
title="Topology 1">
<artwork align="center">
+--------------+
| Group A |
| 192.0.1.1/32 |
| SID:100 |
| |
+-----------A1---A3----------+
| | | \ / | | |
SID:10 | | | / | | | SID:30
1.1.1.1/32 | | | / \ | | | 1.1.1.3/32
PE1------R1----------A2---A4---------R3------PE3
\ /| | | |\ /
\ / | +--------------+ | \ /
\ / | | \ /
/ | | /
/ \ | | / \
/ \ | +--------------+ | / \
/ \| | | |/ \
PE2------R2----------B1---B3----+----R4------PE4
1.1.1.2/32 | | | \ / | | | 1.1.1.4/32
SID:20 | | | / | | | SID:40
| | | / \ | | |
+-----+-----B2---B4----+-----+
| |
| Group B |
| 192.0.2.1/32 |
| SID:200 |
+--------------+
</artwork>
</figure>
<t> In <xref target="example-topology-1"/> above, there are two groups of transit
devices. Group A consists of devices {A1, A2, A3 and A4}. They are all provisioned
with the anycast address 192.0.1.1/32 and the anycast SID 100. Similarly, group B
consists of devices {B1, B2, B3 and B4} and are all provisioned with the anycast
address 192.0.1.2/32, anycast SID 200. In the above network topology, each PE
device is connected to two routers in each of the groups A and B. </t>
<t>Following are all the possible ECMP paths between the various pairs of PE
devices.
<list style="symbols">
<t>P1: via {R1, A1, A3, R3} </t>
<t>P2: via {R1, A1, A4, R3} </t>
<t>P3: via {R1, A2, A3, R3} </t>
<t>P4: via {R1, A2, A4, R3} </t>
<t>P5: via {R2, B1, B3, R4} </t>
<t>P6: via {R2, B1, B4, R4} </t>
<t>P7: via {R2, B2, B3, R4} </t>
<t>P8: via {R2, B2, B4, R4} </t>
</list>
</t>
<t> As seen above, there is always eight ECMP paths between each of pair of
PE devices. The network operator may not wish to utilize all possible ECMP paths
for all possible types of traffic flowing between a given pair of PE devices. It
may be more useful for use paths P1, P2, P3 and P4 for certain types of traffic
and use paths P5, P6, P7 and P8 for all other types of traffic between the same
PE devices. If so desired, operators may use these anycast groups A and B and the
corresponding anycast segment to impose a segment-list to forward the respective
traffic flows over the desired specific paths as shown below.
<xref target="topology-2"/> below depicts a expanded view of the paths
via group A. The range labels allocated for SRGB on each of the devices in
group A are also mentioned in this diagram.</t>
<figure anchor="topology-2"
title="Transit paths via anycast group A">
<artwork align="center">
+-------------------------+
| Group A |
| 192.0.1.1/32 |
| SID:100 |
|-------------------------|
| |
| SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30
PE1---+ +-------A1-------------A3-------+ +---PE3
\ / | | \ / | | \ /
\ / | | +-----+ / | | \ /
SRGB: \ / | | \ / | | \ / SRGB:
(7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \
/ \ | | +-----+ \ | | / \
/ \ | | / \ | | / \
PE2---+ +-------A2-------------A4-------+ +---PE4
SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)|
| |
+-------------------------+
</artwork>
</figure>
<t> In the above topology, if device PE1 (or PE2) requires to send a packet
to the device PE3 (or PE4) it needs to encapsulate the packet in a MPLS
payload with the following stack of labels.
<list style='symbols'>
<t> Label allocated R1 for anycast SID 100 (outer label)</t>
<t> Label allocated by the nearest router in group A for SID 30 (for destination PE3)</t>
</list>
While the first label is easy to compute, in this case since there are more than
one topologically nearest devices (A1 and A2), unless A1 and A2 implement same exact
SRGB, determining the second label is impossible. In all likeness, devices A1 and A2
may be devices from different hardware vendors and it may not implement the same exact
SRGB label ranges. In such cases, separate labels are allocated by A1 and A2 (1030
and 2030 respectively, in the above example). Hence, PE1 (or PE2) cannot compute an
appropriate label stack to steer the packet exclusively through the group A devices.
Same holds true for devices PE3 and PE4 when trying to send a packet to PE1 or PE2.</t>
</section>
<section anchor='solution' title='Solution'>
<t> </t>
<section anchor='anycast-seg-lbl'
title='Anycast Segment Label'>
<t> This document introduces the term 'Anycast Segment Label' to define the label
allocated by a device to advertise reachability for the specific anycast prefix
segment. The value of this label is derived by applying the SID index associated
with the anycast prefix segment as an offset to the SRGB of the specific device.
<xref target='any-seg-label'/> below shows the labels allocated by the various
devices in <xref target='topology-2'/> for the anycast prefix segment with SID
100.</t>
<texttable anchor="any-seg-label"
title="Anycast Segment Label Allocation">
<ttcol align="left">Anycast-SID</ttcol>
<ttcol align="left">Device</ttcol>
<ttcol align="left">SRGB</ttcol>
<ttcol align="left">Anycast-Segment-Label</ttcol>
<c>100</c>
<c>R1</c>
<c>7000-8000</c>
<c>7100</c>
<c>100</c>
<c>A1</c>
<c>1000-2000</c>
<c>1100</c>
<c>100</c>
<c>A2</c>
<c>2000-3000</c>
<c>2100</c>
<c>100</c>
<c>A3</c>
<c>3000-4000</c>
<c>3100</c>
<c>100</c>
<c>A4</c>
<c>4000-5000</c>
<c>4100</c>
<c>100</c>
<c>R3</c>
<c>6000-7000</c>
<c>6100</c>
</texttable>
</section>
<section anchor='virt-sid-table'
title='Virtual SID Label Lookup Table'>
<t> When a MPLS packet on the wire first hits a device, the forwarding hardware
reads the topmost label in the MPSL header and looks up the default label lookup
table associated with the interface on which the label has been received. This
table is generally called LFIB. The range of labels found in the LFIB constitutes
the default label space.</t>
<t> This document introduces a separate virtual label lookup table (hereafter
referred to as Virtual LFIB or V-LFIB), that represents a label space which is
also separate from the actual label space represented by the default LFIB. The
label value may be present in both the default and Virtual LFIB. However the
forwarding semantics associated with the label under the default and Virtual
LFIB may not be same. Following are the fields of a typical entry of this
table.
<list style="symbols">
<t>SID-Index: The SID index assoicated with a prefix segment originated by
another device in the same network. This is also the key field for this table.</t>
<t>Forwarding Semantics: This is once again one or more tuples of following
items.
<list style="symbols">
<t>Outgoing-Label: The label(s) allocated by the neighbor device(s) on the
shortest-path to the topologically nearest originator(s) of the prefix
segment.</t>
<t>Outgoing-link: The link(s) connecting the device to the neighbor device(s)
on the shortest path to the topologically nearest originator(s) of the prefix
segment.</t>
</list></t>
</list>
</t>
<t> This document proposes that, any device, when provisioned with one or more
anycast prefix segment (address and SID), it MUST create a Virtual LFIB table.
Such a device MUST add an entry in the Virtual LFIB for each unicast and anycast
prefix segments learnt from a remote device, if and only if the same prefix has
not been provisioned on the device. The device SHOULD NOT add a entry for any
of the Anycast or Node prefix segments that it has advertised itself. However if
the device has learnt any anycast prefix segment from a remote device, and the
same is not provisioned on this device, the device MUST include the same in the
Virtual LFIB table.</t>
<t>In cases where a prefix segment is reachable via multiple shortest paths on a
given device, the corresponding entry for the prefix SID MUST have as many
forwarding entries in the Virtual LFIB table as the number of shortest-paths
found for the corresponding prefix on the device. .</t>
<t><xref target='table-1'/> below shows how the Virtual LFIB table on each of
devices in group A should look like. Please note that some of the prefix segments
has multiple forwarding semantics associated with them. For example, on device A1,
the prefix SID 10 (originated by PE3) is reachable through its neighbors A3 and A4.
And as per the SRGB advertised by A3 and A4, the labels allocated by A3 and A4 are
3030 and 4030 respectively. Hence A1 has added two forwarding entries for the
prefix SID 30 in its Virtual LFIB table.</t>
<t>Also please note that none of the devices in the anycast group have included
the anycast SID 100 in the Virtual LFIB table, since the same has already been
provisioned on these devices.</t>
<t> When a device receives a MPLS packet with the anycast segment label associated
with one of the anycast prefix segments provisioned on the same device, the device
MUST use the Virtual LFIB table to lookup the next label that follows the anycast
segment label in the stack of labels found in the MPLS header. Refer to
<xref target='pfx-segment-pgm'/> for more details.</t>
<t> Following forwarding instructions MUST be installed in the MPLS data-plane for
each entry in the Virtual LFIB entry.
<list style='symbols'>
<t> If the label at the top of the stack matches any of the prefix SIDs in the
Virtual LFIB table,
<list>
<t>If there are multiple forwarding tuples associated with matching table
entry,
<list>
<t>Select one forwarding tuple. (Criteria to select one is outside the scope
of this document.)</t>
</list></t>
<t>Else,
<list>
<t>Select the single forwarding tuple available.</t>
</list></t>
<t>Replace the Prefix SID index found at top of the MPLS label stack in the
packet received, with the 'Outgoing-label' from the selected forwarding tuple.</t>
<t>Forward the modified packet onto the 'Outgoing-link' as specified in the
selected forwarding tuple.</t>
<t>Ensure the next label lookup is launched on the default LFIB table.</t>
</list></t>
</list></t>
<figure anchor="table-1"
title="Virtual LFIB Table Setup">
<artwork align="center">
+========+============+=======+========================+
| | | Forwarding Semantics |
| Device | Prefix SID |--------------------------------|
| | | Outgoing-Label | Outgoing-Link |
+========+============+================+===============+
| A1 | 10 | 7010 | A1->R1 |
| +------------+----------------+---------------+
| | 20 | 7020 | A1->R1 |
| +------------+----------------+---------------+
| | 30 | 3030 | A1->A3 |
| | | 4030 | A1->A4 |
| +------------+----------------+---------------+
| | 40 | 3040 | A1->A3 |
| | | 4040 | A1->A4 |
+========+============+================+===============+
| A2 | 10 | 7010 | A2->R1 |
| +------------+----------------+---------------+
| | 20 | 7020 | A2->R1 |
| +------------+----------------+---------------+
| | 30 | 3030 | A2->A3 |
| | | 4030 | A2->A4 |
| +------------+----------------+---------------+
| | 40 | 3040 | A2->A3 |
| | | 4040 | A2->A4 |
+========+============+================+===============+
| A3 | 10 | 1010 | A3->A1 |
| | | 2010 | A3->A2 |
| +------------+----------------+---------------+
| | 20 | 1020 | A3->A1 |
| | | 2020 | A3->A2 |
| +------------+----------------+---------------+
| | 30 | 6030 | A3->R3 |
| +------------+----------------+---------------+
| | 40 | 6040 | A3->R3 |
+========+============+================+===============+
| A4 | 10 | 1010 | A4->A1 |
| | | 2010 | A4->A2 |
| +------------+----------------+---------------+
| | 20 | 1020 | A4->A1 |
| | | 2020 | A4->A2 |
| +------------+----------------+---------------+
| | 30 | 6030 | A4->R3 |
| +------------+----------------+---------------+
| | 40 | 6040 | A4->R3 |
+========+============+================+===============+
</artwork>
</figure>
</section>
<section anchor='lbl-stack-comp'
title='Label Stack Computation'>
<t> Any MPLS device that tries to encapsulate any kind of traffic into a
SPRING-based MPLS payload (hereafter referred to as the ingress device)
and steer it through a series of SPRING adjacency and/or unicast/anycast
prefix segments, needs to compute an appropriate stack of MPLS labels and
put it in the outgoing packet. Alternatively, in a SDN environment, the
SDN controller may need to compute the label stack and install it on the
ingress device. </t>
<t> However in both cases, as illustrated in <xref target='problem-stmt'/>,
for a given ingress device (e.g. PE1 or PE2), there maybe multiple topolgically
nearest devices in a specific anycast group (e.g. A1 and A2), even through
there is only out-going link from the source device(e.g. PE1->R1 or PE2-R1).
In such case, when the ingress device (or the SDN controller) wants to steer
a packet through the anycast group A, it can use the anycast segment label
advertised by the downstream neighbor of the ingress device for the specific
anycast prefix segment. Since the packet may reach any one of the multiple
devices in the group and each of them may have a separate SRGB label range,
choosing the MPLS label for the next segment providing reachability to the
final destination. Also, since the packet steered through a anycast segment
can reach of any of the member device in the anycast group, it is sufficient
to assume that the ingress (or the controller) cannot place an adjacency
segment immediately after a anycast segment in the outgoing packet.</t>
<t> This document proposes the ingress device (or the SDN controller) to
directly use the SID as the label for a prefix segment (can be another
anycast)that immediately follows a given anycast segment already encoded
into the label stack of the outgoing MPLS packet. The ingress (or the
controller) MUST follow the algorithm below to compute the label-stack
it must use to steer a packet through a list of SPRING segments.
<list style='symbols'>
<t>Set 'last_segment' ==> NONE.</t>
<t>For [all 'segments' in Segment_List]
<list>
<t>If {'segment'.type == Adjacency_Segment}
<list>
<t>Set 'label' ==> 'segment'.Adjacency_Segment_Label.</t>
</list></t>
<t>Else
<list>
<t>If {'last_segment'.type == Anycast_Prefix_Segment}
<list>
<t>Set 'label' ==> 'segment'.SID_index.</t>
</list></t>
<t>Else
<list>
<t>Set 'label' ==> 'Prefix_Segment_Label'.</t>
</list></t>
</list></t>
</list></t>
<t>Add 'label' to 'label_stack'.</t>
</list></t>
</section>
<section anchor='advt-pfx-segment'
title='Advertising Anycast Prefix Segments'>
<t> Like unicast prefix segments, anycast prefix segments SHOULD be advertised
in IGP Link-state advertsements using IGP protocol extension for SPRING specified
in <xref target="I-D.ietf-isis-segment-routing-extensions"/>,
<xref target="I-D.ietf-ospf-segment-routing-extensions"/> and
<xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions"/>. This document
does not propose any protocol extension for advertising anycast prefix segments.</t>
<t> However when advertising the anycast segments, the originating device MUST
set the corresponding P-Flag(No-PHP) in ISIS Prefix-SID SubTLV and/or the NP-Flag
(No-PHP) in OSPFv2 and OSPFv3 Prefix-SID SubTLV to 1 and the E-Flag in the same
SubTLVs to 0. Please refer to following for more details on usage of these flags.
<list style="symbols">
<t><xref target="I-D.ietf-isis-segment-routing-extensions">ISIS Prefix-SID SubTLV</xref></t>
<t><xref target="I-D.ietf-ospf-segment-routing-extensions">OSPFv2 Prefix-SID SubTLV</xref></t>
<t><xref target="I-D.ietf-ospf-ospfv3-segment-routing-extensions">OSPFv3 Prefix-SID SubTLV</xref></t>
</list>
The proposal above, ensures that a MPLS packet sent to (or taking transit through)
a given anycast group, always arrives at the topologically nearest device in the
group, with a label that is derived from the device's SRGB, and the SID associated
with the corresponding anycast prefix segment.</t>
<t> In <xref target='topology-2'/>, when PE1 or PE2 intends to steer a packet
destined for PE3 or PE4, through the anycast group A (SID 100), it needs to forward the
packet to R1 (SRGB:7000-8000), after putting the label 7100 (derived from R1's SRGB),
at top of the label stack in the MPLS header. However when the same packet is forwarded
to A1 or A2 (topologicaly nearest devices in group A), R1 shall not POP (or remove) the
label 7100. Instead R1 shall replace it with the label 1100 (while forwarding to A1) or
2100 (while forwarding to A2).</t>
</section>
<section anchor='pfx-segment-pgm'
title='Programming Anycast Prefix Segments'>
<t> The proposal specified in <xref target='advt-pfx-segment'/>, ensures that a MPLS
packet destined to (or steered via) a anycast prefix segment always arrives at the
nearest device in the anycast group with a label derived from the device's SRGB and
the SID associated with the corresponding anycast prefix segment, as the top-most label
label stack in its MPLS header. If this label is also the bottom-most label (S=1),
it means packet has been destined to the anycast segment, and should be consumed by
the local device. If the label is not the bottom-most label (S=0), the packet must
be forwarded to the next segment, for which the next label in the stack should be
consulted. However <xref target='lbl-stack-comp'/> specifies that the next label in
such case, shall be directly the SID associated with the next segment. Since the
SID associated with a prefix segment may directly collide with another label in the
default LFIB table, <xref target='virt-sid-table'/> also proposed to have a Virtual
LFIB table to provide a separate label-space for looking up the next label.</t>
<t> This document specifies that a device provisioned with a given prefix segment
index MUST implement following forwarding semantics for the anycast segment label
(refer to <xref target='anycast-seg-lbl'/>) associated with the anycast prefix segment.
<list style='symbols'>
<t>If the label at the top the stack is a anycast segment label,
<list>
<t>Pop the label.</t>
<t>If bottom-most label in the stack (S=1),
<list>
<t>Send it to host stack for local consumption, as usual.</t>
</list></t>
<t> Else if not the bottom-most label in the stack (S=0),
<list>
<t>Set the Virtual LFIB table as the lookup table for the next label lookup.</t>
<t>Launch a lookup for the next label in the stack.</t>
</list></t>
</list></t>
<t>Else
<list>
<t>Lookup the label in the default LFIB table as usual.</t>
</list></t>
</list></t>
</section>
<section title='Packet Flow'>
<t> <xref target='packet-flow'/> below ilustrate how SPRING-based MPLS packets destined for
PE3 and sourced by PE1 are expected to flow theough when PE1 encapsulates the packet with
an appropriate label stack to steer it through group A devices only</t>
<figure anchor="packet-flow"
title="Packet Flow through MPLS-based SPRING Anycast Segments">
<artwork align="center">
+-------------------------+
| Group A |
| 192.0.1.1/32 |
| SID:100 |
|-------------------------|
| |
| |
---> ---> ---> ---> ---> --->
+----+--+--+ +----+--+--+ +----+--+ +----+--+ +--+ +--+
|7100|30|..| |1100|30|..| |3030|..| |6030|..| |..| |..|
+----+--+--+ +----+--+--+ +----+--+ +----+--+ +--+ +--+
| |
| SRGB: SRGB: |
SID:10 |(1000-2000) (3000-4000)| SID:30
-----PE1---+ +-------A1-------------A3-------+ +---PE3-----
\ / | | \ / | | \ /
\ / | | +-----+ / | | \ /
SRGB: \ / | | \ / | | \ / SRGB:
(7000-8000) R1 | | \ | | R3 (6000-7000)
/ \ | | / \ | | / \
/ \ | | +-----+ \ | | / \
/ \ | | / \ | | / \
-----PE2---+ +-------A2-------------A4-------+ +---PE4-----
SID:20 | SRGB: SRGB: | SID:40
|(2000-3000) (4000-5000)|
| |
---> ---> --->
+----+--+--+ +----+--+ +----+--+
|2100|30|..| |4030|..| |6030|..|
+----+--+--+ +----+--+ +----+--+
| |
| |
+-------------------------+
</artwork>
</figure>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many many thanks to Shraddha Hegde for her valuable inputs.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>N/A. - No protocol changes are proposed in this document.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any change in any of the
protocol specifications. It simply proposes additional inequalities
for selecting LFAs for multi-homed prefixes.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title='Normative References'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
</references>
<references title='Informative References'>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-03.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-previdi-6man-segment-routing-header-06.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-spring-segment-routing-mpls-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-isis-segment-routing-extensions-04.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-segment-routing-extensions-04.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-ospf-ospfv3-segment-routing-extensions-02.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:22 |