Interface/Policy-based GUE Decapsulation FNTs for IPv4 tunnel #3473
Conversation
The change is to create a README.md for IPv4 GUE tunnel test cases.
Removed mpls reference as there will be a separate readme file for it.
Updated README file for Interface/policy-based GUE decapsulation feature with various test cases.
Pull Request Test Coverage Report for Build 11600518646Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
|
|
||
| ## Summary | ||
|
|
||
| This is to test the the functionality of policy-based forwarding (PF) to decapsulate Generic UDP Encapsulation (GUE) traffic. These tests verify the use case of IPv4, and IPv6 encapsulated traffic in IPv4 GUE tuennel. The tests are meant for `Tunnel Interface` or `Policy Based` implementation of IPv4 GUE tunnel. The tests validate that the DUT performs the following action. |
There was a problem hiding this comment.
This is to test the the functionality of policy-based forwarding (PF) to decapsulate Generic UDP Encapsulation (GUE) traffic. These tests verify the use case of IPv4, and IPv6 encapsulated traffic in IPv4 GUE tunnel. The tests are meant for Tunnel Interface or Policy Based implementation of IPv4 GUE tunnel. The tests validate that the DUT performs the following action.
| - GUE Inner protocol type must be derived from a unique DST port. If not specifically configured, then the following default DST UDP port will be used. | ||
| - For inner IPv4 - GUE UDP port 6080 | ||
| - For inner IPv6 - GUE UDP port 6615 | ||
| - Post decapsulation the DUT should copy outer TTL(and decrement) to inner header and maintain the inner DSCP vaule. |
There was a problem hiding this comment.
" copy outer TTL(and decrement) to inner header and maintain the inner DSCP value"
- For TTL, requirement is to copy inner TTL to outer during Encap. However, it isnt a requirement to do the reverse during Decap.
- Maintaining the inner DSCP value during Decap isnt a requirement anymore.
There was a problem hiding this comment.
if you don't copy the ttl back post decapsulation, then what will ttl look like.
For example:
---ip4-ttl-30----R1(encap)----R2----R3-----R4----R5(decap)----->do we expect ip4 ttl25 here or not?
For DSCP, Cisco Fretta and 8K have different implementation.
Currently, if I understand correctly, then inner DSCP is not modified. At the encapsulation time, we can match dscp and modify outer tunnel dscp header, but at the decapsulation time, the inner dscp remains as is.
| - If explicit configration is present to not copy the TTL, then it will be honored. | ||
| - Decapsulate the packet only if it matches the locally configured GUE VIP and associated UDP port/port-range. | ||
| - Traffic not subject to match criteria will be forwared using traditional IP forwarding. | ||
| - UDP checksum in the transport (outer) header is used for the packet integrity validation, and the DUT will ignore the GUE checksum (non-zero or all-zero). |
There was a problem hiding this comment.
"and the DUT will ignore the GUE checksum (non-zero or all-zero)"
We are using GUE v1 which doesnt have a GUE header. So I dont think we should include the last part as it may add confusion for NOS impementations.
There was a problem hiding this comment.
Just came to know about it today, so I removed this section. In the original asks, we had mentioned about this specific requirement.
| ``` | ||
|
|
||
| * ATE Port 1: Generates GUE-encapsulated traffic with various inner (original) destinations. | ||
| * ATE Port 2: Receives decapsulated traffic whose inner destination matches the policy. |
There was a problem hiding this comment.
"matches the policy"
Which Policy?
There was a problem hiding this comment.
for this summary explanation, it would be sufficient to give the policy a name. THen below where you generate a config for the policy, ensure you use the intended name.
There was a problem hiding this comment.
Added the policy name TEST-GUE
| 2. Static Routes/LSPs: | ||
| * Configure an IPv4 static route to GUE decapsulation destination (DECAP-DST) to Null0. | ||
| * Have policy configuration that match GUE decapsulation destination and default/non-default GUE UDP port/port-range for the decapsulation. | ||
| * If udp port is not configured then the default GUE UDP port will be inherited/used. |
There was a problem hiding this comment.
"default GUE UDP port will be inherited/used."
- Inherited from where?
- Used: Since we are using GUE v1, there isnt a GUE header that will carry details on the inner header. So looks like the ask here is for the NOS to look at the first 4 bits of the UDP payload
- If 0x4, then the inner header is IPv4
- If 0x6, then the inner header is IPv6
- I none of the above, then it is MPLS payload
If the above is the expectation, then we should probably call it so
There was a problem hiding this comment.
I modified and mentioned the current default port (UDP port 6080 for Inner IPv4 and UDP port 6615 for Inner IPv6 traffic)
for NOS to understand which packet to perform decap and which packet to do transit, one has to specify udp destination port for the decap. Post decap, it can check first 4 bits to determine inner is ipv4 or ipv6.
I don't think GUE1 will support mpls as is because none of the above won't default to MPLS is not mentioned in draft, which is expired.
| * If udp port is not configured then the default GUE UDP port will be inherited/used. | ||
| * Apply the defined policy on the Ingress (DUT port1) port. | ||
| * Configure static routes for encapsulated traffic destinations IPV4-DST1 and IPV6-DST1 towards ATE Port 2. | ||
| * Configure static MPLS label binding (LBL1) towards ATE Port 2. Next hop of ATE Port 1 should be indicated for MPLS pop action. |
There was a problem hiding this comment.
"Next hop of ATE Port 1 should be indicated for MPLS pop action"
What does this mean?
Following is an example config. Do you mean something else here? OR you meant, ATE:Port-2?
mpls {
static-label-switched-path test {
transit 1001035 {
next-hop ATE:Port2_address;
pop;
}
}
There was a problem hiding this comment.
Removed this section as not needed.
|
|
||
| 3. Policy-Based Forwarding: | ||
| * Rule 1: Match GUE traffic with destination DECAP-DST using destination-address-prefix-set and default/non-default GUE UDP port/port-range for decapsulation. | ||
| * If udp port is not configured then the default GUE UDP port will be inherited/used. |
There was a problem hiding this comment.
Same suggestion as above to add clarifications along what exactly do we want the NOS to do here.
There was a problem hiding this comment.
do you mean add sample vendor config?
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Outdated
Show resolved
Hide resolved
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Outdated
Show resolved
Hide resolved
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Show resolved
Hide resolved
|
|
||
| ## Summary | ||
|
|
||
| This is to test the the functionality of policy-based forwarding (PF) to decapsulate Generic UDP Encapsulation (GUE) traffic. These tests verify the use case of IPv4, and IPv6 encapsulated traffic in IPv4 GUE tuennel. The tests are meant for `Tunnel Interface` or `Policy Based` implementation of IPv4 GUE tunnel. The tests validate that the DUT performs the following action. |
There was a problem hiding this comment.
What do tunnel interface and policy-based here? Are we allowing variance between the implementations -- note that we map a single policy-based approach to multiple underlying vendors already, and will require that in OpenConfig going forward...
There was a problem hiding this comment.
+1, we should focus on policy based.
The only need for interface tunnels I think is if we want a control plane protocol (ie: BGP) to have it's session encapsulated over a "fake interface" (tunnel). Otherwise, we should use policy forwarding rules to determine encap/decap.
Underneath OC, implementations can translate the policy into their implementation specific requirements.
There was a problem hiding this comment.
Thanks Rob/Darren for taking time and sharing your input. I modified this section. Please take a look.
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Outdated
Show resolved
Hide resolved
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Outdated
Show resolved
Hide resolved
| - No packet loss. | ||
| - Inner-packet traffic-class should be preserved. | ||
| - Inner-packet TTL value should be decremented by 1 to 63. | ||
| - PF counters reflect decapsulated packets. |
There was a problem hiding this comment.
It'd be good to clarify which counters this refers to.
| - Inner-packet TTL value should be decremented by 1 to 63. | ||
| - PF counters reflect decapsulated packets. | ||
|
|
||
| ### PF-1.4.8: GUE Decapsulation of inner IPv6 traffic using non-default GUE UDP port or port-range and GUE checksum ALL-ZERO |
There was a problem hiding this comment.
Where did this port range specification come from?
I'd suggest that given that all these tests depend on some definition of a configuration schema that is as yet undefined, someone drafts the required configuration ASAP.
There was a problem hiding this comment.
The port range requirement is in b-265024996.
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Outdated
Show resolved
Hide resolved
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Outdated
Show resolved
Hide resolved
feature/policy_forwarding/GUE/Outer_IPv4/decapsulation/otg_tests/Inner_IP/README.md
Show resolved
Hide resolved
| ``` | ||
|
|
||
| * ATE Port 1: Generates GUE-encapsulated traffic with various inner (original) destinations. | ||
| * ATE Port 2: Receives decapsulated traffic whose inner destination matches the policy. |
There was a problem hiding this comment.
for this summary explanation, it would be sufficient to give the policy a name. THen below where you generate a config for the policy, ensure you use the intended name.
|
|
||
| ## Summary | ||
|
|
||
| This is to test the the functionality of policy-based forwarding (PF) to decapsulate Generic UDP Encapsulation (GUE) traffic. These tests verify the use case of IPv4, and IPv6 encapsulated traffic in IPv4 GUE tuennel. The tests are meant for `Tunnel Interface` or `Policy Based` implementation of IPv4 GUE tunnel. The tests validate that the DUT performs the following action. |
There was a problem hiding this comment.
+1, we should focus on policy based.
The only need for interface tunnels I think is if we want a control plane protocol (ie: BGP) to have it's session encapsulated over a "fake interface" (tunnel). Otherwise, we should use policy forwarding rules to determine encap/decap.
Underneath OC, implementations can translate the policy into their implementation specific requirements.
Updated the file to remove not relevant test cases for GUE variant 1 and suggestions for some tests.
Modified test number
Modified the document to reflect gue variant 1 test scenarios and resolve the comments.
Updated readme with additional test details and resolved the comments.
Added a functional tests for feature Interface/Policy-based GUE decapsulation for IPv4 tunnel.