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

David Lamparter <equinox@diac24.net> Thu, 28 July 2022 18:31 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3EDC1A649F for <rtgwg@ietfa.amsl.com>; Thu, 28 Jul 2022 11:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bths2BbK_KCQ for <rtgwg@ietfa.amsl.com>; Thu, 28 Jul 2022 11:31:30 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943D0C1A649E for <rtgwg@ietf.org>; Thu, 28 Jul 2022 11:31:12 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.94.2) (envelope-from <equinox@diac24.net>) id 1oH8Hs-00FoIz-Sx for rtgwg@ietf.org; Thu, 28 Jul 2022 20:31:09 +0200
Date: Thu, 28 Jul 2022 17:33:03 +0200
From: David Lamparter <equinox@diac24.net>
To: Routing WG <rtgwg@ietf.org>
Cc: Adrian Farrel <adrian@olddog.co.uk>, Jen Linkova <furry13@gmail.com>, David Lamparter <equinox@diac24.net>, cuilz@szu.edu.cn, yang.shu@szu.edu.cn, xmw@cernet.edu.cn
Subject: dst-src-routing & introduction-to-semantic-routing
Message-ID: <YuKsLz5GV7uBB4G6@eidolon.nox.tf>
References: <CAFU7BAS9VNawNJuy1M7GHYL7FgbjwjeXbUkJEvQsqx7-xKZBTw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAFU7BAS9VNawNJuy1M7GHYL7FgbjwjeXbUkJEvQsqx7-xKZBTw@mail.gmail.com>
Status: RO
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/8W6kSvWEgTCMJftRzbjDsBDq2MY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2022 18:31:34 -0000

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.