NVO3 has data plane and control plane requirements. In your opinion, where do they fit in this architecture?
Lucy -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Yves Hertoghs (yhertogh) Sent: Tuesday, October 22, 2013 10:00 AM To: Lucy yong; Larry Kreeger (kreeger); Thomas Narten Cc: [email protected] Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture document] Lucy, If the document allows for different interpretations, we need to improve the document in my opinion. But i haven't really seen where the current text is implying what you are saying with regards to control / data plane separation. Yves On 22/10/13 16:56, "Lucy yong" <[email protected]> wrote: >Larry and Yves, > >It is great that an architecture clearly points out the protocol need >between two entities and does not deal with the entity implementation. >However, IMO, it is necessary to define the role of each entity in >order to be clear what are needed in the protocol. Without it, we will >later argue this in the protocol development and may end up a heavy and >complex protocol to support different implementations; or make it clear >later during the protocol development. Isn't it that the architecture >draft had intention in staying long in WG for this reason? I am fine >that people have different views and interpretations of the >description. In the end, we will see the consequences and make consensus one >way or another. > >Thanks, >Lucy > >-----Original Message----- >From: Larry Kreeger (kreeger) [mailto:[email protected]] >Sent: Monday, October 21, 2013 7:07 PM >To: Lucy yong; Yves Hertoghs (yhertogh); Thomas Narten >Cc: [email protected] >Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >document] > >Hi Lucy, > >I think you are interpreting the sections you quoted below differently >from how they were intended. I'm not aware of any mention of >separation of forwarding from control in the architecture document. >Where it talks about obtaining information from the NVA for building >its internal forwarding tables, this does not mean that all internal >forwarding table information comes from the NVA. An NVE can certainly >build local forwarding state all on its own. Forwarding between >locally connected TS on the same NVE should not necessarily require the NVA. > > - Larry > >On 10/21/13 1:32 PM, "Lucy yong" <[email protected]> wrote: > >>Hi Yves, >> >>To clarify, this is not I say it, it is the architecture described in >>the arch. draft. Here is text from section 6. >> >> Before sending to and receiving traffic from a virtual network, an >> NVE must obtain the information needed to build its internal >> forwarding tables and state as listed in Section 4.3. An NVE obtains >> such information from a Network Virtualization Authority. >> >> The Network Virtualization Authority (NVA) is the entity that >> provides address mapping and other information to NVEs. NVEs >> interact with an NVA to obtain any required information they need in >> order to properly forward traffic on behalf of tenants. The term NVA >> refers to the overall system, without regards to its scope or how it >> is implemented. >> >>Section 3 has the similar statement. >> >>I agree that it is possible to implement NVO without the separation of >>data plane and control plane. In that architecture, the focus will be >>the protocol between NVA/NVE -NVA/NVE as suggested in another thread. >>The WG needs decide if we should document one architecture or both >>architectures; if one, which one as the standard recommendation. I >>thought that the WG already had the decision and pointed the team to >>document it, wasn't? >> >>Thanks, >>Lucy >> >> >>-----Original Message----- >>From: Yves Hertoghs (yhertogh) [mailto:[email protected]] >>Sent: Monday, October 21, 2013 5:30 AM >>To: Larry Kreeger (kreeger); Lucy yong; Thomas Narten >>Cc: [email protected] >>Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >>document] >> >>Allow me to take a step back here. >> >>It seems that Lucy is saying that in all cases, the NVA is the >>control-plane, and the NVEs are implementing the data plane. I >>believe this is doesn't have to be the case for all deployments, as a >>matter of fact this separation of control plane versus data plane is >>merely a deployment model rather than an architectural foundation. >> >>The NVA is more like a 'last-resort' function. If the NVE has the >>correct mappings and policies locally, it can just use those. Only in >>the case where it doesn't , it should pull them from the NVA. >> >>On the other hand the NVA doesn't always need to 'provisioned' via >>some sort of northbound interface regarding mappings and policies. An >>NVE can also 'feed' the NVA with information it discovers at the TS >>facing side of it. >> >>With regards to the 'new service type' of a combined L2/L3 NVE, >>http://tools.ietf.org/html/draft-hertoghs-nvo3-lisp-controlplane-unifi >>e >>d-0 >>0 >> describes what you are referring to , but i am not sure if it needs >>to be called a new service-type. I see it more as a deployment choice >>where you choose to deploy distributed gateways with uniform mac/IP >>addressing across the DC, collocate them with the L2 overlay, and do >>some traffic steering to make sure IP traffic gets sent to the L3 >>overlay (at all times), and non-IP traffic gets sent across the L2 >>overlay. >> >>Yves >> >>On 21/10/13 10:28, "Larry Kreeger (kreeger)" <[email protected]> wrote: >> >>>Lucy, >>> >>>See inline with LK2>. >>> >>> - Larry >>> >>>On 10/20/13 8:20 PM, "Lucy yong" <[email protected]> wrote: >>> >>>>Hi Larry, >>>> >>>>Please see inline with [Lucy] >>>> >>>>-----Original Message----- >>>>From: Larry Kreeger (kreeger) [mailto:[email protected]] >>>>Sent: Friday, October 18, 2013 6:39 PM >>>>To: Lucy yong; Thomas Narten >>>>Cc: [email protected] >>>>Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >>>>document] >>>> >>>>Lucy, >>>> >>>>See inline with LK>. >>>> >>>>Thanks, Larry >>>> >>>>On 10/18/13 3:21 PM, "Lucy yong" <[email protected]> wrote: >>>> >>>>>Larry, >>>>> >>>>>Distributed L3 gateway is very useful and some vendors already >>>>>implement that. >>>> >>>>I agree. >>>> >>>>>Current framework also includes L2/L3 service as Marc agrees to add >>>>>the text I proposed although we did not explicitly define as a >>>>>service type. >>>> >>>>I think we will need to because the control plane requirements will >>>>likely be different for a hybrid service. >>>>[Lucy] Do you mean that we should define an l2/L3 service type? I >>>>full agree and hope see more people support that too. We can either >>>>define it in the existing framework, or in the framework addition >>>>draft I submitted while ago. >>> >>>LK2> Yes, if the group is to seriously address a hybrid L2/L3 >>>LK2> service, I >>>think we need to define it as we will need to identify its >>>requirements independently from a pure L2 or pure L3 service. >>> >>>> >>>>> >>>>>Current architecture clear states NVE and NVA roles, i.e. NVE >>>>>performs forwarding, and NVA performs routing. >>>> >>>>I'm not sure what you mean by routing. Are you referring to L3 >>>>service? >>>>If so, I don't agree. >>>>[Lucy] Sorry to make you confuse. The routing here does not mean L3 >>>>services. I should state that NVE performs data plan forwarding, NVA >>>>performs control plane routing, which, IMO, it is not just simple DB >>>>to have inner to outer mappings. NVA may get the routing policy from >>>>operators or customer, then interpret the policy, then generates the >>>>mapping of tenant/next-hop location and send to NVEs. An NVE >>>>receives the mapping in which, if the location is the same as >>>>itself, it translates to a tenant/VAP mapping; If not, it installs >>>>as an inner/outer mapping. >>>>Thus, it works regardless whether sender tenant and destination >>>>tenant are one the same NVE or on different NVEs. The mapping >>>>between tenant/location is fully controlled under NVA. In this way, >>>>operator only needs to input the routing policies to NVA. NVE simply >>>>performs the forwarding accordingly. This is also my view about the >>>>SDN based architecture. >>>> >>>>>If NVA is not able to distribute routing policy to NVE at all, I do >>>>>not know how NVA can perform route distribution control? >>>> >>>>You lost me. Are you referring to a hybrid L2/L3 service? >>>>[Lucy] Let me know above explanation help or not. No, not >>>>particulate to >>>>L2/L3 service but that certainly applies to L2/L3 service. >>> >>>LK2> OK, if it isn't specific to L2/L3 service, than I'd rather leave >>>LK2> it >>>out of the discussion for now. And yes, the above helped me >>>understand what you meant. The term "routing" is very overloaded. >>> >>>> >>>>> If NVA only supports simple inner to outer mappings, how can NVE >>>>>get information to perform local forwarding? >>>> >>>>Inner to outer mapping resolution works fine for pure L2 or pure L3 >>>>service. Local forwarding doesn¹t need mappings, the local NVE >>>>knows what VAPs the TSI are connected to. >>>>[Lucy] does pure L3 service means an L3VPN w/o any policy? For an L3 >>>>service, you can implement it w/o policy or w policy. >>> >>>LK2> Yes, I was thinking of pure L3 service without adding policy. >>>LK2> I'm >>>pretty sure you need more than just inner to outer mappings to >>>implement policy. >>> >>>>IMO: NVE is not the entity to enforce the policy. NVA is the entity >>>>to enforce the policy regardless the tenant locations. Again, >>>>Network virtualization overlay has to address how to support the >>>>policies and tenant mobility. IMO: current architecture draft is >>>>vague in or lacks of describing this but it is important to >>>>architect this when having data plan and control plane separated on >>>>different entities. >>> >>>LK2> I'm not sure if I agree with you about the NVE not being the >>>LK2> entity >>>to enforce policy, but I think it is something better discussed in a >>>conversation (not email). >>> >>>> >>>>Thanks, >>>>Lucy >>>> >>>>> >>>>>Thanks, >>>>>Lucy >>>>> >>>>>-----Original Message----- >>>>>From: Larry Kreeger (kreeger) [mailto:[email protected]] >>>>>Sent: Friday, October 18, 2013 5:00 PM >>>>>To: Thomas Narten; Lucy yong >>>>>Cc: [email protected] >>>>>Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >>>>>document] >>>>> >>>>>Hi Thomas and Lucy, >>>>> >>>>>The WG needs to think hard about this one. >>>>> >>>>>Support of a distributed L3 gateway function between L2 VNs is a >>>>>significant increase in scope of the NVA, and the NVE to NVA protocol. >>>>>Where we had previously stated L2 service or L3 service and pretty >>>>>much left a combined L2/L3 service as an exercise for the reader, >>>>>we would now be adding whatever mechanisms are needed to the protocols. >>>>>We will need to add cases for >>>>>L2 service, L3 service and L2/L3 service. We no longer have simple >>>>>inner to outer mappings, but now need NVEs to do MAC rewrites, >>>>>local NVE ARP termination, and multiple lookups depending on the >>>>>destination MAC address (first L2, then potentially L3). We will >>>>>also need to distribute two different VN identifiers (one for L2 >>>>>and one for L3), and somehow convey the containment relationship >>>>>between the two (multiple L2 VNs within one >>>>>L3 VN). While I think this is all very useful, I just want to make >>>>>sure the WG agrees to this since I feel it is a significant >>>>>change/increase in scope from my perspective. >>>>> >>>>>Thanks, Larry >>>>> >>>>> >>>>> >>>>>On 10/18/13 2:52 PM, "Thomas Narten" <[email protected]> wrote: >>>>> >>>>>>Hi Lucy. >>>>>> >>>>>>Lucy yong <[email protected]> writes: >>>>>> >>>>>>> Section 5.3 describes gateways. IMO: it misses an important use >>>>>>> case. A Gateway, say overlay gateway, may be used to >>>>>>> interconnect two or more overlay VNs. In this case, the traffic >>>>>>> traversing between two overlay VNs must go through the gateway >>>>>>> where the policy can be enforced. Furthermore, it is possible to >>>>>>> implement centralized or distributed overlay gateway. The latter >>>>>>> has overlay gateway function implemented on NVEs. Thus, it >>>>>>> requests the cross-VN policies to be distributed to NVEs. >>>>>> >>>>>>> Current section seems very focus on overlay VN interconnect a >>>>>>> non-overlay network, which centralized gateway architecture is >>>>>>> practical. But in overlay networks, both centralized or >>>>>>> distributed are possible and depend on the applications. >>>>>> >>>>>>Agreed. I propose adding a new section after 5.3 that says: >>>>>> >>>>>> <section title="Distributed Gateways"> >>>>>> <t> >>>>>> The relaying of traffic from one VN to another deserves >>>>>> special consideration. The previous section described >>>>>> gateways performing this function. If such gateways are >>>>>> centralized, traffic between TSes on different VNs can take >>>>>> suboptimal paths, i.e., triangular routing results in paths >>>>>> that always traverse the gateway. As an optimization, >>>>>> individual NVEs can be part of a distributed gateway that >>>>>> performs such relaying, reducing or completely eliminating >>>>>> triangular routing. In a distributed gateway, each ingress >>>>>> NVE can perform such relaying activity directly, so long as >>>>>> it has access to the policy information needed to determine >>>>>> whether cross-VN communication is allowed. Having individual >>>>>> NVEs be part of a distributed gateway allows them to tunnel >>>>>> traffic directly to the destination NVE without the need to >>>>>> take suboptimal paths. >>>>>> </t> >>>>>> <t> >>>>>> The NVO3 architecture should [must? or just say it does?] >>>>>> support distributed gateways. Such support requires that >>>>>> NVO3 control protocols include mechanisms for the >>>>>> maintenance and distribution of policy information about >>>>>> what type of cross-VN communication is allowed so that NVEs >>>>>> acting as distributed gateways can tunnel traffic from one >>>>>> VN to another as appropriate. >>>>>> </t> >>>>>> </section> >>>>>> >>>>>>Thoughts? >>>>>> >>>>>>Thomas >>>>>> >>>>>>_______________________________________________ >>>>>>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
