>>> Dino, >>> >>> Are you talking about one TS connected to two different NVEs? >> >> No, I was talking about any NVE talking to any other NVE, regardless of >> the number of TSes attached to it. > > Aren't NVEs the end hosts to the underlay network? It is the underlay > network's responsibility to forward
Don't go there and confuse matters. > (encapsulated) packets to other NVEs. If the destination NVEs don't exist, > those packets go to black hole. Yes, it is. But a NVE could be unreachable and if the encapsulating NVE has a choice to select another NVE to encapsulate to, it should. This makes the architecture more robust. Dino > > Linda > > >> >>> >>>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On Behalf >> Of >>>> Dino Farinacci >>>> Sent: Friday, November 15, 2013 5:40 PM >>>> To: Thomas Narten >>>> Cc: [email protected]; Lucy yong; Yves Hertoghs (yhertogh) >>>> Subject: Re: [nvo3] No need for NVE-NVE control plane [was Re: Poll >> for >>>> WG adoption and IPR check for draft-narten-nvo3-arch-01.txt >>>> >>>>> NVO3 does not need an NVE to NVE control protocol. >>>> >>>> How about so an NVE knows a path to another NVE is up? Because if it >> is >>>> not, it could choose another NVE that supports the end-host. >>>> >>>>> Calling this out explicitly, as it is consistent with the current >>>>> architecture document. There is no need for an NVE to NVE control >>>>> protocol, for the purpose of maintaining/populating the mapping >>>>> tables. There may well be interactions between NVEs, such as >> setting >>>>> up tunnels, creating security associations for protecting data >> plane >>>>> traffic, or providing error indications (e.g., equivalent of ICMP >> "TS >>>>> unreachable" responses). >>>> >>>> Then don't worry about naming semantics. Let's just agree that NVEs >>>> need to talk to each other, other than just encapsulating to each >> other. >>>> >>>>> If folk disagree, now would be a good time to have that >> conversation. >>>> >>>> I know you may not be suggesting using ICMP unreachables or the >>>> equivalent, but remember they just tell you when something "goes >>>> unreachable". They don't tell you when something has become >> reachable >>>> (not just become reachable but in a timely fashion), so you'll need >>>> some NVE-to-NVE interaction. >>>> >>>> Dino >>>> >>>>> >>>>> "Yves Hertoghs (yhertogh)" <[email protected]> writes: >>>>> >>>>>>>> I disagree with the need for an NVE to NVE control plane. >>>>>> >>>>>>> [Lucy] do you think we need NVE-NVE control plane? I don't think >>>>>>> this is what you mean from the following statement. >>>>>> >>>>>> No we dont need an NVE to NVE control plane. >>>>>> >>>>>>>> That doesn't mean that you can't colocate a portion of the >>>>>>>> distributed NVA with every NVE, which is the model that >>>>>>>> e.g. BGP/L3VPN or ISIS/TRILL uses. >>>>>> >>>>>>> [Lucy] Agreed. NVA can collocate w/ NVE. (partially or entire). >>>>>> >>>>>> And as a result there is only a need for a control plane between >> the >>>>>> NVE function and the NVA function. >>>>> >>>>> 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
