* 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-101 nvo3 minutes

Session 2018-03-21 1520-1650: Blenheim - Audio stream - nvo3 chatroom

Minutes

minutes-101-nvo3-00 minutes



          IETF101 NVO3 WG agenda
          
          Network Virtualization Overlays WG
          
          Wednesday Afternoon session I - 15:20-16:50 - Blenheim
          
          Matthew: Welcome to NVO3 down in the dungeons.
          Matthew: Note well applies.
          
          
          1. Administrativia.
          WG Chairs.         5 min
          
          Matthew: Blue sheets circulating. Note takers. This is a normal meeting,
          no roundtables. Please keep to your time slots. Alia is stepping as RTG
          AD. Thank you Alia for your guidance and support and encouragement. Martin
          is taking over as a new responsible AD, and good luck. Ignas has been a
          secretary for a while, he is stepping down. We will be looking for a new
          WG secretary. If you are interested in this role please come and see WG
          chairs after the meeting.
          
          Agenda bashing.
          
          Milestones.
          
          
          
          2.        WG status update.
          WG Chairs.         10 min
          
          Document status.
          Split NVE liaison to IEEE. Appreciate if you could take a look at the
          liaison and review it. See chairs for access credentials.
          LC plans for Geneve and DT encapsulation document. There is an ongoing
          poll for security requirements document.
          VMM protocol draft might be about the time to go into WG LC.
          Jorge: We have EVPN applicability draft that you have requested. We
          should issue WG adoption call soon.
          Matthew: Yes.
          Sam Aldrin: We will start the process.
          Jorge: Sounds good.
          
          Matthew: Incoming liaison from IEEE P802.1Qcy. Feedback by 15 May for
          this draft document.
          Pat Thaler: I will be retiring, but will send the message to the list
          with the names of the editors who will be managing this that people can
          send the feedback to the correct contacts. We appreciate feedback before
          we progress the document. Sponsor ballot is equivalent to LC in the IETF
          and it is getting close to be done.
          Pat: Last time it helped to get some people who committed to the review,
          if you could ask for people.
          Mat: If you would like to volunteer either raise your hand now or see
          the chairs at the end.
          Pat: This document is the control plane for the split NVE.
          
          
          3.        draft-mglt-nvo3-geneve-security-requirements-03
                  a) Ilango Ganga
                  b) Daniel Migault
                   Discussion on outstanding issues and comments
                   20 min
          
          Matthew: Ilango is going to do a remote presentation on his comments to
          the document, and Daniel is going to respond as an editor of the security
          document.
          
          Ilango presenting.
          
          Daniel presenting. Responses.
          Matthew: The old NVO3 security requirements document was written several
          years ago and since has expired. This one needs to go independently
          from the old security requirements document, the old one may never
          be published. What you need for Geneve should be in this requirements
          document.
          
          Matthew: We should avoid getting a misref from that document.
          Sam: Do you plan to address the comments from Ilango in the next
          version?
          Daniel: Yes.
          Sam: What is the timeframe?
          Daniel: Mid-April.
          Matthew: Maybe the way forward is to publish a new document. Not saying
          that the document has to be perfect, it just puts the document in to
          the hands of the WG to represent the consensus of the WG.
          Daniel: The next version is going to be -02 and not -00.
          
          
          
          4.        draft-ooamdt-rtgwg-ooam-header-03
          Greg Mirsky        10 min
          
          Greg presenting.
          
          Asking for WG adoption.
          Matthew: A bit of history on this. We did run a WG adoption poll for
          this document. At that time we had very few participants proposing and
          opposing the adoption, it was difficult to judge the consensus given
          the lack of participation on the list. It would be very good to sense
          whether people have read this document and express their opinion. There
          are other OAM drafts too, we cannot sit and wait.
          Frank Brockners: Would help the document if you added the applicability
          section that said how that particular header would be slotted in with
          Geneve, GRE, and the likes. What you have now work well for protocols
          that have a pointer of next header of 8 bits. That would not work for
          16 bit protocol pointers. Showing how that fits in a general way would
          give more appeal for people to care about it.
          Greg: Are you suggesting that different encapsulations have different
          length of the next protocol field?
          Frank: It depends where you want to go with this. If you have GRE, next
          type will be ethertype. I wonder where it does apply, how does that apply,
          and adding that to the document would be of great help.
          Greg: I will look into the document, but our original goal was to use
          ion new encapsulations like BIER, Geneve, SFC. Whether that is applicable
          to GRE we need to discuss.
          Frank. Having applicability and deployment section would be good.
          Greg: In BIER, Geneve, and NSH it looks not different.
          Sam: [].
          ?/Cisco: Curious to know - this seems to be an inband OAM type. How
          would this relate to IOAM work in IPPM?
          Greg: I would stress that inband behavior of OAM is the function of the
          encapsulation layer. If it draws only from the encapsulation layer and not
          from the payload then any type of OAM will be inband. In order to ensure
          that active OAM is inband with the data flow it puts certain restrictions
          on how the following decision should be drawn. One of the examples that
          we have is an example how this type of encapsulation can be used for
          IOAM. The format of the header is something that we can discuss.
          ?/Cisco: Can you explain how the next protocol is supposed to be used? Do
          you need to look at the first part of the header?
          Greg: Yes. If next protocol is 0 it means you have only OAM control
          packet. If you have nonzero it means that there is something following
          after the control packet.
          ?/Cisco: I will take this offline.
          Greg: Next protocol registry is something that we can discuss.
          Ilango: The OAM proposal that you have is applicable at different layers,
          it could be on the overlay layer, it could be on the service layer. Both
          could coexist, and the document does not have enough applicability
          information for this case.
          Greg: I would personally think that the same packet for the OAM for
          different layers.
          Ilango: Not necessarily. NSH can be transported on multiple different
          transports. If you go through multiple encapsulations before reaching
          the service node. OAM as part of the NSH header is independent from OAM
          in the overlay layer.
          Greg: It would be interesting and helpful to get some operational
          considerations where one packet is OAM for NSH and overlay transport
          at the same time. How to identify where the fault happened. It is much
          easier if it is done on the on the different layers.
          Ilango: Can you clarify that in the further version of the document?
          Greg: This can be applied on both layers but independently.
          Parviz: Back to Frank’s question on applicability - you are going to
          change behavior of SFC nodes? Is it going to impact the behavior of the
          SF node, or is it transparent?
          Greg: If we talk about active OAM, we have multilayer OAM individual
          document in SFC WG, the scope is SFF.
          Parviz: Forwarding behavior?
          Greg: Forwarding behavior is based on SFF, not SF.
          Parviz: The behavior of the forwarding node is captured?
          Greg: The expected behavior - the document introduces echo request and
          reply, and SFF can reply to the sender out of band as requested.
          Sam: Clarification question. Are you going to pursue this in other
          WGs? Are you going to pursue to get a common solution?
          Greg: If the WG in the current work in the header - there is a dependency
          between OOAM DT and this work in header. If both documents get adopted
          I will pursue a common solution, if not I will continue with SFC.
          Matthew: Show of hands who have read the draft? 10 hands.
          Matthew: Of those who have read the draft, how many think of common
          header? 1 hand.
          Matthew: Of those who have read who do not think it is a good
          idea? None.
          Matthew: Please read the draft.
          Alia: I would like to reiterate - I am very happy to see the discussion
          happening, this is something that WG was working for 3-4 years. We
          need this. VXLAN has been deployed for a very long time, and Geneve is
          coming. Let’s get this done.
          
          
          5.        draft-ao-nvo3-multi-encap-interconnect-00                Ting
          Ao         10 min
          
          Ting presenting.
          
          Discussion.
          
          Kyle Larose/Sandvine: Curious what motivated you to start to work on
          this? This seems to be similar to Network Slicing. There is a gateway
          function there. The other document that I am reading is much higher
          layer. Is this appropriate to COMS BoF tomorrow?
          Ting: This is for dataplane.
          Zachy Haramaty/Mellanox: The TNV can be combined, what is the reason for
          this? Logically it is a separate entity even if vendor would combine it?
          Ting: [].
          Zachy: I still think that TNV as a component does not need to connect,
          it is a separate logical component.
          Greg: Can you roll back to the reference model.
          Zachy: TNV in the middle can be connected to a TS.
          Greg: It is not a requirement.
          Zachy: That is a different logical entity.
          Greg: That is why we give a different name.
          Frank Brockners: Where do you want to take this work? Right now it is an
          articulation of the problem domain. I have this uber thing that provides
          for mapping device. Do you want to specify protocols, what is the next
          step?
          Ting: Do you mean the protocol between TNV and []?
          Frank: You articulated on the architecture. Today I have VXLAN getting
          in and Gneeve leaving, that is set up. What you articulating is that
          someone needs to set up the control protocols. Are you intending to
          standardize the control protocols?
          Greg: Yes. Frank is right. This is a problem statement at this time. We
          are looking whether this is a problem to be solved. What is the conclusion
          - adoption of this document will be an agreement that this is a problem
          that needs to be solved. Not necessarily this will be a document that
          provides a protocol or a standard way of a solution. There needs to
          be some normalization of negotiation of what protocol is capable of,
          what needs to be translated. Yes, there will be some negotiation of the
          control plane in order to work on the data plane layer.
          Matthew: That is a problem statement. We have one standard dataplane
          encapsulation. Interworking between how standard encapsulation and a
          set of those that are not standard ones.
          Greg: That is why we are not going to the solution but first say that
          if WG agrees that this is a problem that is worth to be working on.
          Mathew: We have architecture RFC, and this is an extension that can
          apply to it.
          
          
          6.        draft-xiang-nvo3-geneve-packet-spray-00                 Yolanda
          Yu        10 min
          
          Yolanda presenting.
          
          Kyle: That was pretty cool. Why did you put source UDP port? Was it the
          same for all the flows that you would get distribution within the mesh?
          Kyle: You used Geneve? When you build Geneve header and you out in UDP
          header, what value did you use for source port?
          Yolanda: It was random. We are considering to involve node aware
          parameter.
          Kyle: It would be nice to have some guidance on this draft - if all
          packets take one point and there is a congestion there it is different
          if you would use different source point input.
          Zachy: Name of the document - packet spraying is a unique case, the
          document talks about packet reordering.
          Greg: That is not necessary. Packet reordering may happen, it is not
          the goal.
          Zachy: The document defines the framework for packet handling.
          Greg: My understanding of the document - because of spraying reordering
          may happen and this is how we recommend to handle the situation. This
          is a proposal for mitigating this.
          Zachy: There is a chapter 5.3, I think this is a generic infrastructure.
          Yolanda: I got a comment via email that this should be a separate
          draft. There is no encapsulation for TCP over Geneve directly. We will
          post another draft about that.
          Matthew: question from Meetecho: [audio unusable].
          
          
          7.        Working Group next steps open mic
          Chairs                10 min
          
          Matthew: Next steps in WG.
          OAM is a topic that needs to be covered.
          EVPN applicability draft.
          That leaves centralized control plane/management plane.
          We need YANG model for Geneve, and a generic YANG model for configuring
          various elements in the NVO3 architecture. We may want to have a YANG
          DT team for NVO3.
          Matthew: Anyone interested in developing YANG model? None.
          Matthew: Have a think about it. This is more in the management plane. We
          have not focused on a true centralized management plane yet.
          Alia: What are you all interested in working on? Just Geneve? Do we need
          any other chunks? What are you looking for, what are the things that are
          missing? Obviously you here are watching and interested what do you see
          as gaps?
          Matthew: Any comments? Is there anything that needs to be done
          for management plane? There is work in LSVR on centralized control
          plane? Would you like to see any work in that area done in NVO3? Please
          raise your hand if you would like NVO3 to work on a more centralized
          dynamic management plane? No hands.
          Martin, incoming RTG AD: Seeing an overwhelming number of responses,
          I would ask a different question - should we close NVO3 when we have
          done Geneve? Please raise your hands.
          Greg: Let’s define what is done. Does it mean that Geneve specification
          achieves standard, or we have done OAM as well, and done YANG model? To
          me to say yes first I need to understand what done means.
          Sam: For YANG, no-one in the room raised hands.
          Greg: Give us some time to sleep on it. Jumping the gun may not be the
          best thing. Probably I would appreciate if we discussed really more
          seriously what done means, what scope of the work is a complete set of
          functionality that we can release to the world and say that we are done.
          ?: One document discussed potential new options for Geneve header. YANG
          model for the configuration would be a very useful thing. I am speaking
          in favor of doing something for the centralized model.
          Sam: We have a good presentation from Frank, I am not sure whether the
          authors would like to pursue that work.
          Daniel: When you say Geneve is completed, do you include security
          mechanisms too?
          Matthew: Yes. Do we need to do anything more in the control and management
          plane?
          Frank: There are many aspects to OAM, some of the work is done in IPPM. It
          would make sense to continue with big items to make a complete protocol
          solution. Maybe call it Geneve maintenance. I also advocate for YANG
          models. That would be useful.
          Jeff Tantsura: I would recommend to have a YANG DT. We had routing YANG
          DT, they delivered great models.
          Matthew: Drop us email if you would like to serve on YANG DT.
          Jeff: YANG expertise outside of NETMOD is sparse, potentially those who
          worked on routing.
          Martin: May I suggest that you relay those questions on the list to
          reach a broader audience?
          Matthew: Yes.
          
          
          Matthew: End of meeting.
          
          



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