Skip to content

Meeting Minutes: December 6, 2018

JK Lee edited this page Dec 8, 2018 · 1 revision

Meeting Time and Location

10 am to 11:30 am PDT (GMT - 8), Barefoot Networks, 4750 Patrick Henry Dr, Santa Clara, CA 95054

Attendees

Barefoot Networks: Jeongkeun Lee, Mickey Spiegel

Cisco Systems: Ramesh Sivakolundu

As for the layout of this new 32b metadata, the working group decided to follow the similar layout of egress queue occupancy -- 8b buffer ID, 24b buffer occupancy level -- as the example layout put in the spec. We also clarified in the spec that different implementations can 1) use different layouts and semantics (semantics such as buffer occupancy unit) and 2) declare them in the metadata YANG model. These changes have been pushed to the PR. The PR is merged to INT.mdk master and will be the major change in INT v1.1 against INT v1.0.

Remaining PRs

The other open PRs for INT spec (domain specific extension, IPv6 encap) and the one for telemetry report spec (opaque data) will go into v2.0 of these two specs.

Improving VXLAN GPE encap

The INT transport over VXLAN GPE has a deployment issue since most production VXLAN deployments do not use VXLAN GPE. The working group discussed one solution that INT Source/Sink devices convert between VXLAN to VXLAN GPE so that INT can be applied to the case where server-side vswitches support only VXLAN. There was a desire to push this change to INT v1.1 while it was not clear if the solution is backward compatible with INT v1.0. What if the source switch is v1.1 while the sink is v1.0 and vice versa? Mickey Spiegel will create a PR and the working group will review and decide. With this, INT v1.1 cut is delayed to early 2019.

Two questions arose for the YANG model.

Can it be used to handle compatibility issue between switch dataplanes?

The YANG model was introduced to help the metadata collector to deal with the different metadata semantics from different implementations. It will also handle different metadata field layouts as the need was identified in the discussion for PR #55, but the use case is still confined to handle compatibility between the collector and switches. In the context of VXLAN GPE conversion, one idea was proposed to use the YANG model to describe the INT version number, and let the INT domain manager to use the version information to make a decision whether to enable the VXLAN<->GPE conversion or not. The working group agreed that is a potentially useful extension to the YANG model but decided not to introduce this capability (or dependency to the YANG model) before INT v2.0. The backward-compatibility decision for the VXLAN<->GPE conversion will be made independent of the YANG model.

Do we need to version the YANG model?

Versioning is needed if any definition in the YANG model need to change. We're fine if things will be only added to the model. So far the working group hasn't seen a case that existing definitions would need to change. We will continue this discussion in the next meeting.

Next Steps

Next meeting would be held in the 2nd week of 2019, (Thursday, January 10, 2019) at the same time 10 to 11:30 am Pacific Time.