draft-ietf-spring-conflict-resolution-03.txt   draft-ietf-spring-conflict-resolution-04.txt 
Networking Working Group L. Ginsberg Networking Working Group L. Ginsberg
Internet-Draft P. Psenak Internet-Draft P. Psenak
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: October 29, 2017 Cisco Systems Expires: November 25, 2017 Cisco Systems
M. Pilka M. Pilka
April 27, 2017 May 24, 2017
Segment Routing Conflict Resolution Segment Routing MPLS Conflict Resolution
draft-ietf-spring-conflict-resolution-03.txt draft-ietf-spring-conflict-resolution-04.txt
Abstract Abstract
In support of Segment Routing (SR) routing protocols advertise a In support of Segment Routing (SR) for an MPLS data plane routing
variety of identifiers used to define the segments which direct protocols advertise a variety of identifiers used to define the
forwarding of packets. In cases where the information advertised by segments which direct forwarding of packets. In cases where the
a given protocol instance is either internally inconsistent or information advertised by a given protocol instance is either
conflicts with advertisements from another protocol instance a means internally inconsistent or conflicts with advertisements from another
of achieving consistent forwarding behavior in the network is protocol instance a means of achieving consistent forwarding behavior
required. This document defines the policies used to resolve these in the network is required. This document defines the policies used
occurrences. to resolve these occurrences.
Requirements Language 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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 October 29, 2017. This Internet-Draft will expire on November 25, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SR Global Block Inconsistency . . . . . . . . . . . . . . . . 3 2. SR Global Block Inconsistency . . . . . . . . . . . . . . . . 3
3. SR-MPLS Segment Identifier Conflicts . . . . . . . . . . . . 5 3. SR-MPLS Segment Identifier Conflicts . . . . . . . . . . . . 5
3.1. SID Preference . . . . . . . . . . . . . . . . . . . . . 6 3.1. SID Preference . . . . . . . . . . . . . . . . . . . . . 6
3.2. Conflict Types . . . . . . . . . . . . . . . . . . . . . 6 3.2. Conflict Types . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. Prefix Conflict . . . . . . . . . . . . . . . . . . . 6 3.2.1. Prefix Conflict . . . . . . . . . . . . . . . . . . . 7
3.2.2. SID Conflict . . . . . . . . . . . . . . . . . . . . 8 3.2.2. SID Conflict . . . . . . . . . . . . . . . . . . . . 8
3.3. Processing conflicting entries . . . . . . . . . . . . . 9 3.3. Preference rule for resolving conflicts . . . . . . . . . 10
3.3.1. Policy: Ignore conflicting entries . . . . . . . . . 9 3.4. Conflict Resolution Algorithm . . . . . . . . . . . . . . 11
3.3.2. Policy: Preference Algorithm/Quarantine . . . . . . . 10 3.5. Example Behavior - Single Topology/Address
3.3.3. Policy: Preference algorithm/ignore overlap only . . 10 Family/Algorithm . . . . . . . . . . . . . . . . . . . . 13
3.3.4. Preference Algorithm . . . . . . . . . . . . . . . . 10 3.6. Example Behavior - Multiple Topologies . . . . . . . . . 13
3.3.5. Example Behavior - Single Topology/Algorithm . . . . 11 3.7. Guaranteeing Database Consistency . . . . . . . . . . . . 14
3.3.6. Example Behavior - Multiple Topologies . . . . . . . 12 3.8. Minimizing the occurence of conflicts . . . . . . . . . . 14
3.3.7. Evaluation of Policy Alternatives . . . . . . . . . . 13 4. Scope of SR-MPLS SID Conflicts . . . . . . . . . . . . . . . 15
3.3.8. Guaranteeing Database Consistency . . . . . . . . . . 14 5. Conflict Resolution and non-forwarding nodes . . . . . . . . 16
4. Scope of SR-MPLS SID Conflicts . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.2. Informational References . . . . . . . . . . . . . . . . 17
8.2. Informational References . . . . . . . . . . . . . . . . 16 Appendix A. Alternative SID Conflict Resolution Policy
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Discussion . . . . . . . . . . . . . . . . . . . . . 17
A.1. Policy: Ignore conflicting entries . . . . . . . . . . . 17
A.2. Policy: Preference Algorithm/Quarantine . . . . . . . . . 18
A.3. Policy: Preference algorithm/ignore overlap only . . . . 18
A.4. Example Behavior - Single Topology/Address
Family/Algorithm . . . . . . . . . . . . . . . . . . . . 18
A.5. Evaluation of Policy Alternatives . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Segment Routing (SR) as defined in [SR-ARCH] utilizes forwarding Segment Routing (SR) as defined in [SR-ARCH] utilizes forwarding
instructions called "segments" to direct packets through the network. instructions called "segments" to direct packets through the network.
Depending on the forwarding plane architecture in use, routing Depending on the forwarding plane architecture in use, routing
protocols advertise various identifiers which define the permissible protocols advertise various identifiers which define the permissible
values which can be used as segments, which values are assigned to values which can be used as segments, which values are assigned to
specific prefixes, etc. Where segments have global scope it is specific prefixes, etc. Where segments have global scope it is
necessary to have non-conflicting assignments - but given that the necessary to have non-conflicting assignments - but given that the
advertisements may originate from multiple nodes the possibility advertisements may originate from multiple nodes the possibility
exists that advertisements may be received which are either exists that advertisements may be received which are either
internally inconsistent or conflicting with advertisements originated internally inconsistent or conflicting with advertisements originated
by other nodes. In such cases it is necessary to have consistent by other nodes. In such cases it is necessary to have consistent
resolution of conflicts network-wide in order to avoid forwarding resolution of conflicts network-wide in order to avoid forwarding
loops. loops.
This document is limited to discussion of conflict resolution for
identifiers used in an MPLS data plane.
The problem to be addressed is protocol independent i.e., segment The problem to be addressed is protocol independent i.e., segment
related advertisements may be originated by multiple nodes using related advertisements may be originated by multiple nodes using
different protocols and yet the conflict resolution MUST be the same different protocols and yet the conflict resolution MUST be the same
on all nodes regardless of the protocol used to transport the on all nodes regardless of the protocol used to transport the
advertisements. advertisements.
The remainder of this document defines conflict resolution policies The remainder of this document defines conflict resolution policies
which meet these requirements. All protocols which support SR MUST which meet these requirements. All protocols which support SR MUST
adhere to the policies defined in this document. adhere to the policies defined in this document.
2. SR Global Block Inconsistency 2. SR Global Block Inconsistency
In support of an MPLS dataplane routing protocols advertise an SR In support of an MPLS dataplane [SR-MPLS] routing protocols advertise
Global Block (SRGB) which defines a set of label ranges reserved for an SR Global Block (SRGB) which defines a set of label ranges
use by the advertising node in support of SR. The details of how reserved for use by the advertising node in support of SR. The
protocols advertise this information can be found in the protocol details of how protocols advertise this information can be found in
specific drafts e.g., [SR-OSPF], [SR-OSPFv3], and [SR-IS-IS]. the protocol specific drafts e.g., [SR-OSPF], [SR-OSPFv3], [SR-IS-
However the protocol independent semantics are illustrated by the IS], and [SR-BGP]. However the protocol independent semantics are
following example: illustrated by the following example:
The originating router advertises the following ranges: The originating router advertises the following ranges:
Range 1: (100, 199) Range 1: (100, 199)
Range 2: (1000, 1099) Range 2: (1000, 1099)
Range 3: (500, 599) Range 3: (500, 599)
The receiving routers concatenate the ranges and build the Segment The receiving routers concatenate the ranges and build the Segment
Routing Global Block (SRGB) as follows: Routing Global Block (SRGB) as follows:
skipping to change at page 5, line 7 skipping to change at page 5, line 7
receivers MUST ignore all advertised SRGB ranges from that node. receivers MUST ignore all advertised SRGB ranges from that node.
Operationally the node is treated as though it did not advertise any Operationally the node is treated as though it did not advertise any
SRGB ranges. [SR-MPLS] defines the procedures for mapping global SRGB ranges. [SR-MPLS] defines the procedures for mapping global
SIDs to outgoing labels. SIDs to outgoing labels.
Note that utilization of local SIDs (e.g. adjacency SIDs) advertised Note that utilization of local SIDs (e.g. adjacency SIDs) advertised
by a node is not affected by the state of the advertised SRGB. by a node is not affected by the state of the advertised SRGB.
3. SR-MPLS Segment Identifier Conflicts 3. SR-MPLS Segment Identifier Conflicts
In support of an MPLS dataplane Segment identifiers (SIDs) are In support of an MPLS dataplane Segment Identifiers (SIDs) are
advertised and associated with a given prefix. SIDs may be advertised and associated with a given prefix. SIDs may be
advertised in the prefix reachability advertisements originated by a advertised in the prefix reachability advertisements originated by a
routing protocol (PFX) . SIDs may also be advertised by a Segment routing protocol (PFX) . SIDs may also be advertised by a Segment
Routing Mapping Server (SRMS). Routing Mapping Server (SRMS). How this is done is defined in the
protocol specific drafts e.g., [SR-OSPF], [SR-OSPFv3], [SR-IS-IS],
and [SR-BGP]
Information in a SID advertisement is used to construct a mapping Information in a SID advertisement is used to construct a mapping
entry. A generalized mapping entry can be represented using the entry. A generalized mapping entry can be represented using the
following definitions: following definitions:
Prf - Preference Value (See Section 3.1) Prf - Preference Value (See Section 3.1)
Pi - Initial prefix Pi - Initial prefix
Pe - End prefix Pe - End prefix
L - Prefix length L - Prefix length
Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)
Si - Initial SID value Si - Initial SID value
Se - End SID value Se - End SID value
R - Range value (See Note 1) R - Range value (See Note 1)
T - Topology T - Topology
A - Algorithm A - Algorithm (see [SR-ARCH])
A Mapping Entry is then the tuple: (Prf, Src, Pi/L, Si, R, T, A) A Mapping Entry is then the tuple: (Prf, Pi/L, Si, R, T, A)
Pe = (Pi + ((R-1) << (Lx-L)) Pe = (Pi + ((R-1) << (Lx-L))
Se = Si + (R-1) Se = Si + (R-1)
NOTE 1: The SID advertised in a prefix reachability advertisement NOTE 1: The SID advertised in a prefix reachability advertisement
always has an implicit range of 1. always has an implicit range of 1.
Conflicts in SID advertisements may occur as a result of Note: Topology is a locally scoped identifier assigned by each
misconfiguration. Conflicts may occur either in the set of router. Although it may have an association with Multitopology
advertisements originated by a single node or between advertisements Identifiers (MTID) advertised by routing protocols it is NOT
originated by different nodes. Conflicts which occur within the set equivalent to these identifiers. MTIDs are scoped by a given routing
of advertisements (P-SID and SRMS) originated by a single node SHOULD protocol. MTID ranges are protocol specific and there may be
be prevented by configuration validation on the originating node. standardized protocol specific MTID assignments for topologies of a
specific type (e.g., an AFI specific topology). As mapping entries
can be sourced from multiple protocols it is not possible to use a
network scoped identifier for a topology when storing mapping entries
in the local datbase.
When conflicts occur, it is not possible for routers to know which of Conflicts in SID advertisements may occur as a result of
the conflicting advertisements is "correct". In order to avoid misconfiguration. When conflicts occur, it is not possible for
forwarding loops and/or blackholes, there is a need for all nodes to routers to know which of the conflicting advertisements is "correct".
resolve the conflicts in a consistent manner. This in turn requires In order to avoid forwarding loops and/or blackholes, there is a need
that all routers have identical sets of advertisements and that they for all nodes to resolve the conflicts in a consistent manner. This
all use the same selection algorithm. This document defines in turn requires that all routers have identical sets of
procedures to achieve these goals. advertisements and that they all use the same selection algorithm.
This document defines procedures to achieve these goals.
3.1. SID Preference 3.1. SID Preference
If a node acts as an SRMS, it MAY advertise a preference to be If a node acts as an SRMS, it MAY advertise a preference to be
associated with all SRMS SID advertisements sent by that node. The associated with all SRMS SID advertisements sent by that node. The
means of advertising the preference is defined in the protocol means of advertising the preference is defined in the protocol
specific drafts e.g., [SR-OSPF], [SR-OSPFv3], and [SR-IS-IS]. The specific drafts e.g., [SR-OSPF], [SR-OSPFv3], and [SR-IS-IS]. The
preference value is an unsigned 8 bit integer with the following preference value is an unsigned 8 bit integer with the following
properties: properties:
0 - Reserved value indicating advertisements from that node 0 - Reserved value indicating advertisements from that node
MUST NOT be used. MUST NOT be used.
1 - 255 Preference value 1 - 255 Preference value
Advertisement of a preference value is optional. Nodes which do not Advertisement of a preference value is optional. Nodes which do not
advertise a preference value are assigned a preference value of 128. advertise a preference value are assigned a preference value of 128.
All SIDs advertised in prefix reachability advertisements implicitly All SIDs advertised in prefix reachability advertisements originated
have a preference value of 192. by an IGP implicitly have a preference value of 192.
All SIDs advertised in prefix reachability advertisements originated
by BGP implicitly have a preference value of 64.
These preference values are deliberately chosen to favor SID
advertisements originated within a domain (IGP and SRMS) over SID
advertisements which may have been imported from other domains (BGP).
In addition, as BGP originated advertisements may not be known on all
nodes within a domain (because not every node will be a BGP speaker),
the presence of a BGP originated mapping entry MUST NOT cause a
mapping entry originated within the domain to become unusable as this
would introduce inconsistency in the set of SIDs considered usable by
a node which has the BGP originated mapping entries and the set
considered usable by nodes without the BGP originated mapping
entries.
3.2. Conflict Types 3.2. Conflict Types
Two types of conflicts may occur - Prefix Conflicts and SID Two types of conflicts may occur - Prefix Conflicts and SID
Conflicts. Examples are provided in this section to illustrate these Conflicts. Examples are provided in this section to illustrate these
conflict types. conflict types.
3.2.1. Prefix Conflict 3.2.1. Prefix Conflict
When different SIDs are assigned to the same prefix we have a "prefix When different SIDs are assigned to the same prefix we have a "prefix
conflict". Prefix conflicts are specific to mapping entries sharing conflict". Prefix conflicts are limited to mapping entries sharing
the same topology and algorithm. the same topology and algorithm.
Example PC1 Example PC1
(192, 192.0.2.120/32, 200, 1, 0, 0) (192, 192.0.2.120/32, 200, 1, 0, 0)
(192, 192.0.2.120/32, 30, 1, 0, 0) (192, 192.0.2.120/32, 30, 1, 0, 0)
The prefix 192.0.2.120/32 has been assigned two different SIDs: The prefix 192.0.2.120/32 has been assigned two different SIDs:
200 by the first advertisement 200 by the first advertisement
30 by the second advertisement 30 by the second advertisement
skipping to change at page 7, line 29 skipping to change at page 8, line 4
(128, 2001:DB8::1/128, 400, 200, 2, 0) (128, 2001:DB8::1/128, 400, 200, 2, 0)
(128, 2001:DB8::121/128, 50, 10, 2, 0) (128, 2001:DB8::121/128, 50, 10, 2, 0)
Prefixes 2001:DB8::121/128 - 2001:DB8::130/128 are assigned Prefixes 2001:DB8::121/128 - 2001:DB8::130/128 are assigned
two different SIDs: two different SIDs:
420 through 429 by the first advertisement 420 through 429 by the first advertisement
50 through 59 by the second advertisement 50 through 59 by the second advertisement
Examples PC3 and PC4 illustrate a complication - only part of the Examples PC3 and PC4 illustrate a complication - only part of the
range advertised in the first advertisement is in conflict. It is range advertised in the first advertisement is in conflict. It is
logically possible to isolate the conflicting portion and try to use logically possible to consider the sub-range(s) which are in conflict
the non-conflicting portion(s). as unusable while considering the sub-range(s) not in conflict as
usable.
A variant of the overlapping prefix range is a case where we have A variant of the overlapping prefix range is a case where we have
overlapping prefix ranges but no actual SID conflict. overlapping prefix ranges but no actual prefix conflict.
Example PC5 Example PC5
(128, 192.0.2.1/32, 200, 200, 0, 0) (128, 192.0.2.1/32, 200, 200, 0, 0)
(128, 192.0.2.121/32, 320, 10, 0, 0) (128, 192.0.2.121/32, 320, 10, 0, 0)
(128, 2001:DB8::1/128, 400, 200, 2, 0) (128, 2001:DB8::1/128, 400, 200, 2, 0)
(128, 2001:DB8::121/128, 520, 10, 2, 0) (128, 2001:DB8::121/128, 520, 10, 2, 0)
Although there is prefix overlap between the two IPv4 entries (and Although there is prefix overlap between the two IPv4 entries (and
skipping to change at page 8, line 14 skipping to change at page 8, line 32
Given two mapping entries: Given two mapping entries:
(Prf, P1/L1, S1, R1, T1, A1) and (Prf, P1/L1, S1, R1, T1, A1) and
(Prf, P2/L2, S2, R2, T2, A2) (Prf, P2/L2, S2, R2, T2, A2)
where P1 <= P2 where P1 <= P2
a prefix conflict exists if all of the following are true: a prefix conflict exists if all of the following are true:
1)(T1 == T2) && (A1 == A2) 1)(T1 == T2) && (A1 == A2) && (L1 == L2)
2)P1 <= P2 2)The prefixes are in the same address family.
3)The prefixes are in the same address family.
2)L1 == L2
3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2) 3)(P1e >= P2) && ((S1 + (P2 - P1)) != S2)
Prefixes in the following range are in conflict:
P2 through MIN(P1e,P2e)
3.2.2. SID Conflict 3.2.2. SID Conflict
When the same SID has been assigned to multiple prefixes we have a When the same SID has been assigned to multiple prefixes we have a
"SID conflict". SID conflicts are independent of address-family, "SID conflict". SID conflicts are independent of address-family,
independent of prefix len, independent of topology, and independent independent of prefix len, independent of topology, and independent
of algorithm. A SID conflict occurs when a mapping entry which has of algorithm.
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.
Example SC1 Example SC1
(192, 192.0.2.1/32, 200, 1, 0, 0) (192, 192.0.2.1/32, 200, 1, 0, 0)
(192, 192.0.2.222/32, 200, 1, 0, 0) (192, 192.0.2.222/32, 200, 1, 0, 0)
SID 200 has been assigned to 192.0.2.1/32 by the SID 200 has been assigned to 192.0.2.1/32 by the
first advertisement. first advertisement.
The second advertisement assigns SID 200 to 192.0.2.222/32. The second advertisement assigns SID 200 to 192.0.2.222/32.
Example SC2 Example SC2
skipping to change at page 9, line 29 skipping to change at page 10, line 5
SIDs 500 - 509 have been assigned to two different prefixes. SIDs 500 - 509 have been assigned to two different prefixes.
The first advertisement assigns these SIDs to The first advertisement assigns these SIDs to
2001:DB8::101/128 - 2001:DB8::10A/128. 2001:DB8::101/128 - 2001:DB8::10A/128.
The second advertisement assigns these SIDs to The second advertisement assigns these SIDs to
2001:DB8:1::1/128 - 2001:DB8:1::A/128. 2001:DB8:1::1/128 - 2001:DB8:1::A/128.
Examples SC3 and SC4 illustrate a complication - only part of the Examples SC3 and SC4 illustrate a complication - only part of the
range advertised in the first advertisement is in conflict. range advertised in the first advertisement is in conflict.
3.3. Processing conflicting entries Given two mapping entries:
Two general approaches can be used to process conflicting entries.
1. Conflicting entries can be ignored
2. A standard preference algorithm can be used to choose which of
the conflicting entries will be used
The following sections discuss these two approaches in more detail.
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.
3.3.1. Policy: Ignore conflicting entries
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.
Implementations are required to identify the conflicting entries and (Prf, P1/L1, S1, R1, T1, A1) and
ensure that they are not used. (Prf, P2/L2, S2, R2, T2, A2)
3.3.2. Policy: Preference Algorithm/Quarantine where S1 <= S2
For entries which are in conflict properties of the conflicting a SID conflict exists if all of the following are true:
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.
This approach requires that conflicting entries first be identified 1)S1e >= S2
and then evaluated based on a preference rule. Based on which entry 2)P1 and P2 are NOT in the same address family OR
is preferred this in turn may impact what other entries are L1 != L2 OR
considered in conflict i.e. if A conflicts with B and B conflicts (P1 + ((S1e-S2) << (L1x-L1))) != P2
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.
3.3.3. Policy: Preference algorithm/ignore overlap only SIDs in the following range are in conflict:
A variation of the preference algorithm approach is to quarantine S2 through MIN(S1e,S2e)
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.
3.3.4. Preference Algorithm 3.3. Preference rule for resolving conflicts
The following algorithm is used to select the preferred mapping entry When a conflict is detected the following algorithm is used to select
when a conflict exists. Evaluation is made in the order specified. the preferred mapping entry. Evaluation is made in the order
Prefix conflicts are evaluated first. SID conflicts are then specified. Prefix conflicts are evaluated first. SID conflicts are
evaluated on the Active entries remaining after Prefix Conflicts have then evaluated on the Active entries remaining after Prefix Conflicts
been resolved. have been resolved.
1. Higher preference value wins 1. Higher preference value wins
2. Smaller range wins 2. Smaller range wins
3. IPv6 entry wins over IPv4 entry 3. IPv6 entry wins over IPv4 entry
4. Longer prefix length wins 4. Longer prefix length wins
5. Smaller algorithm wins 5. Smaller starting address (considered as an unsigned integer
6. Smaller starting address (considered as an unsigned integer
value) wins value) wins
6. Smaller algorithm wins
7. Smaller starting SID wins 7. Smaller starting SID wins
8. If topology IDs are NOT identical both entries MUST be ignored 8. If topology IDs are NOT identical both entries MUST be ignored
When applying the preference rule to prefix/SID pairs associated with
an advertised mapping entry with a range greater than one, each
prefix/SID pair in the range is considered as having the range
associated with the advertised mapping entry. For example:
Advertised mapping entry: (128, 192.0.2.1/32, 200, 200, 0, 0)
The advertisement covers 200 prefix/SID pairs:
192.0.2.1/32 200
192.0.2.2/32 201
...
192.0.2.200/32 399
Each of these prefix/SID pairs is considered as having a range of 200
when applying Rule #2 above.
As SIDs associated with prefix reachability advertisements have a As SIDs associated with prefix reachability advertisements have a
preference of 192 while by default SRMS preference is 128, the preference of 192 and an implied range of 1 while by default SRMS
default behavior is then to prefer SIDs advertised in prefix preference is 128, the default behavior is then to prefer SIDs
reachability advertisements over SIDs advertised by SRMSs, but an advertised in prefix reachability advertisements over SIDs advertised
operator can choose to override this behavior by setting SRMS by SRMSs, but an operator can choose to override this behavior by
preference higher than 192. setting SRMS preference higher than 192.
Preferring advertisements with smaller range has the nice property Preferring advertisements with smaller range has the nice property
that a single misconfiguration of an SRMS entry with a large range that a single misconfiguration of an SRMS entry with a large range
will not be preferred over a large number of advertisements with will not be preferred over a large number of advertisements with
smaller ranges. smaller ranges.
Since topology identifiers are locally scoped, it is not possible to Since topology identifiers are locally scoped, it is not possible to
make a consistent choice network wide when all elements of a mapping make a consistent choice network wide when all elements of a mapping
entry are identical except for the topology. This is why both entry are identical except for the topology. This is why both
entries MUST be ignored in such cases (Rule #8 above). Note that entries MUST be ignored in such cases (Rule #8 above). Note that
Rule #8 only applies when considering SID conflicts since Prefix Rule #8 only applies when considering SID conflicts since Prefix
conflicts are restricted to a single topology. conflicts are restricted to a single topology.
3.3.5. Example Behavior - Single Topology/Algorithm 3.4. Conflict Resolution Algorithm
The following mapping entries exist:in the database. For brevity, The following logical steps MUST be followed in the order specified
when resolving conflicts.
Step 1: Resolve Prefix Conflicts (same topology/address family/
algorithm)
For each supported topology/address family/algorithm examine all
qualifying mapping entries in the following order:
1)Preference (start w highest)
2)Range (start w smallest)
3)Prefix length (start w longest)
4)Address (start w smallest)
5)SID (start w smallest)
At each step if a prefix conflict is detected the losing prefix/SID
pair is declared Inactive and is not considered in any subsequent
steps. The remaining prefix/SID pairs are Active.
Mapping entries with Active prefix/SID pairs after completion of Step
1 are fed into ...
Step 2: SID Conflicts (across all topologies/address families/
algorithms)
Examine all Active prefix/SID pairs from Step #1 in the following
order:
1)Preference (start w highest)
2)Range (start w smallest)
3)IPv6 entries
a)Prefix length (start w longest)
b)Address (start w smallest)
4)IPv4 entries
a)Prefix Length (start w longest)
b)Address (start w smallest)
5)Algorithm (start w smallest)
6)SID (start w smallest)
Prefix/SID pairs which are identical and are associated with the
same topology are duplicates - both entries MUST be considered as
Active.
Prefix/SID pairs which are identical and are associated with
different topologies MUST both be considered Inactive.
Active Entries in the database may be used in forwarding. Inactive
entries MUST NOT be used in forwarding.
Note that when the database of mapping entries changes the full set
of logical steps MUST be reapplied to the entire database as conflict
resolution is NOT transitive.
NOTE: Clever implementors may realize optimizations when rerunning
the algorithm by evaluating changed entries as to whether they have
potential conflicts with any of the existing entries in the database
(both active and inactive). Such optimizations are outside the scope
of this specification. The normative behavior is defined by the
logical algorithm above.
3.5. Example Behavior - Single Topology/Address Family/Algorithm
The following mapping entries exist in the database. For brevity,
Topology/Algorithm is omitted and assumed to be (0,0) in all entries. Topology/Algorithm is omitted and assumed to be (0,0) in all entries.
1. (192, 192.0.2.1/32, 100, 1) 1. (192, 192.0.2.1/32, 100, 1)
2. (192, 192.0.2.101/32, 200, 1) 2. (192, 192.0.2.101/32, 200, 1)
3. (128, 192.0.2.1/32, 400, 255) !Prefix conflict with entries 1 and 3. (128, 192.0.2.1/32, 400, 255) !Prefix conflict with entries 1 and
2 2
4. (128, 198.51.100.40/32, 200,1) !SID conflict with entry 2 4. (128, 198.51.100.40/32, 200,1) !SID conflict with entry 2
The table below shows what mapping entries will be used in the The table below shows what mapping entries will be used in the
forwarding plane (Active) and which ones will not be used (Excluded) forwarding plane (Active) and which ones will not be used (Inactive)
under the three candidate policies:
+--------------------------------------------------------------------+ +------------------------------------------------------------+
|Policy | Active Entries | Excluded Entries | | Active Entries | Inactive Entries |
+--------------------------------------------------------------------+ +------------------------------------------------------------+
|Ignore | |(192,192.0.2.1/32,100,1) | | (192,192.0.2.1/32,100,1) | (128,198.51.100.40/32,200,1)|
| | |(192,192.0.2.101/32,200,1) | | (192,192.0.2.101/32,200,1) |*(128,192.0.2.1/32,400,1) |
| | |(128,192.0.2.1/32,400,255) | |*(128,192.0.2.2/32,401,99) |*(128,192.0.2.101/32,500,1) |
| | |(128,198.51.100.40/32,200,1) | |*(128,192.0.2.102/32,501,154) | |
+--------------------------------------------------------------------+ +------------------------------------------------------------+
|Quarantine|(192,192.0.1.1/32,100,1) |(128,192.0.2.1/32,400,255) |
| |(192,192.0.2.101/32,200,1) |(128,198.51.100.40/32,200,1) |
+--------------------------------------------------------------------+
|Overlap- |(192,192.0.2.1/32,100,1) |(128,198.51.100.40/32,200,1) |
| Only |(192,192.0.2.101/32,200,1) |*(128,192.0.2.1/32,400,1) |
| |*(128,192.0.2.2/32,401,99) |*(128,192.0.2.101/32,500,1) |
| |*(128,192.0.2.102/32, |
| | 501,153) | |
+--------------------------------------------------------------------+
* Derived from (128,192.0.2.1/32,400,300) * Derived from (128,192.0.2.1/32,400,255)
3.3.6. Example Behavior - Multiple Topologies 3.6. Example Behavior - Multiple Topologies
When using a preference rule the order in which conflict resolution When using a preference rule the order in which conflict resolution
is applied has an impact on what entries are usable when entries for is applied has an impact on what entries are Active when entries for
multiple topologies (or algorithms) are present. The following multiple topologies (or algorithms) are present. The following
mapping entries exist in the database: mapping entries exist in the database:
1. (192, 192.0.2.1/32, 100, 1, 0, 0) !Topology 0 1. (192, 192.0.2.1/32, 100, 1, 0, 0) !Topology 0
2. (192, 192.0.2.1/32, 200, 1, 0, 0) !Topology 0, Prefix Conflict 2. (192, 192.0.2.1/32, 200, 1, 0, 0) !Topology 0, Prefix Conflict
with entry #1 with entry #1
3. (192, 198.51.100.40/32, 200,1,1,0) ! Topology 1, SID conflict 3. (192, 198.51.100.40/32, 200,1,1,0) ! Topology 1, SID conflict
with entry 2 with entry 2
The table below shows what mapping entries will be used in the The table below shows what mapping entries will be used in the
forwarding plane (Active) and which ones will not be used (Excluded) forwarding plane (Active) and which ones will not be used (Inactive)
under the Quarantine Policy based on the order in which conflict based on the order in which conflict resolution is applied.
resolution is applied.
+------------------------------------------------------------------+ +------------------------------------------------------------------+
|Order | Active Entries | Excluded Entries | |Order | Active Entries | Inactive Entries |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
|Prefix- |(192,192.0.2.1/32,100,1,0,0)|(192,192.0.2.101/32,200,1,0)| |Prefix- |(192,192.0.2.1/32,100,1,0,0)|(192,192.0.2.101/32,200,1,0)|
|Conflict|(192,198.51.100.40/32,200,1,| | |Conflict|(192,198.51.100.40/32,200,1,| |
|First | 1,0) | | |First | 1,0) | |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
|SID- |(192,192.0.2.1/32,100,1,0,0)|(192,192.0.2.101/32,200,1,0)| |SID- |(192,192.0.2.1/32,100,1,0,0)|(192,192.0.2.101/32,200,1,0)|
|Conflict| |(192,198.51.100.40/32,200,1,| |Conflict| |(192,198.51.100.40/32,200,1,|
|First | | 1,0) | |First | | 1,0) |
+------------------------------------------------------------------+ +------------------------------------------------------------------+
This illustrates the advantage of evaluating prefix conflicts within This illustrates the advantage of evaluating prefix conflicts within
a given topology (or algorithm) before evaluating topology (or a given topology (or algorithm) before evaluating topology (or
algorithm) independent SID conflicts. It insures that entries which algorithm) independent SID conflicts. It insures that entries which
will be excluded based on intratopology preference will not prevent a will be excluded based on intratopology preference will not prevent a
SID assigned in another topology from being considered Active. SID assigned in another topology from being considered Active.
3.3.7. Evaluation of Policy Alternatives 3.7. Guaranteeing Database Consistency
The previous sections have defined three alternatives for resolving
conflicts - ignore, quarantine, and ignore overlap-only.
The ignore policy impacts the greatest amount of traffic as
forwarding to all destinations which have a conflict is affected.
Quarantine allows forwarding for some destinations which have a
conflict to be supported.
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 compared to quarantine. Mapping entries with a range greater than
1 which are in conflict with other mapping entries 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 other mapping entries and those which are NOT in
conflict. 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 be maintained which 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.
There is then a tradeoff between a goal of maximizing traffic
delivery and the risks associated with increased implementation
complexity.
Consensus of the working group is that maximizing traffic delivery is
the most important deployment consideration - therefore ignore-
overlap-only is specified as the standard policy which MUST be
implemented by all nodes which support SR-MPLS.
3.3.8. Guaranteeing Database Consistency
In order to obtain consistent active entries all nodes in a network In order to obtain consistent active entries all nodes in a network
MUST have the same mapping entry database. Mapping entries can be MUST have the same mapping entry database. Mapping entries can be
obtained from a variety of sources. obtained from a variety of sources.
o SIDs can be configured locally for prefixes assigned to interfaces o SIDs can be configured locally for prefixes assigned to interfaces
on the router itself. Only SIDs which are advertised to protocol on the router itself. Only SIDs which are advertised to protocol
peers can be considered as part of the mapping entry database. peers can be considered as part of the mapping entry database.
o SIDs can be received in prefix reachability advertisements from o SIDs can be received in prefix reachability advertisements from
skipping to change at page 14, line 36 skipping to change at page 14, line 45
local to the area or be leaked from other areas and/or local to the area or be leaked from other areas and/or
redistributed from other routing protocols. redistributed from other routing protocols.
o SIDs can be received from SRMS advertisements - these o SIDs can be received from SRMS advertisements - these
advertisements can originate from routers local to the area or advertisements can originate from routers local to the area or
leaked from other areas leaked from other areas
o In cases where multiple routing protocols are in use mapping o In cases where multiple routing protocols are in use mapping
entries advertised by all routing protocols MUST be included. entries advertised by all routing protocols MUST be included.
3.8. Minimizing the occurence of conflicts
Conflicts in SID advertisements are always the result of a
misconfiguration. Conflicts may occur either in the set of
advertisements originated by a single node or between advertisements
originated by different nodes.
Conflicts which occur within the set of advertisements (PFX and SRMS)
originated by a single node SHOULD be prevented by configuration
validation on the originating node.
It is possible to minimize the occurrence of conflicts between
advertisements originated by different routers if new configuration
is validated against the current state of the conflict resolution
database before the configuration is advertised. How this is done is
an implementation issue which is out of scope of this document.
4. Scope of SR-MPLS SID Conflicts 4. Scope of SR-MPLS SID Conflicts
The previous section defines the types of SID conflicts and The previous section defines the types of SID conflicts and
procedures to resolve such conflicts when using an MPLS dataplane. procedures to resolve such conflicts when using an MPLS dataplane.
The mapping entry database used MUST be populated with entries for The mapping entry database used MUST be populated with entries for
destinations for which the associated SID will be used to derive the destinations for which the associated SID will be used to derive the
labels installed in the forwarding plane of routers in the network. labels installed in the forwarding plane of routers in the network.
This consists of entries associated with intra-domain routes. This consists of entries associated with intra-domain routes.
There are cases where destinations which are external to the domain There are cases where destinations which are external to the domain
skipping to change at page 15, line 21 skipping to change at page 16, line 5
between the sites (assuming SR is being used across the backbone) between the sites (assuming SR is being used across the backbone)
only requires using a SID associated with a gateway PE. So a only requires using a SID associated with a gateway PE. So a
destination in Site A MAY use the same SID as a destination in Site B destination in Site A MAY use the same SID as a destination in Site B
without introducing any conflict in the forwarding plane of routers without introducing any conflict in the forwarding plane of routers
in Site A. in Site A.
Such cases are handled by insuring that the mapping entries in the Such cases are handled by insuring that the mapping entries in the
database used by the procedures defined in the previous section only database used by the procedures defined in the previous section only
include entries associated with advertisements within the site. include entries associated with advertisements within the site.
5. Security Considerations 5. Conflict Resolution and non-forwarding nodes
The previous sections define conflict resolution behavior required of
nodes which perform forwarding. But conflict resolution also impacts
other entities e.g., controllers. If a controller were to define an
explicit path using a SID in a way that is inconsistent with the set
of Active entries produced by conflict resolution procedures used by
the forwarding nodes then traffic following the explicit path may be
misdelivered.
To prevent this such an entity MUST either implement the conflict
resolution procedures defined above or implement an alternate form of
conflict resolution which produces a subset of the Active entries
which result from the conflict resolution procedures defined above.
One such alternate form is to consider Inactive any mapping entry
which has either a prefix conflict or a SID conflict with any other
mapping entry.
6. Security Considerations
The ability to introduce SID conflicts into a deployment may The ability to introduce SID conflicts into a deployment may
compromise traffic forwarding. Protocol specific security mechanisms compromise traffic forwarding. Protocol specific security mechanisms
SHOULD be used to insure that all SID advertisements originate from SHOULD be used to insure that all SID advertisements originate from
trusted sources. trusted sources.
6. IANA Consideration 7. IANA Consideration
This document has no actions for IANA. This document has no actions for IANA.
7. Acknowledgements 8. Acknowledgements
The authors would like to thank Jeff Tantsura, Wim Henderickx, and The authors would like to thank Jeff Tantsura, Wim Henderickx, Bruno
Bruno Decraene for their careful review and content suggestions. Decraene, and Stephane Litkowski for their careful review and content
suggestions.
8. References 9. References
8.1. Normative References 9.1. Normative References
[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>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>. 2006, <http://www.rfc-editor.org/info/rfc4364>.
[SR-BGP] "Segment Routing Prefix SID extensions for BGP, draft-
ietf-idr-bgp-prefix-sid-05(work in progress)", April 2017.
[SR-IS-IS] [SR-IS-IS]
"IS-IS Extensions for Segment Routing, draft-ietf-isis- "IS-IS Extensions for Segment Routing, draft-ietf-isis-
segment-routing-extensions-11(work in progress)", March segment-routing-extensions-12(work in progress)", April
2017. 2017.
[SR-MPLS] "Segment Routing with MPLS dataplane, draft-ietf-spring- [SR-MPLS] "Segment Routing with MPLS dataplane, draft-ietf-spring-
segment-routing-mpls-08(work in progress)", March 2017. segment-routing-mpls-08(work in progress)", March 2017.
[SR-OSPF] "OSPF Extensions for Segment Routing, draft-ietf-ospf- [SR-OSPF] "OSPF Extensions for Segment Routing, draft-ietf-ospf-
segment-routing-extensions-12(work in progress)", March segment-routing-extensions-16(work in progress)", May
2017. 2017.
[SR-OSPFv3] [SR-OSPFv3]
"OSPFv3 Extensions for Segment Routing, draft-ietf-ospf- "OSPFv3 Extensions for Segment Routing, draft-ietf-ospf-
ospfv3-segment-routing-extensions-09(work in progress)", ospfv3-segment-routing-extensions-09(work in progress)",
March 2016. March 2017.
8.2. Informational References 9.2. Informational References
[SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment- [SR-ARCH] "Segment Routing Architecture, draft-ietf-spring-segment-
routing-11(work in progress)", February 2017. routing-11(work in progress)", February 2017.
Appendix A. Alternative SID Conflict Resolution Policy Discussion
A number of approaches to resolving SID conflicts were considered
during the writing of this document. Two general approaches with a
total of three policy alternatives were considered. This
Appendix documents the alternatives considered. All content in this
section is non-normative.
Two general approaches can be used to process conflicting entries.
1. Conflicting entries can be ignored
2. A standard preference algorithm can be used to choose which of
the conflicting entries will be used
The following sections discuss these two approaches in more detail.
A.1. Policy: Ignore conflicting entries
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.
Implementations are required to identify the conflicting entries and
ensure that they are not used.
A.2. Policy: Preference Algorithm/Quarantine
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.
Losing mapping entries with ranges greater than 1 are quarantined in
their entirety.
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.
A.3. Policy: Preference algorithm/ignore overlap only
A variation of the preference algorithm approach when applied to
mapping entries with ranges greater than 1 is to quarantine only the
portions of the less preferred entry which actually conflict. The
original entry is logically considered as a set of entries with a
range of 1, each of which inherits the range value of the original
entry for purposes of applying the preference rule.
A.4. Example Behavior - Single Topology/Address Family/Algorithm
The following mapping entries exist in the database. For brevity,
Topology/Algorithm is omitted and assumed to be (0,0) in all entries.
1. (192, 192.0.2.1/32, 100, 1)
2. (192, 192.0.2.101/32, 200, 1)
3. (128, 192.0.2.1/32, 400, 255) !Prefix conflict with entries 1 and
2
4. (128, 198.51.100.40/32, 200,1) !SID conflict with entry 2
The table below shows what mapping entries will be used in the
forwarding plane (Active) and which ones will not be used (Inactive)
under the three candidate policies:
+--------------------------------------------------------------------+
|Policy | Active Entries | Inactive Entries |
+--------------------------------------------------------------------+
|Ignore | |(192,192.0.2.1/32,100,1) |
| | |(192,192.0.2.101/32,200,1) |
| | |(128,192.0.2.1/32,400,255) |
| | |(128,198.51.100.40/32,200,1) |
+--------------------------------------------------------------------+
|Quarantine|(192,192.0.1.1/32,100,1) |(128,192.0.2.1/32,400,255) |
| |(192,192.0.2.101/32,200,1) |(128,198.51.100.40/32,200,1) |
+--------------------------------------------------------------------+
|Ignore- |(192,192.0.2.1/32,100,1) |(128,198.51.100.40/32,200,1) |
|Overlap- |(192,192.0.2.101/32,200,1) |*(128,192.0.2.1/32,400,1) |
| Only |*(128,192.0.2.2/32,401,99) |*(128,192.0.2.101/32,500,1) |
| |*(128,192.0.2.102/32, |
| | 501,153) | |
+--------------------------------------------------------------------+
* Derived from (128,192.0.2.1/32,400,300)
A.5. Evaluation of Policy Alternatives
The previous sections have defined three alternatives for resolving
conflicts - ignore, quarantine, and ignore overlap-only.
The ignore policy impacts the greatest number of mapping entriesas
all prefix/SID pairs contained in an advertisement which has a
conflict are considered Inactive.
Quarantine allows forwarding for some destinations which have a
conflict to be supported - but losing mapping entries with ranges
greater than 1 are declared Inactive in their entirety. This may
result in not using individual prefix/SID entries contained within
the quarantined advertisement which do not have a conflict.
Ignore-overlap-only maximizes the entries which may be Active as each
prefix/SID pair contained within an advertised mapping entry with
range greater than 1 is evaluated independent of the other entries
within the same advertisement. To implement this alternative
advertised mapping entries with a range greater than 1 which have a
conflict with other advertised mapping entries have to logically be
split into 2 or more "derived mapping entries". The derived mapping
entries then fall into two categories - those that are in conflict
with other mapping entries and have lost based on the preference rule
and those which are either NOT in conflict or have won based on the
preference rule. The former are considered Inactive while the latter
are considered Active. 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 be maintained
which 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.
There is then a tradeoff between a goal of maximizing advertised
mapping entry usage and the risks associated with increased
implementation complexity.
Consensus of the working group is that maximizing the use of the
advertised prefix/SID pairs is the most important deployment
consideration - therefore ignore-overlap-only has been specified as
the standard policy which MUST be implemented by all nodes which
support SR-MPLS.
Authors' Addresses Authors' Addresses
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
821 Alder Drive 821 Alder Drive
Milpitas, CA 95035 Milpitas, CA 95035
USA USA
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
 End of changes. 59 change blocks. 
205 lines changed or deleted 405 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/