On 8/8/2016 10:43 PM, Patrick Frejborg wrote: > Hi, > > perhaps we need to take a step back, look on the overall architecture > and see how challenges like this has been solved in the past. www.isi.edu/x-bone
> Think > that an NVO3 architecture have many similarities with a communication > systems, so what the Audio-Video Transport WG came up with was roughly > this: FWIW, X-Bone was developed two decades ago as a kind of "teleconferencing for routers". > > SIP > - register endpoints to the system > - finding out capabilities of the endpoints > - setting up sessions between the endpoints We had one protocol that corresponds to SIP (x-bone-ctl). Note that we had a separate API protocol (x-bone-api). > RTP > - streaming between endpoints > - optimized for hardware offload > - several RFCs exists > - UDP the preferred transport protocol > - extensions should not be implemented, from RFC 3550, section 5.3.1 > " Note that this header extension is intended only for limited use. > Most potential uses of this mechanism would be better done another > way, using the methods described in the previous section." > - SRTP, encrypted version We used two-layer IP-in-IP encapsulation to virtualize the link and network layers. The virtual link layer was necessary to support "revisititation", in which a single physical node represents multiple virtual nodes. > RTCP > - sister protocol to RTP > - control packets between the endpoints, on the data path > - SRTCP, encrypted version It's not clear why this is distinct. Aspects of management and reporting of the entire overlay can use the SIP equivalent. Aspects of managing and monitoring the channel between the endpoints should happen in-band, within the RTP equivalent IMO. Joe > > > Taking that approach and apply it on NVO3 would give us > > Overlay Controller Protocol (OCP) > - register VTEPs to the system > - finding out capabilities of the VTEPs > - setting up tunnels between the VTEPs > > Overlay Tunnel Protocol (OTP) > - "streaming" between VTEPs > - optimized for hardware offload > - UDP the preferred transport protocol > - extensions should not be implemented > - encrypted version(s) > > Overlay Tunnel Control Protocol (OTCP) > - sister protocol to OTP > - control packets between the VTEPs, on the data path > - encrypted version > > > What do we have at the moment, please add if I miss something or got it wrong > > OCP > - BESS and LISP WG on standards tracks > - some proprietary solutions > - OpenStack with OVN > > OTP > - MPLS, L2TPv3, GRE etc on standards track but not implemented in NVO3 > solutions. > - VXLAN/LISP, NVGRE, STT, GUE, Geneve etc > > OTCP > Missing, instead each OTP is trying to have its own extension field > for various use cases. Some of those extension use cases should be > solved by the OCP but since there are several OCPs deployed today and > their architecture might not be able to handle all needed uses case, > it might be more convenient to add an extensions header for a > preferred OTP. But that interferes with hardware offloading > implementations. The question is, is it possible to leave the OTPs as > much as possible without extensions headers, optimized for hardware > offloading, and instead create a common NVO3 OTCP that all OCPs and > OTPs can leverage? > The OTP should stay as much as possible in the data forwarding path > but an OTCP packet should/can be ignored by VTEP's hardware offloading > mechanism and punted to the control plane of the VTEP. Perhaps NVO3 > OAM could be one TLV subset here? As an NVO3 admin I would like to > have a NVO3 traceroute for the VTEP and underlay switches/routes, so > when a customer complains I could issue NVO3 traceroute, copying the > UDP header for the encap used by the customer, to figure out on which > ECMP path in the underlay network the customer traffic is on. And a > NVO3 ping would be useful to to check path MTU in the ECMP network. > > Regards, > Patrick > > > On Mon, Aug 8, 2016 at 10:43 AM, Lizhong Jin <[email protected]> wrote: >> Hi, >> With my design experience of NIC and Switch, I prefer VXLAN-GPE. I have the >> same concern of HW complicated logic from Fabio, and additional concern to >> GENEVE and GUE is its long size of header. >> 1. GENEVE: 256+8=262Bytes >> 2. GUE: 128+4=132Bytes >> In many current switch and NIC design, the parser buffer size is still >> 128Bytes, and some NIC/DMA has 256Bytes buffer. This is workable because: >> 1. IPv4 options is not widely used. >> 2. IPv6 extension header only support with limited number. >> But if adding GENEVE/GUE header, the minimum size of buffer is 256Bytes, or >> even 512Bytes. Then the question is, does the hardware need to process these >> Variable Length Options/Optional Fields/Private Data. If not, then it is not >> reasonable to force the hardware to increase the cost, but gain little. >> >> Lizhong >> >> >> >>> ---------- Forwarded message ---------- >>> From: Alia Atlas <[email protected]> >>> To: NVO3 <[email protected]> >>> Cc: "Bocci, Matthew (Nokia - GB)" <[email protected]> >>> Date: Fri, 29 Jul 2016 11:13:00 -0400 >>> Subject: Re: [nvo3] Consensus call on encap proposals >>> I'd like to have people focus on the key point of this thread. >>> >>> Are there serious technical objections (and specifically what are they) to >>> moving forward with VXLAN-GPE as the standards-track protocol? >>> >>> Are there serious technical objections (and specifically what are they) to >>> moving forward with GENEVE as the standards-track protocol? >>> >>> Are there serious technical objections (and specifically what are they) to >>> moving forward with GUE as the standards-track protocol? >>> >>> We need to capture any relevant objections. So far, there's been some >>> discussion on extensibility - with Tom Herbert providing concrete concerns. >>> >>> I have concluded that almost all the authors would prefer to have no >>> standards track solution if they can't guarantee that theirs is that >>> standard. >>> >>> I do hear concerns about whether a decision will be too late. I think >>> that a decision can only be helpful. It goes back to when is the best time >>> to plant a tree - with the answer of 20 years ago or now. >>> >>> Regards, >>> Alia >>> >>> >>> On Fri, Jul 29, 2016 at 4:34 AM, Naoki Matsuhira >>> <[email protected]> wrote: >>>> >>>> >>>> On 2016/07/21 23:56, Bocci, Matthew (Nokia - GB) wrote: >>>>> WG >>>>> >>>>> There was a discussion in the NVO3 WG meeting in Berlin following strong >>>>> advice from our Area Director that we need to come to a consensus on >>>>> converging on a common encapsulation. Two sets of questions were asked: >>>>> (1) Should the WG move forward with one standards track encap? >>>>> (2) For a given encap, do you have significant technical objections? >>>> >>>> I want to inform to this mailing list that I proposed ME6E-FP and ME6E-PR >>>> at the yokohama meeting. I also have proposal M46E-FP and M46E-PR (past >>>> called SA46T). >>>> >>>> These encapsulation technologies are based on address mapping. ME6E use >>>> IPv6 address which mapping MAC address, and M46E use IPv6 address which >>>> mapping IPv4 address. >>>> >>>> I understand too many encapsulation technologies, however these my >>>> proposal are simple, and may contribute to the Internet. >>>> >>>> I believe address mapping approach is unique, so I want to propose again. >>>> >>>> sorry not the answer to the question. >>>> >>>> Naoki Matsuhira >>>> >>>> >>>> _______________________________________________ >>>> nvo3 mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/nvo3 >>> >>> >> >> _______________________________________________ >> nvo3 mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/nvo3 >> > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
