Hello, Sorry to jump into this discussion. A few questions on the Distributed Gateways definition. - There is Gateway defined in section 5.3. Do we still need a Gateway when Distributed Gateways are enabled in the NVEs? Maybe yes. Please clarify it in the draft. - Assuming the Distributed Gateway is defined for L3 service, right? Please clarify it in the draft. - For L3 service, does the Distributed Gateway support routing or forwarding or both? There is no routing protocol running between the Distributed Gateways, right? I assume it is a Yes as it is "relaying" function only. Maybe the Distributed Gateways can be renamed to Distributed Forwarding. Or a clarification needs to be added. - The text in 5.4 implicitly say that the forwarding policies are updated by the NVA. This may be ok if user plane routing is not in the scope. If there is a vR installed in a VM as an user plane router, there may be routing communications between the vR and the Gateway (or Distributed Gateways) which may have an impact on the forwarding policies. Do we expect any forwarding policies updates due to above data plane routing communications? I hope it is a No. Maybe it is better to have it clarified in the draft.
Have a nice day Zu Qiang >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Larry Kreeger (kreeger) >Sent: Friday, October 18, 2013 6: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
