Participants
* Zoltan, Jan, Jiri, Ben P, Georg, Ben M
Review/Discussion of current patch sets
* RTNETLINK tunnel configuration (RedHat)
Done: Merged my Joe on May 18th
* L3 Tunneling (Ericsson)
Done: remaining 3 patches merged by Ben on June 2nd
* L3 tunnel config based on RTNETLINK patches (RedHat)
Work can start. Aim for end of the month for OVS 2.8
* PTAP (Ericsson)
v3 based on final (v9) of L3 Tunneling sent out June 2nd.
To be reviewed by Ben
Gitlab integration branch with PTAP, Basic NSH MD1 fields, Generic
Encap/Decap (EXT-382) for Ethernet and NSH is fully working for userspace
datapath.
We are working on folding the bugfixes into the various patch sets and
submit them to ML this week:
* PTAP - v4 (Ericsson)
Rebased to master after merge of L3 tunneling. No other change compared
to v3 yet.
* Basic Gen Encap/Decap: OF control plane and support for Ethernet
(Ericsson)
v1 (based on PTAP v4)
* Basic NSH MD1 fields (Intel)
v2 (based on PTAP v4). Completely revised since v1 posted April 20th
* Generic Encap/Decap for NSH MD1 (Intel)
v1 (based on Basic Gen Encap/Decap).
Outstanding work:
* Test PTAP and Generic encap/decap(Ethernet) with Linux kernel datapath
Should work without further changes, but bugfixes may be necessary.
* To support NSH with kernel datapath we will also need the following:
NSH MD1 support (fields and encap/decap) in net-next kernel datapath
(Intel)
Yi Yang to start. Jiri can assist with this.
Technical questions:
* It is not safe to modify the "packet-type-aware" property of a bridge,
as already installed packet_type match fields and encap()/decap() actions have
undefined semantics in a non-PTAP bridge.
Should we prevent changing this parameter after bridge creation?
o The general concept of having a bridge property was re-discussed:
* Ben P and M asked whether a "versatile" property per tunnel port would
not be better to control the bridge behavior.
* Jan referred to the discussion in the Google doc (link below) and
argued that maintaining strict backward compatibility for non-PTAP aware
controllers was an important design goal. A bridge-global parameter to turn on
packet type-awareness is the only safe way to not expose a controller to
packet_type effects (e.g. in Packet In).
* Ben P raised the issue with a patch port connecting a PTAP and a
non-PTAP bridge. We need to make sure that the decision in the Google doc, not
to support such patch ports is implemented.
o Ben P: Users are not accustomed that OVSDB is transactional and would
be confused if "packet-type-aware" cannot be set after bridge creation. Rather
explain in documentation that this property should not be changed if there is
flow state already.
o We way need to harden ofproto not to crash in situations where
encap/decap actions are translated in a bridge that is no longer packet-type
aware.
Planning:
* Can we still somehow meet freeze date for OVS 2.8?
o Ben P is aiming at merging these patches for 2.8, provided the review
cycles are fast.
o Ericsson and Intel will do what
* Jan to call for a follow-up meeting next week.
Thanks,
Jan
-----Original Appointment-----
From: Jan Scheurich
Sent: Sunday, 18 December, 2016 15:34
To: Jan Scheurich; Zoltán Balogh; Yang, Yi Y (yi.y.y...@intel.com); Jiri
Benc (jb...@redhat.com); Pravin Shelar; Simon Horman
(simon.hor...@netronome.com); 'ja...@ovn.org'; 'Ben Pfaff';
'ben.mackcr...@corsa.com'; d...@openvswitch.org; Georg Schmuecking
Cc: Maria Pilar Benito Diez
Subject: Sync on PTAP, EXT-382 and NSH - Tue 2017-06-07 17:00 CET
When: Wednesday, 07 June, 2017 17:00-18:30 (UTC+01:00) Amsterdam, Berlin,
Bern, Rome, Stockholm, Vienna.
Where: Skype Meeting
Hi,
Let's have a look at the progress of the different patch series with
respect to submission, review and merging.
Target is still to upstream these changes in time for OVS 2.8.
Thank you,
Jan
Link to the Google design doc:
https://docs.google.com/document/d/1oWMYUH8sjZJzWa72o2q9kU0N6pNE-rwZcLH3-kbbDR8/edit
.........................................................................................................................................
--> Join Skype Meeting<https://meet.ericsson.com/jan.scheurich/HJ2NTF23>
This is an online meeting for Skype for Business, the professional meetings
and communications app formerly known as Lync.
Join by phone
+492115343925<tel:+492115343925,70849799%23> (Germany) English
(United States)
89925<tel:+89925,70849799%23> (Germany) English (United States)
Find a local number<https://dialin.ericsson.com?id=70849799>
Conference ID: 70849799
Forgot your dial-in PIN?<https://dialin.ericsson.com>
|Help<http://o15.officeredir.microsoft.com/r/rlidLync15?clid=1033&p1=5&p2=2009>
To join a Lync / Skype for Business meeting from an Ericsson standard
video room, add 77 before the Conference ID (e.g. 771234567 where 1234567 is
the conference ID). To join from a video room outside of Ericsson add one of
the domains after 77 and Conference ID (e.g. 771234567@ xxxx.ericsson.net,
where xxxx=emea/apac/amcs). For assistance contact the IT Service Desk.
[!OC([1033])!]
.........................................................................................................................................
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
