Re: [Idr] Proposed CAN WG charter for discussion

[Robert Raszuk <[e-mail]>]

Hi Linda,

I believe that you can get much wider and faster traction with the idea if
you keep routers outside of it.

I know LISP roots started at the assumption that xTRs should be placed in
routers vs ILNP idea (or family of ideas) to make it in the host - however
today I think that even for LISP xTR can be natively implemented in the
compute nodes itself.

I am not pointing at any specific solution here - just trying to better
understand where in IETF such WG (if/when formed) should reside. Routing
Area does not sound to me like a best/good fit for it. Hence the note.

Cheers,
R.



On Fri, Jan 27, 2023 at 11:29 PM Linda Dunbar <[e-mail]>
wrote:

> Robert,
>
>
>
> I believe the CAN proponents only want to distribute the information on
> Overlay, not involving the network elements in the underlay, as stated in
> the current CAN charter:
>
>
>
> *The assumed model for the CAN WG is an overlay network, where an ingress
> routing node makes a forwarding decision based on the metrics of interest,
> and then steers the traffic to an egress node that serves the selected
> service instance, for example using a tunnel. Architectures that require
> the underlay network to be service-aware are out of scope.*
>
>
>
> As for OTT, does it imply egress routers distribute the information to the
> external system which in turn distribute the information to the relevant
> ingress routers?
>
>
>
> Dino did suggest LISP as one way to distribute the information between
> egress routers and Ingress routers. Maybe the draft you mentioned can be
> considered as the starting point for applicability study of using LISP?
>
>
>
>
>
> Linda
>
>
>
> *From:* Robert Raszuk <[e-mail]>
> *Sent:* Friday, January 27, 2023 3:35 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* John Scudder <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]
> *Subject:* Re: [Idr] Proposed CAN WG charter for discussion
>
>
>
> Hi Linda,
>
>
>
> But why do we need to do that within the underlay network vs Over The Top
> (OTT) way ?
>
>
>
> Why network needs to be at all involved in distribution of the load
> information if we could solve it at the application level
> and keep network lean and as much stateless as possible ? Simple mapping
> plane will work just fine for this resulting in OTT Compute Aware Load
> Balancer (for the lack of the better name).
>
>
>
> Why bring this "awareness" to BGP or IGP or even routers in general ?
>
>
>
> Isn't the draft https://www.ietf.org/id/draft-kjsun-lisp-dyncast-03.html
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-kjsun-lisp-dyncast-03.html&data=05%7C01%7Clinda.dunbar%40futurewei.com%7C8b49fda4a1b548aebefc08db00ae6a4a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638104521338387708%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=E5qPzKk%2FTxYPBEgmXOXIjeeTZgNzYWKk9bm12D2Gves%3D&reserved=0>
> a possible solution ?
>
>
>
> Many thx,
>
> R.
>
>
>
>
>
> On Fri, Jan 27, 2023 at 9:43 PM Linda Dunbar <[e-mail]>
> wrote:
>
> John,
>
> Oh, I guess I have over-thought of the "Architecture & framework".
> The proponents' wanting a mechanism for egress routers to distribute
> computing resources to ingress routers can be considered as one rough
> architecture.
>
> Thank you.
>
> Linda
>
> -----Original Message-----
> From: John Scudder <[e-mail]>
> Sent: Friday, January 27, 2023 12:06 PM
> To: Linda Dunbar <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: Proposed CAN WG charter for discussion
>
> Hi Linda,
>
> I didn't mean to say that the architecture would have to be completed to
> the point of RFC publication before that step could be started! But of
> course, anyone studying the applicability of a mechanism, has to be
> thinking, "applicable for what purpose"? So I think that studying
> applicability presupposes that the person doing the study has an
> architecture in mind.
>
> Your summary seems about right, and I think it demonstrates that those in
> the side discussion *do* have at least a rough architecture in mind. My
> point is,
>
> a. It's important to write that rough architecture down, to make the
> assumptions transparent to all WG participants, and b. It's important that
> when listing work items, we do not lose sight of the fact that this is one
> work item.
>
> I don't see the bullet list as comprising a strictly ordered list of tasks
> that have to be completed in the order listed, I'm sure some will be worked
> on in parallel or even out of order.
>
> I hope that helps?
>
> -John
>
>