Re: [babel] Dummy source address [was: I-D Action: draft-ietf-babel-v4viav6-01.txt]

[Donald Eastlake <[e-mail]>]

Hi Juliusz,

On Tue, Apr 13, 2021 at 6:49 PM Juliusz Chroboczek <[e-mail]> 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.

OK.

> Not sure how to proceed:
>
>  1. reuse the 4rd dummy address, as David suggested, repurposing it
>     to be a generic dummy address?

  To the extent that it  changes the use of and existing assignment,
it seems a little mucky.

>  2. write a new RFC defining a cross-protocol dummy address?

  It would be a pretty short RFC but it feels like it would cause some delay.

>  3. define a cross-protocol dummy address in this draft?

  That would actually be a fairly typical thing to do. Basically just
replace appropriate occurrences of "Babel" with "IPv4-via-IPv6" so
it's the "IPv4-via-IPv6 dummy address" and just mention in passing at
some point that it "may" be used with other routing protocols that
support IPv4 via IPv6.

>  4. remain vague, as in the current text?

  Seems unsatisfying to me.

>  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.

I don't think (3) exceeds our scope. We need a facility. So we specify
it in our draft. And, just in passing, we are liberal and say others
can use it. There is no need to make a big point of it being
"cross-protocol" and no need to name any other routing protocol(s).

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> -- Juliusz