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

[Joel Halpern <[e-mail]>]

Really, you want two non-interoperable solutions?  So what happens if 
you are peering with operator 1 who has chosen solution 1, and also 
peering with operator 2 who has chosen solution 2. Even if you support 
both solutions in your network, you can not offer paths that traverse 
yourself and both peers.

And, if you want to deploy both solutions then not only do the vendors 
have to support both, but you have to test both.

I suppose you could choose only one of the two solutions.  And simply be 
unable to have intent paths that cross into other operators who made a 
different choice?

This seems like exactly what standards are supposed to avoid / prevent.  
It may be nice for python to have 6 ways to do everything.  It is not 
good for the Internet.

Yours,

Joel

On 7/16/2022 5:55 PM, Gyan Mishra wrote:
>
> I agree as well with Jim & Luay being against the one size fits all 
> “single” basket approach.
>
> Both solutions are functionally similar with different approaches.
>
> As Luay stated, having a two vendor solution does lead to more 
> development work on the vendor side to develop both solutions and 
> ensure interoperability, but that is indeed their business to develop 
> new innovative solutions and with that, possible ROI in development of 
> both solutions.
>
> This is not the first time we have been in this situation, where we 
> are pitching both vendors against each other trying to get to a one 
> solution model to ensure interoperability.
>
> For operators, if we have two good solid solutions , why not promote 
> both even if they are functionally similar but operationally different.
>
> It is very difficult to make a decision now without letting the 
> solutions bake off in the industry and see which one prevails or it 
> might be they they both have their own niche use cases and they both 
> may prevails which I can see that happening in the long run.
>
> Flexibility is  important which being the consumers of the solution 
> and ultimate beneficiary, it makes sense to develop both solutions and 
> let the industry decide.
>
> Kind Regards
>
> Gyan
>
>
> On Sat, Jul 16, 2022 at 2:15 PM Luay Jalil <[e-mail]> 
> wrote:
>
>     I agree with Jim that as an operator I like to have options and
>     let market, needs,  use cases drive them. I do also understand
>     sometimes this causes more development in the vendor community to
>     develop both plus interoperability, but that's their bread &
>     butter 😁
>
>     It seems that we keep putting ourselves in this impasse because of
>     the "One" rule. In my mind, if the community sees 2 "good"
>     solutions then instead putting them against each other, promote
>     them. You never know what we will find in the future with more
>     operational experience and new use cases that could make one
>     solution fits better in certain use cases. I'm not a big fan of
>     the "One" basket as you can see 😉
>
>     Regards,
>     Luay
>
>     On Thu, Jul 14, 2022 at 8:12 AM UTTARO, JAMES <[e-mail]> wrote:
>
>         *_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]> *On Behalf Of * Robert Raszuk
>         *Sent:* Wednesday, July 13, 2022 3:44 AM
>         *To:* 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
>
>         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]> 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]> 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]> 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]> on behalf
>                         of Susan Hares <[e-mail]>
>                         *Date: *Wednesday, July 6, 2022 at 11:15 AM
>                         *To: *[e-mail] <[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://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/idr/Xt-xFxKep2lJzMrn8Rd5QetVmaU/__;!!NEt6yMaO-gk!DIHzGUB1oKg0c5aVVP7zCgMqNXAnghOW6G5YdE-uEFmfuacEyGpVuiQIY2x9HO0FQb-LOBs04MMa$>
>
>                         "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://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-kaliraj-idr-multinexthop-attribute/__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkaKpci_Q0$>
>
>                             _______________________________________________
>                             Idr mailing list
>                             [e-mail]
>                             https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DIHzGUB1oKg0c5aVVP7zCgMqNXAnghOW6G5YdE-uEFmfuacEyGpVuiQIY2x9HO0FQb-LOODosKe5$
>                             <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!DIHzGUB1oKg0c5aVVP7zCgMqNXAnghOW6G5YdE-uEFmfuacEyGpVuiQIY2x9HO0FQb-LOODosKe5$>
>
>                         Juniper Business Use Only
>
>                         _______________________________________________
>                         Idr mailing list
>                         [e-mail]
>                         https://www.ietf.org/mailman/listinfo/idr
>                         <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkawpPBVgE$>
>
>
>
>                     -- 
>
>                     *Gokhan****Gumus**|***Senior Routing-Switching
>                     Architect*|**eu**Networks*
>                     Theodor-Heuss-Allee 112
>                     <https://www.google.com/maps/search/Theodor-Heuss-Allee+112%0D%0A+%7C+60486+Frankfurt+am+Main?entry=gmail&source=g>*|
>                     <https://www.google.com/maps/search/Theodor-Heuss-Allee+112%0D%0A+%7C+60486+Frankfurt+am+Main?entry=gmail&source=g>*60486
>                     Frankfurt am Main
>                     <https://www.google.com/maps/search/Theodor-Heuss-Allee+112%0D%0A+%7C+60486+Frankfurt+am+Main?entry=gmail&source=g>
>
>                     [phone]mobile *
>                     *
>                     **
>
>                     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://urldefense.com/v3/__http:/www.eunetworks.de/__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkarvHGmXc$>. Abonnieren
>                     Sie Updates von euNetworks unter
>                     eunetworks.de/kontakt/newsletter/
>                     <https://urldefense.com/v3/__https:/eunetworks.de/kontakt/newsletter/__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkaaoyKExg$>
>
>                     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]
>                     https://www.ietf.org/mailman/listinfo/idr
>                     <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkawpPBVgE$>
>
>
>
>             -- 
>
>             *Gokhan****Gumus**|***Senior Routing-Switching
>             Architect*|**eu**Networks*
>             Theodor-Heuss-Allee 112
>             <https://www.google.com/maps/search/Theodor-Heuss-Allee+112%0D%0A+%7C+60486+Frankfurt+am+Main?entry=gmail&source=g>*|
>             <https://www.google.com/maps/search/Theodor-Heuss-Allee+112%0D%0A+%7C+60486+Frankfurt+am+Main?entry=gmail&source=g>*60486
>             Frankfurt am Main
>             <https://www.google.com/maps/search/Theodor-Heuss-Allee+112%0D%0A+%7C+60486+Frankfurt+am+Main?entry=gmail&source=g>
>
>             [phone]mobile *
>             *
>             **
>
>             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://urldefense.com/v3/__http:/www.eunetworks.de/__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkarvHGmXc$>. Abonnieren
>             Sie Updates von euNetworks unter
>             eunetworks.de/kontakt/newsletter/
>             <https://urldefense.com/v3/__https:/eunetworks.de/kontakt/newsletter/__;!!BhdT!k7iwR1yc66KHwXWacP0jAnPbfeR9M-WKTB_vuXWe1YkelPFWQJEailNKet_Ibn2hONkaaoyKExg$>
>
>             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]
>         https://www.ietf.org/mailman/listinfo/idr
>
>     _______________________________________________
>     Idr mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/idr
>
> -- 
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> /Network Solutions A//rchitect /
>
> /Email [e-mail]//
> /
>
> /M 301 502-1347
>
> /
>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr