[Idr] Re: WG Adoption for draft-ssangli-idr-bgp-generic-metric-00 (7/9 to 7/23/2024)

Robert Raszuk <robert@raszuk.net> Tue, 09 July 2024 16:40 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 AEE7EC17C882 for <idr@ietfa.amsl.com>; Tue, 9 Jul 2024 09:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpNAiJVEyEzZ for <idr@ietfa.amsl.com>; Tue, 9 Jul 2024 09:40:37 -0700 (PDT)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C233C16A126 for <idr@ietf.org>; Tue, 9 Jul 2024 09:40:37 -0700 (PDT)
Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-58b966b4166so6469318a12.1 for <idr@ietf.org>; Tue, 09 Jul 2024 09:40:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; t=1720543235; x=1721148035; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=f7fgoF8AlG8uCiG1DLZsSBJYiM9N7UEMdGptDtPKPeQ=; b=f0DzFc4NcvGnhXywGX+EP4GajCWyaPQfaM/o9N7niwuL+A+0IIE7sSOQvF2wSE4kxM Auycez7M2feaXS8XfnqirTU3BstGc+XmFoGY/jlJatknrBT/LwkyoZGKfn7xmF06vOA7 tBRF3DuKSmbm2yk/0M1q25IahuQW39v1BcDkAfffoDpCxtgvFpjVStQ2ygwZwniwg/SH qgdbDhm2sTvAryz7E2RFN0p867lybzoIiWVMiOy+s/Ia8J5fK9z+A+nkpiACRpZEx0Ah 9usomgy7mDoojhPvI61Ia8e4KNXQQHdvLtaWbBEgzucOlhUH73KlsX1Unw3/tuc2GNOY a/UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720543235; x=1721148035; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=f7fgoF8AlG8uCiG1DLZsSBJYiM9N7UEMdGptDtPKPeQ=; b=K201S23/gW4f5Z4nG7pMDte51FyMnCrdeA5xXyOLJwyb7N8NCaXKGh9qq4KpD46btl P6vQS86xPn14LHSpyrUGY5rq7cTj7lL8TI5o0YejuCfC1Fu9PBky4bvBbB8P4pgfXc2Z Mt9eCPOPXJAl0yZKUdBizw4XtZVpbmn+JuWP3TlP0t2IQE8nsALDOr+XCyUcxUFud0wA BKwURBr7AUaPzweCntjUIEUlFco+5IpjmMjaINPVPZrOj8QZT1SouqITZ607VxYwW9os bvnzLsAV3bqrOC7lk+bOJFRPGkfXWOgchlbzTltlgNJdq4wdo8NKkPpB1eDm2u10CPwP ZvIQ==
X-Gm-Message-State: AOJu0YxCn5/4ZUvuppjZWRW8pViy4BOaQ+gQ1LnRg/kWGD97FYQSc1cA 68+5urwI5Ds8Hom/hF67r2yigjTKH2VDkawG52Ve2CCuaayhsTedOu3tOQbJCEi5aQNR0ZGPhYh tveyNki80i3xmvuJDncg/4R6qMPvEf3QsJOLQ30bD/wM+f1yN6og=
X-Google-Smtp-Source: AGHT+IHIgow6V9dkYgbZdiR5GrtO9Ze3dO98MVgm6Nt7DFCoeSnWLd17wbHcUzvNRVisdd0AgdcflfEbdOnMYxdhnMM=
X-Received: by 2002:a05:6402:35d0:b0:58b:73f4:2ed with SMTP id 4fb4d7f45d1cf-594bcba7716mr2100615a12.35.1720543234852; Tue, 09 Jul 2024 09:40:34 -0700 (PDT)
MIME-Version: 1.0
References: <CO1PR08MB66110D7F5477ECFD5823CD98B3DB2@CO1PR08MB6611.namprd08.prod.outlook.com>
In-Reply-To: <CO1PR08MB66110D7F5477ECFD5823CD98B3DB2@CO1PR08MB6611.namprd08.prod.outlook.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Tue, 09 Jul 2024 18:40:24 +0200
Message-ID: <CAOj+MMFUBYraezNkQE+L_N1CZ6gkD89-gC+DuLScov1u92bvSw@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary="00000000000055a3f5061cd330a2"
Message-ID-Hash: T6LWJC3NEWXAUBK2RS3KDDJDV5IDB65G
X-Message-ID-Hash: T6LWJC3NEWXAUBK2RS3KDDJDV5IDB65G
X-MailFrom: robert@raszuk.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "idr@ietf.org" <idr@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: WG Adoption for draft-ssangli-idr-bgp-generic-metric-00 (7/9 to 7/23/2024)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/R51-FbzU1IfOWxh_NHG1pmiRW3E>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hi,

I support adoption of this document.

Encoding wise I think there is still room for WG discussion if atomic
metrics should be added during propagation or if we should rather move
towards per BGP segment metrics and let the receiver compute it as it seems
fit.

The latter could be actually much more inline with interdomain SR
architecture (under same administration - of course :).

Best,
Robert




On Tue, Jul 9, 2024 at 5:58 PM Susan Hares <shares@ndzh.com> wrote:

> This begins a 2 week WG Adoption  (7/9/2024 to 7/23/2024)
>
> for draft-ssangli-idr-bgp-generic-metric-00
>
> https://datatracker.ietf.org/doc/draft-ssangli-idr-bgp-generic-metric/
>
>
>
> All authors should reply to this email with an IPR Statement.
>
>
>
> This draft is a revision of the concepts in
>
> draft-ssangli-idr-bgp-generic-metric-aigp-08,
>
> But uses the NextHop Dependent Capability.
>
>
>
> A short description of from the document may help you review the text.
>
>
>
>    RFC7311 describes mechanism for carrying accumulated IGP cost across
>
>    BGP domains however it limits to IGP-metric only.  There is a need to
>
>    accumulate and propagate different types of metrics as it will aid in
>
>    intent-based end-to-end path across BGP domains.  This document
>
>    defines BGP extensions for Generic Metric sub-types that enable
>
>    different types of metrics to be accumulated and carried in BGP.
>
>    This is applicable when multiple domains exchange BGP routing
>
>    information.
>
>
>
>    This document proposes "Accumulated Metric" TLV in the Next-Hop
>
>    Dependent Capability (NHC) attribute described in
>
>    [I-D.ietf-idr-entropy-label] to carry the accumulated metric value
>
>    for end-to-end path, hereby referred as AMetric.  The AMetric
>
>    supports all the metric types defined in the IGP-Parameters metric-
>
>    type registry.  Additionally this document provides procedures for
>
>    computation and usage of accumulated generic metric value during the
>
>    BGP best path computation.
>
>
>
> In your comments, please consider:
>
>
>
> 1.  Does this mechanism solve the problem we have discussed in interims on AIGP metrics?
>
> 2.  Are there any downsides to using NHC?
>
> 3.  Do you support IDR working on this mechanism?
>
>
>
> Cheerily, Sue Hares
>
>
> _______________________________________________
> Idr mailing list -- idr@ietf.org
> To unsubscribe send an email to idr-leave@ietf.org
>