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

[Srihari Sangli <[e-mail]>]

Ketan,

Thanks for bringing up your viewpoints. Comments inline.

srihari…



Juniper Business Use Only

From: Idr <[e-mail]> on behalf of Ketan Talaulikar <[e-mail]>
Date: Wednesday, 25 October 2023 at 6:10 PM
To: Susan Hares <[e-mail]>
Cc: [e-mail] <[e-mail]>
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]

Hello Sue/All,

I fully support the requirement for the advertisement of "Generic Metric Types" and their accumulation in the BGP protocol (on similar lines as the current AIGP metric). We have introduced Generic Metric in IGPs already.

To answer your questions - Yes, this is needed across multiple domains (multiple-AS within a single provider construct as also single AS but across multiple IGP domains). This feature may be used for intent-based BGP transport paths.

Srihari> Thanks

That said, I have some concerns with the proposed solution in this draft.

1) There are challenges with introducing the Generic Metric TLV in the AIGP attribute. The authors have done a great job of capturing some of those in Sec 4. Additionally, the AIGP attribute and AIGP metric TLV is widely deployed today. Being non-transitive, it would be challenging to introduce new TLVs and ensure smooth operations given the current spec in RFC7311.

2) The draft proposes normalization of the generic metric when that specific metric type is not used/available for NH resolution at a specific hop. This may not always be desirable. Importantly, there is no indication of discontinuity for a particular metric type (say delay metric) due to "fallback" to best-effort at some hop.

Perhaps there is another way to convey the Generic Metric types (yes, there can be more than one metric type conveyed at the same time). I would like to suggestion the following to the authors and the WG:


  1.  We don't use the AIGP attribute for carrying generic metrics. Instead, we use the existing AIGP TLV to carry the "normalized" metric. The intent is described by the "color" of the route anyways which in many cases gives an idea of what kind of metric is being used. This is how some implementations/deployments are conveying metrics today for intent based paths.

Srihari> The metric type used in generic_metric proposal is as per IANA. Using color to indicate intent will not communicate the true intent and will open for misinterpretation of what exactly the metric type was.


  1.  Since the generic metric needs to be accumulated whenever NH is changed, it falls under the category of "NH dependent" and perhaps we can introduce it under the new NHC attribute. I agree that it is not strictly a "capability" - but one can argue that it is a capability of the NH to provide a path with say X delay. Being transitive allows it to be conveyed across RRs and domains which are not yet upgraded to support this feature.

Srihari> I’ll review NHC, but it may not cater to existing deployments is my initial take.

c) On the TLV itself, we need some flags to indicate a "discontinuity" and whether it was due to a "fallback" condition. If there is "normalization" then the same can be also indicated.

Srihari> thanks, we can incorporate this, it may not completely address discontinuity however.

I would like to know views from the authors as well as other WG members on this alternate proposal.

Srihari> we can discuss offline in more detail and update the wg. I may get a slot on Friday’s IDR session and can present details. Thanks.



I would be happy to collaborate with the authors on this.

Srihari> Thanks for offering to collaborate on this, we can discuss separately and update the wg.

Thanks,
Ketan


On Fri, Oct 20, 2023 at 11:26 PM Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:
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!CVmSfubLY9xqFq9Mksqe0eRgs07FlzOX5mv58mAM5UXAxKfZ7FiT-Zi5Ew7Lmh68cNbMcy7LIsaLWuSOCzjK$>

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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!CVmSfubLY9xqFq9Mksqe0eRgs07FlzOX5mv58mAM5UXAxKfZ7FiT-Zi5Ew7Lmh68cNbMcy7LIsaLWhpl--M2$>