[RTG-DIR]Re: [pim] Re: [Last-Call] Re: Rtgdir last call review of draft-ietf-pim-3810bis-10

David 'equinox' Lamparter <equinox@diac24.net> Fri, 26 July 2024 23:16 UTC

Return-Path: <equinox@diac24.net>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433D8C14F689; Fri, 26 Jul 2024 16:16:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 6U23tWObRR8S; Fri, 26 Jul 2024 16:16:55 -0700 (PDT)
Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF9A8C14F60B; Fri, 26 Jul 2024 16:16:50 -0700 (PDT)
Received: from equinox by eidolon.nox.tf with local (Exim 4.97.1) (envelope-from <equinox@diac24.net>) id 1sXUAx-00000000InL-3iM9; Sat, 27 Jul 2024 01:16:40 +0200
Date: Sat, 27 Jul 2024 01:16:39 +0200
From: David 'equinox' Lamparter <equinox@diac24.net>
To: Toerless Eckert <tte@cs.fau.de>
Message-ID: <ZqQuV9r1624D4KPZ@eidolon.nox.tf>
References: <171645303257.23265.13071555183433458489@ietfa.amsl.com> <ZqA4pRrSIHbEChRn@eidolon.nox.tf> <PH0PR11MB4966C2F68694E9F69A7B5380A9AA2@PH0PR11MB4966.namprd11.prod.outlook.com> <BL0PR05MB5316D008A5849BA5CE8776ACAEAB2@BL0PR05MB5316.namprd05.prod.outlook.com> <ZqPY9izwyBBh7GKV@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <ZqPY9izwyBBh7GKV@faui48e.informatik.uni-erlangen.de>
Message-ID-Hash: WIFMHEHR4OSMZWHLE2HG4HAOTWFFN77M
X-Message-ID-Hash: WIFMHEHR4OSMZWHLE2HG4HAOTWFFN77M
X-MailFrom: equinox@diac24.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-rtg-dir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Ron Bonica <rbonica@juniper.net>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, Mohamed Boucadair <mohamed.boucadair@orange.com>, Erik Kline <ek.ietf@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-pim-3810bis.all@ietf.org" <draft-ietf-pim-3810bis.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "pim@ietf.org" <pim@ietf.org>, "draft-ietf-6man-deprecate-router-alert@ietf.org" <draft-ietf-6man-deprecate-router-alert@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [RTG-DIR]Re: [pim] Re: [Last-Call] Re: Rtgdir last call review of draft-ietf-pim-3810bis-10
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/jgPGyY8lZj1pu3g0MK7DyH3tWjc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Owner: <mailto:rtg-dir-owner@ietf.org>
List-Post: <mailto:rtg-dir@ietf.org>
List-Subscribe: <mailto:rtg-dir-join@ietf.org>
List-Unsubscribe: <mailto:rtg-dir-leave@ietf.org>

On Fri, Jul 26, 2024 at 07:12:22PM +0200, Toerless Eckert wrote:
[...]
> To the extend of router-alert i think we would want to say "MUST
> support receiving messages with router-alert, SHOULD NOT send messages
> with router alert".

This is the wrong way around.  For any kind of non-catastrophic interop
scenario, it needs to say "MUST send messages with router alert, SHOULD
process received packets with or without router alert."

This is also the only thing I would consider for the MLD bis draft -
weakening this text (multiple places):

  "[...] and if the Router Alert option is present in the Hop-By-Hop
  Options header of the IPv6 packet. If any of these checks fails, the
  packet is dropped."

i.e. adjusting this text in order to allow processing received MLD
packets without router alert option.

BUT this can create "desync" scenarios, e.g. snooping switch requires RA
option, ignores membership report, router doesn't require it, processes
it.

I think I'll switch my position from "no opinion" to "change nothing" at
this point.  Again: I have only raised this issue because it came up in
6man.  Better to have discussed and dismissed this than to regret it
later.


-equi
(David)