Thanks! Yours Irrespectively,
John Juniper Business Use Only > -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Wednesday, June 9, 2021 1:26 PM > To: Ali Sajassi (sajassi) <saja...@cisco.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-bess-evpn-inter-subnet- > forward...@ietf.org; bess-cha...@ietf.org; bess@ietf.org; Jeffrey (Zhaohui) > Zhang <zzh...@juniper.net> > 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, > > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/r > fc4365__;!!NEt6yMaO- > gk!XgkkkSIRory7sPHrJsUvgyQ3SGcMybs9rXDJk5wUPXIAGWIw5xMw9PXdM9w8 > MvI$ >] 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
