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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 22 June 2022 13:51 UTC

Return-Path: <pthubert@cisco.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 CEB26C157B5B; Wed, 22 Jun 2022 06:51:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.604
X-Spam-Level:
X-Spam-Status: No, score=-14.604 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VmqHP7jO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=s8iHys2C
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 pR_Yh7FMIGcL; Wed, 22 Jun 2022 06:51:38 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F6C2C14F724; Wed, 22 Jun 2022 06:51:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64752; q=dns/txt; s=iport; t=1655905898; x=1657115498; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IeoDN1vMCXakQKAO7N6wZh4rl1d+QeoMFPqq7KJtXrY=; b=VmqHP7jOYhc3vf1E50D1VeaHH5dhREpbWx6ASxrMjER5qsDDjFF2ofTO +w/Hhg2eIEFVe81VQrvfVLkiwIhGlBbYE6JJDztA/4DClDDbcEfICTc59 IdtltepeFDqNhzdu/vVO2cRIuXPIl/Uq70sB4MAypXOfCUGUlDI9h6fev g=;
X-IPAS-Result: =?us-ascii?q?A0D6AACZHbNimJ1dJa1aHgEBCxIMggQLgSExUn8CWTpEh?= =?us-ascii?q?E6DTAOFMYUKgwIDgROPOYpzgSyBJQNPBQsBAQENAQEsAQwJBAEBhQMCFoUzA?= =?us-ascii?q?iU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBBwQUAQEBAQEBAQEJFAcGD?= =?us-ascii?q?AUOECeFaA2GQgEBAQECAQEBEBEKEwEBLAsBBAsCAQgRBAEBDRQBBgMCAgIlC?= =?us-ascii?q?xQJCAIECgQFCBqCWwGCDlcDDSMDAQ6fLQGBPwKKH3qBMYEBgggBAQYEBIE3A?= =?us-ascii?q?QMCEEGCfxiCOAMGgT2DFoMKXkoBAYcrJxyBSUSBFUOBZko3PoJiAQECAYE/I?= =?us-ascii?q?BUWCYMgN4IugW4KaY8QhxoHOANHLxKBIG4BCAYGBwoFMAYCDBgUBAITElMcA?= =?us-ascii?q?hIMChsOVBcMDwMSAxEBBwIJEggVKwgDAgMIAwIDKQIDFgkHCgMdCAocEhAUA?= =?us-ascii?q?gQRHgsIAxkeLAkCBA4DQggLCgMRBAMTGAkWCBAEBgMILw0nCwMUDQEGAwYCB?= =?us-ascii?q?QUBAyADFAMFJAcDIQ8mDQ0EGwcdAwMFJQMCAhsHAgIDAgYVBgICbi4NCAQIB?= =?us-ascii?q?DckDwUCBy8FBC8CHgQFBhEIAhYCBgQFAgQEFgIQCAIIJxcHEzMZAQVZEAkhH?= =?us-ascii?q?CkKBgUGFgMjbgVFDyg0NjwsHxsKgRssKxsDBAQDAgYjBQQgmiprBjI2IiEOA?= =?us-ascii?q?iE6IBY6MhYgRJIDEINaigKODZFggScKg06LIJUQFYN1jEORNIZ3lm4ggiuKZ?= =?us-ascii?q?JRNCAsNA4RvAgQCBAUCDgEBBoFhghVwFTuCaFEZD44gDA0JFYM7hRSFSnUCC?= =?us-ascii?q?TACBgEKAQEDCYZHiDoBAQ?=
IronPort-PHdr: A9a23:R7Etsxw61FivnRfXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv
IronPort-Data: A9a23:8ox0eKu4qW6rbKWuW+505YhWpOfnVHpeMUV32f8akzHdYApBsoF/q tZmKT+CPvzca2Hwf4xzboXjoBgE6sWDz4VmSlZt+CwyHiMXgMeUXt7xwmUckM+xwmwvaGo9s q3yv/GZdJhcokf0/0vrav67xZVF/fngqoDUUIYoAQgsA14+IMsdoUg7wbRh3NQy2YLR7z6l4 LseneWOYDdJ5BYsWo4kw/rrRMRH5amaVJsw5zTSVNgT1LPsvyB94KE3ecldG0DFrrx8RYZWc QpsIIaRpQs19z91Yj+sfy2SnkciGtY+NiDW4pZatjTLbhVq/kQPPqgH2PU0NmhIkAypovRKx +pEk46aaCYAJbGWh7FIO/VYO3kW0axu4rTLJz20ttaeihOAeHr3yPIoB0YzVWEa0r8oWicVq rpJc3ZUM0/ra+GemNpXTsF0msQ+JsTxIKsUu2prynfSCvNOrZXrE/SbuIIIg2xq7ixINfnCW 9s9YAZsVgbZTTFKE2cQWY84sPj90xETdBUB+A7K+sLb+VP7kgh2+LngLNSTfcaFLe1PmUKcj mPL42q/BQsVXPSFwDqY9jSti/PBtSz+UYMWUra/85ZXbEa73GcfDlgdUkG25Kf/gU+lUNUZI EsRksYzkUQs3BOEUcLEfyCcm3G7tzgOcftxOvYmsh7Yn8I4/D2lLmQDSzdAbvkvu8k3WSEm2 ze1czXBWGEHXFq9FCn1y1uEkd+hEXNPfDNdP0foWSNAsoe8+Nts5v7aZow7eJNZmOEZDt0ZL 9qilik1h7wJgdUM0c1XFniY3mr8//AlouPJjzg7s0q/5Q9/IYWifYHttx7Q7O1LK8CSSVzpU Jk4dyq2sbBm4XKlzXHlrAAx8FeBvK7t3Nr02gcHInXZ327xk0NPhKgJiN2EGG9nM9wfZRjia 1LJtAVa6fd7ZSX3MP8sPdjqU5pxlsAM8OgJsNiJMbKihbAsKWe6EN1GPiZ8Iki0yhF3yPFjU XtlWZ/wVSdy5VtbIMqeHrdBjuBDKtEWzmLITpez1AW8zbebfxaopUQtbjOzghQCxPrc+m39q o8HX+PTkkk3eLCuM0H/rN9IRXhXfCdTLc6t8aR/KLXcSjeK7Ul8UZc9N5t7Jdw890mU/8+Vl kyAtrhwmASl3yaad1rRAp2hAZu2NatCQbsAFXREFT6VN7ILOO5DMI93m0MLQIQa
IronPort-HdrOrdr: A9a23:o3Qbd616LXGEON8dNBB2pAqjBRlyeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5AEtQ5uxpOMG7MBfhHO1OkPcs1NaZLUbbUQ6TTb2KgrGSuwEJlUfFh5VgPM tbAspD4ZjLfCRHZKXBkUeF+rQbsaO6GcmT7I+0pRoMPGJXguNbnnpE422gYypLrXx9dOME/e 2nl6x6TlSbCBEqR/X+IkNAc/nIptXNmp6jSwUBHQQb5A6Hii7twKLmEjCDty1uEg9n8PMHyy zoggb57qKsv7WQ0RnHzVLe6JxQhZ/I1sZDPsqRkcIYQw+cyjpAJb4RGIFqjgpF5d1H22xa1O UkZC1QePib3kmhPF1dZyGdnTUIngxeskMKgmXo8EcL6faJNA7STfAx3b6wtnDimhAdVBYW6t MR44vRjeslMTrQ2Cv6/NTGTBdsiw69pmcji/caizhFXZIZc6I5l/1UwKp5KuZJIMvB0vFtLA CuNrCq2N9GNVeBK3zJtGhmx9KhGnw1AxedW0AH/siYySJfknx1x1YRgJV3pAZNyLstD51fo+ jUOKVhk79DCscQcKJmHe8EBc+6EHbETx7AOH+bZV7nCKYEMXTQrIOf2sR52Mi6PJgTiJcikp XIV11V8WY0ZkL1EMWLmIZG9xjcKV/NFAgFCvsukaSRloeMMYYDaxfzOmzGu/HQ18kiPg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.92,212,1650931200"; d="scan'208,217";a="899558732"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jun 2022 13:51:37 +0000
Received: from mail.cisco.com (xfe-aln-005.cisco.com [173.37.135.125]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 25MDpa15006039 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2022 13:51:36 GMT
Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 22 Jun 2022 08:51:36 -0500
Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 22 Jun 2022 08:51:36 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZyHqkDPWDLYDPFQnn6MKGwS9/OXWE1kjJWGy51X33qKDYNYBBq8RKWJG+4iaVF2npuFaGmQVMLZ1jpkh88CYUjSP7LbfiaMlbayAv3yQ6UNWt2kE7YGo/hVMjwQsp/IWe2tSPqX5CfuT7saFHx4vpvDI/0MM0Uqng560kta3EV8UMDyb2tqsNnSV0JqT8WUz0hxfITlVEqZCwg1VFXXwDqqdnaC/zxJJTU7HVny5YC+rAZgjjCdYxt03dpdp31NGoBtiZFzMxkFe6zQv+G+bfR6TrEPPXPn6bdWf1TT+ABo7EZyh4jqdEemjOPLPMZNmrsIqVIFzT1zGd5oMx8hh0g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=IeoDN1vMCXakQKAO7N6wZh4rl1d+QeoMFPqq7KJtXrY=; b=cqqSvStDGp9QVHHa9SUNFpmYKEULW5wBqk8QSqVIj5fD4+oShgEkE/Ukiz0IY5tyydFz2IXrb7hx4TCoBYQjaGOSBmfP8bDJUPY5I73UWVpIId4wP5Z0umCE3tdvPHBs0f4Jrb91HX5BfRZdjqC7rW7p68wQX92/6RAiMLgS0ERETMFxmfIyBjda3F6jWqFbSox2sPJ9ha5wnFKrtlQ/537N1W45O91g3hD5QFoTfv2L4JRTBeen2/eVcc/aM5aRMPHi47hpCWc3ASjJZadV+2X13QT54X6fcs1Ad9H2VGcmcPU/VfCP38bLAhA0DhgdqDnkXWwJHgAFzm+yr/9IpA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IeoDN1vMCXakQKAO7N6wZh4rl1d+QeoMFPqq7KJtXrY=; b=s8iHys2CGKpW2kSAtrddtHbESM8XjWlVer75dXBMAu0+Y9IiAlx+l15ojf1dhCLDLjnQ2p90SHVhHzwJFm27oeS/J2j/l2NibH/oigskXqtMq8piZA1JnMSFRTiElXB55ARekkD1wIdyPk8L0CKqksGxU5dndCrshkvmwI0FhfU=
Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW4PR11MB5774.namprd11.prod.outlook.com (2603:10b6:303:182::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5353.18; Wed, 22 Jun 2022 13:51:35 +0000
Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::8136:7f6a:45e:1d16]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::8136:7f6a:45e:1d16%8]) with mapi id 15.20.5373.015; Wed, 22 Jun 2022 13:51:35 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>, "Routing Over Low power and Lossy networks" <roll@ietf.org>
CC: lo <6lo@ietf.org>
Thread-Topic: [6lo] [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling
Thread-Index: AQHYd1z0sQO0gqqlCUyrNFA4rJUS461FnYvggAZrG4CAD4MlQA==
Date: Wed, 22 Jun 2022 13:51:22 +0000
Deferred-Delivery: Wed, 22 Jun 2022 13:50:40 +0000
Message-ID: <CO1PR11MB4881CD09B72B9AE0D29F0F6DD8B29@CO1PR11MB4881.namprd11.prod.outlook.com>
References: <CAO0Djp3rU3Z_obYmmUdvJ80UjpK4EYfvPNKJckS3BGpdm6TBfw@mail.gmail.com> <CO1PR11MB4881549A04FC95BA9061C3A2D8A49@CO1PR11MB4881.namprd11.prod.outlook.com> <CAO0Djp1z1P=4TxaCR3PQFcVESax=2pPVLZta-sYbF4T3gH6HXQ@mail.gmail.com>
In-Reply-To: <CAO0Djp1z1P=4TxaCR3PQFcVESax=2pPVLZta-sYbF4T3gH6HXQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f96a440a-3a32-4fb6-24d8-08da54565245
x-ms-traffictypediagnostic: MW4PR11MB5774:EE_
x-microsoft-antispam-prvs: <MW4PR11MB5774643853DCB639C4A3B988D8B29@MW4PR11MB5774.namprd11.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: qANW73F4EvBtO+gpb7AJ78V52F7tR0HF9ak73iIPMHy/DPqBezUjH7P2Qv9yDX5TI4GlxqedHqJi7p76mXTjqLi8mU78qzQXvXm9yifyzslLhbQ045pEVY3/RhPYrgWI4UB9kW4Mv7JpoHg5DfPSmQPV/Uub+GgfQujPiTTpaUkX14KlsmIPC+IMOT5XPppMBfJOFRihZGXCsfJhuxIIjku/4y/dNHjiPh6pWytLkcA/fi23hgPDA3rz83hHfuRBbTW6Ti4YcTS1hTKtxA1nNHhmw94zd9dMY3ifRM1/NWXOR5mXcJs71cFApbWv+k39xsdzoSx3Ln52eH92/jisQWk63hhiWC+d6qdLJGuhoLHatgWMuDiavWmcOb184Rd98htRG4nP28LReIHqBhh+WYfbjNvu4SRStJ/eHo++baQE9CrL+YI725r6rZzKsw0db/3w9VWKBy2VENxrbIFEsb8FJOPgmRNgqGBiuEqnQP3P7Aywi9p9/YFyoioJ8nuRN1MtP6XnzkFiVfCZ8mnTE9jX3yaDhvr6hmISnkHXiIzKeeHzODk1yd9WhAUASDp86aYnMfHYLtFvKryw2PRaEurHT6QEpEc5lxMZoGsMRUe/StcwsGsOi9Y22Qx/gNUmKTzvNi4jCCMawR0wQ4J+naT2tJSH1NDwVkUivH7ZrvnAwMyKSeAjZILM7g8HJFDZ3JZtzYgS6oXEA7fIvpD2s/qBC0qBpV96yWdgUhWOojUAdlRgG7YvhD5epHSsdeEgabDG+SeaaZ6zJHNjB54hXmwHMvoZ03aX9C+5/SytCnsTJ+Bp0CbyTFWlxOa9iTqLt49Qp/zIHsFyl1dd5otuCg==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(39860400002)(136003)(376002)(396003)(366004)(346002)(122000001)(38070700005)(52536014)(110136005)(186003)(316002)(33656002)(83380400001)(26005)(66574015)(2906002)(71200400001)(5660300002)(7696005)(8936002)(966005)(64756008)(76116006)(4326008)(66476007)(478600001)(6506007)(6666004)(66556008)(66446008)(53546011)(66946007)(8676002)(55016003)(9686003)(38100700002)(86362001)(41300700001)(166002); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TDZwUlJRNUZVdnFGUWlqR2lXQmNrRUpuTGlvQWVvdmdIQ3lJK2YwSHlXbkM1?= =?utf-8?B?Rzl0R05Fc3VIcmJhTno5ejlkVlNOSWlhbE9za0FhcklvWU1MemEyQVhoVHRG?= =?utf-8?B?WEdEeW44R3NsVkdBOFloU2d4a0x2UStya0JoMGlScnpNK05YMGJmVzg5bjRS?= =?utf-8?B?dVowZzVFRTI4TG1LS3FQT2ZUajVWdFlNSmtqaHRYRFJBTU5rWDg3eXlxVlB6?= =?utf-8?B?T041NlV0ajh2Zm5UNDFSeU0vdWtuckYraHVEa0NSRW1xaWxaK3RackNUNE9X?= =?utf-8?B?aTIyb0FBT0o0OWsySms1MENnV2Jrb0pZbU1GUWdITzh6Z0h6RFVIeEJxOXBz?= =?utf-8?B?VHZSVFVydkIxRHFhSi9JeDVnL0xXRWRyalFsZUZvamwxUG5RblU1bkNhR0FV?= =?utf-8?B?eEJ4eFZWdkxSdllNL2xnMWQ2MEhmUERyaUUzejZUeHdkS1l0MnBaS2RrSFJH?= =?utf-8?B?UUlvbkp3U0R0V1p2bjgrVHU5OU9XRzlxWW0vZWhYQVpSMFcreTF3cUt4Q2dL?= =?utf-8?B?djQ2Nm5DY3BiSkRzVWIxZjZOTVpoQnRBWEFodG9pM1V3U3UyM2FBMmJQM05m?= =?utf-8?B?c1Jlb3pTSy80QW0yWmVqemp6SlJTWDllU0NkTWZzRlZkMVhUWFBOUFlCVGJY?= =?utf-8?B?eFJaUVpWditLRys5Q1ZueVFyYytVMHN0N01aWkViWVVlR0FndEYwQnQwUHEv?= =?utf-8?B?RGtPamQ3dzZTck42RjNIbGhIN3FranpWNlUrbldZQkErUm9oVWFGUEVFRXJy?= =?utf-8?B?bG9RSzVGOEV5K2dmNTh5MjZndzlNZ0lxb3VYRWk3RzlEUkt2SHc2WkYvQ0pw?= =?utf-8?B?WHh5dm1Sc01iakZ5RnBnRWQ1SEhDTUM5NXhoQmh1b2g4RmJNV1ppV25jc0dF?= =?utf-8?B?VUY5LytLSFRDOUpPem9lZngrNWVpd251dlVyRUE0UVg5VkJiaklMSkdHaEty?= =?utf-8?B?OHdWS3JzSFNoMEtrVDgzN01lRVp3OTZra2xvcUFRQ0FCM09NOXgydDlHbnVE?= =?utf-8?B?bGtVMGp0QitpUlgvN0ZpOHNRVTdYdUUxSm16RW8zcEdyL3pWK0RlM0dHQzdk?= =?utf-8?B?cEpyVWtPaWhQYmxyeHM1Mk5NbW9KYW9yUEpKY3N6SE9ucnFILzFoR0JIMGZQ?= =?utf-8?B?cXN4TzYvNGxSUGFTMWxJTXdKZHFBRjlBTFlFUTJPWWdIcHlrd2hxeUhiUUw2?= =?utf-8?B?cDUzWVJDSzlKVkNTSnUwMEZHSHJuK0xJaHRMWW5UY0VTZmRva1VHT3MvMGxU?= =?utf-8?B?YzNHdUNhU2djaTJ0VXdYenRTKy9JRXV2YWtwQ1JYYnluOFFodmdvbVVxNy9z?= =?utf-8?B?a3pCTEw4bDBwYk5vNitLdXQzWkg1MExrOGc0LzdvTjJYNkwvUWhGVVRKWVU0?= =?utf-8?B?VVUzM1pEYWlYVWxXZ1FSMHhoNXFGYWRMdlNZTGdzMjRZM0lxbDhMZVR5Nkdm?= =?utf-8?B?OUQwSCt1QXdIL3hZT2N3bG4yaVZ3THVCSVlseVRtRlZIc3UraEJkZi9ySFFP?= =?utf-8?B?YmQ1UFgrdkF3S0duSUlsK1RnOFliMStBbE43ZGZIZGsxdUlZL09aMkNPTndG?= =?utf-8?B?ckVUNFc0TlQ1UnJ1NTlNY0lzZS91YjVpanRNblhUcW56VEpUU09OMk9HeDhn?= =?utf-8?B?V3ZyMndDOUpJQ0R3RzRPeExobVEyYm5aU25XTjF3MEk3YnRDd3pLUncvNmVK?= =?utf-8?B?UjUxTGJiUEhHQ2I2ZkUyVWRHaDVvbklaWnp6algxaTYvWHpqQTNNRFJoMmhn?= =?utf-8?B?dTJzTHd6TzFwckdzRnRGczE1OG1uOTB4NjRzQmtoMDJsczFSZGhMYjgyOFZ4?= =?utf-8?B?NUU2WjlaWTRLeDFTbWNNOEpJSm9uelVnWDVRQzRRTWtLY3lYSUpxblpBSFNH?= =?utf-8?B?YkZSb011TXNrb3AvUmd0ckVocHBSZEVjc2ZrYldXNGFMRjJFTHZicU1EaHVp?= =?utf-8?B?VHFnV3k1aHp5WVBQSXBtOCt2VFVDQ290dFpyUU5MaTFyMDB1VTNUS25wbDdk?= =?utf-8?B?RUlHeGh5dmZRL3J4anlRdVdJdTlMVEhFb3hodGcwSHVKbWNtbHhReTVtZlFX?= =?utf-8?B?RkI1VjdtRHJCOGQvdzZFY3Fpc1NKa0NpWm1oUmYxdG90Q1lPQStnaXBHcDZR?= =?utf-8?B?S3AzYS9uM0pWa2pzUnVDays2MmROT01TeVJOd0lXTFU0elR5dktVM0t4NTRr?= =?utf-8?B?RytReXNsdEJnbTJIaWltNWVyUU1JQnAyMFJDOUJGRUw0MTBhZm04bWYrRGVn?= =?utf-8?B?RzNSdlNtWm81a1NYdkJkRFNaMlQ5dG9nOVJIeHlDYWM5OWYwaFNleGdRZXNI?= =?utf-8?B?ajk1emNVNW9tSjFMLzNTMVZrNzhWaGFLRWdtSFFTTDkyUmhocFBsQT09?=
Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881CD09B72B9AE0D29F0F6DD8B29CO1PR11MB4881namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f96a440a-3a32-4fb6-24d8-08da54565245
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2022 13:51:34.9626 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: OaZimGHMQoVUPyNUK6UV+Vip+WGBwwRShgX1SLoBcZ0tGhTrjIdtq7lhKR5QyDJB6rwVwX9vDRq5xwZcheU+lg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW4PR11MB5774
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.135.125, xfe-aln-005.cisco.com
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/1RrRE5aOxA6Ez5Z0SGIGMb_tryw>
Subject: Re: [Roll] [6lo] 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: Wed, 22 Jun 2022 13:51:42 -0000

Hello Rahul

> One more comment:  Section 5.2 says "non-storing Mode DAO to the Root may contain multicast addresses in the RPL Target Option (RTO),"
> An RTO cannot contain multiple addresses. Is it meant to say that multiple RTOs may contain the different multicast addresses within the same DAO?

Good catch, I used: “  the Root may advertise a multicast address in the RPL Target Option (RTO),”

> Ok. That's what I assumed but wanted an explicit response. Multicast/Anycast proactive cleanup is not possible to handle and lifetime elapsing sounds fine to me. Should this be explicitly stated?

You’re right. Added
“
   The route disappears when the associated path lifetime in the transit
   option times out, but the procedure to remove a unicast route based on TID
   cannot apply to multicast and anycast.
“

>> MOP is 1 but there’s storing mode DAO for multicast happening as well. Some out of band control would allow this to happen. We can remove that text if people think it is open ended…

> I feel it is open-ended.

Let’s work on it, from experience it is needed.

> I have raised a PR to your repo here.

I used it, many thanks!

Keep safe;

Pascal

From: 6lo <6lo-bounces@ietf.org> On Behalf Of Rahul Jadhav
Sent: dimanche 12 juin 2022 18:45
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Cc: lo <6lo@ietf.org>
Subject: Re: [6lo] [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling

Thanks for the response.

PFA my comments inline.

One more comment:  Section 5.2 says "non-storing Mode DAO to the Root may contain multicast addresses in the RPL Target Option (RTO),"
An RTO cannot contain multiple addresses. Is it meant to say that multiple RTOs may contain the different multicast addresses within the same DAO?

Thanks,
Rahul

On Wed, 8 Jun 2022 at 21:23, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote:
Hello Rahul

Many thanks for your review!!

Please see below:

>  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).

This is effectively https://datatracker.ietf.org/doc/html/rfc6550#section-12; this is indicated in the introduction and the overview. Effectively the TID must be ignored and the RFC misses text to that effect. This oversight (of ours at the time of RFC 6550) is corrected in the cases covered by the draft though we do not specifically update RFC 6550 to clarify that it also applies to MOP3. I’m adding text to be more specific on this:

“
   Though it was implicit in [RFC6550], this specification
   clarifies that the freshness comparison based on the TID field is ignored
   for RPL multicast operations. A RPL router maintains a remaining Path
   Lifetime for each DAO that it receives for a multicast target, and sends it
   own DAO for that target with the longest remaining lifetime across its
   listening children.
“
Same for MOP 5
“
   As with MOP 3, the freshness comparison based on the TID field is ignored
   for RPL MOP 5 multicast operations. The Root maintains a remaining Path
   Lifetime for each DAO that it receives, and the 6LRs generate the DAO for
   multicast addresses with the longest remaining lifetime across its registered
   6LNs.
“

There is no route cleanup. There’s history of async clean up to do damage in race conditions. It’s hard enough for unicast, we do not attempt for multicast or anycast. So we leave it to lifetime elapsing.

Ok. That's what I assumed but wanted an explicit response. Multicast/Anycast proactive cleanup is not possible to handle and lifetime elapsing sounds fine to me. Should this be explicitly stated?



> This opens up a lot of possibilities and I am not sure how the hybrid mode would work.

Well, the  announced MOP is 1 but there’s storing mode DAO for multicast happening as well. Some out of band control would allow this to happen. We can remove that text if people think it is open ended…

I feel it is open-ended.


> "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.

This is described in section 12 of RFC 6550 for MOP 3:
“

   As a result, multicast routing states are installed in each router on
   the way from the listeners to the DODAG root, enabling the root to
   copy a multicast packet to all its children routers that had issued a
   DAO message including a Target option for that multicast group.

“

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

The git is https://github.com/pthubert/6lo-multicast-registration; you’re very welcome to submit a pull request. I pushed the changes above in https://github.com/pthubert/6lo-multicast-registration/commit/02f5b9144f39f54e76ee2c8b480703449450ddf3

I have raised a PR to your repo here<https://github.com/pthubert/6lo-multicast-registration/pull/1>/1>.


I suggest to move it to the ROLL git when we transfer focus to ROLL?

Many thanks again

MAny Thanks

Pascal



From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav
Sent: vendredi 3 juin 2022 17:16
To: lo <6lo@ietf.org<mailto:6lo@ietf.org>>; Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] draft-ietf-6lo-multicast-registration: route cleanups and storing MOP handling

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

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll