[bess] Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00

Jeffrey Haas <jhaas@pfrc.org> Mon, 24 June 2024 13:40 UTC

Return-Path: <jhaas@pfrc.org>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A512C151093; Mon, 24 Jun 2024 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSt66pBI_AYF; Mon, 24 Jun 2024 06:40:54 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 34B99C151071; Mon, 24 Jun 2024 06:40:52 -0700 (PDT)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id AE40E1E039; Mon, 24 Jun 2024 09:40:51 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A43ED656-FDF1-4960-BCB1-7DA33939AFA0"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <SA1PR08MB72156E91C0567D85031C5895F7D42@SA1PR08MB7215.namprd08.prod.outlook.com>
Date: Mon, 24 Jun 2024 09:40:51 -0400
Message-Id: <6DC6F763-4931-4C87-B0E6-941884DBD05F@pfrc.org>
References: <171206184624.18356.7891001527073621519@ietfa.amsl.com> <20240425145537.GA12879@pfrc.org> <SA1PR08MB721526C32B8FDC49EFF57C13F7CE2@SA1PR08MB7215.namprd08.prod.outlook.com> <20240623162307.GB21586@pfrc.org> <SA1PR08MB72156E91C0567D85031C5895F7D42@SA1PR08MB7215.namprd08.prod.outlook.com>
To: "Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com>
X-Mailer: Apple Mail (2.3696.120.41.1.8)
Message-ID-Hash: QPNTOFQT2VAAZ24LCYZF2UX2DQED2KWT
X-Message-ID-Hash: QPNTOFQT2VAAZ24LCYZF2UX2DQED2KWT
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "draft-ietf-bess-evpn-dpath@ietf.org" <draft-ietf-bess-evpn-dpath@ietf.org>, "bess@ietf.org" <bess@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [bess] Re: Questions about route selection in draft-ietf-bess-evpn-dpath-00
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/yDNd-ZtjW7mYRPnJQw6RMZNZ6rA>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Jorge,


> On Jun 24, 2024, at 8:04 AM, Jorge Rabadan (Nokia) <jorge.rabadan@nokia.com> wrote:
>> I understand that for this D-PATH feature that the providers should be
>> "mutually cooperating" and thus this may be a trivial or even silly concern.
>> But if it ever becomes competing providers, this becomes a conversation
>> about money.
>>  
> [jorge] ok, I think ask the chairs for 5 minutes at IETF120 to discuss this and bring awareness. For the moment we can leave it as is, since there are implementations doing this. Thanks for the discussion.

I'll try to be available for that discussion.  However, as usual, bess has conflicts with other work of interest for me.

>> It'd be helpful if you did.  I'm glad I came to the appropriate conclusion
>> as a semi-informed reader, but for these sorts of steps having the algorithm
>> explicitly written out can remove doubt.
> 
> [jorge] hopefully the text makes it better now:
>  
> “Then routes with the numerically lowest left-most Domain-ID are preferred (only the Domain-ID is compared, and not the ISF_SAFI_TYPE). Hence, routes not tied for the numerically lowest left-most Domain-ID are removed from consideration. When comparing two Domain-IDs, the two six byte values are compared starting with the Global Admin field. The lowest value in the first differing byte between the two six byte values, is considered to belong to the "numerically lowest Domain-ID"”

This works.

>> Some explicit text would be appreciated.  While escape isn't expected, we're
>> partially having some of this review because escape has been observed from
>> existing implementations.
> 
> [jorge] OK, added some text in the security considerations section, and also in section 4. We can always improve it at a later version.

Part of the additional text you've added is this:
"As an additional security mechanism, a PE following this specification that receives an EVPN route from a non-upgraded PE should discard the route via policy if the route contains the D-PATH attribute."

How do you tell if the PE is "non-upgraded"?

Note that such considerations were part of the reason I urged the dpath authors towards a BGP capability. :-)

-- Jeff