Subject: [babel] Warren Kumari's Discuss on draft-ietf-babel-v4viav6-07: (with DISCUSS and COMMENT)

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 15 Feb 2022 08:39:30 -0800

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

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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?

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 15 Feb 2022 10:54:07 -0600

> https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/

Someone pointed out to me (off-list, probably in an attempt to spare me
embarrassment on the assumption that I'm not already used to looking
foolish) that e.g BGP advertising v6 next hops for v4 does some similar.

That's entirely true, but I don't remember (and I'm on my phone at the
moment and cannot easily check) much discussion on things like how to deal
with things like sourcing packet too big, etc.

If this is all already covered and discussed elsewhere, I'm happy for the
document to point at that, and we'll be good...

W

> --
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Feb 2022 14:52:41 +0100

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

This implies finding a volunteer willing to spend a year of their life
getting such a document through v6ops, with no guarantee of getting
through the IESG at the end.  Do you have anyone in mind?

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 16 Feb 2022 18:57:53 -0500

Hi Warren,

Would you be satisfied if the target status of the draft was changed
to Experimental? From what I have seen, I believe the WG would not
oppose that.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

On Tue, Feb 15, 2022 at 11:54 AM Warren Kumari <[email-masked]> wrote:
>
>
>
> On Tue, Feb 15, 2022 at 10:39 AM Warren Kumari via Datatracker <[email-masked]> wrote:
>>
> Someone pointed out to me (off-list, probably in an attempt to spare me embarrassment on the assumption that I'm not already used to looking foolish) that e.g BGP advertising v6 next hops for v4 does some similar.
>
>
> That's entirely true, but I don't remember (and I'm on my phone at the moment and cannot easily check) much discussion on things like how to deal with things like sourcing packet too big, etc.
>
> If this is all already covered and discussed elsewhere, I'm happy for the document to point at that, and we'll be good...
>
> W
>
>>

---

From: Warren Kumari <[email-masked]>
Date: Wed, 16 Feb 2022 18:18:09 -0600

> to Experimental?

Yup, That would make me happy enough to clear my DISCUSS. I'd still really
like it if someone were to write up the v4-via-v6 next hop forwarding in a
standalone document at some point in the future, because I really do think
that it would be valuable.

I'd love to be able to commit to doing it myself, but realistically am not
likely to get around to it...

I'd hope/ assume that if such a document is created, we'd also update this
to Std Track and say "just like RFCxxx says..."

W

>From what I have seen, I believe the WG would not
> oppose that.
>
> Thanks,
> Donald
> <https://www.google.com/maps/search/2386+Panoramic+Circle,+Apopka,+FL+32703+USA?entry=gmail&source=g>
>  [email-masked]
>
> >> Please refer to
> https://www.ietf.org/blog/handling-iesg-ballot-positions/
> think
> > If this is all already covered and discussed elsewhere, I'm happy for
> the document to point at that, and we'll be good...
> >
> > W
> >
> >>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 24 Feb 2022 18:28:15 +0100

> 6MAN) document, and then this document includes it by reference.

The document has been made Experimental, as you propose.

> I'm sure that this DISCUSS will be frustrating to the authors/WG

Not really.  We're planning to deploy this spring, barring any unforeseen
issues, and the document being Experimental will make it easier to say "we
told you so!" when we've broken everyone's networks ;-)

-- Juliusz

---

From: Warren Kumari <[email-masked]>
Date: Thu, 24 Feb 2022 14:45:22 -0500

> The document has been made Experimental, as you propose.

... and just for completeness, I've already updated my ballot to NoObj.

> told you so!" when we've broken everyone's networks ;-)

:-P
W

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