Hi, I think that we want to keep the text as-is. I.e., withdraw the route and then send an ARP probe, because in the normal case the ARP probe will fail and we have cleaned up expeditiously. A positive response to the ARP probe is highly unlikely, but if it happens then we need to re-advertise the route.
Yours Irrespectively, John Juniper Business Use Only > -----Original Message----- > From: Benjamin Kaduk <[email protected]> > Sent: Saturday, February 27, 2021 7:05 PM > To: Ali Sajassi (sajassi) <[email protected]> > Cc: The IESG <[email protected]>; draft-ietf-bess-evpn-inter-subnet- > [email protected]; [email protected]; [email protected]; Jeffrey (Zhaohui) > Zhang <[email protected]> > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet- > forwarding-09: (with DISCUSS and COMMENT) > > [External Email. Be cautious of content] > > > Hi Ali (again), > > As promised in the other thread I wanted to say a couple more things here. > I'll trim the stuff that's being covered elsewhere or is already resolved... > > On Fri, Feb 05, 2021 at 07:53:44AM +0000, Ali Sajassi (sajassi) wrote: > > Hi Ben, > > > > Please see my replies marked with AS>> > > > > On 10/29/20, 5:26 PM, "Benjamin Kaduk" <[email protected]> wrote: > > > > On Thu, Sep 03, 2020 at 06:17:01AM +0000, Ali Sajassi (sajassi) wrote: > > > Hi Ben, > > > > > > Thanks very much for your review and comments. Please refer to my > replies inline marked with [AS]. > > > > > > On 7/14/20, 2:00 PM, "Benjamin Kaduk via Datatracker" > <[email protected]> wrote: > > > Section 7 > > > > > > The concrete advice we give in Section > > > 7.1 to send a local ARP probe is good, but how rigid does the > > sequencing > > > need to be amongst (receive EVPN MAC/IP Advertisement, send local > ARP > > > probe/wait for response, and withdraw EVPN Mac/IP Advertisement)? > > If > > > there was a way to avoid the need to withdraw+readvertise step, it > seems > > > like that might be preferable. > > > > > > [AS] If the reply to the local ARP probe is positive, then the source > > PE > doesn't withdraw the MAC/IP but rather it readvertised it with a higher > sequence > number and performs MAC duplication detection. > > > > The current text does not give me that impression. I would prefer if we > > could reword it somehow to clarify, perhaps "It then sends an ARP probe > > locally to ensure that the MAC is gone, and withdraws the EVP MAC/IP > > Advertisement route upon confirmation that the MAC is gone". > > > > AS>> The sentence above it says the source NVE withdraws the MAC/IP route. > Here it is: > > "It then withdraws its EVPN MAC/IP Advertisement route. > > Furthermore, it sends an ARP probe locally to ensure that the MAC is > > gone. If an ARP response is received, the source NVE updates its ARP > > entry for that (IP, MAC) and re-advertises an EVPN MAC/IP > > Advertisement route for that (IP, MAC) along with MAC Mobility > > Extended Community with the sequence number incremented by one." > > I think I'm still confused. The sequencing in this paragraph, just taking > the steps > in order, is "first, withdraw the route. Second, send a local ARP probe. > Third, if > the ARP probe gets a response, re-advertise [a new] route for the MAC/IP with > higher sequence number". But earlier in the quoted text you said that "the > source PE doesn't withdraw the MAC/IP but rather it readvertised it". I > still see > the first "withdraw" step in the procedure, so I'm not sure whether we expect > there to be a "withdraw then readvertise with higher sequence number" or just > "readvertise with higher sequence number" (no withdraw at all). > > (I don't really know how disruptive the withdraw is and thus I don't know to > what lengths we should go to avoid it. But if the document is saying > something > that is different than the expected behavior we should change the > document.) > > > > Section 11 > > > > > > Furthermore, the security consideration for layer-3 routing is > > this > > > document follows that of [RFC4365] with the exception for > > application > > > > > > The Security Considerations of RFC 4365 notes that RFC 4111 > > provides a > > > template "that may be used to evaluate and summarize how a given > PPVPN > > > approach (solution) measures up against the PPVPN Security > Framework". > > > Given that the IP-layer inter-subnet routing introduced by this > > document > > > is in some sense a new L3VPN technology, would it be appropriate > > to fill > > > out that template as it applies here? It's unfortunate that RFC > > 7432 > > > does not itself fill out the template from RFC 4111, as it would > > be > > > useful to have that information readily available as well (though > > I > > > understand that the L2-only parts of the mechanims described in > > this > > > document are essentially unchanged from RFC 7432 and it is only > > our > > > responsibility to document otherwise-undocumented critical > > security > > > flaws). > > > > > > [AS] Yes, the L2-only parts of this document (MAC-VRF) are basically > > the > same as RFC 7432. > > > > But the L3 parts are new. Shouldn't we at least document that part? > > > > AS>> I think it is OK. > > If you don't mind, I'd be happy to hear more about why you think it is okay to > ignore the RFC 4111 template. But I do not insist. > > Thanks again for your thoughtful responses, and sorry again for my > unresponsiveness. > > -Ben _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
