Yves, Absolutely, but I'm not sure what statement I made you were responding to.
- Larry On 10/22/13 7:57 AM, "Yves Hertoghs (yhertogh)" <[email protected]> wrote: >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
