Skip to content

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

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

vishnureddybadveli
Copy link

@vishnureddybadveli vishnureddybadveli commented Mar 5, 2025

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.

Copy link

@LimeHat LimeHat left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

rgwilton commented Mar 5, 2025

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
Copy link
Member

dplore commented Mar 5, 2025

/gcbrun

@dplore dplore moved this to Ready to discuss in OC Operator Review Mar 5, 2025
@OpenConfigBot
Copy link

OpenConfigBot commented Mar 5, 2025

No major YANG version changes in commit 2896f24

@dplore
Copy link
Member

dplore commented Mar 6, 2025

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
Copy link

trlongth commented Mar 6, 2025

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
Copy link
Member

dplore commented Mar 6, 2025

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.

@vishnureddybadveli
Copy link
Author

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.

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

@vishnureddybadveli
Copy link
Author

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

dplore commented Mar 8, 2025

/gcbrun

@LimeHat
Copy link

LimeHat commented Mar 8, 2025

@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
Copy link
Member

dplore commented Mar 17, 2025

@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
Copy link
Author

@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
Copy link
Member

dplore commented Mar 19, 2025

/gcbrun

@dplore
Copy link
Member

dplore commented Mar 25, 2025

/gcbrun

@dplore
Copy link
Member

dplore commented Mar 25, 2025

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
Copy link
Member

dplore commented Mar 25, 2025

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

@dplore dplore moved this from Ready to discuss to Waiting for author in OC Operator Review Mar 25, 2025
@dplore
Copy link
Member

dplore commented Mar 26, 2025

/gcbrun

@LimeHat
Copy link

LimeHat commented Mar 31, 2025

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Waiting for author
Development

Successfully merging this pull request may close these issues.

6 participants