Hi Ben, Sorry for the delayed response. I think we can address your last two comments rather easily and hopefully close this review. Please refer to my replies marked in red.
From: Benjamin Kaduk <[email protected]> Date: Saturday, February 27, 2021 at 4:06 PM To: Ali Sajassi (sajassi) <[email protected]> Cc: The IESG <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]>, Zhaohui Zhang <[email protected]> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT) 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). In terms of sequencing, both the current paragraph in section 7.1 and your understanding of it are correct (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). Sorry for confusing you with my earlier response by saying that "the source PE doesn't withdraw the MAC/IP but rather it readvertised it". We always withdraw the route first and then send a local ARP probe. (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.) Vast majority of the cases there is a valid workload/TS move which means the TS is moved from source to the target NVE. Therefore, the procedure in this section is based on that – i.e, to optimize for vast majority of the cases which need route withdrawal. > > 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. In “Security Consideration” of this draft, it says that “The security consideration for layer-3 routing in this document follows that of [RFC4365<https://datatracker.ietf.org/doc/html/rfc4365>] with the exception for the application of routing protocols between CEs and PEs.” – i.e, there is no L3 protocol between CE and PE. So, we are saying that security aspects of RFC 4365 (and in turn RFC 4111) can be used in here similar to L3VPN except for CE-PE protocol part. Thanks again for your thoughtful responses, and sorry again for my unresponsiveness. Thank you for the time you have spent on this and giving us valuable feedback. We truly appreciate your effort in making these documents better. Regards, Ali -Ben
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
