Re: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions

[Susan Hares <[e-mail]>]

Bruno:

I found that the Intent concept definitions from IRTF has been sent to the RFC editor:
(https://datatracker.ietf.org/doc/draft-irtf-nmrg-ibn-concepts-definitions/)

This draft specifies
      Intent: A set of operational goals (that a network should meet)
      and outcomes (that a network is supposed to deliver), defined in a
      declarative manner without specifying how to achieve or implement
      them.

I think this matches our practical discussion that indicates intent are operational
goals (SLE (service level expectations) and SLAs (service level agreement))
that are expressed in declaratively by the customer.   The network
tasked with implementing or achieving these goals, and debugging
when these goals are not met.

The IRTF document looks like it is worth a read.  If you are coming to IETF-114, perhaps
we can chat about this over your favorite beverage (e.g. beer, water, coffee)

Sue

From: [e-mail] <[e-mail]>
Sent: Monday, July 11, 2022 10:42 AM
To: Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: RE: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions

Sue, Please see inline [Bruno2] Orange Restricted From: Susan Hares <[e-mail]<mailto:[e-mail]>> Sent: Friday, July 8, 2022 7:43 PMTo: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; idr@ietf.o<mailto:idr@ietf.o>
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2VmMmM4ZmU2MTM5MzYwYjBjNzAwZGE1M2U0Nzk0OGI1LzE2NTc1NTA1MjcuNQ==#key=046082b4b7a4abcaa18814d7cf546087>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

Sue,

Please see inline [Bruno2]



Orange Restricted
From: Susan Hares <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 8, 2022 7:43 PM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions

Bruno:

Thank you for taking time to write such insightful answer to my questions.
[Bruno2] You are very welcome. _You_ are doing the hard job; minimally I try to provide answers/opinions.

You asked questions about the following - so I'm bringing it to the top.


[Sue-1> b.  Should IDR consider future work on a MP-Color Attribute?

[Bruno] Not sure what you have in mind.



To explain this consider:



MP-REACH/MP-UNREACH - group NLRIs by AFI/SAFI



An MP-Color attribute would group attributes by color

An MP-NH attribute could group by NHs.



Example of an MP-Color attribute

[MP-Color-Green:

{MED, Tunnels, non-key data (Next-Hop label-pairs, etc)]

MP-color-Gold

(MED, Tunnels, non-key data (NH, Labels, backup, preferences



Example of an MP-NH attribute would group this by Next-Hops

Could pack

[Next-hop-1

Color, tunnels, non-key data (labels, other things), preferences)

[Next-hop-2]



Please do not take my examples as anything other than vague directions

the IDR might go into.



[Bruno2] Thanks for the clarification.

The above proposal could help; however IMHO one difficulty is the selection of this additional "group by" key. You provided two (Next-Hop, Color), but there could be multiple. IMHO, the one which is likely to be the most useful (based on history and current discussion) is to be able to advertise non-key data per NLRI.



Personally, in order to be generic (and hopefully benefit from a single code base to debug) I would propose a new MP_REACH_NLRI attribute carrying sets of (NLRI, non-key data), compared to (NLRI) currently. Or may be even better for error handling two lists: a list of NRLI, followed by a list of non-key data (in the same order). But this may be seen as a larger effort compared to BGP-CAR which only defines a new SAFI.



[Sue2] I agree that migration to a new MP_REACH_NLRI is a larger effort.

However, the non-key data for NLRIs continues to grow.

The stability of the BGP protocol error handling suggest a migration to

an attribute with better error handling that supports the non-key fields

(NH, Color, labels).





Regards,

--Bruno







[Bruno] I don't think that encoding the color is the issue as this is a short, constant size value.

To me the difficult question is more about encoding some NLRI specific data

(e.g. label for MPLS, but those days we may need to be more general)

in order to avoid breaking packing (in which case, the question is not completely specific to BGP colors).

Thank you for your insights.  It really helps the IDR chairs know what is important.

Cheers, Sue

From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Friday, July 8, 2022 12:16 PM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: RE: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions



Hi Sue, chairs, IDR,



Interesting questions. Please see inline





Orange Restricted



> -----Original Message-----

> From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Susan Hares

> Sent: Wednesday, July 6, 2022 8:15 PM

> To: [e-mail]<mailto:[e-mail]>

> Subject: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions

>

> IDR WG:

>

> This message is part 1 of the adoption call for CAR/CT drafts in IDR.

>

> The IDR Chairs need input from the community on technology direction

> for these drafts.  The four questions ask your opinion on the

> key facets of the technology direction.  Please help the IDR chairs by

> answering some or all of these questions.   We'll use this input in our decision

> on the adoption call of the CAR and CT drafts.

>

> Part 2 of the CAR/CT adoption call is an adoption call for the drafts.

>

> Gyan Mishra states on:

> https://mailarchive.ietf.org/arch/msg/idr/Xt-xFxKep2lJzMrn8Rd5QetVmaU/<https://shared.outlook.inky.com/link?domain=mailarchive.ietf.org&t=h.eJxNzLkOwjAQRdFfQa7B4yRMFioqChAFSCBax54sInGiiYMQiH8Hd7RP9523mLkTm4VovB-nDUCv206zadoHyZZ8JQeuIQzQTzW0luHmV8_d80Bj3O1fR3b52eKJ_LXXFxDLhbgHzpH_HSOFeVpEMUyNZpq2zr4aaYYeqIpNXlEaJUWSqlKZTCmrMaF1VqzzEiFKMUNUGGcSA0oBLXl2g7RkWJOj7cDa1RS8UNhQ_E2fL3p-RH0.MEUCIQC-8CB5w-6V4gz5uLPiOVXGNpunPrZcngdF-bAf5InzagIgeWZllOb2FIMkzgf7wBvV6WC2euYB0kp0yJRf4cR2kik>

>

> "The concept of coloring has existed for decades with MPLS, we just didn't

> call it "colors" until now with the advent of Segment Routing SR-TE & Flex

> Algo, as we called it different VPN SLO's with various QOS policies for

> customer SLA Gold, Bronze, [or] Silver classes."

>

> Intent may be expressed in color, but it is more than color:   In 2015 in

> draft-hares-ibnemo-overview-01.html, I state:

> "As IP networks grow more complicated, these networks require a

> new interaction mechanism between customers and their networks

> based on intent rather than detailed specifics. An intent-based

> language is need[ed] to enable customers to easily describe their

> diverse intent for network connectivity [requirements/needs] to

> the network management systems."

>

> IMHO, there is no clear and universal intent-based language in 2022.

+1



> So, let us use color as a BGP defined value and transport class as a BGP defined value.



+1 (plus BGP already has a color extended community, and the BGP-SR-policy already uses color so I think that's not needed to define a different term))



>

> 1. What is the customer need driving the use of Color to express Customer Intent?

>

> a. Are applications requesting to be able to tag their routes

> with SLAs (color) at the service level?



Different applications/customers have different requirements in term of routing paths.

e.g. optimize for bandwidth, vs optimized for delay (I mean link delay, not QoS/queuing related). There are others uses cases such as two different planes which is a rather usual "niche"



Note that we already have the need and solution within the single IGP (e.g. with FlexAlgo, SR policies). IMO the question is extending this to BGP, in a way allowing each AS to use its own solution for its intra AS routing. Such as RSVP-TE in one AS, FlexAlgo in another AS, SR-policy in a another AS.



> b. If so, is it due to QoS/SLA measurements on traffic between Data Center

> applications and user applications (such as applications on phone)?



This may be either dynamic measurement or static attributes.

Immediate use case use static attributes.

> 2. In the distant past QoS was hard to set-up seamlessly as a QoS pathway

> across multiple Autonomous systems (AS).



We probably need to distinguish multiple AS vs multiple Administrative Domains.

A Single Administrative domain may cross multiple ASes, e.g. due to organization boundaries or technical scaling. I would hope that agreeing on a QoS / color within single administrative domain should be doable regardless the number of ASes.



Plus in my view, a color does not match to a packet forwarding QoS treatment (à la diffserv) but rather to a different routing paths toward the same destination (NLRI)

> a. Should Customer intent that expresses pathway "QoS"

> be passed in BGP routing updates sent between Autonomous Systems?



Yes. IMHO both for:

- the service routes (e.g. BGP or "Internet") to express the requirement

- the transport routes fulfilling the requirement

Note that the above already requires agreement on the meaning of color between ASes and also between administrative domains. (and many more than the number of ASes that may be involved to setup interop domain transport colors)



> b. Is it the purpose of color or transport class to allow automatic steering of

> traffic on into an "QoS" path (across different technologies)?



Yes



> c. How should this automatic steering interact with flow specification?



On my side,, initial use case does not involve BGP Flowspec.

Automatic steering is expressed by the service/VPN routes attaching a color to express the color/path it wants to follow.

> 3. For those who believe that BGP should set-up a seamless path across multiple

> Autonomous Systems for a single Intent/QoS, do the exact mechanisms matter

> or do you simply want an interoperable solution?



Primarily, we need interoperability.

Then automated steering should be simple and inline with what we already have with SR-policy (IMHO) and what we have within one AS.

BGP encoding is less important but for sure, it seems like different persons have different opinions.



> If they matter, please describe what matters.



Not having to manage unnecessary indirections or ID spaces would help IMO.

> 4. RFC7606 focused on error handling in which the MP-NLRI focuses on destination keys

> (RD and Prefix) plus non-key material (Labels, SIDS).  Attributes (generally) apply to all NLRI.

> For example, MED applies to all NLRIs in the packet.

>

> a. Would error handling be better for color-aware routing if attributes

> relevant to a specific color/class be grouped in a MP-Color-Attribute?



Probably, error handling would be better with a simple NLRI. However this is a complex subject and it really depends on the type of error and whether the length field match the size of the value field (or not)

However there are other tradeoff involves (e.g. efficiency, extensibility/generality).

Note that we have already encoded non-key data in the NLRI (e.g. label, label stack) so it may not be black and white.





> b.  Should IDR consider future work on a MP-Color Attribute?



Not sure what you have in mind. I don't think that encoding the color is the issue as this is a short, constant size value. To me the difficult question is more about encoding some NLRI specific data (e.g. label for MPLS, but those days we may need to be more general) in order to avoid breaking packing (in which case, the question is not completely specific to BGP colors).



Thank you.

--Bruno

>

> _______________________________________________

> Idr mailing list

> [e-mail]<mailto:[e-mail]>

> https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=www.ietf.org&t=h.eJxNzEsOgyAUheGtNIwbLj4uqCO3gnBRUoUGMCZtuveWWacn3_nf7Ew7m25sK-WZJ4Drurin4nhMKxza74cOsPtcfHARvE3sfmOP-ghUfqYROMixaSFvOlGeg31t3MQDyLVmcCSbbuykWIRRQliNHfVq7IcFoZGoEAW2imONUo0u6QyRWzJJU6A5Jh1Wqr0qbBV_0-cLiXA6vQ.MEQCIHTt1FCSudOdFnZVOb9CAXkG7hdrrPuNOPgyRw9kzqtyAiA87SiPxQ5rHNShMCiSZmJ_yHAJQxQjmh3jXqhv7FEPbA>



_________________________________________________________________________________________________________________________



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.



_________________________________________________________________________________________________________________________



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.