Re: [Rift] Ipv4 and ipv6 cooperating in rift

Alvaro Retana <aretana.ietf@gmail.com> Thu, 11 July 2019 18:42 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: rift@ietfa.amsl.com
Delivered-To: rift@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EA4120228 for <rift@ietfa.amsl.com>; Thu, 11 Jul 2019 11:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.701
X-Spam-Level:
X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9uG1gFFifnh7 for <rift@ietfa.amsl.com>; Thu, 11 Jul 2019 11:42:14 -0700 (PDT)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 8BFE21200D7 for <rift@ietf.org>; Thu, 11 Jul 2019 11:42:13 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id v15so6798178eds.9 for <rift@ietf.org>; Thu, 11 Jul 2019 11:42:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=QgUsDOqxvstUd9a80rxmxCU7xyjoz9hMH70xDCbwSrs=; b=k12EbDYlvS3vtWjIbazGIY/0tc3EiigSsTsG+mwjgs2iImPtwviqY5Pxn7UwLg1WXz 2kJlPYDgKDJ9EFXtN3EzR826UTyD0XHuPGFs80W7ZEDY8spDymjA1LizWit4cWLzvTDY 0Pgfs30AYD33qE+DRhX7GYfee8w4Zzk+FQXnv9eIDSX2+1wFDYB9phFncbbTSvto0eUI T5mEPbmQeWFQS0+etcDt6mAi2pfee19n0NOGYYUU45K8cBdGddWTqzRzvEriKTVxl+Zc hGkeQ1yV8e4wmzgUG3BAA6LMXqwYqEYJgtR6VXbDFzgt3LCA1Vp6RlI2KKPoahTlqnLM dgHw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=QgUsDOqxvstUd9a80rxmxCU7xyjoz9hMH70xDCbwSrs=; b=cH/55lwxEfZ66fwR6TFHQi+b7W0omn7D1czPfvz5TeBxXMERYjY5rd4cuCcsASek5p 80LDEbVIL8u/vuGHHgd1PyBMbWAE6YjB21nEjOxhZ3u6FNVG6gi6/jAJguTdyzoJnoqr U6+Z3m4xctkUtJ/TXRhSXdv0cYN9zJK7XUQykrMieYiTo95JAwwgLDNW94Riv82tPPap dyXt1MOSvq3rVqbf3bzFsr6FJCWzsCgUblm9o79pU4MiVkBramy4SCRDimqu+TgdbUSf /YY+V5WetPgI4wYroS0ZAD4Rigzn6D6JMVpl/DXQWFRK/uUnh3Tstff0qY9FRVPzMNAK KZPg==
X-Gm-Message-State: APjAAAWYH7Y6hNhgjusI58wvQzeEO8Q8IGQ6jQ+Is+5eOY6yb8Yabhdp FtdSfA0Kocch1pF3fsM0SPLa8IRlsQnH/t5C4sk=
X-Google-Smtp-Source: APXvYqyqMGoa1ghJRu9WH5BYy8Z8CYtv1EDSpdUb3ggzqJcRk0DnVO76H4enf2k+OSzvW+gJ0hvVG9864JHWkpZHrXI=
X-Received: by 2002:a17:906:505:: with SMTP id j5mr4546675eja.261.1562870532174; Thu, 11 Jul 2019 11:42:12 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 11 Jul 2019 11:42:11 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MWHPR05MB3279BAF107468754E6FD72EBACF30@MWHPR05MB3279.namprd05.prod.outlook.com>
References: <201907101656125835263@zte.com.cn> <MWHPR05MB3279B78E6D9AECB771D2497FACF00@MWHPR05MB3279.namprd05.prod.outlook.com> <CAMMESsyLRtyTaMTFqzuizuNgxfRm6iuFqfun-711ayq5H4Cb8A@mail.gmail.com> <MWHPR05MB3279BAF107468754E6FD72EBACF30@MWHPR05MB3279.namprd05.prod.outlook.com>
MIME-Version: 1.0
Date: Thu, 11 Jul 2019 11:42:11 -0700
Message-ID: <CAMMESszEFviA+yEH27CsiGU3QHpCm95SHz+EPPWYL6v5sJE-wQ@mail.gmail.com>
To: Antoni Przygienda <prz@juniper.net>, "xu.benchong@zte.com.cn" <xu.benchong@zte.com.cn>
Cc: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "rift@ietf.org" <rift@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e67884058d6c26c6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rift/cDBmbtlEfMZ-I9-x84ls8uG22-g>
Subject: Re: [Rift] Ipv4 and ipv6 cooperating in rift
X-BeenThere: rift@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Routing in Fat Trees <rift.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rift>, <mailto:rift-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rift/>
List-Post: <mailto:rift@ietf.org>
List-Help: <mailto:rift-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rift>, <mailto:rift-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2019 18:42:17 -0000

Tony:

Hi!

As I said before, I may be jumping in without proper context…. I just want
to make sure that we don’t end up with discussions about the charter or how
much it may or may not reflect reality later in the process.  If a change
needs to be made, better sooner than later…if no change is needed, then
we’re good. :-)

Alvaro.

On July 11, 2019 at 11:49:12 AM, Antoni Przygienda (prz@juniper.net) wrote:

Alvaro, protocol specification requirements and router running the protocol
requirements are AFAIS not the same thing. And the distinction is
meaningful here.

So, the protocol DOES support IPv6 and it DOES suppoort IPv4 so it does
fulfill the charter you refer to perfectly.

not to the requirements _of devices runing RIFT_:  we cannot mandate that
everyone in reality will run IPv6 forwarding on the fabric so the reality
is that every silicon does IPv4 today and some does IPv6. And then IPv4
over IPv6 is reality while IPv6 over IPv4 is not (since IPv6 does ND anyway
so why would you).  So it is very good for v6 here to basically make it an
implicit transport for v4 (by saying running v6 does _automatically_ give
you v4 forwarding) while making sure that v4
being-de-facto-what-e'one-can-do is the lowest common denominator of the
router's running RIFT. RIFT being only usable if a router/switch can do
IPv6 is simply not a practical proposition AFAIS.  We could arguably split
it into a "RIFT router/switch requirements document" but that seems just
paper bloat ...

So I think we are meeting the charter mandating protocol specification
perfectly while @ the same the spec is aligning with reality of v4ov6
forwarding without v4 addresses. We could just as well remove the sentence
and everything would work except we'd end up in lots of
discussions/possibly non-interoperable implementations in regards to v4
forwarding when no v4 addresses are present and people considering things
undeployable until all the silicon in the world does v6 and everyone runs
v6 by default everywhere. Which may happen but not in a foreseable future I
can discern ...

I hope I do make sense ...

--- tony


------------------------------
*From:* Alvaro Retana <aretana.ietf@gmail.com>
*Sent:* Thursday, July 11, 2019 8:15 AM
*To:* Antoni Przygienda; xu.benchong@zte.com.cn
*Cc:* rift@ietf.org; EXT-zhang.zheng@zte.com.cn; Jeffrey (Zhaohui) Zhang
*Subject:* Re: [Rift] Ipv4 and ipv6 cooperating in rift

On July 10, 2019 at 11:05:40 AM, Antoni Przygienda (
prz=40juniper.net@dmarc.ietf.org) wrote:

Hi!

I might be jumping in without proper context, but this text caught my
attention...

b) If you want the "laziest" possible implementation then in fact yes, you
can fall back on

"

All RIFT routers MUST support IPv4 forwarding and MAY support IPv6
   forwarding.  A three way adjacency over IPv6 addresses implies
   support for IPv4 forwarding.

"

…because the WG Charter says that "The protocol must support IPv6 and
should also support IPv4.”   So the text above contradicts the Charter.

Alvaro.