One document matched: draft-ginsberg-spring-conflict-resolution-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?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-ginsberg-spring-conflict-resolution-01.txt"
ipr="trust200902">
<front>
<title abbrev="sr-conflict-resolution">Segment Routing Conflict
Resolution</title>
<author fullname="Les Ginsberg" initials="L" surname="Ginsberg">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>510 McCarthy Blvd.</street>
<city>Milpitas</city>
<code>95035</code>
<region>CA</region>
<country>USA</country>
</postal>
<email>ginsberg@cisco.com</email>
</address>
</author>
<author fullname="Peter Psenak" initials="P" surname="Psenak">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Apollo Business Center Mlynske nivy 43</street>
<city>Bratislava</city>
<code>821 09</code>
<region/>
<country>Slovakia</country>
</postal>
<email>ppsenak@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S" surname="Previdi">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Via Del Serafico 200</street>
<city>Rome</city>
<code>0144</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Martin Pilka" initials="M" surname="Pilka">
<organization>Pantheon Technologies</organization>
<address>
<postal>
<street/>
<city/>
<code/>
<country/>
</postal>
<email>martin.pilka@pantheon.tech</email>
</address>
</author>
<date day="12" month="April" year="2016"/>
<area>Routing Area</area>
<workgroup>Networking Working Group</workgroup>
<keyword/>
<abstract>
<t>In support of Segment Routing (SR) routing protocols advertise a
variety of identifiers used to define the segments which direct
forwarding of packets. In cases where the information advertised by a
given protocol instance is either internally inconsistent or conflicts
with advertisements from another protocol instance a means of achieving
consistent forwarding behavior in the network is required. This document
defines the policies used to resolve these occurrences.</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 RFC 2119 [RFC2119].</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Segment Routing (SR) as defined in [SR-ARCH] utilizes forwarding
instructions called "segments" to direct packets through the network.
Depending on the forwarding plane architecture in use, routing protocols
advertise various identifiers which define the permissible values which
can be used as segments, which values are assigned to specific prefixes,
etc. Where segments have global scope it is necessary to have
non-conflicting assignments - but given that the advertisements may
originate from multiple nodes the possibility exists that advertisements
may be received which are either internally inconsistent or conflicting
with advertisements originated by other nodes. In such cases it is
necessary to have consistent resolution of conflicts network-wide in
order to avoid forwarding loops.</t>
<t>The problem to be addressed is protocol independent i.e., segment
related advertisements may be originated by multiple nodes using
different protocols and yet the conflict resolution MUST be the same on
all nodes regardless of the protocol used to transport the
advertisements.</t>
<t>The remainder of this document defines conflict resolution policies
which meet these requirements. All protocols which support SR MUST
adhere to the policies defined in this document.</t>
</section>
<section title="SR Global Block Inconsistency">
<t>In support of an MPLS dataplane routing protocols advertise an SR
Global Block (SRGB) which defines a set of label ranges reserved for use
by the advertising node in support of SR. The details of how protocols
advertise this information can be found in the protocol specific drafts
e.g., [SR-OSPF] and [SR-IS-IS]. However the protocol independent
semantics are illustrated by the following example:</t>
<t><figure>
<artwork><![CDATA[The originating router advertises the following ranges:
Range 1: (100, 199)
Range 2: (1000, 1099)
Range 3: (500, 5990
The receiving routers concatenate the ranges and build the Segment
Routing Global Block (SRGB) as follows:
SRGB = (100, 199)
(1000, 1099)
(500, 599)
The indices span multiple ranges:
index=0 means label 100
...
index 99 means label 199
index 100 means label 1000
index 199 means label 1099
...
index 200 means label 500
...]]></artwork>
</figure></t>
<t>Note that the ranges are an ordered set - what labels are mapped to a
given index depends on the placement of a given label range in the set
of ranges advertised.</t>
<t>For the set of ranges to be usable the ranges MUST be disjoint.
Sender behavior is defined in various SR protocol drafts such as
[SR-IS-IS] which specify that senders MUST NOT advertise overlapping
ranges.</t>
<t>Receivers of SRGB ranges MUST validate the SRGB ranges advertised by
other nodes. If the advertised ranges do not conform to the restrictions
defined in the respective protocol specification receivers MUST ignore
all advertised SRGB ranges from that node. Operationally the node is
treated as though it did not advertise any SRGB ranges. [SR-MPLS]
defines the procedures for mapping global SIDs to outgoing labels.</t>
<t>Note that utilization of local SIDs (e.g. adjacency SIDs) advertised
by a node is not affected by the state of the advertised SRGB.</t>
</section>
<section title="Segment Identifier Conflicts">
<t>In support of an MPLS dataplane Segment identifiers (SIDs) are
advertised and associated with a given prefix. SIDs may be advertised in
the prefix reachability advertisements originated by a routing protocol.
SIDs may also be advertised by a Segment Routing Mapping Server
(SRMS).</t>
<t>Mapping entries have an explicit context which includes the topology
and the SR algorithm. A generalized mapping entry can be represented
using the following definitions:</t>
<t><figure>
<artwork><![CDATA[ Pi - Initial prefix
Pe - End prefix
L - Prefix length
Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)
Si - Initial SID value
Se - End SID value
R - Range value
T - Topology
A - Algorithm
A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)
Pe = (Pi + ((R-1) << (Lx-L))
Se = Si + (R-1)
Note that the SID advertised in a prefix reachability advertisement
can be more generally represented as a mapping entry with a range
of 1.
]]></artwork>
</figure>Conflicts in SID advertisements may occur as a result of
misconfiguration. Conflicts may occur either in the set of
advertisements originated by a single node or between advertisements
originated by different nodes. When conflicts occur, it is not possible
for routers to know which of the conflicting advertisements is
"correct". If a router chooses to use one of the conflicting entries
forwarding loops and/or blackholes may result unless it can be
guaranteed that all other routers in the network make the same choice.
Making the same choice requires that all routers have identical sets of
advertisements and that they all use the same selection algorithm.</t>
<section title="Conflict Types">
<t>Various types of conflicts may occur.</t>
<section title="Prefix Conflict">
<t>When different SIDs are assigned to the same prefix we have a
"prefix conflict". Prefix conflicts are specific to mapping entries
sharing the same topology and algorithm. Consider the following sets
of advertisements:</t>
<t><figure>
<artwork><![CDATA[(192.0.2.120/32, 200, 1, 0, 0)
(192.0.2.120/32, 30, 1, 0, 0)
The prefix 192.0.2.120/32 has been assigned two different SIDs:
200 by the first advertisement
30 by the second advertisement
(2001:DB8::1/128, 400, 1, 2, 0)
(2001:DB8::1/128, 50, 1, 2, 0)
The prefix 2001:DB8::1/128 has been assigned two different SIDs:
400 by the first advertisement
50 by the second advertisement]]></artwork>
</figure></t>
<t>Prefix conflicts may also occur as a result of overlapping prefix
ranges. Consider the following sets of advertisements:</t>
<t><figure>
<artwork><![CDATA[(192.0.2.1/32, 200, 200, 0, 0)
(192.0.2.121/32, 30, 10, 0, 0)
Prefixes 192.0.2.121/32 - 192.0.2.130/32 are assigned two
different SIDs:
320 through 329 by the first advertisement
30 through 39 by the second advertisement
(2001:DB8::1/128, 400, 200, 2, 0)
(2001:DB8::121/128, 50, 10, 2, 0)
Prefixes 2001:DB8::121/128 - 2001:DB8::130/128 are assigned
two different SIDs:
420 through 429 by the first advertisement
50 through 59 by the second advertisement]]></artwork>
</figure></t>
<t>The second set of examples illustrate a complication - only part
of the range advertised in the first advertisement is in conflict.
It is logically possible to isolate the conflicting portion and try
to use the non-conflicting portion(s) at the cost of increased
implementation complexity.</t>
<t>A variant of the overlapping prefix range is a case where we have
overlapping prefix ranges but no actual SID conflict.</t>
<figure>
<artwork><![CDATA[(192.0.2.1/32, 200, 200, 0, 0)
(192.0.2.121/32, 320, 10, 0, 0)
(2001:DB8::1/128, 400, 200, 2, 0)
(2001:DB8::121/128, 520, 10, 2, 0)
]]></artwork>
</figure>
<t>Although there is prefix overlap between the two IPv4 entries
(and the two IPv6 entries) the same SID is assigned to all of the
shared prefixes by the two entries.</t>
<t><figure>
<artwork><![CDATA[Given two mapping entries:
(P1/L1, S1, R1, T1, A1) and (P2/L2, S2, R2, T2, A2) where P1 <= P2
a prefix conflict exists if all of the following are true:
1)The prefixes are in the same address family.
2)(L1 == L2) && (T1 == T2) && (A1 == A2)
3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2)
]]></artwork>
</figure></t>
</section>
<section title="SID Conflict">
<t>When the same SID has been assigned to multiple prefixes we have
a "SID conflict". SID conflicts are independent of address-family,
independent of prefix len, independent of topology, and independent
of algorithm. A SID conflict occurs when a mapping entry which has
previously been checked to have no prefix conflict assigns one or
more SIDs that are assigned by another entry which also has no
prefix conflicts. Consider the following examples:</t>
<figure>
<artwork><![CDATA[(192.0.2.1/32, 200, 1, 0, 0)
(192.0.2.222/32, 200, 1, 0, 0)
SID 200 has been assigned to 192.0.2.1/32 by the
first advertisement.
SID 200 has been assigned to 192.0.2.222/32 by the
second advertisement.
(2001:DB8::1/128, 400, 1, 0, 0)
(2001:DB8::1/128, 400, 1, 0, 1)
SID 400 has been assigned to 2001:DB8::1/128 for algorithm 0
by the first advertisement.
SID 400 has been assigned to 2001:DB8::1/128 for algorithm 1
by the second advertisement.
(192.0.2.1/32, 400, 1, 0, 0)
(2001:DB8::1/128, 400, 1, 0, 0)
SID 400 has been assigned to 192.0.2.1/32 by the
first advertisement.
SID 400 has been assigned to 2001:DB8::1/128 by the
second advertisement.
]]></artwork>
</figure>
<t>SID conflicts may also occur as a result of overlapping SID
ranges. Consider the following sets of advertisements:</t>
<figure>
<artwork><![CDATA[(192.0.2.1/32, 200, 200, 0, 0)
(198.51.100.1/32, 300, 10, 0, 0)
SIDs 300 - 309 have been assigned to two different prefixes.
The first advertisement assigns these SIDs
to 192.0.2.101/32 - 192.0.2.110/32.
The second advertisement assigns these SIDs to
198.51.100.1/32 - 198.51.100.10/32.
(2001:DB8::1/128, 400, 200, 0, 0)
(2001:DB8:1::1/128, 500, 10, 0, 0)
SIDs 500 - 509 have been assigned to two different prefixes.
The first advertisement assigns these SIDs to
2001:DB8::65/128 - 2001:DB8::6E/128.
The second advertisement assigns these SIDs to
2001:DB8:1::1 - 2001:DB8:1::A/128.
(192.0.2.1/32, 200, 200, 0, 0)
(2001:DB8::1/128, 300, 10, 0, 0)
SIDs 300 - 309 have been assigned to two different prefixes.
The first advertisement assigns these SIDs
to 192.0.2.101/32 - 192.0.2.110/32.
The second advertisement assigns these SIDs to
2001:DB8::1/128 - 2001:DB8::A/128.
]]></artwork>
</figure>
<t>The second set of examples illustrate a complication - only part
of the range advertised in the first advertisement is in conflict.
It is logically possible to isolate the conflicting portion and try
to use the non-conflicting portion(s) at the cost of increased
implementation complexity.</t>
<t><figure>
<artwork><![CDATA[Given two mapping entries:
(P1/L1, S1, R1, T1, A1) and (P2/L2, S2, R2, T2, A2) where S1 <= S2
a SID conflict exists if all of the following are true:
1)S1e >= S2
2)(AF1 != AF2) || (L1 != L2) || (T1 != T2) || (A1 != A2)
|| (P1 + ((S2-S1) << (Lx-L1)) != P2
NOTE: The last calculation is valid because it is only done
when the two mapping entries are in the same address family
and have the same prefix length.
]]></artwork>
</figure></t>
</section>
</section>
<section title="Processing conflicting entries">
<t>Two general approaches can be used to process conflicting
entries.</t>
<t><list style="numbers">
<t>Conflicting entries can be ignored</t>
<t>A standard preference algorithm can be used to choose which of
the conflicting entries will be used</t>
</list>The following sections discuss these two approaches in more
detail.</t>
<t>Note: This document does not discuss any implementation details
i.e. what type of data structure is used to store the entries (trie,
radix tree, etc.) nor what type of keys may be used to perform lookups
in the database.</t>
<section title="Policy: Ignore conflicting entries">
<t>In cases where entries are in conflict none of the conflicting
entries are used i.e., the network operates as if the conflicting
advertisements were not present.</t>
<t>Implementations are required to identify the conflicting entries
and ensure that they are not used.</t>
</section>
<section title="Policy: Preference Algorithm/Quarantine">
<t>For entries which are in conflict properties of the conflicting
advertisements are used to determine which of the conflicting
entries are used in forwarding and which are "quarantined" and not
used. The entire quarantined entry is not used.</t>
<t>This approach requires that conflicting entries first be
identified and then evaluated based on a preference rule. Based on
which entry is preferred this in turn may impact what other entries
are considered in conflict i.e. if A conflicts with B and B
conflicts with C - it is possible that A does NOT conflict with C.
Hence if as a result of the evaluation of the conflict between A and
B, entry B is not used the conflict between B and C will not be
detected.</t>
</section>
<section title="Policy: Preference algorithm/ignore overlap only">
<t>A variation of the preference algorithm approach is to quarantine
only the portions of the less preferred entry which actually
conflicts. The original entry is split into multiple ranges. The
ranges which are in conflict are quarantined. The ranges which are
not in conflict are used in forwarding. This approach adds
complexity as the relationship between the derived sub-ranges of the
original mapping entry have to be associated with the original entry
- and every time some change to the advertisement database occurs
the derived sub-ranges have to be recalculated.</t>
</section>
<section title="Preference Algorithm">
<t>The following algorithm is used to select the preferred mapping
entry when a conflict exists. Evaluation is made in the order
specified.</t>
<t><list style="numbers">
<t>Smaller range wins</t>
<t>IPv6 entry wins over IPv4 entry</t>
<t>Smaller algorithm wins</t>
<t>Smaller prefix length wins</t>
<t>Smaller starting address (considered as an unsigned integer
value) wins</t>
<t>Smaller starting SID wins</t>
</list></t>
<t>Using smaller range as the highest priority tie breaker makes
advertisements with a range of 1 the most preferred. This associates
a high priority to SID advertisements associated with protocol
prefix advertisements as these always have an implicit range of one.
SR mapping server advertisements (SRMS entries) may have any
configured range - but in cases where they have a range greater than
1 they will be less preferred as compared to any SIDs in prefix
advertisements. This has the nice property that a single
misconfiguratoion of an SRMS entry with a large range will not be
preferred over a large number of SIDs advertised in prefix
reachability advertisements.</t>
</section>
<section title="Use of topology in preference">
<t>The preference rule defined in the previous section does not
include a comparison of topologies. When evaluating prefix conflicts
this is only done when comparing mapping entries associated with the
same topology - so this omission is not significant. However, when
evaluating a SID conflict the topology associated with two mapping
entries need not be the same. The question arises as to what should
be done when all of the attributes specified in the preference rule
are identical but the topologies are different?</t>
<t>The scope of topology identifiers is NOT global. A given routing
protocol has topology identifiers which are consistent within the
protocol area/domain, but if multiple routing protocols are in use
in a network it cannot be guaranteed that the two routing protocols
will use the same identifier for a given topology. This is, in part,
due to the fact that different routing protocols have different
supported ranges for topology identifiers. It is then NOT possible
to guarantee a consistent identifier for a topology on all routers
in a network. Therefore no preference rule can be defined which will
guarantee the same result on all routers when the topology is the
only attribute which differs between two mapping entries. The
following preference rule is defined to handle these cases:</t>
<t>When a SID conflict is detected between two mapping entries and
the only difference between the two entries is the topology, both
entries MUST be ignored in their entirety.</t>
</section>
<section title="Example Behavior">
<t>The following mapping entries exist in the database. For brevity,
Topology/Algorithm is omitted and assumed to be (0,0) in all
entries.</t>
<t><list style="numbers">
<t>(192.0.2.1/32, 100, 1)</t>
<t>(192.0.2.101/32, 200, 1)</t>
<t>(192.0.2.1/32, 400, 300) !Prefix conflict with entries 1 and
2</t>
<t>(198.51.100.40/32, 200,1) !SID conflict with entry 2</t>
</list></t>
<t>The table below shows what mapping entries will be used in the
forwarding plane (Active) and which ones will not be used (Excluded)
under the three candidate policies:</t>
<t><figure>
<artwork><![CDATA[+-----------------------------------------------------------------+
| Policy | Active Entries | Excluded Entries |
+-----------------------------------------------------------------+
| Ignore | | (192.0.2.1/32,100,1) |
| | | (192.0.2.101/32,200,1) |
| | | (192.0.2.1/32,400,300) |
| | | (198.51.100.40/32,200,1)|
+-----------------------------------------------------------------+
| Quarantine | (192.0.2.1/32,100,1) | (192.0.2.1/32,400,300) |
| | (192.0.2.101/32,200,1) | (198.51.100.40/32,200,1)|
+-----------------------------------------------------------------+
| Overlap- | (192.0.2.1/32,100,1) | (198.51.100.40/32,200,1)|
| Only | (192.0.2.101/32,200,1) |*(192.0.2.1/32,400,1) |
| |*(192.0.2.2/32,401,99) |*(192.0.2.101/32,500,1) |
| |*(192.0.2.102/32,501,199)| |
+-----------------------------------------------------------------+
* Derived from (192.0.2.1/32,400,300)
]]></artwork>
</figure></t>
<t/>
</section>
<section title="Evaluation of Policy Alternatives">
<t>The previous sections have defined three alternatives for
resolving conflicts - ignore, quarantine, and ignore
overlap-only.</t>
<t>The ignore policy impacts the greatest amount of traffic as
forwarding to all destinations which have a conflict is
affected.</t>
<t>Quarantine allows forwarding for some destinations which have a
conflict to be supported. The bias is for mapping entries with the
smallest range (typically - but not exclusively SIDs advertised in
prefix reachability advertisements) to be forwarded while the
destinations included in mapping entries with a larger range but NOT
covered by entries with a smaller range will not be forwarded.</t>
<t>Ignore overlap-only maximizes the destinations which will be
forwarded as all destinations covered by some mapping entry
(regardless of range) will be able to use the SID assigned by the
winning range. This alternative increases implementation complexity
as comapred to quarantine. Mapping entries with a range greater than
1 which are in conflict with mapping entries having a smaller range
have to internally be split into 2 or more "derived mapping
entries". The derived mapping entries then fall into two categories
- those that are in conflict with a mapping entry of smaller range -
and those which are NOT in conflict with an entry with smaller
range. The former are ignored and the latter are used. Each time the
underived mapping database is updated the derived entries have to be
recomputed based on the updated database. Internal data structures
have to maintain the relationship between the advertised mapping
entry and the set of derived mapping entries. All nodes in the
network have to achieve the same behavior regardless of
implementation internals.</t>
<t>There is then a tradeoff between a goal of maximizing traffic
delivery and the risks associated with increased implementation
complexity.</t>
<t>It is the opinion of the authors that "quarantine" is the best
alternative.</t>
</section>
<section title="Guaranteeing Database Consistency">
<t>In order to obtain consistent active entries all nodes in a
network MUST have the same mapping entry database. Mapping entries
can be obtained from a variety of sources.</t>
<t><list style="symbols">
<t>SIDs can be configured locally for prefixes assigned to
interfaces on the router itself. Only SIDs which are advertised
to protocol peers can be considered as part of the mapping entry
database.</t>
<t>SIDs can be received in prefix reachability advertisements
from protocol peers. These advertisements may originate from
peers local to the area or be leaked from other areas and/or
redistributed from other routing protocols.</t>
<t>SIDs can be received from SRMS advertisements - these
advertisements can originate from routers local to the area or
leaked from other areas</t>
<t>In cases where multiple routing protocols are in use mapping
entries advertised by all routing protocols MUST be
included.</t>
</list></t>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Consideration">
<t>This document has no actions for IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Jeff Tantsura, Wim Henderickx, and
Bruno Decraene for their careful review and content suggestions.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<reference anchor="SR-MPLS">
<front>
<title>Segment Routing with MPLS dataplane,
draft-ietf-spring-segment-routing-mpls-04(work in progress)</title>
<author fullname="Filsfils, C., et al"/>
<date month="March" year="2016"/>
</front>
</reference>
<reference anchor="SR-IS-IS">
<front>
<title>IS-IS Extensions for Segment Routing,
draft-ietf-isis-segment-routing-extensions-06(work in
progress)</title>
<author fullname="Previdi, S., et al"/>
<date month="December" year="2015"/>
</front>
</reference>
<reference anchor="SR-OSPF">
<front>
<title>OSPF Extensions for Segment Routing,
draft-ietf-ospf-segment-routing-extensions-07(work in
progress)</title>
<author fullname="Psenak, P., et al"/>
<date month="March" year="2016"/>
</front>
</reference>
<reference anchor="SR-OSPFv3">
<front>
<title>OSPFv3 Extensions for Segment Routing,
draft-ietf-ospf-ospfv3-segment-routing-extensions-05(work in
progress)</title>
<author fullname="Psenak, P., et al"/>
<date month="March" year="2016"/>
</front>
</reference>
</references>
<references title="Informational References">
<reference anchor="SR-ARCH">
<front>
<title>Segment Routing Architecture,
draft-ietf-spring-segment-routing-07(work in progress)</title>
<author fullname="Filsfils, C., et al"/>
<date month="December" year="2015"/>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:11:38 |