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

Robert Raszuk <robert@raszuk.net> Thu, 17 October 2019 07:47 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA5A120855 for <idr@ietfa.amsl.com>; Thu, 17 Oct 2019 00:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcYzpRXss9rM for <idr@ietfa.amsl.com>; Thu, 17 Oct 2019 00:47:23 -0700 (PDT)
Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CC9120865 for <idr@ietf.org>; Thu, 17 Oct 2019 00:47:23 -0700 (PDT)
Received: by mail-qk1-x732.google.com with SMTP id e66so978909qkf.13 for <idr@ietf.org>; Thu, 17 Oct 2019 00:47:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rSPomjMAWYsMGuJk81lO1Gp4GVtwhz7thwngmq/bGPk=; b=ZBmuvdUtoLGFf0pw9GmIavT01Ry7mysWZ0rRM6zvPQ6neSYobIdu7c9DCp+7UFlsDs 17s5huhqvx70m4OtIM248vzEljtH+jZi3XJZF17fpAEp6ziyEFIQzicLUlpdl5a6uYge zy8+JKCxUWuvRH3mz91mMxmExlCuCPw0YMTa1tInx4bkcc9SAoagw/CyNH13Qxh/wDQS xH7PPeKHxEawfmFakLMQOChEgryZWJIT0X9B853MKl+UfDaW55W6KOhFcsLXmJJOLRdi zr1w3lSlDRwSdZCvXJ7pAUVmAwJYGQvvCKuBAHXYhYfNLeIQzxCrOmzQrxwqzdkW6NB9 Njyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rSPomjMAWYsMGuJk81lO1Gp4GVtwhz7thwngmq/bGPk=; b=j+T53HmTy3dTMlneAKuzV8kmgWcqiw3n9MRAAz4LrHk4BXHf/h79wpuGwFOVGuNi54 acgS33b/XD3PIeD67aFstXpoKc5EwSKAGjXi5ewcmjUZTg7+wTkVmbKMeDVTwYH8UPFw SFRg+Zkbf6BeKT9Myan3oSTvDJzlj6LeBGFsO6ZoySF2serkRTBMrt5euAByejLwZUXq 607Nr2kRtQoXdYrIZyMEymryEwVsZsEOAb/c3xgkR/dQgw6a2lbj/qhhZtKpUHI/PjTj Z/uPhSKx6g+3yCiD5K2wo3BjglFpcm2seW67qZnHEtbVK+Pq59KfzHclasIc8jGlaxKi 9eKg==
X-Gm-Message-State: APjAAAUYWr0HutzBKmCQ+3VWbDEVQWuMDwPGneHBJ/JBR9DECL/6CBlU q66lTFct0UbZk3Bvm0id1udrE+dlkai1/0jmmsrWIoqyFIo=
X-Google-Smtp-Source: APXvYqxJWjY4aJLkcaYdL74cAUT9gb6k4+y60u/Z9m7t1zZdXVpPV8xTJTdT2yFTYtgGDhvbLX3KhpUqizkzQtBsxEM=
X-Received: by 2002:a05:620a:12c6:: with SMTP id e6mr1333865qkl.465.1571298441776; Thu, 17 Oct 2019 00:47:21 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB3582A1E1FE3441CDD54A101985950@MN2PR13MB3582.namprd13.prod.outlook.com> <78F7A474-6F86-4EA3-93A3-001B4E2C2116@juniper.net>
In-Reply-To: <78F7A474-6F86-4EA3-93A3-001B4E2C2116@juniper.net>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 17 Oct 2019 09:47:12 +0200
Message-ID: <CAOj+MMGqKj=zKbws92ni1fL2O-So=dbcW-mb02uRnQ+G55xm_w@mail.gmail.com>
To: Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>
Cc: Linda Dunbar <linda.dunbar@futurewei.com>, "idr@ietf.org" <idr@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Content-Type: multipart/related; boundary="000000000000758ba00595166d12"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KYREL9K_ahREdCpVIOpuP4owqVc>
Subject: Re: [Idr] Can one Destination Address appear in both Tunnel Encap Attribute and in MP_REACH_NLRI ?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 07:47:35 -0000

Hey Srihari,

> The presence of Tunnel Encapsulation attribute in an update that carries
MP_REACH
> attribute indicates the data path destined for prefixes encoded in the
NLRI field of MP_REACH.

My reading of Linda's point was a question regarding the case where for
prefix A NLRI points to
next hop NH_1 but tunnel endpoint says go to NH_2.

Is such update still valid ?

Has tunnel encapsulation attribute power to "overrule" BGP next hop from
MP_REACH ?

When BGP best path runs and validates NH_1 is basic next hop validation
also performed on
NH_2 before considering this path as valid ?

When BGP selects such path as best and installs it to RIB does it install
it with NH_1 or NH_2 ? Note that both next hops may be reachable via local
IGP or even going further could be recursive via yet more BGP routes.

Many thx,
Robert.


If a Destination address is already listed in the MP_RACH_NLRI, is it
> listed again in the Tunnel Encap subTLV (if it can be reached via some
> tunnel, such as VxLAN/GRE/?
>
>
>
> I’m not clear what you mean here. The MP_REACH provides the reachability
> information while the Tunnel Encapsulation Attribute provides the Tunnel
> details (remote-endpoint, encapsulation, etc). The presence of Tunnel
> Encapsulation attribute in an update that carries MP_REACH attribute
> indicates the data path destined for prefixes encoded in the NLRI field of
> MP_REACH.
>
>
>
> Thanks.
>
> srihari…
>