Larry, A VN could be dynamically created on an NVE as a result of a move of a certain TS. The NVE could notify the NVA about the new location of the TS.
Yves On 22/10/13 01:47, "Larry Kreeger (kreeger)" <[email protected]> wrote: >Hi Yves, > >See my responses inline with LK>. > > - Larry > >On 10/21/13 3:29 AM, "Yves Hertoghs (yhertogh)" <[email protected]> >wrote: > >>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. > >LK> I agree. Just because we have an NVA to facilitate the running of the >overlays, it doesn't mean that the NVA needs to control the minutiae of >everything an NVE does. I don't recall separation of control and data >planes being a goal of NVO3 (I believe that is what FORCES is doing). > >> >>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. > >LK> I agree with you about mappings. I'm less sure about NVAs feeding >policies to the NVA. > >> >>With regards to the 'new service type' of a combined L2/L3 NVE, >>http://tools.ietf.org/html/draft-hertoghs-nvo3-lisp-controlplane-unified- >>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. > >LK> I'll give you an example of why I think the protocol requirements will >be different for L2 vs L3 vs a combined L2/L3 service. For an L2 VN, the >VN needs to be identified (e.g. with a Name or ID). For an L3 VN, it >similarly needs to be identified. For a combined L2/L3 service, I think >the NVEs need to know both the L3 VN identity (one), and all the L2 VN >identities that are part of the L3 VN. When doing distributed L3 >forwarding between a TS on one L2 VN to one on another L2 VN, it will need >to know not just the mapping of inner to outer address, but the mapping of >inner L3 address to destination L2 VN and MAC address (so it can rewrite >the MAC and the L2 VN). > >> >>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, 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 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 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
