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

Hi Dhananjaya,

> DR## Can you check the Steering requirements section 6.2 ?

> It does include fallback to different colors / best effort. Please do
comment .

I see .. The subject of that section does not reflect the "fallback"
action.

But it addresses only part of the point I was making.

The other part was how do you communicate to the user application that
service is now degraded ?

How can an app increase its buffers when fallback from gold to silver is
triggered ?

In general what is described in section 6.2 is all very static. I am not
seeing a way to express colors (indicate intent) when I use SRv6
encapsulation directly from compute edge - as some operators are already
doing - and even section 3.2 in the original draft just talks about CEs and
VPNs. But as more and more services are starting to be originated directly
by compute nodes CE may just play a P node role.

Many thx,

R.

On Sun, Jul 17, 2022 at 12:10 PM Dhananjaya Rao (dhrao) <dhrao@cisco.com>
wrote:

> Hi Robert,
>
>
>
> Thank you for the rapid review and insightful comments, as usual.
>
>
>
> Please see inline (DR##)
>
>
>
> *From: *Robert Raszuk <robert@raszuk.net>
> *Date: *Saturday, July 16, 2022 at 4:18 PM
> *To: *"Dhananjaya Rao (dhrao)" <dhrao@cisco.com>
> *Cc: *"idr@ietf.org" <idr@ietf.org>
> *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=
> 40cisco.com@dmarc.ietf.org> 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
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
>
>