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 10:29 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 912F912088E for <idr@ietfa.amsl.com>; Thu, 17 Oct 2019 03:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=0.001] autolearn=ham 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 BEZTwqXB-dEe for <idr@ietfa.amsl.com>; Thu, 17 Oct 2019 03:29:37 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 9CC801208AB for <idr@ietf.org>; Thu, 17 Oct 2019 03:29:37 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id y189so1363833qkc.3 for <idr@ietf.org>; Thu, 17 Oct 2019 03:29:37 -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=Q//j6Oi8bReJ5AFuQ/Mk6+fxC9Z/ZO3GDlFVo1+I9ew=; b=Hvku2ubw4KjgrQg1Or6dzSEN7hsfa9qfUu4sKbjDWd/o10Ci65lppf/o+NkXAidlX/ 93UDSYLFART7hZXIVWeyCdOcGkFItutuyCjr7bKmt7mHc/UC/R2mxg2k5BnUg4hKcy7I 2fmvDz2SZmXRMjypmEJ/CFBrKp2Hoh3aFJXhX4LIY36Eic2/PFfLzkjVCgdjlJw23V/k /AAqRL45XsnxucBEah9QisBEfX7dbASA/dEG1FpbW0looCfPOtWB2Bjdy410+9rB+dWY MfBpyJLY+bF1CQ5csTuiQnKO+km6n7ygzvs74skUuHJaiGNYE8zogic2PRu5FGeSv5X9 sehA==
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=Q//j6Oi8bReJ5AFuQ/Mk6+fxC9Z/ZO3GDlFVo1+I9ew=; b=P4LVFCrqbws90xLDtmZsp6jY/anNPb7SnFKvvbQWmRKYloxq+l3AUHYDaAJNfhNVLh 7ybnF1s6YbUgHYNI4MW+1u3iCOwtF2EFAc+NfmAjlp4kjYpuP//p2RFraUQ9gj+K6gXV J6FZRjbKQHeApOFhe+4hIIHleJJFYIhHclC3DbL38UUhDxFIyYZScO7HVQf5LC9K6kSp g7H6ZB1bdJskv6H06cJ2pRs3Uhp8p9TgCpb2sSU7btbMr1n2maZobZ4AYr5/40qPXact 5n9/lATrCQlNZ5DWnX1dL+6MekZmG5hei7fKBRGJO+taTrKkOol5KeFGS3dNmltR/FIF jTHQ==
X-Gm-Message-State: APjAAAUklZ4c3VaVPPbk4y3nBOwhPJw8lCDy+A8UeqiwpeiqnMx2FFZq XSWC6zVwxuWLLowemWaYqRvFgYgJcMMos8Qh14MpcA==
X-Google-Smtp-Source: APXvYqyZCc/vfiptJG1Qtd5zjwk6i0hGIHODROAF7f2MKA52YA+KgpJ8EDyx4DlLJRIT2wXML9mcY7AojpS6RepbM/s=
X-Received: by 2002:a05:620a:6bc:: with SMTP id i28mr2490279qkh.219.1571308176601; Thu, 17 Oct 2019 03:29:36 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR13MB3582A1E1FE3441CDD54A101985950@MN2PR13MB3582.namprd13.prod.outlook.com> <78F7A474-6F86-4EA3-93A3-001B4E2C2116@juniper.net> <CAOj+MMGqKj=zKbws92ni1fL2O-So=dbcW-mb02uRnQ+G55xm_w@mail.gmail.com> <0B48E5E7-3A1F-45C0-ACF9-B9A0FA323ED4@juniper.net> <CAOj+MMHs91BoMpgrN2-qtMAgVtiUE_e2bm=BG=+xVnfU9-6Aaw@mail.gmail.com> <20191017093308.GB2427@feanor.crfreenet.org>
In-Reply-To: <20191017093308.GB2427@feanor.crfreenet.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 17 Oct 2019 06:30:54 -0400
Message-ID: <CAOj+MMFs=StpLvK1dZO+ChBUN5i2AYq+CrhHMfMxifpxqegwiw@mail.gmail.com>
To: Ondrej Zajicek <santiago@crfreenet.org>
Cc: Srihari Sangli <ssangli@juniper.net>, "idr@ietf.org" <idr@ietf.org>, Linda Dunbar <linda.dunbar@futurewei.com>, Srihari Sangli <ssangli=40juniper.net@dmarc.ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b308f2059518b172"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4sQdD3wiEUBY1IkWvqQOsyH-np8>
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 10:29:47 -0000

Well indeed the draft is very underspecified in this space.

The fun starts when next hop from NLRI is unreachable while tunnel end
point is. Does it mean that given path is not going to be considered for
best path selection ?

And we can go further ... say bgp uses selective next hops and is set to
only consider /24 and higher and NH from NLRI does not meet those criteria
... but tunnel endpoint is reachable over default route - what happens then
?

See what strikes me the most is the mandatory nature of endpoint TLV and no
good description of various cases when NH in NLRI != Tunnel endpoint
address. If there are equal tunnel endpoint may be optional.

Thx,
R.

On Thu, Oct 17, 2019 at 5:33 AM Ondrej Zajicek <santiago@crfreenet.org>;
wrote:

> On Thu, Oct 17, 2019 at 10:25:13AM +0200, Robert Raszuk wrote:
> > Srihari,
> >
> > Can you comment on the expected BGP next hop validation behaviour ?
> >
> > Can you also comment on the next hop BGP is installing the prefixes to
> RIB
> > with ?
> >
> > Is tunnel endpoint now the NH BGP is asking RIB to track ?
>
> My impression of the draft is that handling of BGP NH and address from
> Tunnel Encap attribute is different. BGP NH is tracked in RIB and
> recursivery resolved, could be used to daisy-chain encapsulation in RIB
> (section 7). In contrast, the address from the Tunnel attribute is just
> passed to FIB as encapsulation action argument.
>
> But it is true that this part of the draft is a bit blurry and would
> definitely need more clear wording.
>
> --
> Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org)
>