Re: [pim] pim-ipv4-prefix-over-ipv6-nh WGLC

Toerless Eckert <tte@cs.fau.de> Thu, 16 August 2018 03:25 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7707612F1A5 for <pim@ietfa.amsl.com>; Wed, 15 Aug 2018 20:25:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham 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 P7xQTnRFeINi for <pim@ietfa.amsl.com>; Wed, 15 Aug 2018 20:25:22 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 9EF01124C04 for <pim@ietf.org>; Wed, 15 Aug 2018 20:25:22 -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 C198D58C4C2; Thu, 16 Aug 2018 05:25:17 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id B022E4402CB; Thu, 16 Aug 2018 05:25:17 +0200 (CEST)
Date: Thu, 16 Aug 2018 05:25:17 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael McBride <Michael.McBride@huawei.com>
Cc: "pim@ietf.org" <pim@ietf.org>
Message-ID: <20180816032517.s73nbs57yplw3c6t@faui48f.informatik.uni-erlangen.de>
References: <8CCB28152EA2E14A96BBEDC15823481A1CCA37C6@sjceml521-mbx.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8CCB28152EA2E14A96BBEDC15823481A1CCA37C6@sjceml521-mbx.china.huawei.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/pIpg2DP2LXb3et1On8yVYbdsi2c>
Subject: Re: [pim] pim-ipv4-prefix-over-ipv6-nh WGLC
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 03:25:26 -0000

Had not read the document for Montreal, sorry.
Did not find discsussions on ML.

It would be good if one of the co-authors would do a
spell/grammer fixup on the document before passing it to IETF/IESG
review. Forces those reviewers to focus more on paylod feedback ;-))
(btw: i am bad on my own documents on this as well).

Is the example topology in figure 1 an eBGP peering ? If so, please
say so in text, otherwise maybe explain a bit more.

What would be a reason to use a setup as in the example topology,
for unicast only, e.g.: in the absence of multicast ? I can think
of two reasons only: one is that you want to avoid IPv4 address
space use, aka: make your IPv4 forwarders unnumbered on the interface
for simplifiction. The other one is that three is some form of
benefit of just having a single address familiy BGP connection.

I am asking, because as soon as you bring in IP multicast, the solution
proposes that you now must have an IPv4 address to support PIM on the
interface. And if one goal of the setup was to be unnumbered on IPv4,
then that goal would be violated. And once you do have IPv4 addressing,
its unclear to me what the benefit is to only haven an IPv6 peering
with mixed address families vs. simple separate IPv4 vs. IPv6 peerings
that match the forwrding plane.

Or the other way around: If you want to get rid of IPv4 signaling, why
then do we not better define how to send PIM joins for IPv4
groups/channels via PIM IPv6 ? If i remember it correctly, all
the address elements in PIM messages do explicitly indicate the AF
as well.

Another concern is that it may be somewhat risky to introduce this option
such a long time after the option was specified but not used. As in:
this might be a great attack vector to crash a neighboring, badly
implemented PIM neighbor acting extremely surprised seeing such an
unexpected AF. For "friedly" evolution of signaling, it might be
better to use a new code point instead.

Cheers
    Toerless

On Tue, Aug 14, 2018 at 01:23:36AM +0000, Michael McBride wrote:
> Hello folks,
> 
> Today begins a two week wglc for informational draft: https://tools.ietf.org/html/draft-ietf-pim-ipv4-prefix-over-ipv6-nh-02. Please give it a read (it's 4 pages) and provide feedback on it's readiness to be sent to the IESG for publication. In Montreal we had 3 in favor, none against. What say you?
> 
> Thanks,
> mike

> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim


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