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

Susan Hares <> Tue, 05 May 2020 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 844313A044A; Tue, 5 May 2020 07:20:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.224
X-Spam-Level: *
X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id taORHbAGJvDf; Tue, 5 May 2020 07:20:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4EE4E3A046E; Tue, 5 May 2020 07:20:30 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: Susan Hares <>
To: 'John Scudder' <>, 'Alvaro Retana' <>
Cc:,, "'idr@ietf. org'" <>
References: <> <>
In-Reply-To: <>
Date: Tue, 05 May 2020 10:20:25 -0400
Message-ID: <005d01d622e8$525de2d0$f719a870$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01D622C6.CB4C42D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJH7ekTdpypUgfVEnnZV4D7E+BXwwIZdHAcp6UpEgA=
Content-Language: en-us
X-Antivirus: AVG (VPS 200503-0, 05/03/2020), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 May 2020 14:20:37 -0000

<wg-member hat on> 

I like option 3. 




From: Idr [] On Behalf Of John Scudder
Sent: Monday, May 4, 2020 4:51 PM
To: Alvaro Retana
Cc:;; 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 <> wrote:



   When redistributing a route that is carrying a Tunnel Encapsulation

   attribute containing a TLV that itself contains a malformed Tunnel

   Endpoint sub-TLV, the TLV MUST be removed from the attribute before


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