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

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/

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