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

Hi Peng,

IMO both are useful in their own unique ways.

But generalized metric by the definition is much more then single
operational parameter hence unit does not work there. Metric of the link
may express in one number monetary cost, propagation delay, loss
probability, jitter probability etc ... it is an accumulated value.

And I do not think there is any worry about attackers or security risks.
This is only about usefulness of such data.

Best,
R.

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

>
> Hi Robert,
>
>
> Please see inline #PSF2.
>
>
> Regards,
>
> PSF
>
>
>
>
> Original
> *From: *RobertRaszuk <robert@raszuk.net>
> *To: *彭少富10053815;
> *Cc: *ssangli@juniper.net <ssangli@juniper.net>;shares@ndzh.com <
> shares@ndzh.com>;idr@ietf.org <idr@ietf.org>;
> *Date: *2023年10月26日 15:56
> *Subject: **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.
>
> #PSF2: Not sure if explicit definition of the unit type may bring any
> extra cost. But, if without this unit type, the example Srihari gave shows
> the obvious confusion.
>
>
> 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.
>
> #PSF2: In your example, 100ms@ASN may not be explicitly included in the
> advertised route, but rather accumulated as an increment into the
> metric value (except the initial advertised message). Anyway, do you think
> "100ms" has a greater security risk than "100". IMO the information they
> disclose is the same, and attackers (if possible...) can easily guess the
> unit type.
>
>
> 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
>>
>
>