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

Robert Raszuk <> Tue, 06 July 2021 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A4F4A3A30E3 for <>; Tue, 6 Jul 2021 11:32:46 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 vLFRrNRyGUME for <>; Tue, 6 Jul 2021 11:32:42 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC1C13A30E1 for <>; Tue, 6 Jul 2021 11:32:41 -0700 (PDT)
Received: by with SMTP id t17so40027286lfq.0 for <>; Tue, 06 Jul 2021 11:32:41 -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=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;; 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: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Tue, 6 Jul 2021 20:32:29 +0200
Message-ID: <>
To: Kaliraj Vairavakkalai <>
Cc: Minto Jeyananth <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="00000000000074eee805c678a579"
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-kaliraj-idr-multinexthop-attribute-01.txt
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: 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

>    - 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

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

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