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
