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

[Alvaro Retana <[e-mail]>]

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.