Subject: Re: [bess] Benjamin Kaduk's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Jun 2021 10:25:50 -0700

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 <[email-masked]>
> Date: Saturday, February 27, 2021 at 4:06 PM
> To: Ali Sajassi (sajassi) <[email-masked]>
> Cc: The IESG <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Zhaohui Zhang <[email-masked]>
> 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-masked]> 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-masked]> 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

---

From: John E Drake <[email-masked]>
Date: Wed, 9 Jun 2021 18:27:16 +0000

Thanks!

Yours Irrespectively,

John

Juniper Business Use Only

> -----Original Message-----
> Sent: Wednesday, June 9, 2021 1:26 PM
> Cc: The IESG <[email-masked]>; draft-ietf-bess-evpn-inter-subnet-
> [email-masked]; [email-masked]; [email-masked]; Jeffrey (Zhaohui)
> Zhang <[email-masked]>
> 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.
> 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
> 
> > 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.
> >
> >
> > Cc: The IESG <[email-masked]>,
> > [email-masked]
> > <[email-masked]>,
> > [email-masked] <[email-masked]>, [email-masked]
> > <[email-masked]>, Zhaohui Zhang <[email-masked]>
> > Subject: Re: Benjamin Kaduk's Discuss on
> > draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and
> > COMMENT) Hi Ali (again),
> >
> > >     > [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.
> > >
> > 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
> > >     >
> > 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.
> >
> > 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

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 10 Jun 2021 16:15:07 +0000

Thank you Ben for your meticulous review and valuable comments that you have provided during the course of this document review.

Cheers,
Ali

Date: Wednesday, June 9, 2021 at 10:26 AM

Thanks again,

Ben