Re: [Idr] Part 3 of CAR/CT Adoption call (7/14/2022 to 7/27/2022) - Operational Differences

[Jeffrey Haas <[e-mail]>]

> On Jul 21, 2022, at 9:45 AM, <[e-mail]> <[e-mail]> wrote:
> 
> Jeff,
> 
> 
> Orange Restricted
> 
>> -----Original Message-----
>> From: Jeffrey Haas <[e-mail]> 
>> Sent: Thursday, July 21, 2022 3:10 PM
> 
> Jeff's lag 5 minutes. Bruno's lag: 36 hours.... ooops...

But I get high quality answers after the lag. We're good. :-)

>>> I’m not sure to see what would not work if that color number be overwritten by the LCM: we still have one NLRI per intent.
>> 
>> But that "low delay" intent varies per domain, and may not share the same colors for it.
> 
> Not sharing the same color does not seem an issue to me. Let's assume that BGP-CAR LCM community is always added. In this case, this seems exactly like BGP-CT  Transport Class ID, no? (unless I'm missing something in BGP-CT)

The question is partially motivated by that observation.

> Not sharing the same intent across ASes seems like a bigger issue. Intent needs to match, at least roughly, along the path. (unless this is agreed to be "best effort"... which is probably already the case for "low delay" 😉 (low delay may means different delays between different competing ASes)
> Seems a priori like similar to CoS: codepoint may be different but per hop behavior needs to be roughly aligned. 

And similar to CoS troubleshooting, being able to locally determine the intent needed on receipt along with the needed code point further downstream to get the desired behavior.

>> My question is operationally whether the receiver of an NLRI from a remote color domain cares more about "original intent" or about "local intent".
> 
> I'd say "local". But very likely I'm missing the issue that you have in mind.

No, I think you're confirming it.

> 
>> 
>> If locally 100 is my "low delay", anything remote will require you to do some sort of assisted lookup to figure out what that intent was.
> 
> Not sure what you mean by "assisted lookup". One need to look in the community (LCM or TC). Assuming the use of LCM is mandated in all cases, this point seems very similar between CAR and CT.

This is effectively what I'm trying to tease out of the operational picture.

The operational need, that I believe you're confirming, is you care at any given BGP Speaker what the local intent happens to be.  For -CAR, it can move in the update depending on whether LCM is in use or not.  Yet having the "original intent" seems to be the core selling point of the -CAR encoding.

Note that I'm over a year from trying to change someone's mind on the preference.  Protocol-wise, aside from issues with route selection pinch points and error handling considerations, the protocol mechanisms are largely identical.  However, I'm still trying to understand the operators' mental model vs. how things operationally must behave in a multi-color-domain environment.

Thanks for entertaining my question.

-- Jeff



> 
> --Bruno
> 
>> -- Jeff
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>