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

[[e-mail]]

Hi Kaliraj,

Some comments inline [Bruno]



Orange Restricted

From: Kaliraj Vairavakkalai <kaliraj=[e-mail]>
Sent: Wednesday, July 17, 2024 8:13 AM
To: Susan Hares <[e-mail]>; [e-mail]
Subject: [Idr] Re: 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.

Hi Sue,

I support IDR working on a mechanism to accumulate metrics of different kinds in BGP, using the 'Ametric' construct this draft defines.

But about using NHC, I have a few comments:

The propagation scope of NHC is not tight enough. Attribute escape into the wild is possible, as noted in NHC draft sec 6.1

[Bruno] The question is not NHC specific, but whether we want a transitive or non-transitive attribute.
If we pick non-transitive, propagation scope is tight, but deployment is difficult. Especially some have expressed the need to be able to not change/upgrade their BGP RR infrastructure.
We have had this exact discussion with NHC with was non-transitive originally.


[Bruno] But coming back to NHC, the re-use of NHC for 'Ametric' has benefits, and in particular on the specific point that you are raising.
The NHC BGP Attribute is transitive, but the capability codes are not transitive when BGP Next-Hop is changed [1], which would typically be the case on the ASBRs (the first ASBR before 'wild' and all ASBRs in the 'wild'). So re-using a general purpose mechanism -here NHC- which has already been deployed for other reasons (e.g. ELC) is beneficial.

[1] https://datatracker.ietf.org/doc/html/draft-ietf-idr-entropy-label-14#section-2.2

This could exercise bugs far away from origination point of the route. Which I think we want to avoid.

[Bruno] Yes, that's the property of non-transitive BGP attributes. Whatever the option chosen for Ametric, this will not change. Even non-IDR/IETF work, e.g. "research experiments" may trigger this.
As for errors, RFC 7606 would likely help a lot. (assuming it's implemented and enabled... I would call for implementations to enable it by default. If you care for bugs in the wild/networks, surely this is the case for your implementation, isn't it?)

Also, thinking about it a bit - perhaps there may be cases where discontinuity may not be detected by ingress,
when an intermediate node doesn't support NHC and changes nexthop, but a subsequent node may add a new NHC when doing nexthop-self.
To ingress, it would look like everything is OK, but the Ametric will not contain the metric until the egress?
Text may need to be added to handle such cases?


MNH attribute is non-transitive on the other hand. That may help with tighter propagation scope and discontinuity detection.

And, AIGP may anyway need to be added to MNH also. This was suggested earlier in the following thread:

https://mailarchive.ietf.org/arch/msg/idr/DGLHUnop9Go0rR-7cV5eUAQdN28/

So a question to ask is, whether we need an intermediate step of carrying AIGP in NHC also?

Since this point was raised already above, did the authors consider using MNH to carry Ametric?

NHC was done urgently to handle the ELCv2 interop problems that escaped to production.

[Bruno] I have significant disagreements with this single sentence.
As for NHC, work started in 2015 with draft-decraene-idr-next-hop-capability-00. I would not call 9 years (and counting) "done urgently"
As for ELCv2, I'm not sure what you mean exactly by "ELCv2 interop problems that escaped to production". My own perception is that ELCv2 squatted on a code point, using that code-point was buggy by design, and that code point had a badly specified Error Handling. Plus some implementation enabled it by default IIRC. That's a lot for a single thing so yes this triggered issues, which was a pretty expected outcome to me. What puzzle me is how this arrived in production and even in code.


But not sure if we want to keep adding more stuff into it, when MNH is also an adopted draft.

Just want to note that - adding more forwarding-related stuff (Ametric, LinkBW, etc.) to newer attributes adds to the problem space that MNH is attempting to solve.

[Bruno]  If you really want to compare MNH to NHC I would say that NHC is simpler (4.5 pages vs 31 pages), closer to RFC publication and hopefully closer to implementations.

--Bruno

Thanks
Kaliraj



Juniper Business Use Only
From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 9, 2024 at 8:57 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] WG Adoption for draft-ssangli-idr-bgp-generic-metric-00 (7/9 to 7/23/2024)
[External Email. Be cautious of content]

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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ssangli-idr-bgp-generic-metric/__;!!NEt6yMaO-gk!BDJERQ78XBdJqB3VMbbwbQen6biAgR1P-WJ2KWSgCfvW3t4mx2HQN0xNXtkT6bQlI0TdVQmziCjYqUM$>

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:



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

Are there any downsides to using NHC?

Do you support IDR working on this mechanism?



Cheerily, Sue Hares

Orange Restricted

____________________________________________________________________________________________________________
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.