IETF108 NVO3 WG agenda
          ----------------------
          Network Virtualisation Overlays WG
          
          Tuesday - 13:00-13:50 UTC - Room 6
          
          . WG Status update
          (WG Chairs, 10 min)
          Agenda bashing...
          - nvo3-encap-05 draft
          Call for review and feedback
          
          - EVPN Applicability to Geneve draft
          Waiting for BESS draft which is protocol extension for evpn to support
          Geneve. It is in WG last call. We will send them together to AD Martin
          and he will progress both together.
          
          - Virtual Machine Mobility
          It is in the process of publication.
          
          - Yang Models
          Would ask if this is ready for WG LC. It is a high level model and it
          does not go into all the details of how to configure the options of the
          encapsulations. We probably need Yang Doctors review for that.
          
          - OAM draft
          On the agenda. They aave been around for some time. We do need an OAM
          solution. I would suggest that we have another go after the presentation
          today and see if we can adopt these drafts.
          
          
          . Geneve OAM
          (Greg Mirsky,  15 minutes)
          draft-mmbb-nvo3-geneve-oam
          
          Greg presenting...
          Active oam uses specifically constructed packets to detect, troubleshoot,
          localize defects and measure performance. RFC7799 gives classification
          of three types of oam, active oam, passive oam and in between (refered
          as hybrid oam). Passive oam is oam that does not affect data packet in
          anyway,usually that would be snmp, information from pub/sub. Hybrid oam
          refers to methods that are on path telemetry collection and use some
          information that embedded in data packets themselves.
          
          Propose two Active OAM encap, had more and moved them in appendix:
          •IP/UDP Encapsulation
           Destination port number would be used for demultiplexing UDP based
           active oam protocols. Most of them are UDP based with an exception of
           ICMP. The concern is additional IP/UDP overhead which creates a distance
           between Geneve header and packet payload.
          •Geneve Associated Channel
           Use EtherOAM or a new Ethertype for Geneve oam. EtherOAM might be
           misinterpreted as cfm Y.1731 oam type. So probably better to get a new
           ethertype for Geneve Associated Channel encapsulation. Demultiplexing
           will be using the message type. The message type can be directly mapped
           to already existing pseudowire VCCV oam.
          
          Suggested use VNI 1 as a management VNI for oam. Management VNI has no
          tenants associated with it so that oam packets are not leaked.
          
          Echo request/echo reply depends on the decision of encapsulation. Plan
          to investigate and it's more likely it will be a reference to existing
          mechanism.
          
          Sam: Regarding the control channel you are proposing, what are you trying
          to verify using that? You mentioned using management VNI
          Greg: That can be used in the same way as in IP/UDP encapsulation,
          between Geneve nodes, not between tenants. Any oam function proactive
          defect detection of their Geneve tunnel, performance measurement along
          Geneve tunnel. Because it shares the same encapsulation as Geneve data
          packets, so it shares fate with them.
          Sam: disagree with sharing fate conclusion. Customer VNI is different.
          Greg: fate sharing is critical for active oam. Hashing
          Sam: You are assuming that it shares the same fate. I totally disagree
          with that because you could have totally different load balancer setup
          which could take depending on which customer you are talking to, what
          kind of traffic it is taking. The question is: you are trying to correlate
          based on what are the channel with the customer VNI which is not true.
          Greg: Yes, that's interesting point. Fate sharing is critical requirement
          for active OAM. So if VNI information is used for load balancing, then
          effectively we are talking about service oam because then it has to be
          tenant to tenant.
          Sam: Not necessarily, because you are using oam bit or whatever to trap
          the packet. So not necessary that you always have to go to the tenant. My
          point is that you are making an assumption here that the traffic for
          management VNI will always take the same fate as customer traffic which
          is not true. You might have a use case to measure but I don't see what
          exactly you are trying to measure. In case of IP/UDP for example, it is
          you're emulating like customer traffic, you are going to apply the same
          policies with the options you have for the customer because in this case
          with the control channel of Geneve I don't know what kind of options you
          are going to use because you are constructing totally abstract packet
          kind of thing.
          Greg: We have problem of number of sessions. The suggestion to use
          management VNI is that for defect detection it gives us a continuity check
          so it gives us assurance that there is a way for the network to get from
          one Geneve node to another. In regard to the performance measurement,
          I agree there is a challenge. But wouldn't be that outer IP encapsulation
          used to create an entropy? Or it's a payload used to create an entropy?
          Sam: My point is that any policies you're going to apply based on that the
          customer traffic and the kind of encapsulation use. You are proposing a
          general packet and you're trying to validate the customer path so that's
          where I am not able to see one to one there. But we can take it offline.
          Santosh: I just wanted to answer Sam's question. For load balancing it
          is the outer IP and UDP that is going to get used, right?
          David: Sometimes the VNI will get used as well and maybe the path
          forward here is not restrict to be the management VNI depending on what
          you are trying to assess. If something weird going on with a customer's
          traffic you might want to use the same VNI to figure out where it went
          off the rails. Reasons to use Management VNI or VNI for ordinary traffic,
          depending on what the OAM is being used to check/investigate
          Santosh: Agreed. So only in those cases I agree, but that is something
          like you are really verifying a tenant to tenant. It's for a tenant you
          are verifying and that's when the VNI comes into picture. But if you are
          verifying a node, then probably you really don't need to get the Geneve
          header itself. The outer IP and outer UDP is the one which is actually
          getting used to load balance.
          David: I think some of the discussion we're in semi-violent agreement
          and we need to write careful text on which VNI to use for what purpose.
          
          
          . BFD for Geneve
          (Xiao Min, 10 minutes)
          draft-xiao-nvo3-bfd-geneve
          
          Min presenting...
           key points, see slides
          Matthew: I presume the intent is to point to the other draft for the
          encapsulations that you need. Make sure the two drafts (oam encap & BFD)
          are aligned and you are pointing to the oam encapsulation draft.
          Min: In this draft, I have made my own selection for encap. I selected
          the IP/UDP encapsulation. Because I think this kind of encapsulation is
          fate sharing with the real data packets.
          David: Agree with Matthew. We ought to use one encap for both drafts. At
          least for the non-management VNI case. Yes we ought to get them aligned.
          
          
          . LOOPS (Local Optimizations on Path Segments) updates
          (Yizhou Li, 10 min)
          draft-bormann-loops-geneve-binding
          draft-li-tsvwg-loops-problem-opportunities
          draft-welzl-loops-gen-info
          
          Yizhou presenting...
          LOOPS BoF will be on Friday. The key function is in-network recovery. It
          relates to NVO3 in a way that Geneve will be the first focus protocol
          embed this function in charter proposal. LOOPS runs between two Geneve
          NVE nodes.
          Transport feature will be discussed in BoF. Encapsulation is also
          important so we would like to invite Geneve encapsulation experts to
          join.
          
          
          Sam: Do you require specific codepoints from Geneve protocol to make
          this happen?
          Yizhou: Not yet, because we want to make sure the transport area
          comfortable with what we are proposing first. Afterwards when talking
          about the details of encapsulation, we would like to request for the
          codepoints. The codepoints are for the options.
          Sam: Does any of the intermediate hosts, not the end host, should be
          taking a look at any of these options and behave differently? Because
          one of the things we were deliberating for last few years is that the
          options do not play much within the network. In other words, it is pretty
          much into a negotiation and you won't be using much within the path. So
          I was just wondering like what exactly the implication because of that.
          Yizhou: We are expecting the LOOPS ingress and egress nodes are NVEs
          and not end hosts. They can be some NFV form of virtual nodes. We are
          seeing Geneve option are used in controlled environment for example in
          data center. In our specific use case, all the virtual nodes are NVEs
          which can be configured by a controller so that we can make sure all
          the virtual nodes/overlay nodes can support the same functionality of
          this option. That's the plan.
          
          
          Closing
          Matthew: Please review and comment the draft especially the OAM drafts. We
          would like to continue discussion on and move forward with some OAM
          solutions.