[Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling

Rahul Jadhav <rahul.ietf@gmail.com> Fri, 03 June 2022 15:16 UTC

Return-Path: <rahul.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B522FC15AAD7; Fri, 3 Jun 2022 08:16:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 C6lNp4LawkBF; Fri, 3 Jun 2022 08:16:42 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 42935C14CF09; Fri, 3 Jun 2022 08:16:42 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id 25so10306946edw.8; Fri, 03 Jun 2022 08:16:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=mE8aU11MsWRqCIhPtNEGP8H7ZKZRdnJl8QLYlY0wVqw=; b=iTOPdDxNdEbxqN/hZdUEpZYpg5MgN3NgawCmh53qflFjyXvgXZz1iEvi2MeCZTAWGu Falt5UNM2sTGm2qp4wWfQufPI0JImWNctJo2xbkP52S+RuG/a0sTfjWpHWu4UgvZFPTt 6IDabqjLz2wwoiyVLkI+VgAzN28Q1eFiOzLE2/ZFcq/4NYk1dGpu8+ozVY+pcQ9fwR1U CP+oVVTeipqMr48EYlcP3exge3t+Zg//Umy1x/I9ui+vY+yXyPxdP3Uemf0wk32DqiyQ 3C1RVwJcxVGx+75Cuczesakp1Wyf2+vBzVKQhvKQwCmoGF+FmifahK/ZU+ABEr9KehSg DwNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mE8aU11MsWRqCIhPtNEGP8H7ZKZRdnJl8QLYlY0wVqw=; b=XWmK9cstRtxvegrX9Bwl5hfPG7JnBLmC98IXYp09sfpLdWjmnjBYDwhLj8CuJxhhXn PBBRX4Eqe2goiM0KaUWEwQJxXwXCt1XdxkaNZw/eUlyesTRhF16TESlifeZGtOgtQ6tp CVfPHBCMlF0UfJDeChY1tFZp+M7y9Zz0Za6y2uy/KZSiVXeEGRfl6zuRfK/jOzktary+ HwCpcbkd2VV6liDhqBSgDGeCGBFN9Qf6VvYfhDdZeuI5x+ixB5IUdF7ucpJ0nbn9trM9 mTIoGK7/o4xcJM9HQTQHKjPWIz5FCCXCJJ4oUagCSSo4SNEAR47ameaLTdh0ZO4tojUe 8mlQ==
X-Gm-Message-State: AOAM531nj6pMH8eOZC/CqRf6YGnIhdNm6/83xNW1GDqv3KBPhKQzHe7J REyF8ooDnO1d3Ny8GFGoo1v++xuGUCRgke//t/tPnlFtP5c=
X-Google-Smtp-Source: ABdhPJxPBlaXAxoD7GlTDoxXE17B6oduhEorQzV/AqELZCNP3FzSKfhBGXLGOme+iPal8QMKhZNSAVWW9s6CYWldqm4=
X-Received: by 2002:a05:6402:2694:b0:42d:e05d:3984 with SMTP id w20-20020a056402269400b0042de05d3984mr11146254edd.419.1654269400274; Fri, 03 Jun 2022 08:16:40 -0700 (PDT)
MIME-Version: 1.0
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Fri, 03 Jun 2022 20:46:29 +0530
Message-ID: <CAO0Djp3rU3Z_obYmmUdvJ80UjpK4EYfvPNKJckS3BGpdm6TBfw@mail.gmail.com>
To: lo <6lo@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f75cbb05e08c9b68"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/87O7dQAx95OCc94yerCf1uKMS1Q>
Subject: [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jun 2022 15:16:42 -0000

Hello Pascal, Authors,

Thank you for this work. We had discussions before where the ability to
register anycast/multicast addresses for 6LN nodes spanning RPL (or even
non-RPL) network was missing. This work fulfills that requirement.

Following is my review of the draft:
1. storing MOP handling: Even though the draft mentions that storing MOP
should also work, the details seem to be missing (or it might be an
oversight on my side). Consider following instances (for storing MOP):
   a. in the case where multiple 6LNs subscribe to the same multicast
address in the same DODAG, how will the intermediate 6LR handle this
situation? Is it expected that the 6LR maintains state for all DAOs? Note
that the DAOs may come from different paths when the parent switching
happens and thus bloat the state. The only new thing added in the context
is the 'M' flag in the RTO. The path-sequence, TID seems to be getting
mandatorily ignored as per the text.
  b. How would the route cleanup happen for multicast/anycast addresses?

>From non-storing mode perspective, I realize that it will be much easier
handling since the DAO from the 6LR is directly targeted to the root and
thus the root would be able to handle all the complexity.
But the text seem to be loosely specified in the context of storing mode.
For e.g., consider section 5.1 which talks about storing MOP handling... it
states,
 "Though it is preferred to build separate RPL Instances,
   one in MOP 1 and one in MOP 3, this specification allows to hybrid
   the Storing Mode for multicast and Non-Storing Mode for unicast in
   the same RPL Instance, more in Section 10."
This opens up a lot of possibilities and I am not sure how the hybrid mode
would work.

I see text in Section 5.3 that roughly handles some part by stating,
"Like the 6LR, a RPL router in Storing Mode propagates the route to
   its parent(s) in DAO messages once and only once for each address,
   but it MUST retain a routing table entry for each of the children
   that advertised the address."
"MUST retain a routing table entry for each children", is a change from the
default behaviour and thus has impact on backward compatibility which is
not called out in the corresponding backward compatibility section.

What is the preferred mode for sending syntax fixes since I dont see this
draft on github?

Again, thanks for this work.

Best Regards,
Rahul