Re: [Bier] BIER in IPv6 --- draft-zhang-bier-bierin6-04

Toerless Eckert <tte@cs.fau.de> Thu, 26 March 2020 20:13 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C45C3A09D9; Thu, 26 Mar 2020 13:13:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 akyvYAquQR3D; Thu, 26 Mar 2020 13:13:57 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7F13A0C88; Thu, 26 Mar 2020 13:13:56 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6716F548015; Thu, 26 Mar 2020 21:13:51 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5F3A7440040; Thu, 26 Mar 2020 21:13:51 +0100 (CET)
Date: Thu, 26 Mar 2020 21:13:51 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: BIER WG <bier@ietf.org>, 6MAN <6man@ietf.org>
Message-ID: <20200326201351.GB30139@faui48f.informatik.uni-erlangen.de>
References: <CABNhwV00MFZ794q2QOiLA2p51O8m5w6oG6AUwQaCMpMa1A_r+w@mail.gmail.com> <202003261725503637966@zte.com.cn> <CA+wi2hPSPVnaSLps-2qw5kjsf5-KtiWGSu9cx6p3y1wbSckNtQ@mail.gmail.com> <20200326184414.GA30139@faui48f.informatik.uni-erlangen.de> <CA+wi2hMg52V+WmYEQk5kLoUsvqZ_8C4qMFjiRREKp6t4N3CM4w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+wi2hMg52V+WmYEQk5kLoUsvqZ_8C4qMFjiRREKp6t4N3CM4w@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/RK5QcIb62MweyUc0qdo4J1dTFHo>
Subject: Re: [Bier] BIER in IPv6 --- draft-zhang-bier-bierin6-04
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Mar 2020 20:14:16 -0000

On Thu, Mar 26, 2020 at 12:05:30PM -0700, Tony Przygienda wrote:
> On Thu, Mar 26, 2020 at 11:44 AM Toerless Eckert <tte@cs.fau.de> wrote:
> 
> > On Thu, Mar 26, 2020 at 09:11:16AM -0700, Tony Przygienda wrote:
> > > Yes, critical point. We are _not_ "tunneling" in case of LL to LL BIERin6
> > > in fact for all practical purposes (tunnel assumes fragmentation/security
> > > etc which BIER architecture does NOT presume from L2 header, we do not
> > > expect Ethernet to fragment or encrypt BIER).
> >
> > When you say "We" your hat is that of a co-author ?
> >
> >
> yepp, co-author of the original bierin6 draft obviously ...
> 
> Asking in wider scope: while reading the rest of your email: are you
> implying that BIER WG should be in the busines of, as a previous
> commentator put it, inventing yet another L3-routed source-specific
> multicast tunneling technology?

Until i know what you're trying to imply with the word tunneling, i
have to guess ... lets simply talk about the properties we
want/do-not-want.

The BIER architecture RFC very nicely points to the fact how BIER 
can automatically determine remote neighbors to hop over non-BIER
enabled routers. Benefit of relying on the IGP. I think it would
nice if this can be leveraged in our IPv6 solution, but it only
makes sense if we can reasonably expect that a good amount of
devices can do this in the "fast-path" like hop-by-hop. I think
thats possible with both drafts.

I am not persuased that link-local encap+decap on every hop is
faster in HW data-plane than rewriting IPv6 header elements. I
have seem many forwarding planes where encap/decap would cause
recycling.

Functionally, the main difference between the drafts IMHO is that Xie's draft
uses the IPv6 header to carry VPN info, whereas i do not understand
how we would do this in Sandy's draft.

Cheers
    Toerless

> -- tony

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


-- 
---
tte@cs.fau.de