Lucy, Pretty much everything has a data plane (e.g. IPv4, IPv6) and a control plane (e.g. OSPF, IS-IS), but that doesn't mean they are separated into different devices.
- Larry On 10/22/13 8:08 AM, "Lucy yong" <[email protected]> wrote: >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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
