Larry, Yes, let's talk more in YVR.
Lucy -----Original Message----- From: Larry Kreeger (kreeger) [mailto:[email protected]] Sent: Wednesday, October 23, 2013 6:48 PM To: Lucy yong; Yves Hertoghs (yhertogh); Thomas Narten Cc: [email protected] Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture document] Hi Lucy, I'm afraid we both may be misunderstanding each other. When I read your statement "NVO3 has data plane and control plane requirements. In your opinion, where do they fit in this architecture?" I interpreted this to mean that because we have separate documents for data plane requirements from control plane requirements, than that leads to the assumption that they are separated. I apologize if I misinterpreted you. So far, IMO, NVO3 has not been about the OpenFlow architecture, nor SDN (whatever that means, let's leave that do the marketers and SDNRG), nor about control/data plane separation (FORCES). The architecture calls for a logically centralized NVA to resolve inner to outer address mappings (among other things), and based on recent list discussions, NVEs may send messages directly to each other to help optimize the correction of a stale mapping. Maybe we can have a conversation about this more easily when we are in Vancouver. Thanks, Larry On 10/22/13 10:24 PM, "Lucy yong" <[email protected]> wrote: >Larry, > >I am surprised to see your answer. Does nvo3 control plane requirement >draft also covers underlying control plane requirement? > We are talking about the control plane for overlay virtual network! >Yes, every communication in overlay data plane and control plane relies >on underlying network. Traditional underlying networks do not have >control plane and data plane separation. Recently OF or SDN based >architecture uses the concept of control plane and data plane separation. > >In addition, I use the word entity, not device. They are not equivalent >in my opinion. > >Lucy > >-----Original Message----- >From: Larry Kreeger (kreeger) [mailto:[email protected]] >Sent: Tuesday, October 22, 2013 10:07 PM >To: Lucy yong; Yves Hertoghs (yhertogh); Thomas Narten >Cc: [email protected] >Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >document] > >Lucy, > >Pretty much everything has a data plane (e.g. IPv4, IPv6) and a control >plane (e.g. OSPF, IS-IS), but that doesn't mean they are separated into >different devices. > > - Larry > >On 10/22/13 8:08 AM, "Lucy yong" <[email protected]> wrote: > >>NVO3 has data plane and control plane requirements. In your opinion, >>where do they fit in this architecture? >> >>Lucy >> >>-----Original Message----- >>From: [email protected] [mailto:[email protected]] On Behalf >>Of Yves Hertoghs (yhertogh) >>Sent: Tuesday, October 22, 2013 10:00 AM >>To: Lucy yong; Larry Kreeger (kreeger); Thomas Narten >>Cc: [email protected] >>Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >>document] >> >>Lucy, >> >>If the document allows for different interpretations, we need to >>improve the document in my opinion. >>But i haven't really seen where the current text is implying what you >>are saying with regards to control / data plane separation. >> >>Yves >> >>On 22/10/13 16:56, "Lucy yong" <[email protected]> wrote: >> >>>Larry and Yves, >>> >>>It is great that an architecture clearly points out the protocol need >>>between two entities and does not deal with the entity implementation. >>>However, IMO, it is necessary to define the role of each entity in >>>order to be clear what are needed in the protocol. Without it, we >>>will later argue this in the protocol development and may end up a >>>heavy and complex protocol to support different implementations; or >>>make it clear later during the protocol development. Isn't it that >>>the architecture draft had intention in staying long in WG for this >>>reason? I am fine that people have different views and >>>interpretations of the description. In the end, we will see the >>>consequences and make consensus one way or another. >>> >>>Thanks, >>>Lucy >>> >>>-----Original Message----- >>>From: Larry Kreeger (kreeger) [mailto:[email protected]] >>>Sent: Monday, October 21, 2013 7:07 PM >>>To: Lucy yong; Yves Hertoghs (yhertogh); Thomas Narten >>>Cc: [email protected] >>>Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >>>document] >>> >>>Hi Lucy, >>> >>>I think you are interpreting the sections you quoted below >>>differently from how they were intended. I'm not aware of any >>>mention of separation of forwarding from control in the architecture >>>document. >>>Where it talks about obtaining information from the NVA for building >>>its internal forwarding tables, this does not mean that all internal >>>forwarding table information comes from the NVA. An NVE can >>>certainly build local forwarding state all on its own. Forwarding >>>between locally connected TS on the same NVE should not necessarily >>>require the NVA. >>> >>> - Larry >>> >>>On 10/21/13 1:32 PM, "Lucy yong" <[email protected]> wrote: >>> >>>>Hi Yves, >>>> >>>>To clarify, this is not I say it, it is the architecture described >>>>in the arch. draft. Here is text from section 6. >>>> >>>> Before sending to and receiving traffic from a virtual network, an >>>> NVE must obtain the information needed to build its internal >>>> forwarding tables and state as listed in Section 4.3. An NVE >>>>obtains >>>> such information from a Network Virtualization Authority. >>>> >>>> The Network Virtualization Authority (NVA) is the entity that >>>> provides address mapping and other information to NVEs. NVEs >>>> interact with an NVA to obtain any required information they need in >>>> order to properly forward traffic on behalf of tenants. The term >>>>NVA >>>> refers to the overall system, without regards to its scope or how it >>>> is implemented. >>>> >>>>Section 3 has the similar statement. >>>> >>>>I agree that it is possible to implement NVO without the separation >>>>of data plane and control plane. In that architecture, the focus >>>>will be the protocol between NVA/NVE -NVA/NVE as suggested in >>>>another thread. >>>>The WG needs decide if we should document one architecture or both >>>>architectures; if one, which one as the standard recommendation. I >>>>thought that the WG already had the decision and pointed the team to >>>>document it, wasn't? >>>> >>>>Thanks, >>>>Lucy >>>> >>>> >>>>-----Original Message----- >>>>From: Yves Hertoghs (yhertogh) [mailto:[email protected]] >>>>Sent: Monday, October 21, 2013 5:30 AM >>>>To: Larry Kreeger (kreeger); Lucy yong; Thomas Narten >>>>Cc: [email protected] >>>>Subject: Re: [nvo3] Distributed Gateways [was Re: NVO3 Architecture >>>>document] >>>> >>>>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. >>>> >>>>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. >>>> >>>>With regards to the 'new service type' of a combined L2/L3 NVE, >>>>http://tools.ietf.org/html/draft-hertoghs-nvo3-lisp-controlplane-uni >>>>f >>>>i >>>>e >>>>d-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. >>>> >>>>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 >>>>>LK2> 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 >>>>>LK2> 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. >>>>>LK2> 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 >>>>>LK2> 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 >>_______________________________________________ >>nvo3 mailing list >>[email protected] >>https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
