Minutes for NVO3 at interim-2015-nvo3-7
minutes-interim-2015-nvo3-7-1

IETF NVO3 WG
Virtual Interim Meeting Minutes
2015-03-13 11:00-12:30 EST (15:00-16:30 GMT)

Chairs: Benson Schliesser, Matthew Bocci
Secretary: Sam Aldrin

Note takers: Ignas, Sam

Topic: Data Plane
(This meeting will be a replacement of the virtual interim meeting originally
 scheduled for 2015-02-27.)

1. Meeting Introduction and Agenda Bashing (10 min)
Chairs

Benson: starting. Waiting for Eric Nordmark to get audio.
This is the same meeting as planned two weeks ago, webex problems last time
prevented from running it.

Benson going through agenda.
•Everyone please sign into Bluesheet
•Today’s agenda is Data plane related topics.
•Making up for the last virtual meeting due to Webex issue
•This is an IETF meeting please read NoteWell
•We are going to hear from Erik about DP efforts
•Later we are going to hear from three encap authors.

Uri: do we plan to rerun this same discussion in two weeks?
Benson: we have a physical meeting in two weeks. I would like to see discussion
on mailing list starting on the data plane, and during the IETF we can continue
with that.

2. Update from the Routing Area Encap Considerations Design Team (20 min)
https://tools.ietf.org/html/draft-rtg-dt-encap-01
Erik Nordmark <nordmark@sonic.net>

Eric Nordmark: overview of DT and some history since Hawaii.
- 8 of us, part of DT, discussed about DP requirements and encaps proposed
- What have we done in the past and what we can learn from it.
- The observation is that there may be multiple encapsulations happening at the
same time. The observation is that the - encaps take care of the issues that
are important for them only. Not necessary independent of the specifics of each
encap. - As an example, what about congestion control? - We try to look from
the perspective of the impact to the packet format, and not only control plane.
- Did not attempt to bring in all what was done for MPLS and L2TP. More focus
on IP and UDP. - Entropy label architecturally appeared to fit well even with
no MPLS. - This is not an attempt to define a new encap that will rule them
all. - A list of common aspects - also covered in charter (slide of 12 steps).
- This will also be covered in rtgwg in Dallas.

David Black: as TSVWG chair: yes, it will be put on agenda for Dallas meeting.

Erik:
- what common data and behavior encapsulation should have? VNI ID is the
minimum. If OAM is carried, do we carry it as is, or allow modifications? - SFC
requires much more modifications. - BIER needs to modify the bitmap as it is
forwarded to turn off bits to indicate that a copy has been sent. - NVO3 might
be the easiest in the space of modifications. - What happens when you use
multiple of these encaps? What should be the common set of functionality? - The
underlying transport also needs some indication that what is carried is an
encap too. - The question for broader IETF is whether it makes sense to pick
something common from transport perspective. Or should one group use Ethernet
types, and another use something else?

Security> Three things - anti-spoofing, can you leverage IPSec, and privacy
considerations. - Anti-spoofing - there is a difference between ULP traffic
over say SSL, and injecting traffic into the overlay. - Might need to do some
hash of header fields, but needs to exclude modifiable fields. NVO3 needs to
understand what kind of threats there may be.

Header protection> running over IPv6 and no header checksum. Do we care about
the headers in the actual encapsulation header not covered by checksum? Should
be at least optional to protect those fields to avoid eg: mis-delivery in case
of error in VNI ID field.

Extensibility> new functionality not seen/needed at the moment and how far do
we go before it breaks? What would actually get implemented in a practical way?

HW friendly> protocol design may impact how it will get deployed later,
component design especially. Example of checksum: if NIC has offload
capabilities, it can do full packet checksum whereas intermediate node cannot
do that easily. - Hardware scales best in parallel. If the field can be
discovered without much sequential processing that would be benefitial. TLVs
don't easily fit this scheme.

Middle-boxes> new middle-boxes may appear that can provide additional
processing of particular encapsulation protocol. NVO3 has touched this briefly
with NVO3/MPLS interworking. NVO3 enabled firewall as an example that looks at
VNI ids. - There is a line of thinking that middle-boxes are evil, same as NATs
are.

Open questions> what is in-order delivery? Do we need to define that over
encap? Timestamps and congestion control indication too.

Next steps> present in rtgwg and tsvwg in Dallas.

Any questions?

Benson: few minutes for questions?

Lucy Yong: would it be good to group the issues for different encaps?
Tunneling? Some may not apply for all encapsulations.

Eric: fair point , we did not yet discuss that. High order message is that we
should think about all of these issues.

Ilango Ganga: you have listed many encap protocols. Do you plan to make
recommendations to each of the relevant working groups? What would be next
steps?

Eric: most of these issues are for the broader area than a specific WG. Example
of MPLS over UDP. Some aspects could be seen as recommendations. Others are
broader discussion items.

David Black: a comment on UDP aspects in transport. Transport area is in
process of revising RFC5xxx on UDP transport (?). That might be a good place to
consolidate the requirements.

Benson: wrapping up to move to next topic.

3. GENEVE (10 min)
https://tools.ietf.org/html/draft-gross-geneve-02
Jon Hudson <jon.hudson@gmail.com>

Jon Hudson: Overview of why we do Geneve. Looking for room for more
functionality in format. Use existing underlay IP fabrics. - Header: no changes
since last revision. - No significant changes to draft since -02 version. -
Implementations: Intel provides support for their NIC now. Linux and OVS
support it now.

Jesse Gross: this slide was done for Honolulu, there are some more
announcements coming.

Jon: looking for adoption and increasing support in the community. Questions?

Benson: as an individual: last slide showed different implementations. Is there
any cross vendor capability overlap in the existing implementations? Jesse:
different implementations do not need to expose the capabilities?

Sam Aldrin: have you considered the issues that Eric has presented previously?

Jesse: Geneve was designed before the DT document came out, but we were aware
of many of those issues already.

Benson: moving to next one.

Lucy Yong: do current implementations support optional headers?

Jesse: yes.

Uri: is there any work on what are the requirements for guidelines for the
encapsulations?

Benson: that is a good question that we need to discuss on mailing list. There
are a number of considerations that we would want to discuss separately. We do
not necessary want to have a 'pick one' approach.

Uri: Interoperability is important in this case - given several possible
options that get built and deployed.

Benson: if we are not building interoperable solutions then what is the point
of IETF. Maybe pick one protocol s must implement and others may be optional
for specific use cases. Would like to see this being discussed on mailing list.

4. VXLAN-GPE (10 min)
https://tools.ietf.org/html/draft-quinn-vxlan-gpe-04
Larry Kreeger <kreeger@cisco.com>

Larry Kreeger:
- generic protocol extensions for VXLAN.
- What we want to achieve - we are extending VXLAN. Allow to carry IPv4/v6,
shim headers. OAM is also important. - Header has a P - next protocol indicator.

Examples:
- Extensibility example with NSH.
- OAM uses another flag bit, O

Future enhancements>
- one way is the reserved bits.
- In order to avoid getting another reserved UDP port, version could be used.
- udp/4790 was allocated for VXLAN-GPE.
- Many changes since previous draft version
- Several closed and open source implementations are on the way, both SW and HW.

Benson: one minute for questions:

Sam Aldrin: you mentioned in OAM slide - the packet should not leak to the
tenant system. How do you ensure in case it does not support OAM bit? Larry: it
must support it. Sam: is there any other way that could leak to tenant system?
Larry: you need to follow the protocol.

Erik Nordmark: what was the reason for not picking the first two bits for
version field? Larry: VXLAN  header is aligned with LISp header, and they are
used there too.

Paul Quinn: LISP group could propose de deprecate the bits.

Lucy: OAM packet is standalone (?)
Larry: OAM packet is a specific type. It requires to recognize OAM bit and then
send to OAM component. If there is no OAM component then drop it.

Benson: moving to next presentation.

5. GUE (10 min)
http://tools.ietf.org/html/draft-herbert-gue-03
Tom Herbert <therbert@google.com>

Tom Herbert: Overview. Header format.
- GUE is derived from GRE.
- Extensibility via extension header.
- VNI id, security, checksum fields defined now.
- Many other options discussed and possibly could be implemented.
- A class of extensions that do not seem interesting - that includes
pseudo-wires, routing header. service related aspects. - Security field - it
needs to protect VNI id and GUE header to avoid corruption and spoofing. -
IPSec interaction - GUE header is outside of IPSec ESP.

Requests - WG adoption.

Benson: questions?

Larry: is this already adopted in TSVWG?
Tom: no, not yet. TSVWG might be more interested in transport, while NVO in
tunneling. David Black: I would prefer data plane stuff to be sorted in NVO3.
Transport aspects - yes, in TSVWG.

6. Open Discussion (30 min)

Benson: any broader questions related to data plane topic:

Ilango: there are 3 different encap protocols all asking for WG adoption. How
WG will proceed here? Benson: we have some flexibility allowed by the charter.
One thing I would like to avoid is beauty contest here. Rather would like to
see WG adopting multiple data plane encaps and let the market decide. It would
be helpful if we had an ability to name one as a must and others as optional.
Would also like to talk on the list about comparisons on the mailing list.
Immediate next step would be to start adoption discussion on the mailing list.
Ilango: adopting one as mandatory and others as optional is not necessary
solving the interoperability issue. Benson: yes, good point, please discuss on
the list. Erik Nordmark: was there any discussion on rechartering in case when
group cannot pick one and treat all as experimental? Benson: we might have
multiple experimental, yes. Erik: different choices may be implemented, and
then we have no interoperability. Benson: if we can pick one that would be
ideal. Another option is to standardize multiple. Right now I am thinking that
we adopt all. Lucy Yong: If we compare then we should align it with the DT
recommendations. Benson: my tentative plan is to send email as a call for
adoption and that discussion should compare design considerations. Anoop
Ghanwani: the danger with multiple encaps is similar to having multiple ways
for extensions. That is difficult for hardware. Benson: yes, agree. Benson:
does the two step process of adopting all and revisiting later is a bad idea?
Ilango: my preference is to better agree on one. Jesse Gross: it is some
contention between what people prefer and what is realistic. David Black: [...]
Erik Nordmark: I suspect that all of the encaps are at different levels of
implementation. To what extent people are willing to chage those things. Do not
know how will that play out because it is already implemented. Ilango Ganga:
maybe we could come up with a hybrid, another protocol, but that is yet another
protocol. Eric: from an industry perspective it gets more flexibility. Benson:
I do not have an answer and was leaning to multiple options and let market
decide. Benson: before Dallas hopefully we have a good discussion on the list.

Benson: thank you for coming. Matthew and I will talk and followup on the
mailing list.