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

[[e-mail]]

I'm not aware of non-disclosed IPR.

As a co-author I support adopting this draft.



1.  Does this mechanism solve the problem we have discussed in interims on AIGP metrics?



On its way. The problem has been raised, the options considered, a path proposed.



2.  Are there any downsides to using NHC?



I think it's a good path to re-use and build on what we have. This also helps incremental deployment.

As already raised, there may be a naming consideration. NHC is used beyond the advertisement of "Capabilities".  May be changing the name to "Characteristic" which have the benefit of starting with the same letter and hence not changing the acronym.



3.  Do you support IDR working on this mechanism?



Yes. There is a need to carry and for BGP to consider the newly defined LSR/IGP metrics across routing borders (ASes or area/level with e.g. seamless MPLS) when BGP Next-Hop is changed.

Thanks,
Cheers,
--Bruno

From: Susan Hares <[e-mail]>
Sent: Tuesday, July 9, 2024 5:56 PM
To: [e-mail]
Subject: [Idr] WG Adoption for draft-ssangli-idr-bgp-generic-metric-00 (7/9 to 7/23/2024)

CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender.
ATTENTION : Cet e-mail provient de l'extérieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pièces jointes à moins de connaitre l'expéditeur.

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

____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.