From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25579 invoked from network); 27 Jun 2022 21:41:07 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 27 Jun 2022 21:41:07 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 5E1C840C75; Tue, 28 Jun 2022 07:40:30 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id 434B840763 for ; Tue, 28 Jun 2022 07:40:24 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1511218C094; Mon, 27 Jun 2022 17:40:23 -0400 (EDT) To: tuhs@tuhs.org Message-Id: <20220627214023.1511218C094@mercury.lcs.mit.edu> Date: Mon, 27 Jun 2022 17:40:23 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Message-ID-Hash: QSN3YHTBC5V56JOF5DMF6JJB2AXCFOZC X-Message-ID-Hash: QSN3YHTBC5V56JOF5DMF6JJB2AXCFOZC X-MailFrom: jnc@mercury.lcs.mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: jnc@mercury.lcs.mit.edu X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Research Datakit notes List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > From: Paul Ruizendaal > Will read those RFC's, though -- thank you for pointing them out. Oh, I wouldn't bother - unless you are really into routing (i.e. path selection). RFC-1992 in particular; it's got my name on it, but it was mostly written by Martha and Isidro, and I'm not entirely happy with it. E.g. CSC mode and CSS mode (roughly, strict source route and loose source route); I wasn't really sold on them, but I was too tired to argue about it. Nimrod was complicated enough without adding extra bells and whistles - and indeed, LSR and SSR are basically unused to this day in the Internet (at least, at the internet layer; MPLS does provide the ability to specify paths, which I gather is used to some degree). I guess it's an OK overview of the architecture, though. RFC-1753 is not the best overview, but it has interesting bits. E.g. 2.2 Packet Format Fields, Option 2: "The packet contains a stack of flow-ids, with the current one on the top." If this reminds you of MPLS, it should! (One can think of MPLS as Nimrod's packet-carrying subsystem, in some ways.) I guess I should mention that Nimrod covers more stuff - a lot more - than just path selection. That's because I felt that the architecture embodied in IPv4 was missing lots of things which one would need to do the internet layer 'right' in a global-scale Internet (e.g. variable length 'addresses' - for which we were forced to invent the term 'locator' because many nitwits in the IETF couldn't wrap their minds around 'addresses' which weren't in every packet header). And separation of location and identity; and the introduction of traffic aggregates as first-class objects at the internet layer. Etc, etc, etc. Nimrod's main focus was really on i) providing a path-selection system which allowed things like letting users have more input to selecting the path their traffic took (just as when one gets into a car, one gets to pick the path one's going to use), and ii) controlling the overhead of the routing. Of course, on the latter point, in the real world, people just threw resources (memory, computing power, bandwidth) at the problem. I'm kind of blown away< that there are almost 1 million routes in the DFZ these days. Boiling frogs... Noel