Re: [Idr] I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt

Robert Raszuk <robert@raszuk.net> Tue, 06 July 2021 18:32 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 A4F4A3A30E3 for <idr@ietfa.amsl.com>; Tue, 6 Jul 2021 11:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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, HTML_MESSAGE=0.001, 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 vLFRrNRyGUME for <idr@ietfa.amsl.com>; Tue, 6 Jul 2021 11:32:42 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 AC1C13A30E1 for <idr@ietf.org>; Tue, 6 Jul 2021 11:32:41 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id t17so40027286lfq.0 for <idr@ietf.org>; Tue, 06 Jul 2021 11:32:41 -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=p6xyPmYYdut5IzaqiBk+crBRkGBnAbIWWDoyYDenlp0=; b=aGoSuV2F+cy1rTlzwbBGxCAyas3nrfkjgbAoYnHwOR07QSO4xnIBXjMyrRdV2Pny1Z igtpQLYrRu8ZFcPH8rVP4Xq2maFeGHztO3eqgZPL7tKVYjKqlJSPVUd4s7yBmkSlRECR PUOQBDGFIpBYZIQPNeMI//nG9dA23etapHaK9/t7HT+fUX2sXDzsoFN8t8uq4XWIz707 sQOxJXBsgkyPcGjHDFBRqOuAaqUbfI8nDhqtaHGcFQZLGeUScGNCrxrv13ZOeUnW0piW Vu7Bis88nWatQ7LP0lLWfJ7wvQ67XmkvqxUgsGvUXIJH+n5BaWz0L4bM8VMn5yfrvxSd sUog==
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=p6xyPmYYdut5IzaqiBk+crBRkGBnAbIWWDoyYDenlp0=; b=fnqj9CHA3HAzLHP0qb3VGQ4vzyx9Czyb0kDYprWXEWbRtPiOsONer1v4dzxe7P/2r/ fe54zcizcc3Th/7vaESa2JGBWFq/YBCzDXh7XCRnAAysr4OElj4wcUqEZzNi88E+mvRI ZcHcF9K9f+1SfJy4t+Pvts9BMOvmP8wE+TBWGqa/1kxo08LdfY7aN5Q00TMwt1WqgIDL TaII4Ate5uiT6bleM8cc4zBkgMQKvQLhjhy/EAjTqskNyH5Kiy5S5SjPFCLcu7MmxLPR 3PDScvbxiAaXmx2riD3KcIz6Bmr/PLT8YetNOLY0CQHIH4AQlrLRE6cUNYl47dh9nRCL 0log==
X-Gm-Message-State: AOAM531/W9yeZhXRdmGfIQvO1e9q8/3c4M9DEIvsAOU3qulQi3oQOzGa +I5xB9SBWxeQjLgwmQc6Nq4LmKGcpiv1B7N5ALvC2g==
X-Google-Smtp-Source: ABdhPJznDsYJV2HTcEzBASmkljaEQYckH2ZaKLlYtn27iZaL/9GIKhNrptY0h/eCKG3pHKWDhtb7kc0gba1LWtC/Fh0=
X-Received: by 2002:a19:700c:: with SMTP id h12mr16302432lfc.541.1625596357824; Tue, 06 Jul 2021 11:32:37 -0700 (PDT)
MIME-Version: 1.0
References: <162340175034.6148.8928864955067799770@ietfa.amsl.com> <CAOj+MMEG6vx7zAJcLAgyuXGPcuvuus=PU48aANJ93VKTLeV9dA@mail.gmail.com> <MN2PR05MB65117FDA62543A0A3A75B165A21E9@MN2PR05MB6511.namprd05.prod.outlook.com> <CAOj+MMFV=3xVzdr0M9VM+u2N_PYuOE0Q_t+2y1zoZdEYmhTS2w@mail.gmail.com> <MN2PR05MB65113F8B521421AE2E4829DFA21E9@MN2PR05MB6511.namprd05.prod.outlook.com> <CAOj+MMHngcqSX-HrrbShPXHHUxLx7S4M+iuQhJ7_tsNrPkgKeg@mail.gmail.com> <DM6PR05MB6505E2185EEA0BA806FFF901A21D9@DM6PR05MB6505.namprd05.prod.outlook.com>
In-Reply-To: <DM6PR05MB6505E2185EEA0BA806FFF901A21D9@DM6PR05MB6505.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 06 Jul 2021 20:32:29 +0200
Message-ID: <CAOj+MMGurrz=tKc57QW6H_VmDtuyuer9gSGyMHkU=z8MMT8dKA@mail.gmail.com>
To: Kaliraj Vairavakkalai <kaliraj@juniper.net>
Cc: Minto Jeyananth <minto@juniper.net>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000074eee805c678a579"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/jLR_FzMfRLlscApQtJIFrVcI4rY>
Subject: Re: [Idr] I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt
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: Tue, 06 Jul 2021 18:32:47 -0000

> BFD to the BGP nexthop elements. (instead of the bgp-peer address).
>

Is there any BFD draft describing this ?

it model A), the RIB-size is increased N times, where N is the number of
> parallel links. With N=4 or 8 this may be tolerable today. But when N goes
> higher 128, 512, this model is un-manageable.
>

Few emails back you said: "KV> Let us say the max-num-ECMP supported by a
router is 16." Now you are bringing a case where we have 512 ECMP paths
.... Is this realistic deployment where anyone including DC fabric would
connect a pair of routers with 512 parallel links for ECMP ???

So we need to go ebgp-multihop between the loopbacks (model B). But then we
> need an intermediate static route to a) provide connectivity and b) to
> resolve the BGP PNH over. And in that scenario, following problems exist
> for the “nexthop resolution (b) part”:
>
>
>
>    - Different service-routes cannot take different set of
>    parallel-links. This would have been possible earlier in model-A.
>
> No it is possible in model B. Just use few groups each with different
loopback.


>    - All service-routes need to share the same load-balancing treatment
>    that is given to the static-route to the lo0. IOW, the per-service route
>    different WECMP treatment that was earlier possible with model-A can no
>    longer be guaranteed.
>
> It is possible in model B. Just use few groups each with different
loopback.

2> When such interface IngressIP1 or IP2 goes down you need to repair the
> encapsulation all the way in the edge instead of just performing local
> repair to get to the same loopback in milliseconds.
>
>
>
> No. The repair happens at the nearest BN called the Forwarding-Helper. So
> the repair happens in sub-second. And actually this is orthogonal to
> whether we use IngressIP or lo0. In this case the IngressIP used as PNH are
> not visible outside this region at-all. So there is no way a convergence
> event propagates until the other edge-PE. The BN does a label-swap to the
> ingressIP to make forwarding happen. So it absorbs any failure event within
> this region.
>

I am talking about single flat IGP - single global region. We have two LSPs
one to IP1 and another to IP2. For simplicity assume no VPNs - just IPvX
routing over say MPLS.

So IP1 interface goes down.

How can any P node (not even running BGP) just swap labels from the one
going to IP1 to go to IP2 ? Based on what source of information ?

To conclude - In my view this draft requires few clearly spelled out  use
case(s).

In general the proposed encoding can be done. But IMO the cost exceeds the
practical benefit.

Thx,
R.