Subject: [babel] Warren Kumari's No Objection on draft-ietf-babel-v4viav6-07: (with COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Thu, 17 Feb 2022 07:39:47 -0800

Warren Kumari has entered the following ballot position for
draft-ietf-babel-v4viav6-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for a well written document.

Other than my discuss, I only have a question:
Section 5 (Backwards Compatibility) says:
"As a result, incompatible versions will ignore v4-via-v6 routes. "

Is it *always* safe for a babel router to ignore a route? I really haven't
thought about it enough (and the fact that it is DV based makes me think that
it should be fine) but I'd like some reassurance that it is, especially in the
case that a prefix is originated by multiple routers, and one of them gets
filtered/ignored.

[ Edit: Changing DISCUSS to NoObj with the understanding that it will be
revised to Experimental ] Original DISCUSS for hysterical raisons, because I
want to capture the desire for a future document that fully describes v6-via-v4
next hop :
----
I'd started balloting this as Abstain, but while writing up the ballot I
realized that it's important enough that it deserves to be DISCUSSed.

This is clearly clever, but feels to me like it might fall into "Oo, you are so
sharp you’ll cut yourself one of these days"[0] territory.

I'm not saying that the "v4-via-v6" is a *bad* idea, but I really don't think
that it should be introduced / documented in a Standards Track Babel document -
it touches core plumbing, and should be discussed and documented in a V6OPS (or
6MAN) document, and then this document includes it by reference.

If this was only ever going to used in Babel environments I'd be much less
concerned, but I suspect (hope?) that future solutions will want to do very
similar things, and that it needs to be reviewed with an assumption that it
might get widely used. It should documented in a "self contained" manner so it
can be cleanly referenced - at the moment, a reference would need to point at
bits of Section 1 and 3, and there is some feeling of "this is probably safe,
the 192.0.0.8 bit might make operations / debugging a bit harder, but...
¯\_(ツ)_/¯"

If this has already received significant discussion in V6OPS / similar, or if
it is already clearly documented elsewhere[1], I'll clear my DISCUSS and
Abstain or support it.

I'm sure that this DISCUSS will be frustrating to the authors/WG - I'm doing so
because I'd like to see this technique more able to be used (and make sure that
there aren't any sharp pointy bits), not because I think it's a bad idea...

[0]: quote from Terry Pratchett, Thief of Time
[1]: I suspect it is already documented somewhere, but the closest I can think
is RFC7600 - "IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)",
an Experimental document which is noticeably different to this. If it *is*
already documented somewhere else though, then why is this not just referencing
that instead?
----

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 17 Feb 2022 18:13:04 +0100

> case that a prefix is originated by multiple routers, and one of them gets

(I assume that by "safe" you mean "preserves Babel's loop-avoidance properties".)

Yes, dropping updates preserves Babel's loop-avoidance properties.  The
proof of the loop-avoidance properties of Babel never assumes that
a packet cannot be repeatedly lost (it only relies on the hypothesis that
a packet is never received before it is sent, i.e. that the happens-before
relation is acyclic).

An intuition that some people have found useful is that Babel is based on
principles similar to BGP: if something is trivial in BGP, then it's
probably easy in Babel; if something is tricky in BGP, then it's difficult
or impossible in Babel (for example, we don't know how to do aggregation
in Babel, since it's not clear how to map an AS-Set to a Babel feasibility
distance).

-- Juliusz

---

From: Warren Kumari <[email-masked]>
Date: Tue, 22 Feb 2022 21:30:54 -0500

> (I assume that by "safe" you mean "preserves Babel's loop-avoidance

Yup!

> a packet is never received before it is sent, i.e. that the happens-before

Awesome, thank you.

> in Babel, since it's not clear how to map an AS-Set to a Babel feasibility

Excellent, thank you -- that's a helpful bit of intuition / analogy  /
comparison / $something to know.
W

-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra