Re: [Idr] WG adoption call for draft-ssangli-idr-bgp-generic-metric-aigp- 10/20/2023 to 11/6/2023

Hi Peng,

> #PSF: The metric-value for specific metric type should have unit type,
for example, for delay metric
> type the unit type is microseconds (see RFC5305 and RFC8570).

IMO generalized metric if agreed between parties does not require a unit
type.

However a transport parameters do (for example it takes 100 ms to traverse
my ASN between specific PEs) and signalling those would be also useful. In
fact signalling those may open a doors to exchange it between domains not
under same administrative umbrella.

Cheers,
R.

On Thu, Oct 26, 2023 at 5:53 AM <peng.shaofu@zte.com.cn> wrote:

>
> Hi Srihari,
>
>
> Thanks for your explanations.
>
> Please see #PSF inline.
>
>
> Regards,
>
> PSF
>
>
>
> Original
> *From: *SrihariSangli <ssangli@juniper.net>
> *To: *彭少富10053815;shares@ndzh.com <shares@ndzh.com>;
> *Cc: *idr@ietf.org <idr@ietf.org>;
> *Date: *2023年10月25日 15:23
> *Subject: **Re: [Idr] WG adoption call for
> draft-ssangli-idr-bgp-generic-metric-aigp- 10/20/2023 to 11/6/2023*
>
> Hi Peng Shaofu,
>
>
>
> Comments inline.
>
>
>
> Thanks & Regards,
>
>
>
> srihari…
>
>
>
>
>
>
>
> * Juniper Business Use Only From: *Idr <idr-bounces@ietf.org> on behalf
> of peng.shaofu@zte.com.cn <peng.shaofu@zte.com.cn>
> *Date: *Wednesday, 25 October 2023 at 9:36 AM
> *To: *shares@ndzh.com <shares@ndzh.com>
> *Cc: *idr@ietf.org <idr@ietf.org>
> *Subject: *Re: [Idr] WG adoption call for
> draft-ssangli-idr-bgp-generic-metric-aigp- 10/20/2023 to 11/6/2023
>
>
> *[External Email. Be cautious of content]*
>
>
>
>
>
> Hi Chair, WG,
>
>
>
> I support the adoption of this document, which is useful to represent the
> necessary
>
> intent information, especially the delay metric types.
>
>
>
> Srihari> Thanks, I agree, the drafts addresses use cases that many
> customers have been asking for.
>
>
>
> But I have a bit doubts about different AIGP metrics across multi-domains.
> The
>
> "normalized" processing defined in the document may not work to get
> expected
>
> path conformed the intent. IMO, a specific metric type carried in the
> advertised
>
> BGP route will clearly indicate that it need an underlay path calculated
> based on
>
> the constraint of that metric type, otherwise,  a single IGP-default
> metric may be
>
> enough for any cases of intent.
>
>
>
> Srihari> AIGP IMHO is best applicable for domains under single
> administrative authority. If not, one cannot even assume that metric
> computation is done consistently across domains. This is applicable even
> when domains have a common metric-type, for example how is delay expressed
> as metric-value : value=1 for 100ms or value 1=10ms delay. Similarly how
> bandwidth is expressed as metric-value : value1 for 10G or value=1 for 100G.
>
> #PSF: The metric-value for specific metric type should have unit type, for
> example, for delay metric type the unit type is microseconds (see RFC5305
> and RFC8570). Maybe for IGP default metric type the metric value is just
> a naked number without units, but that is not true for other metric types.
> Although your example describes the flexibility of a local arbitrary
> setting metric value, it seems that the drawbacks outweigh the benefits.
> That is to say, if based on standardized metric accumulation, there should
> be no difference between multi-admin and single-admin.
>
>
> Because the "normalized" processing is actually a local policy configured
> on some
>
> BGP speakers that may be under the different operators, I am not sure if
> this local
>
> policy conflicts with the overall intention, for example, overal intention
> may need
>
> strict constraint without any affection by local policy, to obtain a true
> and reliable
>
> path to meet flow requirements. So, if "normalized" processing is kept, a
> flag in the
>
> advertisement should be introduced to turn it off.
>
>
>
> Srihari> For domains that have not yet transitioned to doing
> “similar/same” metric type  and want to exchange routes to establish
> end-to-end path, IMHO, enforcement via policy is a good mechanism that BGP
> operators are most familiar with. The draft proposes that operators agree
> on how metric values can be normalized so end-to-end path can be
> established for a particular metric-type (delay or bw or anything else).
>
> #PSF: Agree that for best-effort path in the history the complex local
> policies are always OK because the requirement is just to get a connection,
> and indeed, the connection quality is always improved through a large
> number of bundles links. But now we consider intent-based routing that will
> be often resolved to an underlay traffic-engineering path to match flow
> requirements (e.g, the intent is delay, not a simple connection). So the
> metric accumulation value of the route showed on the ingress PE should be
> true and reliable. I am mainly concerned about deterministic transmission
> and would like to hear the other opinions in WG.
>
>
>
> Regards,
>
> PSF
>
>
>
>
>
> Original
>
> *From: *SusanHares <shares@ndzh.com>
>
> *To: *idr@ietf.org <idr@ietf.org>;
>
> *Date: *2023年10月21日 01:57
>
> *Subject: [Idr] WG adoption call for
> draft-ssangli-idr-bgp-generic-metric-aigp- 10/20/2023 to 11/6/2023*
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
> This begins a 2-week WG adoption call for
> draft-ssangli-idr-bgp-generic-metric-aigp-05.txt
>
> https://datatracker.ietf.org/doc/draft-ssangli-idr-bgp-generic-metric-aigp/
> <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ssangli-idr-bgp-generic-metric-aigp/__;!!NEt6yMaO-gk!DwRwl8LTUk4Fo84tGGU14lbqiTfFlTD5IibA-nhpnB8DYf75DcgmLmGMU2xaVgq1Ok9CFniuyIUoz0kxu2uhBQ$>
>
>
>
> from 10/20/2023 to 11/6/2023.
>
>
>
> This draft defines extensions to the AIGP attribute to carry
>
> Generic Metric sub-types.  This is applicable when multiple domains
>
> exchange BGP routing information.  The extension is intended to
>
>  aid in intent-based end-to-end path selection.
>
>
>
> In your discussions, please consider:
>
>
>
> 1.       Are different AIGP metrics are needed across multiple-domains?
>
> 2.       Are the interactions between the current AIGP metric (type 1)
>
> and other types of metrics clearly defined?
>
> 3.       Is this feature useful for intent-based end-to-end path
> selection?
>
> 4.       Do you see any problems with the mechanisms or the text of the
> draft?
>
>
>
> Cheerily, Sue
>
>
>
>
>
>
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>