* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Nvo3 Status Pages

Network Virtualization Overlays (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2012-May-01 —  
Chairs
 
 


IETF-104 nvo3 minutes

Session 2019-03-28 1050-1220: Berlin/Brussels - Audio stream - nvo3 chatroom

Minutes

minutes-104-nvo3-01 minutes



          Network Virtualisation Overlays WG
          
          Thursday Morning session II - 10:50-12:20 ¨C Berlin/Brussels
          
          1. WG Status update
          Agenda bashing...milestones, document status
          
          2. Security requirements update
          draft-mglt-nvo3-geneve-security-requirements-06
          Daniel Migault presenting...
          
          One of the key issue is Geneve & DTLS.
          Geneve co-authors seem think DTLS is sufficient and security capabilities
          for transit devices are not necessary.
          Daniel:
           - transit devices make Geneve security mechanism implemented through
           Geneve options
           - Geneve options are interpreted by transit device or NVE
           - So transit devices prevent e2e security with geneve.
           - Explainging why DTLS is not sufficient for all cases.
          Question: Do we need transit device? (use case for transit device¡­)
          
          Matthew: Oam requires transit devices to inspect. Have drafts talking
          about trace route. I do not know if you call it a transit devices. In
          the framework we don't have transit devices formally defined¡­
          
          David: A need for transit device to insert/remove/modify options or just
          visible to transit devices but not be modifiable in route?
          
          Daniel: Only read in current spec
          
          David: If current spec is only read, then with a little bit more design
          work, unfortunately DTLS is not exactly what you want, you can arrange
          to secure the readable options for integrity e2e without encrypting them
          and then encrypt everything else, and at that point you are back to e2e
          security model, just some of the stuff that you have integrity protected
          end-to-end is in the clear.
          
          Daniel: I think that¡¯s something can be done if we need these transit
          devices. Maybe we can also agree to have whatever is being read by the
          transit device, protect it or not, but that's need to be clearly stated
          and discussed.
          
          Ilango: You are not characterizing the transit devices accurately and
          that's the main contention between what your written in the document
          versus what the architecture is supposed in Geneve. Transit devices
          exist in the network. It could be the switches or routers, whatever
          that forwards the traffic between the two endpoints. We have a formal
          guidelines so that you're exposing or when the transit devices are
          viewing the Geneve headers information, they can use that information,
          I gave you a very specific example, could be ECMP purposes that could be
          an option that has flow context. If Geneve is secure between the NVEs then
          it doesn't have the visibility and if it doesn't have the visibility it
          can continue to forward it based upon the outer header information. And
          that's how the transit devices today operate in Geneve and even with
          other encapsulations. Geneve does not require the transit devices to
          look at or observe the options in order to forward the traffic. That's
          number one, this is if you are using encryption.
          If you're not using encryption, as David black said if you're using
          data integrity mechanism, then you don't have to do that. So different
          deployments may choose to expose this information to the transit devices
          or not depending upon what's applicable to that deployment. It doesn't
          mean that Geneve is not secure or not secure e2e. So I would suggest
          that the author does not miss characterize that Geneve was insecure just
          because you want to take we are exposing that to the transit devices. Even
          if you remove the transit devices, nothing precludes the transit devices
          from viewing the data.
          
          David Black: I don't think I heard a suggestion that was insecure. What I
          think I heard was a suggestion that if you want transit devices you need
          to do something Geneve specific. What I heard from Ilango was mostly in
          terms of exposure not modification which is going to make the problem much
          simpler. I also think back to the router, tutorial discussion yesterday
          afternoon, and I would suggest that inserting or removing options in route
          is going to be painful for high speed hardware. That's clearly avoided,
          modification would be bad enough. If it sounds like we don't even need
          to do that which means that you've probably got an end-to-end security
          model. You just have to figure out how to spec the crypto to get integrity
          on the stuff that needs to be exposed to the transit devices. Ilango,
          I must have said something.
          
          Ilango: You said it correctly David. Transit devices can view the
          Data, it cannot modify or it cannot insert the options. The options can
          be inserted or in general Geneve header is inserted and removed by the
          endpoints, not by the transit devices.
          
          Tom Herbert: That last effectively means that transit devices cannot
          modify UDP payload. It's problematic because they don't know if this is
          actually Geneve, this could be used for anything. So this should be a
          must not modify in flight as far as I'm concerned.
          
          Ilango: We have spec in the document saying they must not modify. Herbert
          said is accurate that the specification clearly says that the transit
          devices must not modify Geneve headers.
          
          Greg: I think that I understood comment differently, it was not saying
          that says, it should say. In connection to yesterday BoF is there
          was a suggestion to start data plane consideration especially for new
          encapsulations and variable length encapsulations, I think that will be
          good to take it before it becomes mandatory and add a section that will
          highlight impact of Geneve on a fast path processing.
          
          Daniel: Try to summarize some of the comments. The current spec is saying
          clearly that transit device can only read, but the current spec does
          not make any recommendation on how to protect the Geneve packets. So
          if you use the transit device, following the current recommendation for
          security mechanisms, you cannot deploy transit device in a secure way.
          
          Matthew: Wrap up?
          
          Daniel: More characterization is needed on the transit device so that
          to clarify this, because they appear clearly like middleboxes so which
          need explicit signaling. This has been debated and I think it would be
          useful to be done here. Transit device are somehow hardly compatible
          with UDP encapsulation because how a transit device will detect it's a
          Geneve packet¡­
          (Continue with conclusion slide¡­)
          Feel free to be active on the milling I'm happy to any feedback.
          
          3. Geneve update
          draft-ietf-nvo3-geneve-12
          Ilango Ganga presenting remotely...
          
          David Black: TSV reviewer. Thank authors for doing a very productive and
          cooperative job of addressing difficult comments on the draft. There are
          a couple of issues I would characterize as half open. I want to quickly
          bring attention I expect more attention during IETF last call. The first
          one is that omitting UDP checksums in ipv6 is an interesting area. To
          zero the UDP checksum you want to increase the hamming distance between
          valid packets as much as you can. One of the recommend techniques for
          doing so is to vary the ipv6 source address. Not clear that this is what
          running code is prepared to do. And the other one is that it's a very good
          idea for an encapsulating NVE to maintain an MTU value for the tunnel,
          particularly when that encapsulation NVE is not at the origination
          point. The upshot is that if you send a packet into that NVE from the
          network and it's too large you get the ICMP response from encapsulating
          node rather than getting it downstream somewhere and risking lose using
          ICMP payload. Both these I think are very good.
          
          Ilango: Thank you, the working group members can review that those two
          points.
          
          Matthew: The chairs will probably discuss how to proceed with this because
          we still have these ongoing security comments coming from Daniel. He is
          the only person who still has concerns on the list. They may be valid
          and we have to be aware of those. May be brought up again in the security
          Directorate review and review by the security ADs if we progress .We'll
          get together with the authors and decide how to proceed. As far as we
          can see from perspective of calling consensus from the list discussion,
          we're probably pretty much there. But there's still some discussion on
          security that we have to be aware of. So I can address that as a part
          of the Shepherd¡¯s review.
          
          T. Sridhar: I just wanted to highlight the help from multiple folks on
          making this a better draft and also we believe draft version 13 will
          address the comments for the security considerations as well and clarify
          the text with respect to the role of transit devices.
          
          4. 5G-Datacenter Interconnection Use Case
          draft-defoy-nvo3-5g-datacenter-interconnection-00
          Xavier De Foy presenting...
          
          Remy: I think it is a very interesting usage scenario because I think in
          this room most of people are talking about DCN and you are talking about
          interconnection of DCs. So in your opinion is there any usage scenarios
          which permit us to define for example sub TLVs for Geneve?
          
          Xavier: At this point I don't really know of any impact on in
          NVO3. That¡¯s very high level.
          
          Remy: It may be a good thing because people are not very clear about
          the definition of TLVs, how to use and what can they do with TLVs. If we
          find some interesting scenarios, we can define some TLVs for Geneve. I
          think it will be helpful to extend the usage scope of Geneve.
          
          Xavier: Thank you and that's one of the goals of coming here is to find
          people interested in the community who would like to bring some expertise
          in data centers, and see if they are interested or not...
          
          Greg: In 5G we learn that they're considering three use cases. It's ultra
          reliable low latency, extended mobile broadband and extensive machine
          to machine communication. Do you see that for all these three scenarios,
          one solution will be suitable?
          
          Xavier: Actually I hope that not. A lot of work being done in 5g to
          support edge computing as you know probably and that was a new study
          starting to enhance the support for edge computing. So I think that right
          now 5G does not really mandate any specific thing outside of 5G in terms
          of data centers. It provides some mechanism to enable interconnection
          with external data networks. So personally I don't think there is one
          solution that will be mandatory.
          
          Greg: A little bit different angle. So where would you suggest to look
          for requirements for these use cases or scenarios? I think that ultra
          reliable low latency especially, since you mentioned multi-access edge
          computing to minimize round-trip delay, might have some distinct set of
          requirements comparing to enhance mobile broadband. Would you suggest
          any source of requirements?
          
          Xavier: You may have an answer from somebody behind you.
          
          Ulises: I think that one of the reasons why we think it is interesting
          here and have the feedback from the community is that we're also looking
          at the 5GLAN feature that is going to be developed in 3GPP. Based on
          the requirements I've seen there, the case of the reliable communication
          in particular the use of 5GLAN like systems for industrial IOT, I think
          that  will be the use case that from my perspective will be the modules
          for this type of 5GLAN cases. That would be my input to your question.
          
          Yizhou: I want to bring your attention to what we have already done in
          NVO3 working group called the split NVE or external NVE. Your NVE which
          is an external device from the end device is a bit different from our
          current case because we are more focusing on the wired part so there is
          a VLAN mapping between the so called VNI and VLAN ID. I'm probably want
          to consider for the 5GLAN case what kind of mapping information from
          the PTU session since you don't have VNI information there. That's one
          possibility that's how NVO3 can help in your scenario.
          
          Xavier: Thank you, maybe we can talk shortly after session.
          
          Matthew: Who has read the draft? (not many) Those have read the draft,
          who thinks this is in scope of NVO3 first of all? As our Charter is
          very much focused around kind of traditional fixed data centers in one
          geographical site, not DC interconnection, but inside of a physical data
          center. And a distributed data center architecture like this is perhaps
          a little bit new.
          
          Xavier: Will you advise on whether we should continue this work right
          now?
          
          Matthew: I'd suggest that you need to get some more feedback on the list
          and you get some more people to read the draft. I think there is kind
          of scoping issue and charter issue, will talk that to AD.
          
          5. Base YANG Data Model for NVO3 Protocols
          draft-zhang-nvo3-yang-cfg-05
          Remy presenting...
          
          Matthew: General comment from me I think it needs to be very clear on the
          scope. Because we've got another young model draft coming up next. To
          be very clear on the scope of the individual YANG models that one is
          generic to the overall architecture and the other one is specific to
          configure the parameters of a particular encapsulations right?
          
          Remy: Yes
          
          6. YANG Data Model for NVO3 Protocol
          draft-chen-nvo3-yang-00
          Ran presenting...
          
          Remy: I have a couple of comments. First of all just to make sure that
          this YANG just cover Geneve and VXLAN-GPE right?
          Ran: Yes
          
          Remy: So the second question is what is the mapping relationship between
          this YANG model and NVO3 architecture? Because here I can't see the
          terminology that I've been familiar with. For example I can not see the
          NVE here.
          Ran: We will update later.
          
          Remy: NVO3 instance and NVE, what's mapping relationship? Not obvious
          Ran: will update
          
          Remy: have NVE first, then... do not get the point from your model
          Ran: I am defining in a different way from your draft
          
          Some arguments between Ran & Remy on the mapping and sequences of some
          particular parameters.
          
          Ignas (OPS AD): I do care about manageability. Have a slightly broader
          discussion because what I see happening here is talk about tiny fragments
          but I'm not certain whether the working group has the broader view or
          the manageability.
          
          Matthew: We did have an operational requirements draft a long long time
          ago. We don't have any really active doc. We don't have really any draft
          apart framework at the moment on overall what you need to manage in an
          nvo3 network.
          
          Ignas: So the problematic aspect that I would see is, first an NVO
          interface is an interface, it's not a special type of interface. Therefore
          from a manageability point, it should be put into the hierarchy as any
          other interface and have its own parameters. The transport protocols below
          2e2 client protocols should be aligned with the overall manageability
          of other transport e2e client protocols. NVO3 is no special if I want to
          try to use that for practical purposes in a practical network. If it is
          radically different than IP or MPLS encapsulated interface, something is
          just not right. Another aspect and that's probably broader, what probably
          needs to be done is to revisit the use cases draft, and try to talk to
          the user community, what problems they are trying to solve and how they
          are trying to do that, and this will come as a set of requirements how
          that should be managed. The fact that you have a YANG model, it's good,
          but that is nowhere near enough. It's just a tool but it needs to fit
          into the overall management hierarchy somehow.
          
          7. BFD for Geneve
          draft-xiao-bfd-geneve-00
          Xiao Min presenting
          
          Matthew: The question is do we need to separate modes for encapsulation
          of BFD in here? Can we just rely on the fact that IP UDP packet or
          do we need effectively a unique protocol type for BFD in the Geneve
          header? This kind of precedent for this in MPLS and past, for example
          you can either run BFD on IP UDP or you can explicitly identify in the
          G-ACh that you're carrying BFD. But that was really for MPLS TP where you
          did not rely on IP forwarding. I think in the case of Geneve it's an IP
          underlay. So do we actually have a need for this to uniquely distinguish
          BFD? Any feedback on this? Has anybody read this draft yet?
          
          Greg: Co-author. It's a question for the working group and in my opinion
          it's a broader scope question of oam in NVO3 and Geneve. Because how
          do we encapsulate BFD in this case is a question for this draft and
          in general how to demultiplex active OAM protocols in NVO protocols,
          in Geneve in particular. So I think that since Geneve specification
          is stable and ready to be passed to IESG, I think that we're at a time
          where we can start looking at question.
          
          Matthew: yeah, feedback?
          
          Sami: I do have some basic question first and maybe we can provide
          feedback about whether we should include an IP header. When you are
          running BFD here, are you testing the connectivity of the tunnel or VNI
          service?
          
          Ming: Tunnel.
          
          Sami: So what would be the VNI value?
          
          Greg: As being mentioned in the document presentation, there is a lot of
          similarity with the BFD for VXLAN. You probably know that BFD for VXLAN
          is waiting for AD review, so it passed BFD working group last call and
          will follow similar interpretation of VNI in this specification and it
          is the VXLAN. But obviously if you have some suggestions, welcome.
          
          Sami: Sure. I think the other comment is that when we did BFD for mpls-tp
          and didn't include an IP header, it was mainly because we didn't have
          an IP network on which we could be running BFD on. But I think the case
          here is different. We already have an IP network.
          
          Greg: The reason to question whether to include IP header because
          it's extra header and the only purpose of this header is UDP port to
          demultiplex the payload. Think of our ipv6 addressing what unnecessary
          overhead we're inflicting just to carry our UDP port, so that's why
          we're suggesting to consider use of ACH. BFD is supposed to be right
          weight. If we add ipv6 IP UDP headers on top, like 40 bytes of BFD, so
          the header is larger than BFD, right? The overhead is like hundred and
          twenty percent. So I think that it's a good enough reason to at least
          to consider it.
          
          Sami: I think the same comment applies that the associated channel was
          added because you are running on a non-IP network. I understand overhead
          well¡­.
          
          Greg: Associated channel was not only added because MPLS-TP. Associated
          channel is just generalization of pseudowire VCCV. So it's basically
          taking the clue from technology already existed. Because basically the
          same mode is run over pseudowires. There was no IP encapsulation needed
          for the pseudowire BFD.
          
          Sami: layer 2 only and not layer 3.  Meaning an associated channel was
          added for pseudowires VCCV because pseudowire would carry layer 2 traffic
          that could carry IP or non IP. But here the cases are we already have
          an IP network. If you are worried about overhead, anyway Geneve header
          is an overhead.
          
          Ming: Sami, when you say IP network you mean underlay network?
          
          Sami: Correct. I think when VCCV was added or associated channel was
          added, for pseudowire we are carrying only layer 2. L2 does not need to
          carry only layer 3 and it can carry other protocols, others an IP. This
          is why you need to have BFD running with associated channel because
          the network may not have IP and so on, right? But in here you have an
          underlay which is IP¡­
          
          Ming: for the overlay, maybe no IP¡­
          
          Sami: What you're saying is that I'm carrying a layer 2 overlay and now
          is that layer 2 overlay may not be an IP overlay, then I should have an
          protocol for BFD similar to the associated channel so I can run BFD on
          it as a control message only. I think okay, I can buy that argument.
          
          Tom Herbert: I'm looking at the Geneve header, there's a control bit or
          O bit that says control packet. In this scenario what would that be set
          to? Is this a control packet?
          
          Greg: It's great question thank you. We don't know.
          
          Tom: So let's assume that we do set the control bit. Then my question
          becomes, the protocol type field, what does that mean when the control
          bit is set?
          
          Greg: Another great question thank you.
          
          Tom: Third part is, this is answered in GUE. If the control bit is set
          in GUE, that protocol type field is now a control type field, it's a
          completely different numbering space. So what I'm concerned about here
          is do you really want to add an ethertype for control messages? It seems
          like a slippery slope so you might want to consider something like.
          
          Greg: Point to what has been done in SFC NSH. It does have O bit which in
          RFC8300 was defined as identifying oam packet. There is draft IETF-SFC
          multi-layer-oam which we name as SFC active oam draft. We have defined
          with the working group together how O bit with their protocol field
          identify combinations of OAM whether in header extensions. Because they
          can have an NSH fixed length extension or variable length extension
          header and oam in the payload. So it defines the situation that oam
          information data or commands are in a header part or in the payload part
          or there is no oam at all. Actually there was a discussion in Bangkok
          and Adrian provided case that led us to a point to situation that has
          to be interpreted as erroneous situation that O Bit is not set but next
          protocol field is oam so that has to be interpreted as erroneous. I
          will encourage you to look at this. I know what GUE is doing. I'm
          not completely agree with that because there was not all OAM goes to
          the control plane, in particular BFD things are done usually in the
          hardware. So thus changing two name spaces might be unnecessary burden
          on the hardware support implementation. But I'm open to discuss it.
          
          Tom: You made an important point there are two flavors of this. One
          is the payload is the control packet and two we want to attach control
          information. So it's not about OAM, it's about how do you deal with these
          two flavors. I have arbitrary control information to attach or I have
          specific... in this case it looks like the payload is the control data,
          which means...
          
          Greg: no¡­this payload is what's supposed to be processed in the
          hardware¡­
          
          Tom: so is the payload contain an IP packet
          
          Greg: that's another thing that we just discussed..
          
          Tom: What I mean is it being attached to a user IP packet?
          
          Greg: No
          
          Tom: Then I consider that a control packet. I'm not concerned about
          hardware versus not Hardware. On the wire what does this packet look
          like? If I say this is protocol type 800 and that those bits are some
          kind of control information, that's not ipv6. So the protocol type and the
          control bit and the payload have to work together, so that's unambiguous
          what the Geneve payload contains, and since we know the transit devices
          are going to try to parse this, it has to be on ambiguous for them not
          just the endpoints.
          
          Sami: One last comment is if you are talking about ACH here and so on,
          did you consider putting an MPLS label like GAL label and saying this
          is an MPLS packet? Why not? They are using the same approach. Is the
          way we did it in MPLS-TP is that you put a GAL label¡­
          
          David: We need to talk about why we're doing BFD in the first place. What
          is the thing on the far side whose liveness and ability to talk to us
          we'd like to establish. And I believe what we're going after here is the
          chunk of the NVE that knows how to decap Geneve. So the hardware is being
          referred to is the hardware that chews on the Geneve header. ¡­¡­because
          what essentially it says is the hardware chews on the Geneve header
          something in there says this is BFD and the BFD payload comes next,
          and now you have BFD solving the problem you want to solve, is the NVE
          capable chewing on Geneve or did something break before it opened up
          that header?
          
          Sami: I didn't get it. So you want BFD or you donot want BFD?
          
          David: I want the BFD header to be as close to the thing whose liveness
          I'm testing. The more headers you add in the middle, the more ways there
          are to break BFD without breaking the forwarding engine. The further
          away I move BFD from the chunk of hardware's liveness I care about,
          the more opportunities are for BFD and the hardware to not to tell me
          the same thing.
          
          Sami: GAL is only four bytes
          
          David: find some way to code in the Geneve header this is BFD then the
          hardware process of Geneve header grabs that BFD and says yes I'm here
          
          Greg: That's possible just to use a next protocol, allocate BFD next
          protocol and be done with it.
          
          Sami: It's already defined ACH having being used for non IP header and
          you want to use an ACH approach, so I didn't understand the argument
          why not use the ACH approach as its defined already.
          
          Greg: I think that what we can agree on that this is a separate topic
          for discussion because it's broader than just BFD.
          
          Matthew: yeah, to conclude, we need to describe comprehensively how the
          O bit is used and how that should be interpreted in Geneve. In other
          technologies like pseudowire, you define an exception mechanism whether
          that 0001b on a header or ¡­ my interpretation of the O bit here is it's
          an exceptional mechanism that says this is a control channel message,
          and no more than that. But what the structure of that control channel
          is, whether it's something with an ACH, whether it's an IP channel,
          is undefined at the moment.
          
          



Generated from PyHt script /wg/nvo3/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -