Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)

Alvaro Retana <> Wed, 04 November 2020 17:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FB6D3A1388; Wed, 4 Nov 2020 09:23:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FvGd8tvLDrze; Wed, 4 Nov 2020 09:23:11 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 122D03A0E9F; Wed, 4 Nov 2020 09:23:10 -0800 (PST)
Received: by with SMTP id j24so30796861ejc.11; Wed, 04 Nov 2020 09:23:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=ony5ky7z99aI/y2jMxUuTCXNwVH15S3yxcRPBrLG7Y8=; b=c36oexOw0KQKFpITSuhjtEXoc7qASlxU0D1M2TQ/ljuDn6g86Hiwr7/QX8fGzNPowg HZOv+leFQ2PpV14yWWrqbyZ/CXgif0XXvTw7i5hDqlGDhH9diZApmWWBtQOni0N7nmai zVa2tQ7ZDB+thGWuRGn3oXLV2BX/I0pz4vAol69DiU+WG3Yks1Fn07ihFfUZg39a6RxX ZeikE1BCux8tKmVQ/wvDlY4gzkHlwPCrxD9f2R+Y8BQ/URSWgYj2EQolZKCIuyK3B1fl jM4SiBvL15WThnJJZ9zpc/eYwCdAVcWbMjUTGzSbCFhyEsUSlGOOxQWBjGv5h5QYGsQG aAhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=ony5ky7z99aI/y2jMxUuTCXNwVH15S3yxcRPBrLG7Y8=; b=GApTYsxXzeXoP8DFd30nmpUaa+H6SiepB3o2UOxoWx+nh7FkoCmMLeozmxPXDDEnYz UzOcrfxP0VMwI7riYB1Bogn5Dp93nOx3/5lpNKG3dHarmighYRJ2L0OyjUw4oIbtQxQp N3Y6xsXmbgGfUVHXnDPNuAp2nYDmCb53ed91UL1wR+9DC1wgqhl+IEWGICEvUeyLVFOn 6u3EJyGP1LD85ZytxiuOIDTcLlfVfQ1Cpo/PdOPx3f0U6AWFTrmmUyfi73+y2exN6AAM yTbZ3R8u8pYGvghcNinl62p+UCIGCJHKzFcs4dwe2TWeKRZtP4EY+9qC05N9NxYnr/aD 8K0Q==
X-Gm-Message-State: AOAM531C4nSbDp/2kecXi2jgCemuGCvvsYUwNpEhHO5GAz7QkA4fl1Ah 4PYjbqTK/ILjqPIUzk0GIqMsp+N4bPJr7OF1bNssIbDsRxI=
X-Google-Smtp-Source: ABdhPJwD3mg71sSxb/wWmjzV/t4Aq/hB6ukMPCuibWB0FmkU+H3T2xAt5rgv+vHKMN5LNxoLaznDAnfLT1IIYCidroY=
X-Received: by 2002:a17:907:2166:: with SMTP id rl6mr14464265ejb.61.1604510589267; Wed, 04 Nov 2020 09:23:09 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 4 Nov 2020 12:23:08 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Wed, 4 Nov 2020 12:23:08 -0500
Message-ID: <>
To: =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <>, The IESG <>
Cc:, Donald Eastlake <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [babel] Alvaro Retana's Discuss on draft-ietf-babel-source-specific-07: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 04 Nov 2020 17:23:13 -0000

On November 3, 2020 at 4:45:44 PM, Toke Høiland-Jørgensen wrote:



> Alvaro Retana via Datatracker writes:
> > Still, it shows how easy it is to define a policy that may not result
> > in the expected behavior because of the destination-first operation.
> > Please add some guidance on the advertisements and how they may
> > interact in the routing table.
> >
> > Note that what I'm asking for may just be a good example of what to do/
> > not to do. rfc8678/§5 presents an example of how the forwarding table is
> > constructed based on a set of routes -- something like that would be
> > great!
> Since your concern seems to be related to a particular example of what
> the source-specific extension can be used for, mentioned in the
> introduction, I'm not sure I see how it would improve the document to
> write a whole bunch of text addressing this particular operational
> concern? I mean, the section you're quoting the example from (section 4)
> literally says that the choice of dest first / source first is arbitrary
> and all that is required is that it is consistent, before then going
> ahead and spelling out the choice.

The choice may have been arbitrary, but §4 explicitly requires
destination-first: "A Babel implementation MUST choose routing table
entries by using the so-called destination-first ordering..."

Note that I am not questioning the choice, I'm just asking for more details.

> One small change in the introduction that may make this clearer, was to
> amend this sentence in the third paragraph of the introduction:
> "When using
> this technique in a network connected to multiple providers, every
> host is assigned multiple addresses, one per provider."
> to read something like:
> "When using
> this technique in a network connected to multiple providers, every
> host is assigned multiple addresses, one per provider, and each edge
> router exports a default route with a source prefix corresponding to
> the prefix delegated from its upstream."

That is not a bad change.  However, my concern is not just about the
multihomed case, but about the general handling of advertisements into
the routing table.

> > (b) How is the source address selected by the host?
> [...]
> > Even though this document is about Babel and not the host, I would
> > like to see a (short) discussion about how the host is expected to
> > behave (or what it needs to consider) in light of the
> > destination-first operation.
> Juliusz can correct me if I'm wrong here, but I believe this is left out
> because it really doesn't matter. The host can pick source addresses
> however it likes, and packets will make their way to the right upstream
> (in the multi-homing scenario).

If it doesn't matter, I would like to understand why.

The multihomed case with 2 default routes is straight forward -- but
how would it work in a more complex case (§4.4/rfc8678, for example)
where a specific source address is expected?  Or is this use case not