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

[Susan Hares <[e-mail]>]

Jim:

Thanks for letting us know your opinion and your desire for additional use cases.

You might want to look at the post from Moses Nagarajah from Telstra on Thursday, July 7.
Re: [Idr] BGP CAR - multiple color domains (ietf.org)<https://mailarchive.ietf.org/arch/msg/idr/x9Zy9ob5_78bsAiE5Pvr9qAJlKw/>
https://mailarchive.ietf.org/arch/msg/idr/x9Zy9ob5_78bsAiE5Pvr9qAJlKw/

Moses posted to the discussion above, but I think his post fits into this discussion.

Cheers, Sue

From: UTTARO, JAMES <[e-mail]>
Sent: Thursday, July 14, 2022 9:12 AM
To: Robert Raszuk <[e-mail]>; Goekhan Guemues <[e-mail]>; Susan Hares <[e-mail]>
Cc: [e-mail]
Subject: RE: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions

I support the adoption of both BGP CAR and BGP CT. R.Raszuk “…Let the market decide not the mailing list then move one of them to Standards Track and the other one to Historic. “ I agree. Currently th
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2ZjNTNhOWE2YjVjOWRiOTcyYmJjM2ZmOWJjZWZiMTU1LzE2NTc4MDQzMjMuNDg=#key=3d87138940c41a18ed31e0c02cbd5987>  FAQ<https://www.inky.com/banner-faq>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

I support the adoption of both BGP CAR and BGP CT.

R.Raszuk  “…Let the market decide not the mailing list then move one of them to Standards Track and the other one to Historic. “

I agree. Currently there are two solutions although they are “functionally identical” there are important reasons why operators may opt for one or the other.

I am a bit confused as to the driver “We need one interoperable solution”. Kompella and EVPN both can be used to create PWs, Multicast can be deployed using ingress replication, Rosen etc….
The time to drive towards one interoperable solution is before the technologies are specified..

I look forward to a discussion of the use cases addressed in order to better inform architect/designers as to which approach is most appropriate for them. Letting the market decide will provide needed perspective to resolve this in favor of one or both specifications..

Thanks,
          Jim Uttaro

From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Robert Raszuk
Sent: Wednesday, July 13, 2022 3:44 AM
To: Goekhan Guemues <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions

Hi,

> Implementing BGP-CT means we can interact with SR without changing behaviour as inter-op is important for my company.

May I ask what inter-op issues or what "behaviour change" would be needed for SR when using the CAR proposal ?

> We may also face SR if we acquire a third party with SR core.

Actually about acquiring a third party ... IMO CAR works seamlessly for it and color translation at the boundary can be one way. In fact I can easily think about not even requiring translation.

On the other hand with CT imagine the set of issues if your acquired party uses identical RDs - lot's of people have rfc 1918 as intradomain numbering schema including loopbacks. Touching 1000s of routers in this case on either side is clearly going to hurt.

= = =

Comment to the WG chairs,

Watching this debate I think the best option is to accept both proposals as experimental. Let the market decide not the mailing list then move one of them to Standards Track and the other one to Historic.

Many thx,
Robert.



On Wed, Jul 13, 2022 at 9:28 AM Goekhan Guemues <[e-mail]<mailto:[e-mail]>> wrote:
Hello Robert,

We are not moving toward SR as of today, this may change in the future if SR will bring us something we feel is needed.
We may also face SR if we acquire a third party with SR core.

Implementing BGP-CT means we can interact with SR without changing behaviour as inter-op is important for my company.

Kind regards,
Gokhan

On Sat, 9 Jul 2022 at 13:48, Robert Raszuk <[e-mail]<mailto:[e-mail]>> wrote:
Hello Goekhan,

One question to you directly:

This solution may help euNetworks to provide end-to-end coloring with the current brownfield deployment instead of moving to SR. We could offer this to our customers without a need to redesign the network. Deployment in brownfield without downtime and no interruption to service traffic. Easy to troubleshoot using RD and RT show commands to follow the color mapping

I also like that it is service agnostic which means I can use it for RSVP-TE or SR-TE

Few sentences above you said: "instead of moving to SR" but in your last sentence you said "or SR-TE" ... so which one is it ?

- -

And one question to everyone on this thread:

> Easy to troubleshoot using RD and RT show commands to follow the color mapping

Point 1:

What if I want to extend the notion of colorful transport to my IPv4 and IPv6 customers ? Do I need them to understand concepts of VPN encoding with RDs and RTs ? CT seems to fit the "limited domains"  frames ... CAR seems much broader even if not day one in the day two deployments.

To me CAR proposal is much more universal and boldly departs from pretending that everything can be carried as VPNs. But it does use RD in SAFI 84 where it makes sense - for VPN CAR.

Point 2:

Imagine I would like to enhance my IXP offering with color aware IX fabric routing/switching. CAR seems to be a much better fit then pushing lots of engineers to understand RDs and RTs and who never run L3VPNs into CT model.

Thx,
Robert.


Kind regards,
Gokhan Gumus

On Fri, 8 Jul 2022 at 21:23, Natrajan Venkataraman <natv=[e-mail]<mailto:[e-mail]>> wrote:
Hi Susan,

First of all, thanks for valuing this problem space and considering
IDR adoption for technologies that address this problem space.

As a co-author of BGP-CT, I would like to bring to your attention, the
amount of interest that is generated with our customer when we
present our technology to them. From what we gather, this problem
space is applicable to all regions and especially to those customers who
are beginning to adapt their networks for addressing use-cases in the
5G problem space.

They consider “intent driven end-to-end service mapping” as an important
aspect for topology and network slicing requirements in 5G.

Having said that, your questions hit the point clearly and assertively. Please
find my replies inline to the individual items marked with NV>

From: Idr <[e-mail]<mailto:[e-mail]>> on behalf of Susan Hares <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, July 6, 2022 at 11:15 AM
To: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Subject: [Idr] Part 1 of CAR/CT Adoption call (7/6 to 7/20) - Informational Questions
[External Email. Be cautious of content]


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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/idr/Xt-xFxKep2lJzMrn8Rd5QetVmaU/__;!!NEt6yMaO-gk!DIHzGUB1oKg0c5aVVP7zCgMqNXAnghOW6G5YdE-uEFmfuacEyGpVuiQIY2x9HO0FQb-LOBs04MMa$<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1j8tugkAARX9FSJeF4eHwsBtri2gVKU2kujLzBCqghcEoTf-9TNMu77nJyb1fateU6mSk5kKc2wkAQ6SMs7plOjlV4GKDw-Gvq1BRoobkxYXpBRNcPzUZkABUbQYK2oCd0K7z64qdrfKlj5rae6MwYSKt0HbQPCjKJhDOLUKxlh2V5-WiD7cz87TKDAJRmr66_VMWfW52j3WWx-9OCPc00LpgXvEOkeAWntOuSJZ76-ovYmOeYG0dz1pjHEXoTr0fqUf5o2ZimGUa0HN80wJtjhrWTmva579_OIE28pGDIfEp9l0LY2Jz7mPCODYhBKYDXc8Y25atjz1pZdL60Zmu7U2RENIiMZX4P3__APQhZ4I.MEUCIFAcfR-krHGZqCRPxK89iXbEShh0KtpG5W9I5fpFF4sLAiEAvqZfm3lQ0rxSS7pNc_s2ZagRQCfVF2NHswOqC-pH5tg>

"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.
So, let us use color as a BGP defined value and transport class as a BGP defined value.

NV> I agree that intent is more than a color. Seamless MPLS networks have been
able to guarantee intent using SRLG/admin-groups within a single TE domain.
In Brownfield RSVP-TE deployment, there are adequate ways to do the above and I see
Greenfield SPRING networks catching up to the same. However, BGP did not produce a
holistic way of cross cross-connecting these TE characteristics that are necessary for
guaranteeing the SLA end to end until now. BGP needs an identifier to inter marry
these TE characteristics across multiple TE domains. That identifier is the color.

NV> The second part is how flexible it is for services to express intent (language)?

  *   Tunnels in each domain may not have the exact TE characteristic due to the
virtue of the transport protocol that is used to signal them
(RSVP-TE/SR-TE/Flex) since they don’t engineer traffic in the same way within
the TE domain. Can transport color help in inter marrying these similar (but
not the same) TE characteristics?
  *   Can the service choose to have a color space independent of that of
transport?
  *   Can this service color space be used by services to scheme how it can dictate
the transport colors to orderly fallback when the SLA is lost for its individual
flows?
  *   How to manage intent across domains that have heterogenous colors? Say,
Domain A having Red and Green as colors whereas Domain B has 3 shades
for Red and 3 shades for Green. Now, can the service individually pick Red
in Domain A and Red-Shade1 in Domain-B or Green in Domain A and
Green-Shade2 in Domain-B for its individual flows through these
domains at the head-end of the end-to-end service?


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?
b. If so, is it due to QoS/SLA measurements on traffic between Data Center
applications and user applications (such as applications on phone)?

NV> As mentioned above, both a. and b. are true


2. In the distant past QoS was hard to set-up seamlessly as a QoS pathway
across multiple Autonomous systems (AS).

a. Should Customer intent that expresses pathway "QoS"
be passed in BGP routing updates sent between Autonomous Systems?

NV> Yes.

b. Is it the purpose of color or transport class to allow automatic steering of
traffic on into an "QoS" path (across different technologies)?

NV> Yes. However, transport-classes provides a way to organize “QoS” path
Into separate buckets for easier service resolution,

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

NV> BGP features need to interoperate with each other seamlessly and allow
For a deployment to leverage the benefits of the features being used. So,
This is not only limited to BGP flowspec but to other BGP features as well.


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?

If they matter, please describe what matters.

NV> The summary of IDR chairs is that BGP-CT and BGP-CAR are functionally similar.
What matters most to the customer are the following

  *   Do customers wish to carry color as a key in the NLRI?
  *   Do customers wish to carry non-key “forwarding information” as part of the NLRI?
  *   How would customers wish for their services to “Express Intent” for individual flows?


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?
b.  Should IDR consider future work on a MP-Color Attribute?

NV> Yes and Yes. BGP-CT team supports this approach as it confines the
The error handling to the attribute. Such an attribute is already being
Proposed by the BGP-CT team. I am bringing the same to the notice of
Both customers and the IDR chairs alike. Link below.

  *   https://datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1j11PgzAYhf_KRrwUSmF8zZu5RKMS57YsYV6Rt-1bKTAgpWx-xP8uGL085yRPzvNlDbq2ljOrMKbrl4SMUaDEpkeHtydy9kme_20CDBgNvELtKDTSafUbES0nQoM0dgW10lDaSmj7NNRGNfhuirazwRit2GBwRN3M5-tCHOZVpC57-sHDMH24HDPgW7e8bbZM4j55trP0sM7PwzFD-lphvb3Pdk93oOpNiiZ_ZI1XvGwqSDuu8p17ZV3PrGpyaNCMl6gbxGFCPdIXoLFfNeKz-HWRPPAhgZAFPBEsiTzGuC9lwjhKRoOA0DCIYnfhe76ziCcqTtRyoJEfr0aLiTLVYqr_8_cPiXRpMw.MEUCIGJao_cQ2TIqD2JQRMisxaLAEJqjEV52N--MD5CSzAjUAiEAuQ2pBIgW52acAf3QhC3pDLShfA_9E5jPwxHVYxHp9P0>

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DIHzGUB1oKg0c5aVVP7zCgMqNXAnghOW6G5YdE-uEFmfuacEyGpVuiQIY2x9HO0FQb-LOODosKe5$<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jstSgzAARX-lMC6FEGh41E3VUtqpLXYh2hWThASwPCoJxeL47zaOLu-5M2fOl953lT6b6IWUJzED4DozxlkjmEnbGpwdkKZ_3zAMZskkN9suBzUuqxo3oCqFLBvegjLr0vRO03ahdC9bHBv5UVusV2P08gDbTW5RhJPk2Rsf8-3H7u2-yYv41Y3QIQuNPlzWvMc0vESnpC_364P9Gaxia7knxlMcL1qxYehGv53oR5XaMHktgBby3QDaQBS4Y2LeZGPxm8wpcnCAXYJokJHAswmhDucBoYwTiBCALvJ8a-rYjjn1lZUp63sPPcefYymVReFM4f_9_QPwHl4I.MEYCIQDfpVV4XNUebLtbB_4SO0SNkmcp9IexbmPsRyAp-0fV1QIhALD0IoUP7jECEifqFv_o099ZI4QRmijJQmK6gTeEWeIb>


Juniper Business Use Only
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jtFOgzAARX9lEB-VUroCnS-TZEYlTlwWmU-kLe1gQFmgrFHjv0uNPt57k3PPlzsNrbtauJXW53EFwBxLIYUahcf7DlwQKIq_zRjj1UJLrx-OoKN121EF2nrUtZI9qMuhKG4dJ6nKvdNEtdnBDx6G6YM55JRn_ulOZUyKHXm-ydN9UlymQy7geyPa7D5_fdrMvG0qdPHIVFC9bBtqzlnydtxcudcLt7GKSuj5Gfo4DgkMwFjRQYxrVX5Wv6qSY0QJDRnmpGQkChjjSErCuJAMYgxgiKPYX6IAecvYUoWlniYYoXhNtbYUW5e2_s_fP4wSXI8.MEUCIDT3bh-PvtOdKLOnKyxrfm4ltLee88leRE1zJz6msiXyAiEAsl5yso3h0IsTsPXPT6TZEHc9jPMESK9WmL57u_RSORc>


--
Gokhan Gumus | Senior Routing-Switching Architect | euNetworks
Theodor-Heuss-Allee 112 | 60486 Frankfurt am Main
[phone] mobile

[https://ci3.googleusercontent.com/mail-sig/AIorK4zmcHzLfEeMyDsY_2UA4FodP04L6NpvHd3YznbJscdxE-AYqKJdkzzxzlsynx2CUds6G5lM-D0]
Für weitere Informationen über euNetworks oder für Informationen über unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere Webseite www.eunetworks.de<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jl1PgzAYhf_KIF4qpXQFijdziTolTlyWgFekH29lg4HhY40z_nepiZfPOclzzrc79Y2bLNxqHD-HBKEZFWhoB_Bkd0JngsrSdgkyxngwtTCarq8HT8Hc3DrOulJ7p44OZoe_ZBimG1PkXGb-8a7NhIYde7nJ0_26PE9FDvi9hiZ7yN-e7_mh2aYwlk-iDarXbc378-bxVMgr93rh1vbSPNX1H9incchwgIaK9zCsWnWp_q5pSQlnPBRUMiVYFAghidZMSNACU4pwSKPYX5KAeMvYWsFajxOOSLzi42gtNlY2_uefX-8NVow.MEUCIQDmF2Vus2_DVrBxabsv_M9Im7u-GVyYZNgH2ZRmrE1f4QIgUEzsvBMPTdo0SiF67D2AYKWI7pz2jvhGmnIzknwPT8A>. Abonnieren Sie Updates von euNetworks unter  eunetworks.de/kontakt/newsletter/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jl1PgzAYhf_KIF7qSmEFOm_mkhmVuOGyhHlF-vF2bMViaBlO438XjF6ejzznfPldW_vziV85927nCA1SggJjYSqaN3SOUFn-ZdAZcH3TajuVgHRjHNMOGehtDc5BOzRvPW9ZyZ2nk2O_xRcRx9lDvy-YyIPTncm5gi19vimy3bI8d_sC8KuGOr8vXp5W7FivM3DlIzdhtVlrxppLtvo4XPnXE1-PF4f1pj3ggKQxxSGyFWvBLoz8rH6vKkEiRlnMiaCS0yTkXERKUS5AcUwIwjFJ0mAWhdF0lo5UGKmnDidRumDOjZTRlqP9r79_AARUXSw.MEYCIQDcjFHNY3GkvWNmptNtczD1Xpb86tEtXMiGBAtVU4jQ8AIhAK064nQIjNlkF8X6LmzDbIu1mxYrQ698Isn_D_FUNIhY>

Diese E-Mail und oder Anhänge können vertrauliche und/oder gesetzlich privilegierte Informationen enthalten. Wenn Sie nicht der beabsichtigte Empfänger sind, löschen Sie bitte die E-Mail, ohne sie zu lesen und benachrichtigen Sie den Absender. euNetworks GmbH Geschäftsführer: Myriam Buchheister, Markus Weiland Amtsgericht Frankfurt am Main HRB 88224 Steuernummer 04523251638 Umsatzsteuer ID: DE 201 739 716
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jtFOgzAARX9lEB-VUroCnS-TZEYlTlwWmU-kLe1gQFmgrFHjv0uNPt57k3PPlzsNrbtauJXW53EFwBxLIYUahcf7DlwQKIq_zRjj1UJLrx-OoKN121EF2nrUtZI9qMuhKG4dJ6nKvdNEtdnBDx6G6YM55JRn_ulOZUyKHXm-ydN9UlymQy7geyPa7D5_fdrMvG0qdPHIVFC9bBtqzlnydtxcudcLt7GKSuj5Gfo4DgkMwFjRQYxrVX5Wv6qSY0QJDRnmpGQkChjjSErCuJAMYgxgiKPYX6IAecvYUoWlniYYoXhNtbYUW5e2_s_fP4wSXI8.MEUCIDT3bh-PvtOdKLOnKyxrfm4ltLee88leRE1zJz6msiXyAiEAsl5yso3h0IsTsPXPT6TZEHc9jPMESK9WmL57u_RSORc>


--
Gokhan Gumus | Senior Routing-Switching Architect | euNetworks
Theodor-Heuss-Allee 112 | 60486 Frankfurt am Main
[phone] mobile

[https://ci3.googleusercontent.com/mail-sig/AIorK4zmcHzLfEeMyDsY_2UA4FodP04L6NpvHd3YznbJscdxE-AYqKJdkzzxzlsynx2CUds6G5lM-D0]
Für weitere Informationen über euNetworks oder für Informationen über unsere Unternehmen, darunter euNetworks GmbH, besuchen Sie bitte unsere Webseite www.eunetworks.de<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jl1PgzAYhf_KIF4qpXQFijdziTolTlyWgFekH29lg4HhY40z_nepiZfPOclzzrc79Y2bLNxqHD-HBKEZFWhoB_Bkd0JngsrSdgkyxngwtTCarq8HT8Hc3DrOulJ7p44OZoe_ZBimG1PkXGb-8a7NhIYde7nJ0_26PE9FDvi9hiZ7yN-e7_mh2aYwlk-iDarXbc378-bxVMgr93rh1vbSPNX1H9incchwgIaK9zCsWnWp_q5pSQlnPBRUMiVYFAghidZMSNACU4pwSKPYX5KAeMvYWsFajxOOSLzi42gtNlY2_uefX-8NVow.MEUCIQDmF2Vus2_DVrBxabsv_M9Im7u-GVyYZNgH2ZRmrE1f4QIgUEzsvBMPTdo0SiF67D2AYKWI7pz2jvhGmnIzknwPT8A>. Abonnieren Sie Updates von euNetworks unter  eunetworks.de/kontakt/newsletter/<https://shared.outlook.inky.com/link?domain=urldefense.com&t=h.eJw1jl1PgzAYhf_KIF7qSmEFOm_mkhmVuOGyhHlF-vF2bMViaBlO438XjF6ejzznfPldW_vziV85927nCA1SggJjYSqaN3SOUFn-ZdAZcH3TajuVgHRjHNMOGehtDc5BOzRvPW9ZyZ2nk2O_xRcRx9lDvy-YyIPTncm5gi19vimy3bI8d_sC8KuGOr8vXp5W7FivM3DlIzdhtVlrxppLtvo4XPnXE1-PF4f1pj3ggKQxxSGyFWvBLoz8rH6vKkEiRlnMiaCS0yTkXERKUS5AcUwIwjFJ0mAWhdF0lo5UGKmnDidRumDOjZTRlqP9r79_AARUXSw.MEYCIQDcjFHNY3GkvWNmptNtczD1Xpb86tEtXMiGBAtVU4jQ8AIhAK064nQIjNlkF8X6LmzDbIu1mxYrQ698Isn_D_FUNIhY>

Diese E-Mail und oder Anhänge können vertrauliche und/oder gesetzlich privilegierte Informationen enthalten. Wenn Sie nicht der beabsichtigte Empfänger sind, löschen Sie bitte die E-Mail, ohne sie zu lesen und benachrichtigen Sie den Absender. euNetworks GmbH Geschäftsführer: Myriam Buchheister, Markus Weiland Amtsgericht Frankfurt am Main HRB 88224 Steuernummer 04523251638 Umsatzsteuer ID: DE 201 739 716