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

[Robert Raszuk]

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) 
wrote:

> Hi Robert,
>
>
>
> Thank you for the rapid review and insightful comments, as usual.
>
>
>
> Please see inline (DR##)
>
>
>
> *From: *Robert Raszuk 
> *Date: *Saturday, July 16, 2022 at 4:18 PM
> *To: *"Dhananjaya Rao (dhrao)" 
> *Cc: *"i...@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 

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

[Dhananjaya Rao (dhrao)]

Hi Igor,

Thank you for the quick review. Please see inline (DR##)

From: BESS  on behalf of Igor Malyushkin 

Date: Sunday, July 17, 2022 at 2:50 AM
To: "Dhananjaya Rao (dhrao)" 
Cc: "bess@ietf.org" 
Subject: Re: [bess] New draft "draft-hr-spring-intentaware-routing-using-color"

Accidently unicasted the previous message to Dhananjaya, replying to the group.

Hello Dhananjaya,

Can you please clarify some moments in Section 6.2? First, I don't see any sign 
of Section 5.1.9 (also referred to in Section 6.3.1.7) in the document. Looks 
like missed.

DR ## Thanks; yes, it was a reference to Section 5.9. Missed updating during 
conversion. Will be fixed in next revision.

I'm interested in the next scenario. Let's suppose that for a service instance 
(VPN or a global table) there are two ingress flows per single destination. 
This destination is color-marked and resolved by an intent-aware underlay. 
Also, there is a best-effort path as a fallback. Using per-flow steering that 
is based on 5-tuple IP flow is it possible to send ingress traffic from a 
source S1 via the intent-aware path, and ingress traffic from a source S2 via a 
fallback (best-effort) path at the same time? My reading of Section 6.2 shows 
me that it's not possible. But I strongly believe that there are cases when an 
intent/colored path for a distinct destination must be used only by the subset 
of members of service, and the same destination must be available for the rest 
members of the service via a best-effort path(s) only. I can show some business 
logic behind this if you will.

DR## Sending one IP flow for a destination via an intent-aware path while 
sending another flow for the same destination via a best-effort path (or a 
different intent-aware path) is a valid use-case, which is intended to be 
covered. It was described more explicitly in  
https://datatracker.ietf.org/doc/draft-dskc-bess-bgp-car-problem-statement/  
Section 1.2.11, but reduced in the merged doc. We can make it more explicit.

In fact, this scenario is already supported by existing intent-aware solutions 
such as SR-TE :

https://datatracker.ietf.org/doc/html/draft-ietf-spring-segment-routing-policy-22#section-8.6

Regards,
-Dhananjaya


Hope it helps, and thank you!

сб, 16 июл. 2022 г. в 07:15, Dhananjaya Rao (dhrao) 
mailto:40cisco@dmarc.ietf.org>>:

Hello BESS 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)


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Dhananjaya Rao (dhrao)]

Hi Robert,

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

Please see inline (DR##)

From: Robert Raszuk 
Date: Saturday, July 16, 2022 at 4:18 PM
To: "Dhananjaya Rao (dhrao)" 
Cc: "i...@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) 
mailto:40cisco@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
i...@ietf.org