* 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, Alia Atlas, Deborah Brungard | 2012-May-01 —  
Chairs
 
 


IETF-99 nvo3 minutes

Session 2017-07-19 1520-1650: Congress Hall III - Audio stream - nvo3 chatroom

Minutes

minutes-99-nvo3-00 minutes



          IETF99 NVO3 WG agenda
          
          Session 1 (90 mins)
          WEDNESDAY July 19, 2017
          1520-1650  Afternoon Session II. 90 mins.
          Congress hall III               RTG     nvo3            Network
          Virtualization Overlays WG
          
          
          1. Administrativia. 5 min.
              WG Chairs.
          Matthew: Meeting starting. Note Well applies. This is a first normal
          meeting we had in a while, previous meetings had experiments with the
          roundtables. This generated some drafts for security topic. Agenda
          bashing. Towards the end of the agenda we have an overview of EVPN work
          in BESS that is relevant to NVO3. Milestones. Document status. One new
          RFC, use cases. Nothing in RFC editor queue. Multicast framework went
          through LC and publication was requested. Adopted the DT document for
          dataplane encapsulation, and Geneve draft is adopted too. We ran adoption
          poll for two OAM drafts. There was no consensus on adopting. Progress
          needs to be made on those drafts and discussions on the list will be
          initiated. Geneve draft will be presented remotely.
          
          
          2. WG status update. 5 min.
              WG Chairs.
          
          3. Data Plane Design Team.
              draft-ietf-nvo3-encap-00
              10 min. Sami Boutros
          
          Sami presenting. An update for DT encapsulation draft. We
          removed backwards compatibility as a requirement. Bit flag
          extensibility was also removed. More clarifications to the document
          overall. Recommendation on guidance on how control plane could help in
          option processing. Clarified transit node option processing. Clarified
          TLV processing. Clarifications for both hardware and software
          implementation considerations. Clarifications on variable length
          requirements. OAM clarifications on alternative marking and the need
          for 1 or 2 bits. OAM usage models need to be discussed more. We need
          to talk more how OAM can be addressed in general and how that could be
          addressed by Geneve. Fragmentation handling. Critical bit usage in Geneve
          draft. Telemetry TLV option requiting 256 bytes, further discussion needs
          to happen on this topic. IPsec usage clarifications. Entropy discussions
          happening, NAT traversal too.
          
          Tal Mizrahi: I am a coauthor, and question is intended to the
          chairs. VXLAN-GPE at this time is still a standards track draft. Is there
          a future in GPE, and when the recommendations will come into effect?
          
          Matthew: When we chartered the DT for encapsulation, we stated that the
          other encapsulation drafts will have to wait after Geneve is done. If
          people want to progress other encapsulations as informational documents
          they can do. There needs to be changes done to the GPE draft as it states
          standards track at this time and that needs to be fixed. IANA allocations
          need to be fixed too.
          
          Greg Mirsky: The questions that were listed in the dataplane DT
          presentation, how are they addressed in the Geneve presentation?
          
          Sami: That will be presented in Geneve presentation.
          
          Greg: One of the questions is on the OAM bit. I do not expect the answer
          now but that needs to be discussed.
          
          Sami: All the comments that are put on Geneve are getting addressed.
          
          
          
          4. Draft Geneve Update.
              draft-ietf-nvo3-geneve-04
              10min. Ilango Ganga (remote)
          
          Ilango presenting remotely.
          [Meetecho did not work, Sami presenting locally.]
          Ilango presenting remotely finally:-)
          
          Ilango: We are coordinating with the dataplane DT. Updates are
          based on the recommendations of the DT. Control plane constrains
          for the options. Control plane can limit the number of TLV ordering
          and the amount of TLVs. This helps both SW and HW implementation on
          the endpoints. Control plane should have the capability to describe
          the properties of the endpoints. Recommendations for OAM – allow the
          recommendations as for PWE3 and L2VPN to avoid MTU and fragmentation
          issues. Even if there is fragmentation, it needs to be done before
          encapsulation to avoid transit fragmentation. OAM, two bits for alternate
          marking method. OAM proposals and use cases are for further discussion
          before we make any changes. Usage of existing OAM bit. The draft proposes
          an OAM channel. OAM discussions need to mature and we will make changes
          afterwards. Critical bit processing is helpful for critical option
          processing. If that is not clarified enough we will add additional
          text. Increasing option size to 256, mainly targeted for telemetry use
          cases. WG needs to comment on this topic. It will limit the options
          that can be carried in Geneve, if telemetry option takes all the space
          it will be difficult to carry other options. Next steps. Discussion on
          the list is fed back into the changes to the Geneve encapsulation draft.
          
          [No questions and discussions.]
          
          
          
          5. Geneve Protocol Security Requirements
              draft-mglt-nvo3-geneve-security-requirements-00
              10 mins. Daniel Migault
          
          Daniel presenting.
          A set of 4 drafts, requirements, proposed solution approaches, and then
          architectural overview of how it combines together. Tenants can encrypt
          their own communication themselves, this is not in the scope of Geneve
          but the scope of the tenants. Any nodes on the path need to be able to
          read Geneve packets. Geneve NVE needs to agree that the authentication
          includes some options and include some part of the payload. If you
          want to authenticate a single Geneve option then the payload is not
          involved. Geneve intermediate forwarding element may validate the
          packet before it reaches its destination. Forwarding nodes that are
          not supporting the authentication option still can work and forward the
          packets. Redirection and leakage – that is more of a deployment aspect
          and less of the protocol one. How could you mitigate the leakage by
          making it meaningless even if it still happens. IPsec use even can reveal
          much of the information like addresses. TLVs also leak information like
          ports. Geneve NVE must be able to encrypt options that are not intended
          to be modified. How we can make the overlay robust itself? A replay
          attack on OAM traffic. If you increase the volume of OAM traffic you
          can disrupt the network. This requires anti-replay mechanisms.
          
          Tal: Thanks for putting together this draft. One thing that is missing
          for me to understand is the threat analysis to understand the set of
          attack vectors and have a mapping of the vectors and requirements.
          
          Daniel: Are you suggesting that for the draft?
          
          Tal: Yes.
          
          Daniel: We can discuss this.
          
          Suresh: I would like to see some requirements why encrypting UDP is not
          enough.
          
          Dniel: We have included that.
          
          Suresh: The document structure is a bit difficult to handle. Maybe one
          document could cover the architecture and the options.
          
          Daniel: That would be good – merging into one draft.
          
          
          
          
          6. Geneve Header Authentication Option (GAO)
              draft-mglt-nvo3-geneve-authentication-option-00
              10 mins. Daniel Migault
             Geneve Header Encryption Option (GEO)
              draft-mglt-nvo3-geneve-encryption-option-00
              10 mins: Daniel Migault
          
          
          Daniel presenting.
          Why the current DTLS and the IPsec solution does not fulfill the
          requirements, and why do we need a Geneve specific solution. We use IPsec
          AH adapted for Geneve. It allows to insert option on-path. It is a Geneve
          option, the ID used in IPsec is SPI and is 32 bits, here a shorter value
          is sufficient. We have Geneve fixed header, then options that are not
          covered, then GAO, and after it the authenticated options. When you see
          the packet you know already which options will be authenticated and which
          will not be. Processing is similar to IPsec. Encryption option is similar
          to IPsec ESP. A difference is that it does not include the whole packet
          but instead the indicated length after the marker is encrypted. We usually
          use authentication encryption, Geneve fixed header is authenticated too.
          
          
          
          
          7. Geneve Security Architecture
              draft-mglt-nvo3-geneve-security-architecture-00
              10 mins. Daniel Migault
          
          Daniel presenting.
          Security architecture focuses how to associate the security options
          to flows. How do we define whether the packet needs to be protected or
          not. Traffic selector is used for that. In a controlled environment the
          required security policies and associations will be provided, but it is
          also possible to use IKEv2 for more dynamic associations. If you receive
          the packet and cannot validate the signature that is fine, but you need
          to validate it against the security policy. TLS does not make it simpler,
          it is a different model how TLS is being used. Any questions?
          
          Behcet: It is Geneve, and not Geneve, how do you pronounce it?
          
          Matthew: Any Geneve authors in the room? :-)
          
          
          
          
          8. IPsec over Geneve
              draft-boutros-nvo3-ipsec-over-geneve-00
              10 mins. Sami Boutros
          
          Sami presenting.
          A description of how ESP could be carried in Geneve tunnel. A description
          of encapsulation used for carrying AH over Geneve tunnel. Please comment
          on the list.
          
          Behcet: Can this be used with VXLAN?
          
          Sami: VXLAN does not carry protocol identifier field.
          
          Behcet: Can you encapsulate via ESP?
          
          Sami: Geneve has a field to indicate the protocol number. VXLAN has only
          the VNI.
          
          Tal: I hope there are IPsec experts who could correct me if I am wrong
          but I recall at some point I recall that EH was deprecated.
          
          Daniel: This debate comes up every few years. There is a draft on how
          to protect AH.
          
          
          
          
          9. EVPN Overview for NVO3
              No draft.
              10 mins. Jorge Rabadan
          
          Jorge presenting. Chairs have asked to present what we are doing in BESS
          on DC overlay networks. Brief EVPN overview, and then the work in the
          BESS on overlays. EVPN – the original idea was to have L2VPN operated
          in the similar was as we do with routed L3VPNs, replacing the flood and
          learn behavior with BGP. That gives a lot of control, and allows to have
          quick MAC mobility. Efficient ability to deliver BUM traffic. Ability
          to support efficient multihoming. EVPN has evolved since the RFC7432,
          it is a unified control plane technology that allows to have not only
          L2 connectivity technologies. EVPN support NVO3 tunnels, with the most
          popular option being VXLAN. An open discussion  what do we need to do for
          NVO3 to be able to use EVPN as a control plane. We would need to extend
          EVPN with extensions for support of new encapsulations and extensions.
          
          Mattew: Any comments?
          
          Parviz: Did you cover WAN connectivity?
          
          Jorge: Yes, in BESS WGLC now.
          
          Matthew: We asked to have an overview of what is going in BESS on
          EVPN. It is a question whether we need an applicability document in
          NVO3 how EVPN fits into the NVO3 architecture. Second – we need a way
          to input our requirements into BESS.
          
          Sam Aldrin: Applicability document will be generated here and solution
          documents will be worked in BESS.
          
          
          
          
          
          10. Update on IEEE 802.1Qcn (VDP extnsion to support NVO3)
               draft-ietf-nvo3-hpvr2nve-cp-req-06
               5 mins. Yizhou Li
          
          Yizhou presenting.
          Update on the 0.5 draft. Last week there was 802.1 plenary meeting and
          there was nothing controversial, draft will be updated to 0.6. 802.1Qcn
          has a name conflict with queue congestion notification project work,
          our one will move to some other project number.
          
          
          
          
          10. VXLAN GPE Extension for Packets Exchange Between Control and User
          Plane of vBNG
               draft-huang-nvo3-gpe-extension-for-vbng-00
               5 mins. Lu Huang
          
          Lu presenting.
          Presenting on the problem space, requirements, and the proposed
          solution.
          
          Michael/Huawei: Why do we need this optional solution as we have
          discussed with operators and the split of slot/subslot/card id may not
          be enough. The requirement is to have a more flexible split of port
          identifier components.
          
          Lu: Requesting for WG adoption. Questions?
          
          Matthew: Thank you.
          
          
          
          
          Matthew: Any further comments on the topics discussed?
          
          End of meeting.
          
          



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