From nobody Tue Apr 13 19:01:05 2021 Return-Path: X-Original-To: babel@ietfa.amsl.com Delivered-To: babel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFCD3A1371 for ; Tue, 13 Apr 2021 19:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FMJktB0_iAK for ; Tue, 13 Apr 2021 19:00:59 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F4363A136E for ; Tue, 13 Apr 2021 19:00:58 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id e8-20020a17090a7288b029014e51f5a6baso4651575pjg.2 for ; Tue, 13 Apr 2021 19:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yVYv4cHdCxJEYwv2hOrb7A+1KeSj0eme5Q6gpQKPPhI=; b=YIFVD5wjM8GCjale9Ps08Pky5YU4vKG9BJpxouLkb5BIiDkg6lhdXcV7qRJsHI7dFW VXFHttdc0QhkxKASkXaCIgQSnwZNJNtEIPdMYTgy0NfwRnY1vHRTb3YKZcHrAuxD281g 2lw8H0SnbWjZxL32Jb66EL/tNoLCDSPxnh48n+JHvA6FCJThxPWNYxmnGDM1wsnf7ija DQFlC/q14E/KYuzaIWQ+KdgSNCtydPElM/Ua8583MWdADW5O+kvR8/UVbcdWkFZyQvGq lK701xL7mWPPi+taJpWBDoa+jbtifGr3Ls1srOG+LCO6d/6hIEN8546YxOAWlpPUPdV7 JsRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yVYv4cHdCxJEYwv2hOrb7A+1KeSj0eme5Q6gpQKPPhI=; b=g6PDk6LNrqm3WdKiJhTLXEEwILhcDm2qLTsBPLfUEYBGgNLOk14duNqEwP1xeoA3FF TE4qsDbj4HR0UvYEmblsU9MEhHUZMOXlHaG3h4cqD0eA+4uaHNHUlNODBmKDcWKdXUqQ oL3+itGObAM5lOgcoRmyNjbDjDn4rcZGBbJQPztq530MjwB6t+7gXBAD4qqsiWtl0ncU ijxeineaaTxRRFoBFYzGV00hCW+YpYj22NjfvJFFFZyBvAAEAJq1EOfz9iYdAIMd+hJB bnUTkqypQ5WlBw0bty1wH14oxQvWo6l+F8+SpqetifZEOAxTLopc32xCHyZciCMRZwre o6kQ== X-Gm-Message-State: AOAM531IprAGaj4WC7EhbDvxeb+Z2/5OjEHujgCXRKdTjy8oUbiTI7lR PvEQ32LfdxT9bO6TuojIqWzSIHzcVYMmFe+0Mqo= X-Google-Smtp-Source: ABdhPJxjv6v9Hdqd+3Wp6NZOeuIPcMf6DZw3S/j5Ci93WP+w85gART7E8EVMsoXFXWq5RivDUwpb8qxRJlo0vqsFo7Q= X-Received: by 2002:a17:90b:1b42:: with SMTP id nv2mr806109pjb.190.1618365657972; Tue, 13 Apr 2021 19:00:57 -0700 (PDT) MIME-Version: 1.0 References: <161799373903.21494.5029385648255827216@ietfa.amsl.com> <87y2drmgxz.wl-jch@irif.fr> <87mtu2qqgr.wl-jch@irif.fr> <87lf9l6bqo.wl-jch@irif.fr> In-Reply-To: <87lf9l6bqo.wl-jch@irif.fr> From: David Schinazi Date: Tue, 13 Apr 2021 19:00:46 -0700 Message-ID: To: Juliusz Chroboczek Cc: Donald Eastlake , Babel at IETF Content-Type: multipart/alternative; boundary="00000000000029024c05bfe51e39" Archived-At: Subject: Re: [babel] Dummy source address [was: I-D Action: draft-ietf-babel-v4viav6-01.txt] X-BeenThere: babel@ietf.org 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, 14 Apr 2021 02:01:04 -0000 --00000000000029024c05bfe51e39 Content-Type: text/plain; charset="UTF-8" Oh that's a good point, I totally agree. (1) or (4) both seem like the best outcome here. I think I'm now leaning towards (4). David On Tue, Apr 13, 2021 at 3:50 PM Juliusz Chroboczek wrote: > > a separate Babel dummy address > > I've been thinking about this all evening, and I think I now see what > makes me uncomfortable. (Dinner helped.) > > By the time the IPv4 module has decided it needs to send an ICMPv4 packet, > it does not necessarily know whether the issue it's reporting is due to > Babel or to some routing protocol. In fact, there might not even be > a well defined responsible protocol -- if a router running both Babel and > BGP finds out that it has no route to a given destination, is the ICMPv4 > packet associated with Babel or BGP? > > Thus, any implementable procedure for sending ICMPv4 must be independent > of any given routing protocol -- so it's not reasonable to have a Babel > dummy address, distinct from a hypothetical BGP dummy address or an OSPF > dummy address. If we define a dummy address, that address must be common > across all routing protocols. > > Not sure how to proceed: > > 1. reuse the 4rd dummy address, as David suggested, repurposing it > to be a generic dummy address? > 2. write a new RFC defining a cross-protocol dummy address? > 3. define a cross-protocol dummy address in this draft? > 4. remain vague, as in the current text? > 5. some other solution I'm missing? > > I'm not volunteering for (2), although I could perhaps be a co-author. > (3) seems like exceeding the scope of this document. (1) and (4) would be > fine with me. > > -- Juliusz > > _______________________________________________ > babel mailing list > babel@ietf.org > https://www.ietf.org/mailman/listinfo/babel > --00000000000029024c05bfe51e39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oh that's a good point, I totally agree.
(1) or (4= ) both seem like the best outcome here.
I think I'm now leaning= towards (4).

David

On Tue, Apr 13, 202= 1 at 3:50 PM Juliusz Chroboczek <jch@irif= .fr> wrote:
> a separate Babel dummy address

I've been thinking about this all evening, and I think I now see what makes me uncomfortable.=C2=A0 (Dinner helped.)

By the time the IPv4 module has decided it needs to send an ICMPv4 packet,<= br> it does not necessarily know whether the issue it's reporting is due to=
Babel or to some routing protocol.=C2=A0 In fact, there might not even be a well defined responsible protocol -- if a router running both Babel and BGP finds out that it has no route to a given destination, is the ICMPv4 packet associated with Babel or BGP?

Thus, any implementable procedure for sending ICMPv4 must be independent of any given routing protocol -- so it's not reasonable to have a Babel=
dummy address, distinct from a hypothetical BGP dummy address or an OSPF dummy address.=C2=A0 If we define a dummy address, that address must be com= mon
across all routing protocols.

Not sure how to proceed:

=C2=A01. reuse the 4rd dummy address, as David suggested, repurposing it =C2=A0 =C2=A0 to be a generic dummy address?
=C2=A02. write a new RFC defining a cross-protocol dummy address?
=C2=A03. define a cross-protocol dummy address in this draft?
=C2=A04. remain vague, as in the current text?
=C2=A05. some other solution I'm missing?

I'm not volunteering for (2), although I could perhaps be a co-author.<= br> (3) seems like exceeding the scope of this document.=C2=A0 (1) and (4) woul= d be
fine with me.

-- Juliusz

_______________________________________________
babel mailing list
babel@ietf.org
https://www.ietf.org/mailman/listinfo/babel
--00000000000029024c05bfe51e39--