Re: [Bier] [v6ops] IPv6 link-local traffic questions

Toerless Eckert <tte@cs.fau.de> Fri, 13 March 2020 02:00 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 E6A203A0D6C; Thu, 12 Mar 2020 19:00:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.871
X-Spam-Level:
X-Spam-Status: No, score=-0.871 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] 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 Dxj5E7DYLjmz; Thu, 12 Mar 2020 19:00:49 -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 9255A3A0D68; Thu, 12 Mar 2020 19:00:49 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 2EC8C54842E; Fri, 13 Mar 2020 03:00:43 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 26CF7440040; Fri, 13 Mar 2020 03:00:43 +0100 (CET)
Date: Fri, 13 Mar 2020 03:00:43 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Tony Przygienda <tonysietf@gmail.com>
Cc: Erik Kline <ek.ietf@gmail.com>, 6MAN <6man@ietf.org>, v6ops list <v6ops@ietf.org>, BIER WG <bier@ietf.org>, Mark Smith <markzzzsmith@gmail.com>
Message-ID: <20200313020043.GA59538@faui48f.informatik.uni-erlangen.de>
References: <20200312000016.GO54522@faui48f.informatik.uni-erlangen.de> <CAO42Z2zfO9rA8NWfvNgBpWeJgLpuONr39Z2RgForyXCF=PrTrw@mail.gmail.com> <20200312213601.GB34894@faui48f.informatik.uni-erlangen.de> <CAMGpriXhxfM0b4YdCcB9__b=9Us3NosQMXNF4F7QQmeyOUE4Jg@mail.gmail.com> <CA+wi2hPmOq6HOiWE03XGzGMNXH2FrsP4oxieDFLWGo-Gq=ZN6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+wi2hPmOq6HOiWE03XGzGMNXH2FrsP4oxieDFLWGo-Gq=ZN6Q@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/hMqcy_-5RIFKVcZCOqxmZXjrvwI>
Subject: Re: [Bier] [v6ops] IPv6 link-local traffic questions
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: Fri, 13 Mar 2020 02:00:53 -0000

Tony:


On Thu, Mar 12, 2020 at 05:05:01PM -0700, Tony Przygienda wrote:
> interesting exchange and Erik's last observation (ttl=1 and LL for
> multicast) puts it on the point, we are talking here a suggestion for BIER
> control plane where the contained packet is multicast. I would hate to see
> a multicast packet due to TTL > 1 end up in funky place and replicated
> there.

I was actually talking about the "TTL=1" (*) requirement in 
section 2 of draft-zhang-bier-bierin6, and that is an IPv6 unicast
data plane packet, not a multicast packet. It just carries a mlticast packet.

Which packet where you talking about ?

But your point about possible undesirable replication if TTL>1 for
link-local multicast packets is interesting. I had actually not thought
about that, and can not remember an example. Do you have one ?
RFC5082 for once does not mention the words multicast or unicast,
si it's anybody's guess how it feels its recommendation should be
applied (usually mentioning nothing means unicast only, so in that
sense it could be argued to not be intended to apply to multicast).

> Another interesting question is what if the LL source and destination are
> the same and TTL>1 but AFAIK that cannot happen since LL is generated using
> EUI-64 (albeit to my surprise I saw enough customers running same LL
> address on all links of a device & this is valid :-/

Probably not an issue for the v6 encap layer, but the multicast
layer: RPF failure, or bit-reset in BIER for multicast payloads.

> That aside, as I mentioned to Toerless that LL with TTL=1 is usual stuff
> since long time, we are talking here either something like BFD router to
> router

Yes, has been forever for IPv4 multicast link-local and all the
IPv6 link-local i know (e.g.: OSPF). But i just learned from this
thread that IPv6 Neighbor Discovery multicast packets use 255
(predating RFC5082).

I was also interested i there are any rules which HC to use, but
seemingly it is a free choice of the application,  so we (BIER in IPv6)
can decide as we please, we just may need to beat up the 1 vs 255
argument from their technical proc/cons. 

> or now in case of BIER it's suggested to be used as "implicit one
> hop tunnel" basically carrying BIER frame router-to-router instead of ether
> encaps (since BIER is L2.5, strictly speaking "abusing" v6 as transport is
> bit rich but it satisfies things like HOMENET which need mutlicast very
> nicely where the silicon doesn't need to process BIER but processes naive
> v6 easily, after v6 decaps it can go to slow path since HOMENET doesn't
> need any serious mcast throughtput [but nothing special AFAIS if the
> silicon chooses to process it after the decaps when demand arises or when
> used e.g. in core])

May sales pitch would be : Putting something new over L2 can be harder for
wide-ranging adoption, and you need to start thinking about possible L2
differences. Being able tto run it over link-local IPv6 is a nice way
to avoid those issues. I dor for example also have a draft in ANIMA
doing exactly the same thing (not for multicast).

Thanks
    Toerless

> 
> thanks
> 
> --- tony
> 

(*) standard disclaimer: Yes, i do complain to authors using IPv4 terms
for equivalent IPv6 functions, but i complain even more to IPv6 for the gratuitous
renaming of perfect names in IPv6.