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

Alvaro Retana <> Fri, 15 May 2020 18:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 569F73A00C0; Fri, 15 May 2020 11:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PnphzXBcOmCs; Fri, 15 May 2020 11:28:59 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EC59B3A08B5; Fri, 15 May 2020 11:28:45 -0700 (PDT)
Received: by with SMTP id w7so4573645wre.13; Fri, 15 May 2020 11:28:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=fURNPfz5dSspadgZeDEWNKFKL4s0M6vfKjusRo3QUyo=; b=fFNNSp4DOwsNGIfa7jzK/v59TfFIq3XQcorl1k/tqfMFrMqKJTswo4u++TAQpzxCZ1 an3hNUL3LZMYD4BVIFYqA87es4EN/Ld0H6Evd7HVfiPxbt/RbV1oOb7+TjouZGPZDWs0 9LiP6UrjoXtM51/Q6Om+yGPCjsjIH7QnfIxQ9iKAAIDc5YIiI6cpzzG3YrQ4prKWCEx4 0JVEKYBxO9gBgCxiR1gyaiFwVTVTt+Y/4bXbZXyKTkrXpodUY7Ska4JF+QWQUkRo2WWi rZrF8T29jQSfumLOBVabkPo406/5GMnLIo4T8p/y7FmVwyWzWwlUdsNP7BbDCgzqXp/3 gmUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=fURNPfz5dSspadgZeDEWNKFKL4s0M6vfKjusRo3QUyo=; b=O3071BAbUL/7sWKFZ/kbj9T/9ZnjzNey8fwNf7hqNR9co36lXlLuYlwE5k09NdWuv/ tUFYdpYmZttXgtEJDvOuU9k43BQyfQU6IPUM/bs+Y2gah0Ic0jgal7yrjbqCOvlmJO+K J3aL9wzomEV13K07IMseywBs4g49KWPBg88ZfLJHj4ueSVZC8hPb1q22DmRKyysMcwZI U+x9POQ+/GGIK/DBOOCxYwTevequeQjpBtnC4aURkQxqf09Z5tPh332jWGdCzv93eRDP NTq/N5ECy7/qcA1wAn+Xo6NI36m8oY69iann6sSQUp2SLZmiqkjRvIlvj8s5ffr4Arn3 3TcQ==
X-Gm-Message-State: AOAM5316nuKmsjsnVpZa1YxFMeQKW9AupeLbVCGLYShTyOVRjfJm/O44 M0EO+PX5LxZNHNM+rPskLKL0IQg7O2pXMicBIWI=
X-Google-Smtp-Source: ABdhPJyuK+ARF6xPSDJP3HqTbMaGFmDAqoYyUA5F8YU1yaLb92zvZ1t0T0rnuHheVH5CTt1POvrRzVyZ0GFdXxrZZnE=
X-Received: by 2002:a5d:6943:: with SMTP id r3mr5476773wrw.113.1589567324342; Fri, 15 May 2020 11:28:44 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 15 May 2020 11:28:43 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Fri, 15 May 2020 11:28:43 -0700
Message-ID: <>
To: John Scudder <>
Cc: "" <>, "idr@ietf. org" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Fri, 15 May 2020 18:29:01 -0000

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



> > 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] " 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

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