Hi Ali, My apologies once more for taking so long to get back to you -- I should not make a habit of taking a month to reply.
I will top-post since the color is not retained in this text/plain message, but in short, I think we can consider these topics resolved. Thanks for confirming that the procedure and sequencing of steps in the document (withdraw, then probe, then psosible re-advertise) is as-intended to cover the common case. This matches up with John's sentiment, and it sounds like leaving the text in the document as-is is the right thing to do. I also appreciate the additional perspective about how the security considerations for the layer-3 part of this IRB solution relate to the considerations described in RFC 4365. Thanks again, Ben On Tue, May 11, 2021 at 10:31:03PM +0000, Ali Sajassi (sajassi) wrote: > 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 <ka...@mit.edu> > Date: Saturday, February 27, 2021 at 4:06 PM > To: Ali Sajassi (sajassi) <saja...@cisco.com> > Cc: The IESG <i...@ietf.org>, > draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org > <draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>, bess-cha...@ietf.org > <bess-cha...@ietf.org>, bess@ietf.org <bess@ietf.org>, Zhaohui Zhang > <zzh...@juniper.net> > 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" <ka...@mit.edu> 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" > > <nore...@ietf.org> 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 BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
