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 <[email protected]> Sent: 28 July 2022 16:33 To: Routing WG <[email protected]> Cc: Adrian Farrel <[email protected]>; Jen Linkova <[email protected]>; David Lamparter <[email protected]>; [email protected]; [email protected]; [email protected] 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. _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
