-
Notifications
You must be signed in to change notification settings - Fork 667
Added set-ip-ttl under policy forwarding action. #1263
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Added set-ip-ttl under policy forwarding action. #1263
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- please elaborate on the exact behavior expectations:
- can it be combined with other actions, such as encap/decap?
- if yes, what headers are changed (inner/outer)?
- what are the interaction with "normal" TTL processing rules? do we rewrite before or after TTL is decremented by the router? (e.g. if my router receives a packet with TTL=0, and you have a rule set-ip-ttl=10; do we send TTL expired, or do we rewrite first and after processing the packet will have ttl=9?)
- TTL is an ipv4 specific term, is this an ipv4-only use case? Or do you intend to support ipv6 hop-limit as well?
I agree with the issues raised by @LimeHat. Although this is adding a single new leaf, given that there doesn't seem to be an existing implementations that support this by any vendor, then I think it needs a stronger specification of the behaviour, e.g., how it interacts with other features, etc, to have any change of consistent implementations. |
/gcbrun |
No major YANG version changes in commit 2896f24 |
The operational use case for this is at openconfig/featureprofiles#3656. To summarize, the scenario is: The goal is to preserve the inner packet at TTL=1, and not drop it. We also want to encapsulate this packet (and other packets not matching this) in MPLS+UDP. This encapsulation is performed one of two ways, either using gRIBI, via AFT MODIFY RPC with encap-headers fields, which include setting the outer UDP packet's TTL, or using a policy-forwarding policy which encapsulates packets not matched by gRIBI and sends them to a different destination than the gRIBI signaled rules would have. Policy-forwarding Rule 1: Now do a lookup on the packet destination IP. If there is a match, the next-hop group may have encap-headers specified (as signalled by gRIBI, including a gRIBI chosen TTL for the outer UDP packet ) The packet may match a less specific (or default) IP route which is configured via gNMI. This static route will also have next-hop with encap-headers specified (following PR #1234) @vishnureddybadveli does this sound good? If so, then perhaps this leaf is not needed after all (at least, not for this use case) |
@dplore Just to confirm my understanding is correct, by saying "this leaf is not needed", do you mean PR #1234 can cover "retain the inner TTL" use case? Also, this PR seems to cover MPLS-UDP, do we have one for MPLS-GRE? |
I misspoke, sorry for the confusion.
|
I agree and I believe we should have the ability to set the TTL of the inner packet (payload). |
Thank you, The action is only intended for encap as of now. |
/gcbrun |
@dplore @vishnureddybadveli I don't think the two comments you provided are aligned? Scenario described by @dplore , it appears, describes a plain IP packet that has ttl=1 and requires a TTL rewrite. There's no extra encap or inner IP headers on ingress, we're working with an outer (and the only) IP header before (potentially) adding a new header via encap action. Scenario described by @vishnureddybadveli , it appears, implies that a packet is encapsulated (potentially only with an MPLS header? or multiple MPLS headers?) In addition,
This is also not particularly clear to me. If I understood it correctly, @dplore says that TTL rewrite is an independent action which is performed before any further processing, including encapsulation and forwarding which is not dictated by policy-forwarding. If we generalizes this logic, there's nothing that says that the packet has to be encapped (if we rewrite the ttl first and then do a routing lookup, any result from this lookup is possible) |
These are all good observations. The policy-forwarding action is independent of any potential use of encap-headers which might be set using gRIBI or via gNMI (in a PR coming soon to update policy-forwarding models). The operational use case @vishnureddybadveli has will contain
Does that sound correct to you @vishnureddybadveli ? |
Thank you Darren/Sergey, |
/gcbrun |
/gcbrun |
Hi Vishnu, there are some github check errors that should be fixed. Also please provide the path name in your description and add a reference to at least two vendors for support of the feature to set the IP TTL based on destination IP. Do at least two vendors already support this using some native configuration, if yes, please share this. Or do you have commitment from multiple vendors to support this? (You don't need to mention the vendor names for commitment) |
Reviewed in March 25, 2025 OC operators meeting without objection and only the above comments on vendor feature support. |
/gcbrun |
Hi Vishnu,
I think it is good to describe the use case e2e; I just want to make sure that we are all on the same page about it. So, just to confirm:
|
Great Analysis and I respect your observations, should the router decrement TTL by 1 after rewrite during normal processing (since TTL decrement is skipped at the previous step)? Or do you expect that the new value is the one that is sent to the next device?
So I do not think we can generalize router decrement TTL by 1 after rewrite during normal processing. |
Change Scope
(M) release/models/policy-forwarding/openconfig-pf-forwarding-policies.yang
Packet flow:
An IP in MPLS packet enters the device from the backbone/provider network
The inner IP packet is a customer packet and may contain TTL=1 based on customer's use case.
Goal is to provide ability to retain inner packet TTL by setting it again as desired by customer.
Intent is to perform action while encapsulating customer packets and bypass "normal" TTL processing rules.
Platform Implementations
Arista:
Has committed to support the model changes.
Cisco:
Vendor engagement to support the model changes.