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

Alvaro Retana <> Thu, 17 September 2020 22:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71A5B3A0D43; Thu, 17 Sep 2020 15:18:02 -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, 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 6ebcRfon8XCR; Thu, 17 Sep 2020 15:18:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD9433A0D3D; Thu, 17 Sep 2020 15:18:00 -0700 (PDT)
Received: by with SMTP id z23so5343858ejr.13; Thu, 17 Sep 2020 15:18:00 -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=PVNwv5wu3vvpdmN2x1u+vZ/Ye8Nbkzfs3THDaP6s658=; b=lnpIsppM5lcXB0LMGGpBEgRnI26CNmTyc8+ZtI5Gl7/RfCJXFYcIj8o3OOZEbc5+fT s2rg4YcO7OkbbwqXTSyUvQ+OkZK+BbPD9p8gopaoVULAfLxwZiGOdfix8LTg1TYc0BPY QTI8GGRxd69Q3iJVRVAPuY/vRYW7MMt5FGQQ58ooUajZzuXGygFyvTDBraK63Fkwsw9b uUcsgkR8J1RjeVnhbapBlEIW/k5m00SgawYjaSaFM9uunZys6c5SD3DbwewPND8gqh4O 5uBI8Z0U0ivZl9OKvNCkHmmqnLNTGRnDR6O1ZxVZaqKK8a+cFMLxkdoT9jVm9ui7N1jI 4Zqg==
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=PVNwv5wu3vvpdmN2x1u+vZ/Ye8Nbkzfs3THDaP6s658=; b=czqb37uYZb/YqJWjeyONkqBPK7TruRol3D01RiBk+k+9Q8y8C1ZUFpLKRGO4UjVOzz IefQyCeCh9jClvb7IO4clJ34X3lJEgsL3yrVMqjJwPSTeBosfNvf7kWThgTdLzId+Qia dxWcTfpBr6PWA4LcR2taJWnEGVFGz1EBS/y2KAHS9a5O79AMzoSN6zfwCnaVQpq/gmZK ZAKrUHVzmX/Pft+ufywgLVgvi6YbvA7cs8QLoYRc894CN7WaaLOPYinid3ZvOz+U8oHM 2KE8Ea+tL2UYaymsOjyJObqDsoPj7Nwq0Jt3kb5Cek95yrMMipMvEaIUpQo/Dp+WYFwK YmHQ==
X-Gm-Message-State: AOAM530yOMvDjfcVpiH6/GcS8DQ7RUXicP87ddxzi319wIMqd/iuhoYu X/tL4IZQiHC1TJxsBKh4QqQEw2n8/M3sOW8vjAs=
X-Google-Smtp-Source: ABdhPJzrmXmUlfBkyE5G9EeYxr6XSEv95/hylcIpuYvFUhuCxYEQ64AYeKcmgZMQ4ddTbLIzp99w9papT1iAMiySX5U=
X-Received: by 2002:a17:906:4819:: with SMTP id w25mr32722271ejq.300.1600381079181; Thu, 17 Sep 2020 15:17:59 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 17 Sep 2020 15:17:58 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <>
MIME-Version: 1.0
Date: Thu, 17 Sep 2020 15:17:58 -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: Thu, 17 Sep 2020 22:18:03 -0000

On September 11, 2020 at 11:25:31 AM, John Scudder wrote:



Just a couple of comments...  Just one actionable change related to
the reachability issue: you're right, we should move on.



> > ...
> >> We added 5566 and 5640 to the list of obsoleted RFCs, along with an
> >> explanation.
> >
> > [major] The IANA assignments made for those RFCs need to be declared
> > obsolete in the IANA Considerations section.
> Is “obsolete” an IANA thing? I’ve added a subsection to the IANA section as
> requested, but asked them to mark the code points as “deprecated”.

Yes, "obsolete" is an IANA thing. rfc8126: "Specific entries in a
registry can be marked as "obsolete" (no longer in use) or
"deprecated" (use is not recommended)."

You used both terms in §13.1 to refer to the code points.  You're
right, deprecating is the right action, but IANA may be confused by
the use of both.  This is a minor point, so we can wait for them to
ask about it. :-)

> >>> 1054 4.2. Router's MAC Extended Community
> >
> > [] We've been talking about this section in a separate message...
> OK. To loop the WG in on the conclusion of that, it appears that
> draft-ietf-bess-evpn-inter-subnet-forwarding only allows a single Router’s
> MAC (authors have been asked to clarify) so assuming that’s right, we must
> pick one or the other if it’s encoded twice in two ways with different
> values. In -18 I’ve changed the text to say “use the EC” instead of the
> former “use the sub-TLV”.


I have a DISCUSS on draft-ietf-bess-evpn-inter-subnet-forwarding
precisely due to the lack of sync with this document.  I hope that the
authors provide an answer and align with the changes here.

> >>> 1080 5. Semantics and Usage of the Tunnel Encapsulation attribute

> All of this is true. Basically, we can either hang progress of this
> document up for a potentially long time waiting for something that may
> never come: a detailed specification of exactly when a route is, and isn’t,
> resolvable, or we can admit it’s an imperfect world and move forward. I
> will observe that despite 4271’s lack of prescriptiveness, somehow we have
> many interoperable implementations of BGP. I suspect this is because when
> an implementor looks at route resolution, it’s a little like Justice Potter
> Stewart looking at other material: “[I can’t define it but] I know it when
> I see it.”
> I tried to make the paragraph clearer by adding a final clause. The last
> sentence now reads, "The reachability condition is evaluated as per
> [RFC4271], but the essence is that if the router could forward a packet
> addressed to the IP address, the IP address is "reachable”.” We could
> absolutely pick this short summary to shreds if we chose — see above. It’s
> not meant to be prescriptive, only descriptive.


Let's go with an "intermediate" approach, so that we don't try to say
too much, but (hopefully) say enough:

   *  The tunnel is specified in a TLV whose Tunnel Egress Endpoint sub-TLV
      identifies an IP address that is reachable.  The reachability condition
      is evaluated as per [RFC4271].  If the IP address is reachable via
      more than one forwarding table, local policy is used to determine
      which table to use.