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

[Alvaro Retana <[e-mail]>]

On May 4, 2020 at 4:50:36 PM, John Scudder wrote:


John:

Hi!


> > On Feb 21, 2020, at 7:47 AM, Alvaro Retana 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?

Yes, I think so.


> 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.


This is the comment I wrote related to the §11 text:

   [major] "...one exception...a BGP UPDATE whose AFI/SAFI is...listed
   in...Section 5, if a TLV contains a malformed Tunnel Endpoint
   sub-TLV...the entire TLV MUST be ignored, and MUST be removed from the
   Tunnel Encapsulation attribute"   So...the "exception" applies to all the
   currently supported AFI/SAFIs...  If no other AFI/SAFIs are specified at
   this time, why is this "exception" not the norm?


ISTM that §3.1 says the same thing as the "exception" in §11: remove
the TLV.   But the general part of §11 is saying treat as
unrecognized.



> 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?)

I think we should remove the text in §3.1 because (at best) it is redundant.

The text in §11 needs to be clarified.

I think that's closer to #1...but it all depends on what is the
expected behavior: the one specified as normal, or the exception.


Alvaro.