Add a configurable dont-fragment flag to sflow

[rgwilton]

Change Scope

Adding a boolean configuration setting to set the df-bit for sflow packets to a particular collector.
This change is backwards compatible.

Platform Implementations

• Implementation IOS XR: We are adding support for this.
• I couldn't see a second implementation that implements this, most relying on setting the max packet size, but it seems a reasonable and useful addition.

module: openconfig-sampling-sflow

 augment /oc-sampling:sampling:
   +--rw sflow
      +--rw config
      |  +--rw enabled?                 boolean
      |  +--rw agent-id-ipv4?           oc-inet:ipv4-address
      |  +--rw agent-id-ipv6?           oc-inet:ipv6-address
      |  +--rw dscp?                    oc-inet:dscp
      |  +--rw sample-size?             uint16
      |  +--rw polling-interval?        uint16
      |  +--rw ingress-sampling-rate?   uint32
      |  +--rw egress-sampling-rate?    uint32
      +--ro state
      |  +--ro enabled?                 boolean
      |  +--ro agent-id-ipv4?           oc-inet:ipv4-address
      |  +--ro agent-id-ipv6?           oc-inet:ipv6-address
      |  +--ro dscp?                    oc-inet:dscp
      |  +--ro sample-size?             uint16
      |  +--ro polling-interval?        uint16
      |  +--ro ingress-sampling-rate?   uint32
      |  +--ro egress-sampling-rate?    uint32
      +--rw collectors
      |  +--rw collector* [address port]
      |     +--rw address    -> ../config/address
      |     +--rw port       -> ../config/port
      |     +--rw config
      |     |  +--rw address?             oc-inet:ip-address
      |     |  +--rw port?                oc-inet:port-number
      |     |  +--rw source-address?      oc-inet:ip-address
      |     |  +--rw max-datagram-size?   uint16
      |     |  +--rw dont-fragment?       boolean                         <--- ADDED
      |     |  +--rw network-instance?    oc-netinst:network-instance-ref
      |     +--ro state
      |        +--ro address?             oc-inet:ip-address
      |        +--ro port?                oc-inet:port-number
      |        +--ro source-address?      oc-inet:ip-address
      |        +--ro max-datagram-size?   uint16
      |        +--ro dont-fragment?       boolean                         <--- ADDED
      |        +--ro network-instance?    oc-netinst:network-instance-ref
      |        +--ro packets-sent?        oc-yang:counter64

[dplore]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 03c47cf

[dplore]

/gcbrun

[rgwilton]

@dplore, did you get a chance to discuss this in the operators meeting? What is the next step, should I add it to the next monthly meeting? Is there anything that I can do to expedite this at all (given is such a small addition)?

[dplore]

/gcbrun

[dplore]

@dplore, did you get a chance to discuss this in the operators meeting? What is the next step, should I add it to the next monthly meeting? Is there anything that I can do to expedite this at all (given is such a small addition)?

We haven't reviewed yet due to the depth of the queue to review. However I'll respond.

This looks reasonable to me, but we will need to have at least 2 references to implementations, and/or assertions that this feature is in development, before merging. Often assertion of development in progress can be communicated by an network operator who is working with multiple implementors.

[masood-shah]

max-datagram-size in OC already maps to the Cisco packet-length command. we should NOT add a new leaf for packet length

i support the addition of the dont-fragment leaf. while max-datagram-size handles local segmentation, the dont-fragment bit is essential for path MTU enforcement nd avoiding the penalties of mid-path fragmentation

[earies]

Speaking on behalf of JUNOS/EVO - we do not support any DF-bit toggling today but rather just setting of the datagram size.

Quick glance on public docs of EOS/SRL appears to be similar but will defer to those respective implementors

[masood-shah]

We do not support moving forward with this addition.

Technically max-datagram-size already solves the fragmentation issue by allowing operators to cap the payload below the MTU. Additionally introducing specific knobs for IPv4 fragmentation creates technical debt that conflicts with the industry direction toward IPv6. Finally without multi-vendor parity this feature does not meet the criteria for inclusion in the standard models

[masood-shah]

We do not support moving forward with this addition

Technically max-datagram-size already solves the fragmentation issue by allowing operators to cap the payload below the MTU. Additionally introducing specific knobs for IPv4 fragmentation creates technical debt that conflicts with the industry direction toward IPv6. Finally without multi-vendor parity, this feature does not meet the criteria for inclusion in the standard models