Tunnel EPs have OAM tools to monitor each other. Lucy
-----Original Message----- From: Linda Dunbar Sent: Friday, November 15, 2013 6:15 PM To: Dino Farinacci Cc: Thomas Narten; [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 > > 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 (encapsulated) packets to other NVEs. If the destination NVEs don't exist, those packets go to black hole. 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
