[pim] PIM light (draft-ietf-pim-light) and PORT (RFC6559)

Toerless Eckert <tte@cs.fau.de> Wed, 09 November 2022 10:01 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 897B6C1522CC; Wed, 9 Nov 2022 02:01:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.96
X-Spam-Level:
X-Spam-Status: No, score=-3.96 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFw702FkU2kr; Wed, 9 Nov 2022 02:01:32 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38335C1594B4; Wed, 9 Nov 2022 02:01:03 -0800 (PST)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 14C8C548509; Wed, 9 Nov 2022 11:00:58 +0100 (CET)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0B4F54EBF8C; Wed, 9 Nov 2022 11:00:58 +0100 (CET)
Date: Wed, 09 Nov 2022 11:00:58 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: pim@ietf.org
Cc: bier@ietf.org
Message-ID: <Y2t6WvgRaI2N+AeH@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/pEPk6YmG5zwZ7TuFhSk5gt_3L90>
Subject: [pim] PIM light (draft-ietf-pim-light) and PORT (RFC6559)
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 09 Nov 2022 10:01:34 -0000

Repeating here on the list what i said on the mike @IETF115, PIM, also Cc' BIER 
WG as hopefully a beneficiary of this work (draft-ietf-pim-light).

We really had a lot of reliability problems under reconvergence of
PIM with large amounts of stte which are well applicable as a problem
to the target use-cases of PIM light, especially with BIER which will
allow up to support a lot of state much better. Thousands of PIM joins
that under routing reconvergence events have to be buffered as a huge
burst and/or vendor specific pacing that reduces convergence performance.

We solved these problems with mLDP and BGP signaling instead of PIM,
and we also then solved them for PIM via PIM over TCP (RFC6559).

I would really like to see:

a) The authors/WG check if/what if any issues threre would be to
   use PORT with pIM light. I hope/expect none, but if there are,
   lets discuss.

b) Include a requirement that PIM light MUST default to use PORT
   and MAY support datagram PIM encapsulation.

Aka: i really see no reason to continue to use datagram encap with PIM light,
so the "MAY" is really just for unforeseen cases.

Cheers
    Toerless