Re: [Roll] P-DAO refresh

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 21 September 2020 12:49 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 103B33A0E39 for <roll@ietfa.amsl.com>; Mon, 21 Sep 2020 05:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.619
X-Spam-Level:
X-Spam-Status: No, score=-9.619 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_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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=AHpf2ugI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hZ9LXjoG
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeRZMu1AlZxC for <roll@ietfa.amsl.com>; Mon, 21 Sep 2020 05:49:26 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6793A0E30 for <roll@ietf.org>; Mon, 21 Sep 2020 05:49:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37754; q=dns/txt; s=iport; t=1600692566; x=1601902166; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=54hWwkVYW+Yi/5+1TS//hrE+JkPfIIJmMTdiU5iwmx4=; b=AHpf2ugIKIHkVsSsVa4Ff7AZ4difRXFp8MdPXL82tqGlYYjSEZHwnzLM a7SzuwIXFBIO09R0Wa8TEYc1fxXrf3FnRligQHTN6IY0V2TnlhjWbcHy4 0DdKldJl8C9YND+qAPjdTonKaERm++HJM1hc5RPJZgrsKh3aMSNmF6DFK A=;
IronPort-PHdr: 9a23:tT4GfBwqWgbndpPXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEURgZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHRPyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CVBQASoWhf/4wNJK1fHAEBAQEBAQcBARIBAQQEAQGCD4EjAS4jLgdwWS8shDqDRgONdYECl3KBQoERA1ULAQEBDQEBJQgCBAEBhEsCF4IUAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEhEKEwEBOA8CAQgRAwEBASEBBgMCAgIwFAkIAgQTCBqDBYF+TQMuAQ6pGgKBOYhhdoEygwEBAQWBNwKDbhiCEAMGgTiCcYJcS0JLgXyECxuBQT+BEAFDghg1PoJcAQECARaBDBwgHgYHCYJhM4Itj2mDSoZ9i3iRCgqCZ4h2iT2IOoMMiXmDSJA0nVyQaQYohAQCBAIEBQIOAQEFgWsjgVdwFYMkUBcCDY4fg3GFFIVCdAI1AgYBCQEBAwl8jWMBAQ
X-IronPort-AV: E=Sophos;i="5.77,286,1596499200"; d="scan'208,217";a="546284614"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Sep 2020 12:49:25 +0000
Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 08LCnPWt030043 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Mon, 21 Sep 2020 12:49:25 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 21 Sep 2020 07:49:24 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 21 Sep 2020 08:49:23 -0400
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 21 Sep 2020 07:49:22 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QXB9J1o+9HkPKcGgITVAfnKLRhqLNBPxvA6aOgTDbA9J+JcSlIipMTHlH4HA1/Uki/wr6mEkHvO5X3OEbhn3/UV5r6N+0ui47H/xOK2iIvfsel2WVBu3Ag7Lo0pfpQVEpoiKwDqnPbOucW0tTuaoWEn9t9O+YL3bBX5BrowI3MpDMom29Su5vg8SZPGb92K5vRMVHm/2oyNGZqWRXYvqf485cezVcRuQWNVkQF0CjQjGhjfcpVUnmAsYzeYK3rfymxPk3YDxEmV76IDv2JbLZ93K+G7rHzfMVfeITTblY+zKajeVDokXKUgEPLE4T8P7lwlgCtSbVXCtPaHq7lfqHw==
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-SenderADCheck; bh=54hWwkVYW+Yi/5+1TS//hrE+JkPfIIJmMTdiU5iwmx4=; b=TAXv8WU5sOQ3IsfxjAiYv9ocEC+3WYIYnOxqAoiV0mBp1QUUMEE+aBCe1LhBclAngKcd5pUrRBsasAJU0QzPGeFhDTqQQE9Fzx7AB3WBctJPymYQCrRm0jED0vLQh7uy8cs4SU/zoOILJCPfd9a10vugUYxkN0nZyZr9oIJCZdxllsJjdfHDeHLw2eZlMOr45bDkQdnKGz6e0AlTkoaOMADHmzqnqaJIKkWPCRWklTpUAlhxH84pLbMTy9u/+1VD5F/BePYsmKwU6bd3b3en9IB1ilQrzTc1qDV1kYorC8gsYcuRGpWj/Qd6XZzkxuqYrklqPYC2vEnQQQc7aZUVBA==
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=54hWwkVYW+Yi/5+1TS//hrE+JkPfIIJmMTdiU5iwmx4=; b=hZ9LXjoG/hDjmZp/xbYqFu/Nb4l2OLwMaXSb/cbw9Fy43CfFK8ZAVNoX4ElrkLKlRxWVcqBGy3U59ryAv+YlfYLn6Z6oSqfd+7Ya2/pY1ROXnMVgUhdmBvVNqF8WjgEki4Xqgs9oCusiFDNy/LCuXpEf+2SqJAIPOUYg1Tq7E/I=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4013.namprd11.prod.outlook.com (2603:10b6:208:13e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Mon, 21 Sep 2020 12:49:22 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::119:f851:5860:da95%4]) with mapi id 15.20.3391.026; Mon, 21 Sep 2020 12:49:22 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] P-DAO refresh
Thread-Index: AQHWj9pTjcpvA/YVA0Or2qqeN6Hbsqlyq2BQ
Date: Mon, 21 Sep 2020 12:49:12 +0000
Deferred-Delivery: Mon, 21 Sep 2020 12:49:00 +0000
Message-ID: <MN2PR11MB356594E86124B68A04ED5DBAD83A0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <87D48CB0-4437-42B4-B78C-A77BB4A05E81@cisco.com>
In-Reply-To: <87D48CB0-4437-42B4-B78C-A77BB4A05E81@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2a01:cb1d:4ec:2200:6846:1faa:66d6:dfb6]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 82f75399-9abe-4fde-16ab-08d85e2cc35e
x-ms-traffictypediagnostic: MN2PR11MB4013:
x-microsoft-antispam-prvs: <MN2PR11MB401320FD2218DCA7A97F5F84D83A0@MN2PR11MB4013.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VIUjnsFLJcPeg6YmeGcpJm9J6XkWMXcNBZiEDtu+iQtT6MGBBmE2npZs8IqxqTekvGz2MLCetgB9q5/yel6CnkgXboatJCBA+MgZ5BFjNw1s6yWszGA0RdpC/lw/AnrehvJxl9MjECD9zZcxnE2qyXuzQ0WExZBWvvY2cNfVtlRXt23eQT/JNHZd1yqk1HPwfXvdIiPJO2KanNQ1396Fs3hR5Dn8Yh+jXXSGB/UsWpFKxh1aZ0zPbahjfYg4nXY6JSfXIZAKEq2Gtk1GjLSRTY3kyxGRrAb3Bj81NZhE3EQjriYQBTOvJ0DjhmE19rgTCCbK1OC9+hnJ7e0ai2mJRjMUarTH5eoaKEprcUv9J3bT6+NC34Ph3C6TjoR9+mMlOE6vjv2LY4w0JsHRqtVS0w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(346002)(376002)(39860400002)(6916009)(55016002)(9686003)(316002)(2906002)(166002)(83380400001)(186003)(966005)(7696005)(76116006)(8936002)(478600001)(66946007)(71200400001)(52536014)(86362001)(6666004)(66446008)(64756008)(66476007)(66556008)(6506007)(33656002)(5660300002)(8676002)(53546011); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 9RST7zbiYzaszpL6EKZ+LiGDYdvU6q+CM8I20Ofl6AZ4oKxnHStXEYu5cRS1/pC5QsaO/5WELsSZHAMONrrup0PTcXu4bOujdgPKEuhf7QvmiI2R5HO16TVrctn+GBqC6Ot05e88hxtzBn6YnfYm0W1M6Uo7n9id3dg675CDSqVcRzyrj91SfbbBsI7QOec5dLozpLG+P26PoATsbB1M/2/+R0W5U0nX7M+bvh7+yZ9poghy7yJZWOSNqtcv6IRPfnv/X6HUZslw3L0EZaRuzhgk8etw9ALMCqyPSuBNtq/WO5NhM/lGG4VYJweDLCKlZYojh3JfvoKEUJH1viZ1d4KybEizP9z3jw0Ut9l2k84gnZJG8cYFAKMe094IgzNqbDZZTp6FPvzTspBkhJTSf17gmJ/lI1ieHGTb6Q4lyb2mi84cS3BDc2SeF24B3bwcLxgVgVE2WHPNJXt3BHPLWUZyY2QKw6HFW7eOJqbjAY//pkDF0IFgE8gECa18F6SZmva+0yp/ZHSWPj7/gorCa+g5mFU2gfBXhA/Asm8Ff132EqJwdULvGNIThlnH8Jz1uDX+oUD8EZS3dXoMirNldBkERq9AUkZkCJPGFDFk7fCs5U7dSJ6ig0wVoykbStgGqXRDcZcaxalXVgqz+wPUTZw7MeIir1jy+FILWdHtAD/+3kkoFZq/Ytjdsu99bVGRwj3kJVwss3kp1tSfAaCmWA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356594E86124B68A04ED5DBAD83A0MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB3565.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 82f75399-9abe-4fde-16ab-08d85e2cc35e
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Sep 2020 12:49:22.0621 (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: AWOVU/NQP/u6w7azP8YoYZLilYLymDi7j9xNy3pU6VPiK4IVBFvKw7LJYJluV+YW+29dzRiTB4KGuPNSGTvCLQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4013
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Q1Enj-mJknuMEqxu57MaaXBWay4>
Subject: Re: [Roll] P-DAO refresh
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 21 Sep 2020 12:49:29 -0000

Hello Li

Many good points!


  1.  In 5.1 & 5.2, is the flag field MUST initialized to zero by the sender and MUST be ignored by the receiver?

Sure, I added this


  1.  In 5.3 Route Projection Options,  it use Segment lifetime and sequence to replace Track Sequence/ Track Lifetime, but the field description is still for Track Sequence/ Lifetime

Yes, and I forgot to do some clean up; Will be done in next publication


  1.  In 5.3 Option Type is  0x0A for VIO, 0x0B for SRVIO, it’s not consistent with section 8.2. Same issue is for SIO.

Oups, good catch, fixed


  1.  In 5.4, does Compression Type still need 3 bits? I think it should be same as RPO. One bit is enough.

That was with the idea that all addresses go with the same compression, so the RFC 8138 compression could be indicated there, and we need 3 bits for that. This was a good idea for VIO, because the process of coalescence would have been complicated. This is also a good idea for SR-VIO when RFC 8138 is not enabled, because https://tools.ietf.org/html/rfc6554#section-3 has a fixed compression. But for SR-VIO in a network with RFC 8138 turned on, It is a lot easier that the Root computes the optimum RFC 8138 SRH-6LoRH (see https://tools.ietf.org/html/rfc8138#section-5).

Suggestion is to use one bit as you recommend, and indicate that the content in case of compression mut have a single SRH-6LoRH in VIOs and when RFC 8138 is turned off. I’ll do the appropriate change in nest version.


  1.  For B flag in SIO, “and does not provide information on the hop from this node to the sibling”  should be “and does not provide information on the hop from sibling to the node”?

Well, no. The idea is that this node may know only the LQI of received packets so it has info about the receive side from the sibling to this node but cannot provide information on the hop from this node to the sibling.


  1.  For Sibling Rank field in SIO, is it necessary? Root can collect sibling rank from sibling’s DAO.

In non-storing mode that is correct. Initially the idea was that this could be used in storing mode as well, but then there’s a lot more to define. So maybe for now we can indicate everywhere that the main DODAG has to be non-storing, in which case, yes, we can turn the field in reserved in case later we want it back.


  1.  Is there any rule for how to report SIO? E.g. how many siblings can be reported to root?

That’s a question to the group. So far we have not defined any.

I’ll republish asap with the changes above. Please let me know if that’s what you wanted and if I missed anything.

Many thanks Li!

Keep safe,

Pascal


From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: lundi 21 septembre 2020 07:45
To: roll@ietf.org
Subject: Re: [Roll] P-DAO refresh

Hello Pascal,

Some concerns about P-DAO version 11 as following:


  1.  In 5.1 & 5.2, is the flag field MUST initialized to zero by the sender and MUST be ignored by the receiver?
  2.  In 5.3 Route Projection Options,  it use Segment lifetime and sequence to replace Track Sequence/ Track Lifetime, but the field description is still for Track Sequence/ Lifetime
  3.  In 5.3 Option Type is  0x0A for VIO, 0x0B for SRVIO, it’s not consistent with section 8.2. Same issue is for SIO.
  4.  In 5.4, does Compression Type still need 3 bits? I think it should be same as RPO. One bit is enough.
  5.  For B flag in SIO, “and does not provide information on the hop from this node to the sibling”  should be “and does not provide information on the hop from sibling to the node”?
  6.  For Sibling Rank field in SIO, is it necessary? Root can collect sibling rank from sibling’s DAO.
  7.  Is there any rule for how to report SIO? E.g. how many siblings can be reported to root?


Take care,
Li


From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>>
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Date: Monday, September 14, 2020 at 20:19
To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>>
Subject: [Roll] P-DAO refresh

Dear all

I published https://tools.ietf.org/html/draft-ietf-roll-dao-projection-11 to address issues that were signaled to me unicast;

I took advantage of the refresh to do some editorial rewording, based on recent experience with IESG reviews.

One issue was the capability to factorize multiple projected routes for one target. This is doable for non-storing, but hard for storing P DAO since the end point is the one answering, so one request would generate multiple dao acks. I thought it was easier NOT to factorize storing mode P DAOs. Does that make sense?

Also in the RPO:
- the format forced a single compression format for all addresses. It is less error prone to fully inline in the option the  sequence of SRH-6LoRH that will be added in the packet, in the exact same shape, don’t you think?
- The lifetime and the sequence apply to the segment, not the whole track. A node may not be conscious of the whole track. I fixed that.

The diffs are here https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-11.txt

Please let me know if that works!

Keep safe

Pascal