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

[Alvaro Retana <[e-mail]>]

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.