Re: [spring] [Idr] New draft "draft-hr-spring-intentaware-routing-using-color"

["Dhananjaya Rao (dhrao)" <[e-mail]>]

Hi Robert,

Thank you for the rapid review and insightful comments, as usual.

Please see inline (DR##)

From: Robert Raszuk <[e-mail]>
Date: Saturday, July 16, 2022 at 4:18 PM
To: "Dhananjaya Rao (dhrao)" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [Idr] New draft "draft-hr-spring-intentaware-routing-using-color"

Hello Dhananjaya,

I have a few higher level questions/comments in respect to the shared document.

#1 - Any well design service will very often try use multiple *independent* (ie. not closely cooperating administration) transits. It surprises me that none of the documents are trying to normalize at least a few colors such that intent aware transit across independent parties can be comparable by end customers.

DR## Apt point. In fact, a similar comment has been made by a couple of other collaborators as well. Certain well-known common services could in fact be assigned well-known colors for use across providers (or independent transits as you stated). The analogy was to the current well-known BGP Communities.

The current version does not venture into this aspect. It can certainly be included in the document. We would welcome further inputs on it.


#2 - I love requirements as listed in 6.3.3 ! Note that many networks today are light years from meeting those requirements. So what this section is essentially saying is - if you do not meet those basic requirements forget about interaware transit. This is good.

DR## Ack. All requirements may not apply to all intents, and there likely will be considerations of trade-offs when enabling them in networks.

#3 - I am disappointed that the presented document does not say a word about intent/color to other color(s) or to best effort fallbacks. IMO I think it is extremely important and in fact should be part of dynamic signalling.

DR## Can you check the Steering requirements section 6.2 ?
It does include fallback to different colors / best effort. Please do comment .

#4 - How colors are reflected in routing ? In other words if I want to transit over paths which do not use satellite links and suddenly there is failure of all critical terrestrial paths how do I get as the end customer signalled that ? Is my unicast route getting withdrawn ? In fact the document does not say what are the requirements for the customer CE. All pictures start from PE :).  Do I as a client need to participate in color aware routing at all ? Or is the mapping to a colorful path happening on the provider's edge based on something in the packet ?

DR## FWIW, https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ did have a section (3.2) on VPN Service intent requirements, which covered extending intent-aware routing to the CE (and possibly beyond). These may not capture all possibilities – if you have suggestions, we will consider them.

Since this current document is a merged effort, it has taken considerable time to agree on the content and text that should be included. Hence those requirements are not captured in the current version. But they should be included in upcoming versions, once reviewed.

#5 - The entire architecture here seems to be locked to transit or connectivity service provided by a single set of closely cooperating administration. But as we all know more and more connectivity is moving (or has already moved) to SD-WAN or NaaS using native best effort transits provided by a number of ISPs in the underlay. It is either the edge nodes or even apps to detect the best quality end to end path and steer the traffic accordingly. Yet these discussions here about color aware transports are sort of stuck with the network model where there is a customer attaching to a single SP and using it for connectivity service. Is this still so relevant nowadays ? Of course there are networks which do all of those color aware forwarding all by themselves under a given administrative umbrella. But do they need IETF to define a subset of what they have already deployed and operational for years ?

DR## The VPN / Service requirements in the CAR problem statement did anticipate a use-case would be SD-WAN or other transit services, of course still carried over a intent-aware provider transit network to ensure the desired intent is achieved. I agree the scope can be widened.

Regards,
-Dhananjaya

Kind regards,
Robert


On Sat, Jul 16, 2022 at 7:14 AM Dhananjaya Rao (dhrao) <dhrao=[e-mail]<mailto:[e-mail]>> wrote:


Hello IDR folks,

The co-authors of https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/ and https://datatracker.ietf.org/doc/draft-hegde-spring-mpls-seamless-sr/ have published a merged problem statement document :

https://datatracker.ietf.org/doc/draft-hr-spring-intentaware-routing-using-color/

We request working group to review and provide your inputs.

Regards,
-Dhananjaya (for the co-authors)



_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr