< draft-geib-spring-oam-opt-02.txt   draft-geib-spring-oam-opt-03.txt >
Internet Engineering Task Force R. Geib, Ed. Internet Engineering Task Force R. Geib, Ed.
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Best Current Practice 25 October 2021 Intended status: Best Current Practice 26 April 2022
Expires: 28 April 2022 Expires: 28 October 2022
An MPLS SR OAM option reducing the number of end-to-end path validations An MPLS SR OAM option reducing the number of end-to-end path validations
draft-geib-spring-oam-opt-02 draft-geib-spring-oam-opt-03
Abstract Abstract
MPLS traceroute implementations validate dataplane connectivity and MPLS traceroute implementations validate dataplane connectivity and
isolate faults by sending messages along every end-to-end Label isolate faults by sending messages along every end-to-end Label
Switched Path (LSP) combination between a source and a destination Switched Path (LSP) combination between a source and a destination
node. This requires a growing number of path validations in networks node. This requires a growing number of path validations in networks
with a high number of equal cost paths between origin and with a high number of equal cost paths between origin and
destination. Segment Routing (SR) introduces MPLS topology awareness destination. Segment Routing (SR) introduces MPLS topology awareness
combined with Source Routing. By this combination, SR can be used to combined with Source Routing. By this combination, SR can be used to
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 28 April 2022. This Internet-Draft will expire on 28 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. MPLS OAM adding MPLS SR mechanisms . . . . . . . . . . . . . 5 2. MPLS OAM adding MPLS SR mechanisms . . . . . . . . . . . . . 5
2.1. Operation in an SR MPLS domain applying only IP-header 2.1. Operation in an SR MPLS domain applying only IP-header
based ECMP . . . . . . . . . . . . . . . . . . . . . . . 6 based ECMP . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Operation in an SR MPLS domain additionally using incoming 2.2. Operation in an SR MPLS domain additionally using incoming
interface information for ECMP . . . . . . . . . . . . . 7 interface information for ECMP . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . 8 5.1. Normative References . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
Commodity MPLS isn't topology aware and it doesn't support Commodity MPLS isn't topology aware and it doesn't support
standardized source routing methods. It is reasonable to validate standardized source routing methods. It is reasonable to validate
connectivity and locate faults of MPLS LSPs by detecting and testing connectivity and locate faults of MPLS LSPs by detecting and testing
all existing LSP combinations between a source and a destination all existing LSP combinations between a source and a destination
node. The source node originates all MPLS echo requests and node. The source node originates all MPLS echo requests and
evaluates all MPLS echo replies. Operational MPLS OAM evaluates all MPLS echo replies. Operational MPLS OAM
skipping to change at page 3, line 24 skipping to change at page 3, line 24
\ symmetric to / \ symmetric to /
4...upper network ...4 4...upper network ...4
Figure 1 Figure 1
Figure 1: Multiple equal cost path example network. Figure 1: Multiple equal cost path example network.
The total number of MPLS LSP combinations between nodes RS and RD is The total number of MPLS LSP combinations between nodes RS and RD is
multiplicative by the number of (equal cost, so to say) links per multiplicative by the number of (equal cost, so to say) links per
hop. That results in a maximum of 4096=2*4*(8*12+8*4)*4 path hop. That results in a maximum of 4096=2*4*(8*12+8*4)*4 path
combinations which a commodity MPLS may try to validate. Assume RS combinations which a commodity MPLS may try to validate. Assume node
to start an MPLS traceroute to RD containing a Multipath Data Sub-TLV RS to start an MPLS traceroute to node RD, containing a Multipath
requesting Multipath information for 32 IP-addresses. By Equal Cost Data Sub-TLV requesting Multipath information for 32 IP-addresses.
Multipath routing (ECMP, [RFC2991]) traffic of likely 16 of these IP- By Equal Cost Multipath routing (ECMP, [RFC2991]) traffic of likely
addresses is forwarded via R110 as next hop (the other 16 addresses 16 of these IP-addresses is forwarded via R110 as next hop (the other
are assumed to be forwarded along the symmetric and equal cost paths 16 addresses are assumed to be forwarded along the symmetric and
in the lower half, which are omitted in the figure for brevity). equal cost paths in the lower half, which are omitted in the figure
R110 can be expected to respond by an MPLS echo reply indicating for brevity). R110 can be expected to respond by an MPLS echo reply
prefixes to address each of the 4 equal cost (sub-)paths between RS indicating prefixes to address each of the 4 equal cost (sub-)paths
and R110. between RS and R110.
R110 is able to forward traffic addressed by these 16 IP addresses R110 is able to forward traffic addressed by these 16 IP addresses
via 16 equal cost paths. There's a fairly high probability that this via 16 equal cost paths. There's a fairly high probability that this
will not be possible, as some of R110's availble paths to forward will not be possible, as some of R110's availble paths to forward
traffic to RD will receive traffic of two or even three MPLS echo traffic to RD will receive traffic of two or even three MPLS echo
request destination IP addresses resuulting in an MPLS Echo request request destination IP addresses resulting in an MPLS Echo request
being sent from RS to R110 and ahead, while other equal cost paths of being sent from RS to R110 and ahead, while other equal cost paths of
R110 receive no traffic at all. The MPLS Echo Reply returned to RS R110 receive no traffic at all. The MPLS Echo Reply returned to RS
will indicate that. A commodity solution is, to start an additional will indicate that. A commodity solution is, to start an additional
MPLS traceroute from RS with another 32 destination IP-addresses. MPLS traceroute from RS with another 32 destination IP-addresses.
This may help to then enable forwarding of MPLS Echo requests along This may help to then enable forwarding of MPLS Echo requests along
all of R110's paths to RD via R120 and R121, respectively. With bad all of R110's paths to RD via R120 and R121, respectively. With bad
luck, R110 will forward only 14 or 15 addresses via R120. R120 luck, R110 will forward only 14 or 15 addresses via R120. R120
forwards MPLS Echo requests along 12 equal cost paths to RD. Then forwards MPLS Echo requests along 12 equal cost paths to RD. Then
again, there's a fair chance that more destination IP-addresses are again, there's a fair chance that more destination IP-addresses are
required to forward at least one MPLS echo request along all of R120 required to forward at least one MPLS echo request along all of R120
equal cost paths to RD. Per each new set of destination IP- equal cost paths to RD. Each new MPLS Echo Request containing
addresses, the MPLS Echo-Request / Reply dialogue must be completed additional IP destination addresses requires completion of the MPLS
starting from RS to at least all routers along the path to R120. Echo-Request / Reply dialogue starting from RS to at least all
routers along the path to R120.
In the example, roughly only a fourth of the addresses whose In the example, roughly only a fourth of the addresses whose
forwarding is validated starting from node RS will be routed via forwarding is validated starting from node RS will be routed via
R120. ECMP load balancing "filters away" 75% of MPLS Echo requests R120. ECMP load balancing "filters away" 75% of MPLS Echo requests
carrying the destination IP-addresses whose forwarding is to be carrying the destination IP-addresses whose forwarding is to be
determined. If MPLS Echo requests carrying a full set of 32 determined. If MPLS Echo requests carrying a full set of 32
destination IP-addresses were reaching R120, the probability of being destination IP-addresses were reaching R120, the probability of being
unable to forward at least one MPLS Echo request to each outgoing unable to forward at least one MPLS Echo request to each outgoing
interface (or path, respectively) at R110 destined to node RD was interface (or path, respectively) at R110 destined to node RD was
rather small. rather small.
The reason for completing all MPLS Echo Request / Reply dialogues The reason for completing all MPLS Echo Request / Reply dialogues
along the path between RS and R120 is figuring out, which destination along the path between RS and R120 is figuring out, which destination
IP-addresses are routed from R110 to R120 to be available at the IP-addresses are routed from R110 to R120 to be available at the
latter for forwarding traffic along paths to RD which can't be latter for local traffic forwarding along paths to RD which can't be
addressed otherwise. RFC 8029 section 4.1 'Dealing with Equal-Cost addressed otherwise. RFC 8029 section 4.1 'Dealing with Equal-Cost
Multipath (ECMP)' concludes, that 'full coverage may not be possible' Multipath (ECMP)' concludes, that 'full coverage may not be possible'
[RFC8029]. [RFC8029].
Segment Routing (SR) allows node RS to forward MPLS Echo Request Segment Routing (SR) allows node RS to forward MPLS Echo Request
packets with up to, e.g., 32 IP addresses to every node which RS packets with up to, e.g., 32 IP addresses to every node which RS
detects on a path to node RD. Doing so reduces the number of local detects on a path to node RD. Doing so reduces the number of local
router path options to be checked to no more than the sum of the router path options to be checked to no more than the sum of the
interfaces belonging to one of the ECMP routes between nodes RS and interfaces belonging to one of the ECMP routes between nodes RS and
RD. In the case of the example network above, this sum is RD. In the case of the example network above, this sum is
2*(4+8+8+12+4+4)=80 different local router interfaces of routers RS, 2*(4+8+8+12+4+4)=80 different local router interfaces of routers RS,
R110, R120, R121 and R130. That means, that around 2% of the R110, R120, R121 and R130. That means, that around 2% of the
messages and MPLS Label Switched Path checks required with commodity messages and MPLS Label Switched Path checks required with commodity
MPLS traceroute implementations are sufficient to validate all local MPLS traceroute implementations are sufficient to validate all local
forwarding options for paths from RS to RD (note that the calculation forwarding options for paths from RS to RD (note that the calculation
isn't exact, it rather indicates the order of magnitude). The isn't exact, it rather indicates the order of magnitude). The
commodity MPLS OAM implementations are neither broken nor not commodity MPLS OAM implementations are neither broken nor not
working. SR allows an additional router local MPLS OAM method to working. SR allows an additional router local MPLS OAM method to
validate high numbers of ECMP routes reliably and fast. That method validate high numbers of ECMP routes reliably and fast. The method
proposed here reduces the number of MPLS Echo-Request / -Reply proposed here reduces the number of MPLS Echo-Request / -Reply
dialogues to be stored and completed at the origing of the path dialogues to be stored and completed by the origing of the path
validation. validation and it reduces the number of MPLS Echo-Request / -Reply
processing at intermediate nodes.
The functions specified by this document do not require changes in The functions specified by this document do not require changes in
the MPLS OAM protocol as specified by [RFC8029] and [RFC8287]. the MPLS OAM protocol as specified by [RFC8029] and [RFC8287].
1.1. Requirements Language 1.1. 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].
skipping to change at page 5, line 24 skipping to change at page 5, line 42
Suppose SR to be deployed in the case of the example network and Suppose SR to be deployed in the case of the example network and
digits following the letter "R" to indicate the corresponding Node- digits following the letter "R" to indicate the corresponding Node-
SIDs. Assume "mixed operation" of commodity MPLS OAM and the option SIDs. Assume "mixed operation" of commodity MPLS OAM and the option
applying SR. RS starts a commodity MPLS Echo request to R110. After applying SR. RS starts a commodity MPLS Echo request to R110. After
having received an MPLS Echo reply from R110 indicating local paths having received an MPLS Echo reply from R110 indicating local paths
of R110 on which none of the packets with the remaing 16 IP addresses of R110 on which none of the packets with the remaing 16 IP addresses
will be forwarded, RS creates an MPLS Echo Request which transports will be forwarded, RS creates an MPLS Echo Request which transports
the original 32 IP addresses to R110. To do so, an additional top- the original 32 IP addresses to R110. To do so, an additional top-
Segment is pushed carrying the R110 Node-SID, 110. The message below Segment is pushed carrying the R110 Node-SID, 110. The message below
that additional segment is coded as a standard RFC8287 MPLS Echo this additional segment is coded as a standard RFC8287 MPLS Echo
request. Two things are special: the TTL of the MPLS header request. Two things are special: the TTL of the MPLS header
containing the Node SID of RD is always set to 1. Further, a containing the Node SID of RD is always set to 1. Further, a
seperate sequence number series needs to be started to distinguish seperate sequence number series needs to be started to distinguish
the starting point of this SR using MPLS OAM sequence. Coding space the starting point of this SR using MPLS OAM sequence. Coding space
for MPLS OAM Sender's Handle and Sequence Number offer sufficient for MPLS OAM Sender's Handle and Sequence Number offer sufficient
coding space [RFC8029]. If PHP is active, the R110 Node-SID is coding space [RFC8029]. If PHP is active, the R110 Node-SID is
implicitly present only on the link to a neighboring node. Still implicitly present only on the link to a neighboring node. Still
packets with all 32 IP-destination addresses are forwarded to R110. packets with all 32 IP-destination addresses are forwarded to R110.
The chances to address all of the 16 ECMP paths of R110 to RD with The chances to address all of the 16 ECMP paths of R110 to RD with
the originally configured 32 IP-addresses increase. The same method the originally configured 32 IP-addresses increase. The same method
is repeated for R120. Now the top Segment picked by node RS is the is repeated for R120. Now the top Segment picked by node RS is the
Node-SID of R120, again with a separate Sender's Handle and Sequence Node-SID of R120, again with a separate Sender's Handle and Sequence
Number combination. Note, that the MPLS Echo request destined to Number combination. Note, that the MPLS Echo request destined to
R120 doesn't require execution of MPLS OAM functions in R110. That R120 doesn't require execution of MPLS OAM functions in R110. That
latter node simply forwards the packet to R120. Also R120 receives latter node simply forwards the packet to R120. Also R120 receives
32 IP-addresses (which is a significant increase as compared to 32 IP-addresses (which is a significant increase as compared to
commodity MPLS OAM). commodity MPLS OAM).
As a result, the MPLS Echo reply tables maintained by RS likely As a result, the MPLS Echo reply tables maintained by RS likely
indicate ECMP several forwarding masks of the same IP address range indicate several forwarding masks correlated to the same IP address
(discerned by the starting node receiving the MPLS Echo request with range (discerned by the intermediate node receiving an MPLS Echo
top Segment TTL=1). For every path at an indermediate node, to which request with top Segment TTL=1). For every path at an indermediate
the latter can't foward an MPLS Echo request due to the limited node, to which the latter can't foward an MPLS Echo request due to
number of available IP-addresses, a suitable SR top segement is added the limited number of available IP-addresses, a suitable SR top
for an additional next MPLS Echo request of node RS. This in the end segement is added for an additional next MPLS Echo request of node
allows to circumvent the IP-address filtering effect caused by ECMP. RS. This in the end allows to circumvent the IP-address filtering
effect caused by ECMP.
Being able to forward a "complete" set of IP addresses to any Being able to forward a "complete" set of IP addresses to any
interface along an end-to-end path is helpful in locating errors. interface along an end-to-end path is helpful in locating errors.
Different MPLS OAM addressing options also offer more possibilities Different MPLS OAM addressing options also offer more possibilities
to test and unambiguosly locate a faultily sub-path. to test and unambiguosly locate a failed sub-path.
2.1. Operation in an SR MPLS domain applying only IP-header based ECMP 2.1. Operation in an SR MPLS domain applying only IP-header based ECMP
The basic operation is to transport an MPLS Echo request from the The basic operation is to transport an MPLS Echo request from the
sender node sequentially to a next hop identified on any of the paths sender node sequentially to a next hop identified on any of the paths
to a destination node. This is done by applying standard SR to a destination node. This is done by applying standard SR
methodology, which here consists of pushing one additional Node-SID methodology, which here consists of pushing one additional Node-SID
on top of the Label-stack to be validated by the sender node. The on top of the Label-stack to be validated by the sender node. The
Node-SID is set to the value of the node, whose forwarding plane Node-SID is set to the value of the node, whose forwarding plane
information is requested by the MPLS Echo request. This is information is requested by the MPLS Echo request. This is
skipping to change at page 7, line 33 skipping to change at page 8, line 5
request. As the idea is to determine the incoming interface of the request. As the idea is to determine the incoming interface of the
node, whose ECMP path choices are requested by MPLS OAM, the node, whose ECMP path choices are requested by MPLS OAM, the
additionaly pushed Node-SID here is that of the node preceding the additionaly pushed Node-SID here is that of the node preceding the
intermediate node, whose forwarding information is requested. The intermediate node, whose forwarding information is requested. The
Adj-SID is chosen to correspond to a specific incoming interface of Adj-SID is chosen to correspond to a specific incoming interface of
the intermediate node whose forwarding information is requested. As the intermediate node whose forwarding information is requested. As
the aim of that test is to ensure that every incoming to outgoing the aim of that test is to ensure that every incoming to outgoing
interface path choice of the intermediate node can be addressed, the interface path choice of the intermediate node can be addressed, the
topology information required to identify the upstream Adj-SID topology information required to identify the upstream Adj-SID
corresponding to an incoming interface of the intermediate node is corresponding to an incoming interface of the intermediate node is
assumed to be present and maintained in the originating node. This assumed to be present at and maintained by the node originating the
additional MPLS to IP topology excerpt information results from prior MPLS data plane failure test. This additional MPLS to IP topology
MPLS path validations of the same basic set of MPLS path validations information excerpt results from prior MPLS path validations of the
between the source node and the destination node (this is to express, same basic set of MPLS path validations between the source node and
that no extra measurement effort is caused, as correlation of the destination node (this is to express, that no extra measurement
available information is sufficient). The resulting label stack is effort is caused, as correlation of available information is
illustrated by figure 3. sufficient). The resulting label stack is illustrated by figure 3.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Node-SID of node preceding the node whose fwd info is requested| |Node-SID of node preceding the node whose fwd info is requested|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Adj-SID corresp. to inc-IF of node whose fwd info is requested | |Adj-SID corresp. to inc-IF of node whose fwd info is requested |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Sender node MPLS Echo request + + Sender node MPLS Echo request +
skipping to change at page 8, line 4 skipping to change at page 8, line 24
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Node-SID of node preceding the node whose fwd info is requested| |Node-SID of node preceding the node whose fwd info is requested|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Adj-SID corresp. to inc-IF of node whose fwd info is requested | |Adj-SID corresp. to inc-IF of node whose fwd info is requested |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Sender node MPLS Echo request + + Sender node MPLS Echo request +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 Figure 3
Figure 3: MPLS OAM Label Stack applying SR features if ECMP is Figure 3: MPLS OAM Label Stack applying SR features if ECMP is
additionally based on incoming interfaces. additionally based on incoming interfaces.
In the network example of figure 1, node RS picks the Node-SID of In the network example of figure 1, node RS picks the Node-SID of
R110 and an Adj-SID of R110 corresponding to a particular incoming R110 and an Adj-SID of R110 corresponding to a particular incoming
interface of R120, if the latter's ECMP path also depends on the interface of R120, if the latter's ECMP path also depends on the
incoming interface, by which the MPLS Echo request was received. incoming interface, by which the MPLS Echo request was received.
Here, the full set of original IP-addresses can be forwarded Here, the full set of original IP-addresses can be forwarded
individually per incoming interface of the router whose MPLS individually per incoming interface of the router whose MPLS
forwarding information is requested. In the example above, it is forwarding information is requested. In the example above, it is
node R120 (not node R110.) Monitoring incoming interface based ECMP node R120 (not node R110.) Monitoring incoming interface based ECMP
results in a higher number of MPLS OAM validations, no matter whether results in a higher number of MPLS OAM validations, no matter whether
commodity MPLS OAM is applied or the option specified here. The commodity MPLS OAM is applied or the option specified here. The
overall sum of tests now is determinde by the sum of per node overall sum of tests now is determined by the sum of per node
incoming * outgoing paths ( or interfaces, respectively). If the incoming * outgoing paths (or interfaces, respectively). If the
method specified here is applied in the case of the example network, method specified here is applied in the case of the example network,
2*(4*8 + 4*8 + 8*12 + 8*4 + 12*4 + 4*4) = 512 MPLS Echo-Request / 2*(4*8 + 4*8 + 8*12 + 8*4 + 12*4 + 4*4) = 512 MPLS Echo-Request /
Response validations are required. Note that this is still a smaller Response validations are required. Note that this is still a smaller
number than the original 4096 path validations in the case of number as compared to the original 4096 path validations resulting in
comodity MPLS OAM required for a domain applying ECMP based on IP- the case of comodity MPLS OAM based on IP-address information only
address information only. Note that the number of required MPLS OAM deployed by a domain applying ECMP. Note that the number of required
path validations is increasing significantly, if ECMP forwarding is MPLS OAM path validations is increasing significantly, if ECMP
in addition based on incoming interfaces and the product of a nodes forwarding is in addition based on incoming interfaces and the
incoming * outgoing interfaces is high. product of a nodes incoming * outgoing interfaces is high.
3. IANA Considerations 3. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
4. Security Considerations 4. Security Considerations
This document does not introduce new functionality. It combines This document does not introduce new functionality. It combines
Segment Routing functions with those of MPLS OAM. The related Segment Routing functions with those of MPLS OAM. The related
security sections apply, see [RFC8029] and [RFC8402]. security sections apply, see [RFC8029] and [RFC8402].
 End of changes. 20 change blocks. 
55 lines changed or deleted 59 lines changed or added

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