| < 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/ | ||||