Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

[Susan Hares <[e-mail]>]

Ben: 

 

The statement of "a review of Section 8.3.1 of RFC 8365 is called for" regarding the split horizon procedures”. 

Is providing a specific detail to the common phrase  "the combination of the two is out of scope for this document".  

 

Why did we do this? There are new drafts documents in the BESS pipeline that suggest putting the two together so it was a hint for these new documents where to look for issues.   

 

Sue 

 

 

From: Idr [mailto:[e-mail]] On Behalf Of Alvaro Retana
Sent: Thursday, December 3, 2020 9:38 AM
To: Benjamin Kaduk
Cc: [e-mail]; Benjamin Kaduk via Datatracker; The IESG; [e-mail]; [e-mail]; Susan Hares
Subject: Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

 

Yes, you’re right.

 

Thanks!

 

Alvaro.

 

On December 3, 2020 at 9:04:39 AM, Benjamin Kaduk ([e-mail]) wrote:

Hi Alvaro, 

Thanks for this; it causes a lot of the pieces to fit together better and 
make sense. 

Regarding just one thing: 

> related to rfc8365 there's nothing that has to be done. 

The Appendix does mention that "a review of Section 8.3.1 of RFC 8365 is 
called for" regarding the split horizon procedures. Am I correct in 
understanding that this review is only needed in the case that someone 
decides to use RFC 8365 with the expanded functionality provided by the 
Tunnel Encapsulation Attribute (rather than the preexisting extended 
community)? In some sense, that would just be saying that "the combination 
of the two is out of scope for this document", which is something that we 
see fairly often and does not seem problematic. 

Anyway, I think we can consider this discuss point resolved. 

Thanks again! 

-Ben 

On Thu, Dec 03, 2020 at 05:09:41AM -0800, Alvaro Retana wrote: 
> On December 1, 2020 at 1:18:15 PM, Benjamin Kaduk wrote: 
> 
> 
> Ben: 
> 
> Hi! 
> 
> I’m just addressing your second DISCUSS point. 
> 
> Thanks! 
> 
> Alvaro. 
> 
> 
> 
> > ---------------------------------------------------------------------- 
> > DISCUSS: 
> > ——————————————————————————————————— 
> … 
> > I also would like to ensure that we have had adequate discussion of the 
> > relationship between this document and RFC 8365. The IESG has received 
> > comments recently (in the context of a different document) that it is 
> > irresponsible to effectively obsolete or deprecate existing work without 
> > identifying or explicitly updating such work, and without indicating 
> > whose responsibility it is to find discrepancies. That seems like it 
> > might apply to what's currently in Appendix A, which on first reading 
> > suggests "there might be a problem here, but we aren't saying exactly 
> > what or how to fix it, or even who is going to do that work”. 
> 
> First of all, the part (in §1.5) about obsoleting rfc8365 is wrong.  I 
> had pointed that out and expected it to be fixed, then lost track of 
> the updates.  To be fair to the authors, I sent my note in the middle 
> of the IETF week. 
> 
> 
> On to Appendix A. 
> 
> rfc8365 Normatively references rfc5512 (the main RFC we're 
> Obsoleting).  This document includes the functionality (Encapsulation 
> Extended Community) that rfc8365 uses from rfc5512, so no change 
> there. 
> 
> The functionality specified in this document (specifically carrying 
> the Tunnel Encapsulation Attribute in other AFI/SAFIs) means that the 
> attribute, and not just the Encapsulation Extended Community, could 
> also be used to signal the same thing.  The appendix is then pointing 
> out that if this "new" signaling mechanism is used then there might be 
> some things to consider.  But we're not making any change to rfc8365. 
> 
> IOW, there's no problem, rfc8365 implementations can continue to work 
> as specified. 
> 
> 
> To your point about indicating who/how/where any additional work 
> should be done.  In general, I tend to agree with the point.  In this 
> case, related to rfc8365 there's nothing that has to be done.  If at 
> some point in the future a potential rfc8365bis wants to make use of 
> the Tunnel Encapsulation Attribute then it may want to consider 
> Appendix A. 
> 
> 
> This document is Obsoleting 2 documents.  Yes, I know the header says 
> 3, but -21 should have also pointed at an Update (not Obsolete) for 
> rfc5640. 
> 
> This document replaces rfc5512, so there's no work left unaddressed there. 
> 
> As far as rfc5566, the WG had checked on implementations and/or 
> interest in updating it along with this document, but the Chairs came 
> up empty: no current interest or implementations.  There is however 
> other work that is "replacing" the IPsec functionality described in 
> rfc5566 (but independent of it): 
> draft-dunbar-idr-sdwan-edge-discovery, 
> draft-sajassi-besss-secure-evpn, and draft-hujun-idr-bgp-ipsec.