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

Robert Raszuk <robert@raszuk.net> Sat, 03 July 2021 11:28 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 F41A63A0D03 for <idr@ietfa.amsl.com>; Sat, 3 Jul 2021 04:28:10 -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 UVqpP47kQjsp for <idr@ietfa.amsl.com>; Sat, 3 Jul 2021 04:28:05 -0700 (PDT)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 72C8F3A0D02 for <idr@ietf.org>; Sat, 3 Jul 2021 04:28:05 -0700 (PDT)
Received: by mail-lf1-x12d.google.com with SMTP id bu19so23164430lfb.9 for <idr@ietf.org>; Sat, 03 Jul 2021 04:28:05 -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=v2FW++HwihfJ1EdhXHkZc9zlTmngr0OgBAsGYbbw1pU=; b=af/rDwTNdw6QXAtz8LiXYoqo12w4/HmS/0SGGceqpsdEjV6Q0vXQnkiRINIUeyyu9G B7jNUMqGT+3W0a3FIx8YRZAkEpHu1rFsRAmrDpBpXYtnOQkFbVufMOnCJzrH423YVLXR UmiB9Vzo6rsqTvgN1B8X3EeQoEmDTBTp4QNKYIw3j+Wj3VAoUMnI68jCbkcdZmSsikDp Sb/81bSUgkGdFAWOnnrjoDx2iNEKjs2xSUAzaQERRgRWo9gC5nHv1d8Kcw4X5C4/qCXE 7cXyKHIs7o23mjKp/NRjh7PvDnCSaFld5T7ysjXDDyCTyFTaDqoYkHdcFthVxLaCyPSQ 2cqg==
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=v2FW++HwihfJ1EdhXHkZc9zlTmngr0OgBAsGYbbw1pU=; b=Kh7DoT/m1xp8aRqcz6kGHg7aszewJZkDlL2zn3CJv/A0YYPjAhujCnGlbTl9zfXbOO wIGJlKlpP/ht5L4vMj3aDadjDgZeYJHH8ctqA3HTE3bXSDkBY1is14fQ+S1y+ZsczHxr qdNhTzMIVtLwP7vR85ilC6rCkxhw9u+RouXNkQFT49wvIepcVHeeHsCmp+0SxKzy6MgG an8vlnEoz/1o6GslLEauK5cHvEx+bnz9LUlR1+Qt7HE9OUg3igvQEW1ramNY6c5/OfcO hSYIKm0qzXOH+846N0r8lOGvRNgKPRD1v+znbSTULPcbbijSJqV0vUDP15IeQBvZ9sH8 HNWA==
X-Gm-Message-State: AOAM532mMF/WnFLRFshpOjU8Rd1FA9JHyPTNN/PVf9Sc4/rufOBoITzq 4POZR+4iJbgQpcxjyLJg/j2X6uLHcdvfsXbxPboevQ==
X-Google-Smtp-Source: ABdhPJz8YE6JkSFDWiy5RB9IXqFapWM3SNJbqKZ21GuhspGWpdU3+a+sTkKYpnC3So37Jn5Xsc4pteW5lluD1o2evHo=
X-Received: by 2002:ac2:5feb:: with SMTP id s11mr3181176lfg.591.1625311678331; Sat, 03 Jul 2021 04:27:58 -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>
In-Reply-To: <MN2PR05MB65117FDA62543A0A3A75B165A21E9@MN2PR05MB6511.namprd05.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 3 Jul 2021 13:27:47 +0200
Message-ID: <CAOj+MMFV=3xVzdr0M9VM+u2N_PYuOE0Q_t+2y1zoZdEYmhTS2w@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="0000000000003c8d8b05c6365d9d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VQO897VoHfKvdendYMHn626CcWM>
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: Sat, 03 Jul 2021 11:28:11 -0000

Hi,

Few follow up points ...

KV>  All resolved(reachable) legs of the MNH will be installed to FIB.
>

That is huge change BGP <--> RIB interaction. Note today unless you install
more next hops *only* if multipath is enabled.

Besides you can safely do it only when network is doing encapsulation end
to end. If you are doing hop by hop lookup and you do not even know if all
nodes support MNH loops can form.

KV> Let us say the max-num-ECMP supported by a router is 16. Then it will
> install the first 16 nexthops (as per the ‘Relative-preference’ field)
> received in the MNH. It will not install all the nexthops. So the same
> existing ecmp-limit safeguards can be
>

Nope that was not the point ... I am talking about control plane RAM when
the attacker is using MNH attribute fill to the top of the UPDATE MSG SIZE
to kill your box regardless if this will get down to RIB or FIB.

Today prefix limit saves you from this type of attacks. When one deployed
MNH with the peers it opens up his network ... I would love to see this
type of threat discussed in security section.


> used. The only difference is how the nexthops are received. Instead being
> received in 100 routes, it is received in 1 route.
>

Nope ... peers today sends you the single path as best unless you allow him
to do add-paths all.

KV> they could potentially get called-back when effective-igp-cost of the
> route changes. Pls note, this proposal does not increase number of unique
> PNHs in the system/network, for e.g. that is a function of how many PEs
> exist in the network. Just what changes is how those PNHs are conveyed in
> bgp-updates as ecmp/pic nexthops for a bgp-prefix. Number of routes
> required to convey that relationship is greatly reduced, while providing
> more control to the advertiser on signaling the ecmp/pic relationships.
>

If you allow this for EBGP you are changing the BGP game completely.
Especially if you allow this for SAFI 1.

- - -

Btw ... who would build this MNH attribute ? ASBR/PE if not doing next hop
self ?

Can it be build say in transit RR from paths received via add-paths from
PEs ?

If you talking labels ... considering each VPNv4/v6 route has a unique per
VRF RD such MNH would be not very useful anyway.

If not I am not sure what is the big gain here. Yes it could be done (with
lots of work) but I am a bit missing the need for it considering that you
can get the required functionality today already.

Is there anything it actually brings to the table other then ton of
implementation and new operational issues ?

Thx,
R.