Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension

Hitoshi Asaeda <> Tue, 17 March 2020 02:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 20E163A15C7 for <>; Mon, 16 Mar 2020 19:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aVGOzDXXOpa3 for <>; Mon, 16 Mar 2020 19:24:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8488A3A15C6 for <>; Mon, 16 Mar 2020 19:24:49 -0700 (PDT)
Received: by with SMTP id b72so11036540pfb.11 for <>; Mon, 16 Mar 2020 19:24:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=EpNSAzoDyxHBjVOjL04cfL0AlfaIx1yGs42l96ovAk4=; b=c+6YUJOIxUWrYssebhAKyOFYKSNYcGKWNzGfZauoceWtqOE2Nm/O/fCTo5WhBk7gjG ViJL4YqHsn9cE461PZ5TVI4JI/a1ZIJtjZZbHyV8Dq/KZSUxF/NFnEekUltr/bXaa0sm oxuM9IuC+MRCkDMsOdWkEZZDaGg5L3K8jcRS0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=EpNSAzoDyxHBjVOjL04cfL0AlfaIx1yGs42l96ovAk4=; b=Zrzgp74Q1qLgHFKsw5yPwFNrsZXuWQFJirdZNXD6hV5y0X1hViG82KYjsVWGGBv60D kEmTf27wsL5oi05cStJ6uV83e4NIF8n7kfRZ6cb4UlMOSpn8e15vfGUdrL/KjEITj+rB Ak0d+wytbEIpfWXaq6VwIuHQjyq5KVg13aEwOAo+HmZ0OJhs7pXkNjSnoqW7/whyYjew F1iWKVqyE/LMj5sx8901st/VcxzkPfMY4LbQiTWekVkOGUZmMaAFJbhS4w+J1Kj3PYL0 Ipaod7pOP0iIXF+Xp03bpJ+J+Rl/a9k1FOHGln3egieE46/kt3R4ds5fPA1SX8YuIECv nu1g==
X-Gm-Message-State: ANhLgQ0Umhw5hH7ALSsqV/yD1x/jNnxVGSNrqrV4AKJzQFtOxqRDiB2s mrR846JULRDXe6YgR5DP8AmRzmAThPE=
X-Google-Smtp-Source: ADFU+vtvLOxLHOBg/eHNokWjlA7+JxGdNfWJsyCLW12DVbmn4P7d6XoPxgeluMlBUthnGFo1nkSDOQ==
X-Received: by 2002:a65:5688:: with SMTP id v8mr2557556pgs.403.1584411888436; Mon, 16 Mar 2020 19:24:48 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id 73sm722789pgg.90.2020. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2020 19:24:48 -0700 (PDT)
From: Hitoshi Asaeda <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Tue, 17 Mar 2020 11:24:45 +0900
References: <>
To: "" <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [pim] Call for adoption: draft-venaas-pim-igmp-mld-extension
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Mar 2020 02:24:51 -0000


I like the idea and also wanted to add such optional fields in IGMPv3/MLDv2 that can be used for various purposes. The reasons why I hesitated to propose the additional optional fields in IGMPv3/MLDv2 are as follows;

This I-D says;
   The extension will be part of additional data as mentioned in
   [RFC3810] Section 5.1.12 (resp.  [RFC3376] Section 4.1.10) for query
   messages and [RFC3810] Section 5.2.12 (resp.  [RFC3376]
   Section 4.2.11) for report messages.
However, for example, sect.4.1.10 in rfc3376 says;
   If the Packet Length field in the IP header of a received Query
   indicates that there are additional octets of data present, beyond
   the fields described here, IGMPv3 implementations MUST include those
   octets in the computation to verify the received IGMP Checksum, but
   MUST otherwise ignore those additional octets.  When sending a Query,
   an IGMPv3 implementation MUST NOT include additional octets beyond
   the fields described here.
From this last sentence, I understand hosts accepts the longer IGMPv3 query (if the checksum is correct) but ignores the additional fields for the further processes. This may be Ok for existing (conventional) implementations as they simply ignore the additional fields, which they don't understand/proceed. However, you should investigate and mention the situations and conditions in which conventional hosts (that don't support this I-D) and new hosts (that support this I-D) exist in a LAN. Moreover, according to rfc3376, the new hosts that support this I-D must also support rfc3376, which seems a contradiction.

One more another thing is that since IGMP/MLD classifies their version by the packet length, we cannot propose IGMPv4/MLDv3 if you allow this variable length fields in IGMPv3/MLDv2.

If lucky this I-D is accepted, don't forget to refer Lightweight-IGMPv3/MLDv2 [RFC5790] as they also define the standard IGMPv3/MLDv2 formats.



> On Mar 17, 2020, at 8:38, Michael McBride <> wrote:
> Hope everyone is doing well hunkering down.
> Today begins a two week call for adoption for
> Please give it a read (just six pages) and let us know whether or not you support the adoption of this proposal for defining the extensions of IGMP/MLD using a new message type.
> Thanks,
> mike
> _______________________________________________
> pim mailing list