Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?

Robert Raszuk <> Fri, 18 October 2019 09:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC55A120895 for <>; Fri, 18 Oct 2019 02:00:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nz02yk477GKV for <>; Fri, 18 Oct 2019 02:00:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC60912018D for <>; Fri, 18 Oct 2019 02:00:42 -0700 (PDT)
Received: by with SMTP id o49so194684qta.7 for <>; Fri, 18 Oct 2019 02:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=27ymMSAjmJMCNCCdwZMfXLJnIAi39XY6T/G2PJmMaNg=; b=SJTEtFa+Vjar7IRmFl5G/DdVTVhwzPQxD8lif0M0XYXPFzUXDmle2XZnCiH4R4qpEG xGdpjqYLu3Es02m9WOfWoCjYfNQCGSupFjJ73pWHN8FIMt39+XLZ8m0id3WjOuyrBEMP noBdic5JEfz7oY+xKqKpU27XWEyhGylnyklXJByhPs5X+P3cnVtrVUM6onkYVHWCniN7 gGKcnRTEivMjOHALO6bX2KjthV8VOpTaHPuNBzWyK1KEQrTLFPpXXRedfceuSSjiQPKL Jyj8Q+jHH5zxERND3MhXjM/7HGkL8OVo62SNrPT4Q+GTJgbFr75uzY42guGW5UWHbpCq Lfdg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=27ymMSAjmJMCNCCdwZMfXLJnIAi39XY6T/G2PJmMaNg=; b=bc0juyRU8psZ+tmuO+sRDxEjlaCaPy8ODn/RBZe/ORKaXMIr4nOEsf5BcKZObws59h VTKQZAyoPKwx0jVS42SNdxUMlT9PI9ENenoDX7jbSn4btIAg4B0uiogkwkoThf46NjjF pY+iq4fG1IKOlUoysIcZwPu9X7eWlKN4FscUvU1Kp5545mO8FrJEASkFlcFN7cU5MRrk gX9BBwinQeF7czX1IoH0y5fQrqgF9LloWwbG/EXHi2yNJ/zqomL6jWhiCEofjTFGzEyO 7D96/VJchmCrbqknKQMGjax0j/MQDnMwWTrDCpzj1omvByWR2PRQa3L03bRhP1XctnFa urIw==
X-Gm-Message-State: APjAAAV0h2XPxesZhLoVI8eycwBrRNaCUbBR17CfkXWgj4/qjw7jztY4 hSOhstLpjuZJnaqRTQoOgQ2xssOi3do8nLF5PUbhQQ==
X-Google-Smtp-Source: APXvYqxLagtOVFMuegtIuXsy7DyMDjXGduPlNq/mf85bQ+TlKEMkOnW5HFyNHUj5Cy/AC2olGneRocnmjVEdq6xEth0=
X-Received: by 2002:a0c:94af:: with SMTP id j44mr8457030qvj.230.1571389241700; Fri, 18 Oct 2019 02:00:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 18 Oct 2019 11:00:33 +0200
Message-ID: <>
To: Keyur Patel <>
Cc: "Rajiv Asati (rajiva)" <>, Ondrej Zajicek <>, "" <>, Linda Dunbar <>, Srihari Sangli <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000008e494b05952b91c8"
Archived-At: <>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
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, 18 Oct 2019 09:00:45 -0000

Hey Keyur,

> Why don't we use basic BGP recursion (in any AFI/SAFI required) and simply
> advertise within each applicable SAFI an NLRI = NH of endpoint/customer
> routes with NH = Tunnel Endpoint while attaching to such
> UPDATE  Encapsulation Extended Community indicating type of tunnels and
> parameters required ?
> #Keyur: You can still announce the tunnel endpoint (underlay) route using
> tunnel endpoint attribute. The attribute gives you a common placeholder to
> carry tunnel parameters (including endpoint) and specifically as and when
> parameters grow beyond size of community/ext community/large community.

Size is a fair point .. while type of the encap will easily fit in
communities some other associated info may not.

But in the case I described there is no need to put tunnel endpoint address
in the tunnel attribute. How about you update the draft and make tunnel
endpoint address TLV optional - and if not present next hop is used as
tunnel endpoint ?

Of course most if not all of other observations still apply :)  And the
point here is that to get consistent implementations draft should add
perhaps even a new paragraph on how to handle difference in next hop
validation vs tunnel endpoint validation. Is in the case of presence of
reachable (or poor man's check existing in the RIB) tunnel endpoint address
BGP next hop validation and tracking still making sense ? Then how to
address similar "collisions" with Origin Validation results ?