RE: dst-src-routing & introduction-to-semantic-routing

[Adrian Farrel <[e-mail]>]

Ah, thanks for that, David.

I am certainly not trying to appropriate the dst-src routing or try to fit
it into any specific classification. But I do make the observation that
dst-src routing is a step beyond classic destination routing, and it is
worth thinking about the problem space to see whether there is anything that
can be learned and applied to make dst-src routing more robust and useful.

To that end, the draft I wanted to point you at is
draft-king-irtf-challenges-in-routing. That document attempts to briefly
call out a list of things to think about when "messing" with the routing
system. A lot of the issues will appear as "obvious" to those with a long
history in routing, but the list may provide a useful checklist of items to
consider as the dst-src work progresses.

Of course, if you also discover things that are wrong or missing from the
challenges draft, we would really welcome hearing about them.

Cheers,
Adrian

-----Original Message-----
From: David Lamparter <[e-mail]> 
Sent: 28 July 2022 16:33
To: Routing WG <[e-mail]>
Cc: Adrian Farrel <[e-mail]>; Jen Linkova <[e-mail]>;
David Lamparter <[e-mail]>; [e-mail];
[e-mail]; [e-mail]
Subject: dst-src-routing & introduction-to-semantic-routing

Hi all,


just to relay Adrian Farrel's mic comment, that was regarding
https://datatracker.ietf.org/doc/draft-farrel-irtf-introduction-to-semantic-
routing/
and indeed adding a source lookup is a specific instance of additional
routing semantics.

Having become aware of that draft only a few minutes ago I of course
have not grokked it yet, but in case it aids others in correlating these
drafts I'd like to provide 2 pieces of "context":

(1.) the "fundamental point" of dst-src-routing is to properly document
a common basis of operation and interoperability such that - within the
"limited domain" (multihomed enterprise network, cloud service, or
homenet) - compatible implementations can be mixed freely.  This is also
what differentiates this from "policy routing" - aka support for
arbitrary routing semantics established by operator input, where the
operator also assumes all responsibility for making the end result
actually do something useful (or even just non-broken).

(2.) for some of the considerations in introduction-to-semantic-routing,
there will be nothing corresponding in dst-src-routing - because
dst-src-routing only attempts to document forwarding behavior and
provide a common basis to routing protocols, but not routing protocol
operation itself.  If the meaning of a "(D,S)" route itself is fuzzy,
any work by a routing protocol to make it interoperable would be futile;
or rather the considerations in dst-src-routing would need to be
duplicated into each routing protocol.

But considerations like actual compatibility mechanisms in the face of
non-dst-src-routers or how this impacts convergence are better discussed
in the protocol specific documents.  The BABEL document for this has in
fact passed into RFC:
https://datatracker.ietf.org/doc/html/rfc9079 [*]

The OSPFv3 and IS-IS ones have met fates similar to the dst-src draft;
whether there is use in reviving them is a separate question but
regardless of that their contents may contain some useful nuggets of
discussion.

Cheers,


-David


[*] due to my failure at pushing dst-src-routing forward, BABEL has
substituted [SS-ROUTING: Boutier, M. and J. Chroboczek, "Source-Specific
Routing"] as reference.  The behavior is fully identical and all
considerations are bidirectionally transferrable.