Added set-ip-ttl under policy forwarding action.

[vishnureddybadveli]

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.

[LimeHat]

1. 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?)

2. TTL is an ipv4 specific term, is this an ipv4-only use case? Or do you intend to support ipv6 hop-limit as well?

[rgwilton]

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.

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 2896f24

[dplore]

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:
an ingress packet has TTL=1. Instead of consuming or dropping the packet, set the TTL again to 1 (preserve it, don't decrement it).

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)

[trlongth]

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: an ingress packet has TTL=1. Instead of consuming or dropping the packet, set the TTL again to 1 (preserve it, don't decrement it).

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?

[dplore]

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: an ingress packet has TTL=1. Instead of consuming or dropping the packet, set the TTL again to 1 (preserve it, don't decrement it).
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.

• PR Add static next-hop-groups and encapsulation headers #1234 can cover setting the TTL of the outer, IPv4 packet.
• This PR Added set-ip-ttl under policy forwarding action. #1263 is needed to set the TTL of the inner (ingress or payload) packet.

[vishnureddybadveli]

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: an ingress packet has TTL=1. Instead of consuming or dropping the packet, set the TTL again to 1 (preserve it, don't decrement it).
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.

• PR Add static GUE encapsulation #1234 can cover setting the TTL of the outer, IPv4 packet.
• This PR Added set-ip-ttl under policy forwarding action. #1263 is needed to set the TTL of the inner (ingress or payload) packet.

I agree and I believe we should have the ability to set the TTL of the inner packet (payload).

[vishnureddybadveli]

1. 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?)

2. TTL is an ipv4 specific term, is this an ipv4-only use case? Or do you intend to support ipv6 hop-limit as well?

Thank you,
I had updated the description to also include some of the following details.

The action is only intended for encap as of now.
Intention is to change inner packet headers and we would like to skip any "normal" TTL processing rules for inner packet.
Intention is to use IPV4 for now but might be extended to ipv6 hop-limit based on use cases from customers.

[dplore]

/gcbrun

[LimeHat]

@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,

The action is only intended for encap as of now.

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)

[dplore]

@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,

The action is only intended for encap as of now.

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

1. A PF rule for the match dst-ip, action set-ip-ttl
2. That same dst-ip will also have a next-hop-group with encap-headers fields set.

Does that sound correct to you @vishnureddybadveli ?

[vishnureddybadveli]

@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,

The action is only intended for encap as of now.

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

1. A PF rule for the match dst-ip, action set-ip-ttl
2. That same dst-ip will also have a next-hop-group with encap-headers fields set.

Does that sound correct to you @vishnureddybadveli ?

Thank you Darren/Sergey,
Sorry my mistake I should have clarified, I had been describing the end result of one of the use case we are seeing.
This PR is purely trying to solve the following first action
1.policy-forwarding action (A PF rule for the match dst-ip, action set-ip-ttl)
2.potential use of encap-headers which might be set using gRIBI or via gNMI (in a PR coming soon to update policy-forwarding models).

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

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)

[dplore]

Reviewed in March 25, 2025 OC operators meeting without objection and only the above comments on vendor feature support.

[dplore]

/gcbrun

[LimeHat]

Hi Vishnu,

Sorry my mistake I should have clarified, I had been describing the end result of one of the use case we are seeing.

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:

1. there's no additional headers on ingress (no MPLS, no IP-in-IP, no GUE)
2. the router receives a plain IP packet with a single IPv4 header that has any TTL (including, but not limited to, TTL=1)
3. the objective is to rewrite (keep/preserve) TTL on ingress, and perform an action which can be dictated by the same VRF-policy, or it can be a regular routing lookup according to the routing table/AFT.
4. rewrite is performed before any further processing; e.g. for packets which arrive with ttl=0/1 we don't punt it to the control module, don't send TTL expired.
5. 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?

[vishnureddybadveli]

Hi Vishnu,

Sorry my mistake I should have clarified, I had been describing the end result of one of the use case we are seeing.

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:

1. there's no additional headers on ingress (no MPLS, no IP-in-IP, no GUE)
2. the router receives a plain IP packet with a single IPv4 header that has any TTL (including, but not limited to, TTL=1)
3. the objective is to rewrite (keep/preserve) TTL on ingress, and perform an action which can be dictated by the same VRF-policy, or it can be a regular routing lookup according to the routing table/AFT.
4. rewrite is performed before any further processing; e.g. for packets which arrive with ttl=0/1 we don't punt it to the control module, don't send TTL expired.
5. 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?

Great Analysis and I respect your observations,
I am in complete agreement with your findings, just adding one clarification:

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?

• I have seen different vendors behave differently and so we use different techniques:
  For Cisco a plain IP packet coming in with TTL = 1 we explicitly set TTL=2, I think letting the router decrement TTL by 1 after rewrite during normal processing will be fine in this case.
  For ARISTA a plain IP packet coming in with TTL = 1 we preserve it i.e set TTL=1, I think ARISTA have a config that do not let the router decrement TTL by 1 after rewrite during normal processing.

So I do not think we can generalize router decrement TTL by 1 after rewrite during normal processing.