Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

[John Scudder <[e-mail]>]

Hi Alvaro,

On Feb 21, 2020, at 7:47 AM, Alvaro Retana <[e-mail]<mailto:[e-mail]>> wrote:

442    When redistributing a route that is carrying a Tunnel Encapsulation
443    attribute containing a TLV that itself contains a malformed Tunnel
444    Endpoint sub-TLV, the TLV MUST be removed from the attribute before
445    redistribution.

[minor] This paragraph seems to say the same thing as §11, but please
take it out and specify things only once.

You’re referring to this paragraph in section 11?

   In general, if a TLV contains a sub-TLV that is malformed (e.g.,
   contains a length field whose value is not legal for that sub-TLV),
   the sub-TLV should be treated as if it were an unrecognized sub-TLV.
   This document specifies one exception to this rule -- within a tunnel
   encapsulation attribute that is carried by a BGP UPDATE whose AFI/
   SAFI is one of those explicitly listed in the second paragraph of
   Section 5, if a TLV contains a malformed Tunnel Egress Endpoint sub-
   TLV (as defined in Section 3.1), the entire TLV MUST be ignored, and
   MUST be removed from the Tunnel Encapsulation attribute before the
   route carrying that attribute is redistributed.

I’m inclined to agree with you that it covers the same ground. There is one difference, though: the section 11 paragraph is conditioned on the second paragraph of section 5:

   The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
   UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
   Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
   1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
   or 25/70 (Ethernet VPN, usually known as EVPN)).  Use of the Tunnel
   Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
   outside the scope of this document.

So the section 3.1 language you quoted could be considered to mean something just slightly different. Options I can think of include:

- Ditch the section 3.1 language anyway, it’s close enough and besides section 5 says that all other AFI/SAFI are “beyond the scope of this document”.
- Leave the section 3.1 language, because it’s more general.
- Get rid of the condition in the section 11 language. (And also get rid of the 3.1 language.)

I kind of like the third option. Thoughts? (Not just from Alvaro but from the authors and the WG?)

—John