Re: [6lo] instance ID in rfc6775 update

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 12 April 2018 14:23 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA9312D873; Thu, 12 Apr 2018 07:23:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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
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 lgY4ZSt0T3NB; Thu, 12 Apr 2018 07:23:52 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9563126DCA; Thu, 12 Apr 2018 07:23:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14347; q=dns/txt; s=iport; t=1523543032; x=1524752632; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2ZJAkCh5wlB9vmDS+kc8i3EWFjesXs3uJVoSft52DLo=; b=PejmnX9jR7oh78FXPfEDObJ+FNl9bD2z/jStx/rly3P85sq3rHNPX9Up 0akHs5Xs7Bv12XPe9XUDM4rBQv/HSsuZ2o306ZgNC5eF+S5BtJOUXCEXc lS6AckIqrv2SqOb3MxNR1rNLMBuJk3qurF/t/kHw93WMWasK3c3kPh3PG Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CPAgBfa89a/5NdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYJNRi9hbygKmGyBdIEPhmaHFoR7gWcLgViDKwKCISE4FAECAQEBAQEBAmwdC4UiAQEBAQMtOhIQAgEIEQQBAS8hER0IAQEEDgUIhCFMAxWpZ4cJDYErgi+HfYFUP4EPgwuCT4FshgwCkF+GUiwIAos4gnWBO4NahzeHLII0hgsCERMBgSQBMyGBUnAVgn2CIBeOF28RjVmBFwEB
X-IronPort-AV: E=Sophos; i="5.48,442,1517875200"; d="scan'208,217"; a="98259644"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2018 14:23:51 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w3CENoS4025329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Apr 2018 14:23:51 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 12 Apr 2018 09:23:50 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1320.000; Thu, 12 Apr 2018 09:23:50 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "6lo@ietf.org" <6lo@ietf.org>
CC: Yan Filyurin <yanf787@gmail.com>, Tony Przygienda <tonysietf@gmail.com>, "draft-ietf-6lo-rfc6775-update@ietf.org" <draft-ietf-6lo-rfc6775-update@ietf.org>
Thread-Topic: instance ID in rfc6775 update
Thread-Index: AdPSYqpTuA/gdfvGSVe3wCALBC+A3gABgmjA
Date: Thu, 12 Apr 2018 14:23:29 +0000
Deferred-Delivery: Thu, 12 Apr 2018 14:23:10 +0000
Message-ID: <aa1366d50d9f4b58895209d1fe577690@XCH-RCD-001.cisco.com>
References: <f2519dd3dd364bbfad2d51a4febde366@XCH-RCD-001.cisco.com>
In-Reply-To: <f2519dd3dd364bbfad2d51a4febde366@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.216.11]
Content-Type: multipart/alternative; boundary="_000_aa1366d50d9f4b58895209d1fe577690XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/vTFM9Ag49ZjILL0HN4l5WwXFpXY>
Subject: Re: [6lo] instance ID in rfc6775 update
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 14:23:54 -0000

Hi again

A proposed text would be like:


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     Type      |     Length    |    Status     |    Opaque     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Rsvd | I |R|T|     TID       |     Registration Lifetime     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
...             Registration Ownership Verifier                 ...
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

....

Opaque:
       One-byte Opaque field; this is an octet that ND does not need to process
       but that the 6LN wishes the 6LR to pass transparently to another process.
I:
       Two-bit Integer: A value of zero indicates that the Opaque field carries
       an abstract index that is used to decide in which routing topology the
       address is expected to be injected. In that case, the Opaque field is
       passed to a routing process with the indication that this is a topology
       information and the value of 0 indicates default. All other values are
       reserved.


Does that work?

Pascal

From: Pascal Thubert (pthubert)
Sent: jeudi 12 avril 2018 15:40
To: 6lo@ietf.org
Cc: Yan Filyurin <yanf787@gmail.com>; Tony Przygienda <tonysietf@gmail.com>; draft-ietf-6lo-rfc6775-update@ietf.org
Subject: instance ID in rfc6775 update

Dear all :

During a conversation on the RIFT protocol it appeared that there are use cases in RIFT to support host mobility with rfc6775-update.
There is a caveat, though, which is in fact common with RPL. Both cases need a concept of multi topology routing.
In the case of RPL, the topology is indexed by an instance ID. In the case of RIFT, there is a need for an index to a RIB, so one octet is probably enough.
A suggestion is thus to use the reserved octet in the ARO to carry an instance ID, and use a bit to signal that this is what that field does, in case there is a need later to overload it with something else.

I understand this is coming late in the process; but then there is no logic associated to the change, this is just passing on an additional information that is useful for more than one candidate protocol.

Please let me know if there is an issue pursuing this. If there is no opposition, my plan it currently to add this in rev-19.

All the best,

Pascal