> Hi Ivan, > > Snip.. > > On the other hand, LISP defines several mechanisms that can be used to check > the ETR liveliness. > [[LY]] LISP provides a control plane function. If an ETR is not live, it > needs to update all the end systems attaching to that ETR as "deleted". So no > packet should be forwarded to the end systems behind ETR.
There is a LISP mechanism to solve this problem already and it is not the way you describe. By just looking at one technique, called RLOC-probing, the ITRs can determine when one or more ETRs in their locator-set have gone unreachable, and when that happens, the ITR will encapsulate to the ETRs (from the locator-set) that are up and reachable (avoiding the down ETRs). When the overlay is deployed in the network, you have better opportunities for multi-homing, therefore you have more resiliency to failure. Dino > Coming back to nvo3, we'll have serious problems with NVE in a hypervisor > using more than one underlay IP address, more so if its control-plane session > uses only one of them. We'll never know whether the other IP addresses are > reachable (the problem becomes worse if you have a DC transport > infrastructure that's a mixture of L2 and L3). > [[LY]] IMO: an overly network has to "believe" that underlying network is > able to reach the remote NVE. Without such "believe", the architecture will > not work. ETR live does not mean the intermediate nodes or links in > underlying network being live. Overlay tunnel is to rely on the underlying > network transport. Should underlying network report its transport status to > an overlay? This is an very old problem in the layered transport network. It > is option, not required because of the scalability. > > In situation where NVE has more than one IP address used by nvo3, we need (in > my opinion) something that checks the liveliness of the remote NVE IP address > ... and it's not an implementation detail, it's a mandatory requirement. > [[LY]] I think this is different aspect. If NVE is dead, neither IP address > can help to reach the end system behind it. In fact, a sender should not send > a packet to a dead NVE. > > Lucy > > Hope this makes more sense > Ivan > >> -----Original Message----- >> From: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel- >> lucent.com] >> Sent: Tuesday, September 04, 2012 11:46 PM >> To: Ivan Pepelnjak >> Cc: Somesh Gupta; [email protected] >> Subject: RE: [nvo3] Support for multi-homed NVEs >> >> Ivan, >> See in-line... >> >>> -----Original Message----- >>> From: Ivan Pepelnjak [mailto:[email protected]] >>> Sent: Tuesday, September 04, 2012 12:03 PM >>> To: Balus, Florin Stelian (Florin) >>> Cc: Somesh Gupta; [email protected] >>> Subject: Re: [nvo3] Support for multi-homed NVEs >>> >>> A) Not per prefix (at least not without serious amount of end-to-end >>> BGP multipathing+BGP AddPath or multiple RDs) >>> >>> B) There's no liveliness check in *VPN (apart from LISP) >> [FB>] How are the VPN specifications (IP VPN, VPLS, VPWS or incoming EVPN) >> connected to LISP? Also can you be more specific on the absence of >> liveliness check in *VPN. Are you talking about a certain >> deployment/implementation environment? >> Thanks, >> Florin >> >>> >>> In MPLS/VPN we rely on the host route to PE loopback and/or LSP to the >>> /32 prefix to indicate next hop validity. That won't work for >>> hypervisor-based NVEs >>> >>> On 9/4/12 8:00 PM, Balus, Florin Stelian (Florin) wrote: >>>> AFAIK the text in NVO3 framework and requirements drafts allows >>> multiple IPs per NVE. We have multiple IPs per PE in current VPN >>> implementations. This is an implementation matter though in my opinion. >>>> >>>>> -----Original Message----- >>>>> From: Somesh Gupta [mailto:[email protected]] >>>>> Sent: Tuesday, September 04, 2012 10:51 AM >>>>> To: Ivan Pepelnjak; Balus, Florin Stelian (Florin) >>>>> Cc: [email protected] >>>>> Subject: RE: [nvo3] Support for multi-homed NVEs >>>>> >>>>> Florin, >>>>> >>>>> Regarding the multi-homing, my assumption is that the NVE in the >>>>> hypervisor would not (want to) run a routing protocol. So as Ivan >>>>> points out, the standard would need to accommodate multiple IP >>>>> addresses per NVE. >>>>> >>>>> Somesh >>>>> >>>>>> -----Original Message----- >>>>>> From: Ivan Pepelnjak [mailto:[email protected]] >>>>>> Sent: Tuesday, September 04, 2012 9:58 AM >>>>>> To: Balus, Florin Stelian (Florin) >>>>>> Cc: Somesh Gupta; [email protected] >>>>>> Subject: Re: [nvo3] Support for multi-homed NVEs >>>>>> >>>>>> Ah, that other can of worms ;) Mine was simpler. >>>>>> >>>>>> On the underlay side, we might decide that NVEs have a single IP >>>>>> address or multiple IP addresses (like some NVGRE load balancing >>>>>> proposals). If we decide NVEs have a single IP address (potential >>>>>> per virtual network segment), then the rest is implementation >>>>>> details >>>>> (and >>>>>> we're back to MLAG/SMLT land for true redundancy). Alternatively >>>>>> we might implement the option of having multiple IP addresses per >>>>>> NVE, and the NVEs might use the IP-address-per-link option (thus >>>>>> no need for L2 or MLAG at all). >>>>>> >>>>>> On the overlay side, the real problem (as you stated) is the >>>>>> multi-homing of NVO3-to-legacy gateways. I don't see any other >>>>>> need for overlay NVE multihoming. >>>>>> >>>>>> BTW, Nicira has nicely solved the NVO3 gateway multihoming - the >>>>> whole >>>>>> NVO3 network works exactly like VMware's vSwitch: split horizon >>>>>> bridging (thus no forwarding loops through NVO3), with every VM >>>>>> MAC address being dynamically assigned to one of the gateways, >>>>>> which also solves the return path issues (dynamic MAC learning in >>>>>> legacy network takes care of that). Maybe we should just use the >>>>>> wheel >>> that >>>>>> has already been invented? >>>>>> >>>>>> Kind regards, >>>>>> Ivan >>>>>> >>>>>> On 9/4/12 6:45 PM, Balus, Florin Stelian (Florin) wrote: >>>>>>> I understand the discussion below is about the NVE multi-homing >>>>>> towards the IP core, on the tunnel side. >>>>>>> We did not focus in the framework draft on the core redundancy as >>>>> in >>>>>> our opinion there was no need to standardize anything here. There >>>>>> are no differences from what is available today in regular IP >>> networks: >>>>> if >>>>>> NVEs are multi-homed directly to the next IP router, regular >>> routing >>>>>> will take care of it. If there is Ethernet switching in between >>>>>> NVE and the next IP hop, L2 resiliency mechanisms need to be >> employed. >>>>>> From what I read below it looks more of an implementation >>>>>> discussion than a standardization requirement. Am I right? >>>>>>> By Multi-homed NVEs one can also understand a set of NVEs >>>>>>> multi-homed >>>>>> on the access side to other devices. That is a discussion we need >>> to >>>>>> have in my opinion. An use case example: NVO3 network - NVE GWs >>>>> multi- >>>>>> homed to external non-NVO3 networks. Handoff can be VLANs, VPLS >>> PWs, >>>>>> or BGP EVPN labels... >>>>>>> I think the latter is worth discussing although there are some >>>>>> mechanisms and some standardization initiatives in place already. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: [email protected] [mailto:[email protected]] On >>>>>>>> Behalf >>>>>> Of >>>>>>>> Ivan Pepelnjak >>>>>>>> Sent: Friday, August 31, 2012 12:23 AM >>>>>>>> To: 'Somesh Gupta'; [email protected] >>>>>>>> Subject: Re: [nvo3] Support for multi-homed NVEs >>>>>>>> >>>>>>>> This is definitely an interesting can of worms ;) >>>>>>>> >>>>>>>> While I don't think we should go down the path of IP-A/IP-B >>>>>>>> networks similar to some other DC technology, we will face the >>>>>>>> reality of >>>>>> some >>>>>>>> NVE elements (hypervisor soft switches) not being underlay IP >>>>>> routers. >>>>>>>> We could either: >>>>>>>> >>>>>>>> (A) ignore the issue and expect the network designer to solve it >>>>>> using >>>>>>>> any one of the existing NIC teaming/MLAG kludges while retaining >>> a >>>>>>>> single encapsulation IP address per NVE; >>>>>>>> >>>>>>>> (B) provide support for multiple encapsulation addresses per NVE >>>>> so >>>>>> a >>>>>>>> multi-homed NVE could have one IP address per physical interface >>>>>>>> and send and receive nvo3-encapsulated frames using more than >>>>>>>> one >>>>>> address. >>>>>>>> Option (A) is the easy way out similar to existing MPLS/VPN >>>>>>>> behavior and would fit well with existing DC deployments. It >>> would >>>>>>>> also >>>>>> retain >>>>>>>> all the server-to-ToR multihoming complexity. >>>>>>>> >>>>>>>> Option (B) would reduce the complexity of the underlay DC >>>>>>>> network (which would become a simple L3 network with >>>>>>>> single-homed IP addresses), but we'd have to deal with a bunch >>>>>>>> of additional >>>>>> problems >>>>>>>> (peer IP address liveliness check). >>>>>>>> >>>>>>>> Just speculating ... >>>>>>>> Ivan >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: [email protected] [mailto:[email protected]] On >>>>>> Behalf >>>>>>>>> Of Somesh Gupta >>>>>>>>> Sent: Friday, August 31, 2012 6:58 AM >>>>>>>>> To: [email protected] >>>>>>>>> Subject: [nvo3] Support for multi-homed NVEs >>>>>>>>> >>>>>>>>> I did not see any mention of multi-homed NVEs in >>>>>>>>> draft-lasserre- >>>>>> nvo3- >>>>>>>>> framework-03.txt. NVEs are connected together by an L3 network >>>>>>>>> - >>>>>> does >>>>>>>>> that mean only one? >>>>>>>>> Can it be multi-homes to two L3 networks? >>>>>>>>> >>>>>>>>> Somesh >>>>>>>>> _______________________________________________ >>>>>>>>> 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
