Minutes IETF110: nvo3
minutes-110-nvo3-00

IETF110 NVO3 WG agenda
----------------------
Network Virtualisation Overlays WG

Monday, March 8 (15:30-16:30 CET）

1. WG Status update
(WG Chairs, 10 min)

Agenda bashing.
OAM drafts in progress and YANG model in progress.
Some discussion on what to complete that is valuable to the community before
the wg is done. Sam as individual: two drafts now, bfd and oam solution. Do we
have plan to go forward with the oam solution draft? Greg: oam draft was
adopted last year. Hope to have LC issued and comments will come and we'll
address then comments by next meeting. Matthew: we have mechanisms to have
wider review, such routing area review. Greg: great idea, ask rtg directorate
early review. We are committed to work.

Doc status.
One new RFC published.
Data plane encap (nvo3-encap-05) is a valuable draft documenting the experience
of one wg in picking an encap when three were multiple candidates on the table,
and we promised to publish it. It had no sufficient review during last call. We
need some consensus to move it forward. So one possible way is to have another
round of LC and we'd like to see much better buy-in from the working group on
progressing with this. Authors are not so active right now, we need an active
editor to help to move it forward.

Also for draft nvo3-vxlan-gpe, we probably need a LC as well. We're going to
have to look for fairly significant interest from WG and some comments and
proper level of review in order to progress this.

EVPN applicablity to geneve draft is now with Martin and it is held in his
queue waiting for a companion draft in the bess wg that shows the bgp
extensions requried for Geneve. We are waiting for the progress of that.

VMM draft was sent back to wg after review by Martin. The comment was it's not
specific to nvo3. Martin (AD): For this doc, I communicated back to wg my
expections. I know Donald worked a bit to help rework the document, but there
are a number of questions that WG needs to bring an answer to. It would be
great to drive the discussions to see whre it leads.

Yang cfg doc
Sam (shepherd):I received the request from the authors yesterday. I have two
action items for that. The first one is that I have to get review comments from
yang doctors and I'll try to prepare for issuing the LC.

2. Geneve BFD
(Xiao Min, 15 minutes)
draft-ietf-nvo3-bfd-geneve
Xiao Min presenting.

Matthew: It would be worth getting rtg area review and possibly bfd group
review. Sam: what is the decision for dest IP, local host type address? Xiao
min: for ipv4, choose from a range 127.0.0.0/8, for ipv6,::1/128 Sam: so
destination host which is processing the bfd frames needs to open a UDP socket
for 127.0.0.0/8 address? Xiao min: Yes Sam: Interesting. Is it done similarly
for vxlan as well or is it purely for Geneve? Xiao Min: RFC8971 bfd for vxlan
solution is for management VNI. Our draft provides for non-managemnet VNI
solution. so they are different. Greg: When we discussed bfd for vxlan, it was
pointed out that IPv4 loopback addresses mapped in IPv6, they don't have a
special meaning. So the only lookback ip address that exists in ipv6 is
::1/128. So functionally for ipv6 if we use a loopback address range for ipv4
addresses, then in ipv6 we can only use a single address ::1/128. That's what
recommended in geneve oam document that ip encapsulated control packets use
addresses from ipv4 loopback range or ::1/128 for ipv6. In that regard bfd
document and geneve oam document are consistent. Sam: I see. So purely for v4
in this case, if you don't have ip on the source and also ip on the
destination, so you are planning to use 127 address, is that right? Greg: I
would imagine the tenant has no IP but the NVE will have IP. Wouldn't that be
the case? Sam: I am just echoing the issues at hand in the slides where you
mentioned no IP. So I was a little bit curious so NVEs do no have IPs. Greg:
Because it wants to test as much as possible their infrastructure. If no IP, I
will imagine ethernet encap will be in place. Sam: ok. I will take a look at
it. Xiao Min: This draft only describes non-management VNI solution. We provide
two encaps, one is BFD IP over Geneve, the other is bfd over Ethernet over
Geneve. For the second one, there is scenario that VAP of originating or
terminating NVE has no IP address.  There are open questions in the slides just
mentioned regarding this specific scenario.

Matthew: please review the drafts.

Session closed.