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. > >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. >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? > 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. > >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
