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-unified-00 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 service, >LK2> 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. 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
