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

[Susan Hares <[e-mail]>]

<wg-member hat on> 

I like option 3. 

 

Sue 

 

From: Idr [mailto:[e-mail]] On Behalf Of John Scudder
Sent: Monday, May 4, 2020 4:51 PM
To: Alvaro Retana
Cc: [e-mail]; [e-mail]; idr@ietf. org
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15

 

Hi Alvaro,





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