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
