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

Robert Raszuk <> Sat, 03 July 2021 19:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBA363A220E for <>; Sat, 3 Jul 2021 12:46:13 -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 b0esSCCkeseu for <>; Sat, 3 Jul 2021 12:46:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FB3D3A220D for <>; Sat, 3 Jul 2021 12:46:08 -0700 (PDT)
Received: by with SMTP id u25so18472858ljj.11 for <>; Sat, 03 Jul 2021 12:46:08 -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=vEUIMGXJBcmAJP5qxy0etakSEuCuOakuAmGJR8bd4cE=; b=b2OvtqSlF4N4ma3XQVLm90oX85X/weUO9gLX0XcIScYgZnNGGVazNWio/tISX2JKPe bJKRlGT7wj4OucFgXI4NAzave3AxxAlJ9/g0n/E0UvdyixOZNd207gnZ0mSxrykv1e+F MgHJKa9cr6vRkGCCNT0lfFPaQFOirB6h/MgAhVKTaor5hOcbtEuwE2irM/enZl7Jh+mH hpQKZfwALCvZK30gljs/88NMRljbnAdxQvHuV2tFqs5Q358M6cD2NUKrRMqijZ4HxkNc 2iJhDoTVulYfGriC83v8oZN53EKXyKnReo0A3gvmyIleX40WcCVQorSRRpzhHP+uyGiC FQpA==
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=vEUIMGXJBcmAJP5qxy0etakSEuCuOakuAmGJR8bd4cE=; b=V5+czGOSpgpN3uXoXfP/wcl/T8GLHRn+0iTRoss1J9OfHEtS01USA4bdvv3FI91P5g DaA3W0u458w1ip7K3q9JypAbmdk9s3eAcabzd+wzlcMft7+DXfZpdvu/3YcuqB/35XfZ d00/Jzx1Zrimau0P86x+TVRrWP0hXMT+irJbuB6QraZh5gxOuFgJxmb1ydBaSeClNsGx JL80zDKOwFgTrN92WkcmhVF7+Q2O/nGWTUbWlwawYGkxjGqIaTQqXRTCETXj04kKmn9N t9m1CtN3EW8JugjzDJ31vU/RGv/Lrjc46f4eej8ELTDUKZZJjQlG/NOUK8N6ACHXEFhI Xfmg==
X-Gm-Message-State: AOAM530Q9DCMd6YuWoDVHoRjJOEw7bsvlmlvDFDkQwAFx7Y4LMhEndcN 9HrzTyVBs+zX2qMqZfXYfn6XETW34JfSs6FC+RfTJA==
X-Google-Smtp-Source: ABdhPJxt24XkLx54fTrQEQjb7YnJu2yekUHp2EsYtNqV95C5pDHxzBTSARENKdhN+UjeVLNa5g2GFy356KeTD4WzfXk=
X-Received: by 2002:a2e:2283:: with SMTP id i125mr4504999lji.37.1625341566788; Sat, 03 Jul 2021 12:46:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Sat, 3 Jul 2021 21:45:56 +0200
Message-ID: <>
To: Kaliraj Vairavakkalai <>
Cc: Minto Jeyananth <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000ba374f05c63d52a3"
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: Sat, 03 Jul 2021 19:46:14 -0000


> KV2> EBGP is not discounted. One simple example where this can be useful
for EBGP
> is the inter-AS parallel-links case. Even when using one bgp-session
between loopbacks
> over the parallel-links, the MNH can be used to specify how the
load-balancing should
> happen on the parallel links.

And how would you detect liveness of all of those parallel links ? Static +

What's wrong with today's solution of using loopback for next hop +
disable-connected-check knob and point static routes to resolve such next
hop over parallel links ? Sure you can use more then one loopback here as
well and that loopback is only significant locally over EBGP boundary.

KV2> there are some scenarios where it could be. The PE sends the RD:Pfx
> with MNH(IngressIP1, IngressIP2) thus attracting traffic to the
> more-optimal ingress-Forwarding-elements. Avoiding intra-fabric hops. The
> mechanism was invented to solve such a scenario only.

IMO this use case is a pretty bad idea. 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. It almost smells like some solution to fix platform
deficiency in deployments of BGP as an IGP.