Re: [Roll] 'S' field in MPL Options

Robert Cragie <robert.cragie@gridmerge.com> Tue, 04 December 2012 14:39 UTC

Return-Path: <robert.cragie@gridmerge.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 3F19F21F8AF4 for <roll@ietfa.amsl.com>; Tue, 4 Dec 2012 06:39:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58svtSLimk3y for <roll@ietfa.amsl.com>; Tue, 4 Dec 2012 06:39:43 -0800 (PST)
Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1BB21F8AF1 for <roll@ietf.org>; Tue, 4 Dec 2012 06:39:43 -0800 (PST)
Received: from client-82-26-204-201.pete.adsl.virginmedia.com ([82.26.204.201] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1Tftes-00074I-Hf; Tue, 04 Dec 2012 14:39:38 +0000
Message-ID: <50BE0B9B.7050802@gridmerge.com>
Date: Tue, 04 Dec 2012 14:41:31 +0000
From: Robert Cragie <robert.cragie@gridmerge.com>
Organization: Gridmerge Ltd.
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Michael Richardson <mcr+ietf@sandelman.ca>
References: <50AD18CC.90907@gridmerge.com> <50AD7947.8050303@exegin.com> <B50D0F163D52B74DA572DD345D5044AF0F779FCF@xmb-rcd-x04.cisco.com> <50ADF8F6.5000405@gridmerge.com> <18725.1354304978@obiwan.sandelman.ca>
In-Reply-To: <18725.1354304978@obiwan.sandelman.ca>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060500010001010104000503"
X-Authenticated-As: robert.cragie@gridmerge.com
Cc: Roll WG <roll@ietf.org>, "Jonathan Hui \(johui\)" <johui@cisco.com>
Subject: Re: [Roll] 'S' field in MPL Options
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert.cragie@gridmerge.com
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: <http://www.ietf.org/mail-archive/web/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: Tue, 04 Dec 2012 14:39:44 -0000

I agree we should keep the 'S' field as it gives more flexibility for 
future versions.

I'm not sure we reached a conclusion regarding the reserved bits and 
version numbering. Here are the choices as I see them:

1) 5-bit version number:

  * Allocate all reserved bits to be a unsigned 5-bit version field:
      o V = Version. Set to 0. Must be received as 0. If received as 1
        or higher, packet is discarded

In future revisions, this allows:

  * Extension of the frame using TLV suboptions
  * Complete change to the option formatting if V is set to 1 or higher

2) n-bit (1 <= n <= 4) version number:

  * Allocate n reserved bits to be a unsigned n-bit version number:
      o V = Version. Set to 0. Must be received as 0. If received as 1
        or higher, packet is discarded
  * Change behavior for remainder of reserved bits:
      o rsv =  reserved. Set to 0. Ignored on receipt

In future revisions, this allows:

  * Extension of the frame using TLV suboptions
  * Use of remainder of reserved bits
  * Complete change to the option formatting if V is set to 1 or higher

3) No version number:

  * Change behavior for reserved bits:
      o rsv =  reserved. Set to 0. Ignored on receipt

In future revisions, this allows:

  * Extension of the frame using TLV suboptions
  * Use of reserved bits

In draft 02, it is most like (1), except the reserved bits are not 
called a version number. My preference would be for (2), with n=1.

Anyone else?

Robert


On 30/11/2012 7:49 PM, Michael Richardson wrote:
>>>>>> "Robert" == Robert Cragie <robert.cragie@gridmerge.com>; writes:
>      Robert> 2. Allow future revisions to change the format
>
> I suggest that we keep the S bit.  We might introduce additional fixed
> format items using additional reserved bits to flag that they are there.
>
> If we run out of reserved bits, then that would be a reason to bump the
> version and go for a full subTLV format.  Given that bytes are scarce,
> this results in the most efficient packing for now.
>
> This is my suggestion.  If you agree, then we should add this to issue #108.
>