[Softwires] PSID format as described in rfc 7597 vs. rfc 7598

<normen.kowalewski@telekom.de> Mon, 25 July 2016 15:29 UTC

Return-Path: <prvs=0077c4265=normen.kowalewski@telekom.de>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CB0A812D7E6; Mon, 25 Jul 2016 08:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.287
X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Rv3gFzzlgdHW; Mon, 25 Jul 2016 08:29:39 -0700 (PDT)
Received: from mailout13.telekom.de (MAILOUT13.telekom.de []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DE412D7D0; Mon, 25 Jul 2016 08:29:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1469460512; x=1500996512; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=MMAnmm6b0l8+gL3gMqK3WrC9sQ8sAE5/onXdZFm4hqo=; b=esDsSohmBy/h67EBPB9G9/IZYk+dnMQ5wJXpvYlRYfqrPAFd27NtypeQ C8AQPgI2Lb/LNDZkdEF5Gy2zii4NZ/N7+deETn/RYG/NaP+IeXjSUS5Ym EguIpa11nonGdMDhCeudAg5nGuf5fPyyzzWH3GMY3jW875mglZdXye91i Ggh9y0Tu5/P724Ws1YI8C4jUcXr6eZk/0iIgpl5OlwU9PR+no6+Et4NuY cLGq7TV9HFW4hRJb0kSOWA+F3J1Kniny1XL5Xt2Uy/dn/jmxsOJ+3UbDC aKs2SzA+edCAliWmSHLd+d4nNjx6BVIEAlqnRBDpjawZMXR7sjOuZFb4a A==;
Received: from s4de8nsazdfe010.bmbg.telekom.de ([]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES128-SHA; 25 Jul 2016 17:28:24 +0200
X-IronPort-AV: E=Sophos;i="5.28,419,1464645600"; d="scan'208";a="924870734"
Received: from he102219.emea1.cds.t-internal.com ([]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES256-SHA; 25 Jul 2016 17:29:30 +0200
Received: from HE102221.EMEA1.cds.t-internal.com ( by HE102219.emea1.cds.t-internal.com ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 25 Jul 2016 17:29:30 +0200
Received: from HE102221.EMEA1.cds.t-internal.com ([fe80::f5a3:9293:96b6:8eba]) by HE102221.emea1.cds.t-internal.com ([fe80::f5a3:9293:96b6:8eba%25]) with mapi id 15.00.1178.000; Mon, 25 Jul 2016 17:29:30 +0200
From: <normen.kowalewski@telekom.de>
To: <draft-ietf-softwire-map@ietf.org>, <draft-ietf-softwire-map-dhcp@ietf.org>
Thread-Topic: PSID format as described in rfc 7597 vs. rfc 7598
Thread-Index: AdHmiVab41jyZoYvSxizET/ENIq4jw==
Date: Mon, 25 Jul 2016 15:29:30 +0000
Message-ID: <423a5f59a11b4ed289c75c21f2869695@HE102221.emea1.cds.t-internal.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/fwkujtJN1rFy4y2u-2VbcchQlbE>
Cc: softwires@ietf.org
Subject: [Softwires] PSID format as described in rfc 7597 vs. rfc 7598
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jul 2016 15:29:42 -0000

Dear All,
I just want to make sure that I'm not misunderstanding this:
RFC 7597, section 6 describes the last 16 Bits of the construction of the Ipv6 interface identifier as follows:
   The PSID field is left-padded with zeros to create a 16-bit field.  
RFC7598 Section 5.1. describes the format for provision the PSID to clients with the following text: 

   o  PSID: 16 bits long.  The PSID value algorithmically identifies a set of ports assigned to a CE. The first k bits on the left of this field contain the PSID binary value.  The remaining (16 - k) bits on the right are padding zeros.
To me this seems that the two RFCs use two different formats to express the same information in a field with the same name. 
Lets assume an example where the port split ratio is 6 (=k), slicing the IPv4 address up into up 2**6 = 64 slices, each segment having 1024 ports. 
In RFC 7597, to select the third port-range, the parameters become OFFSET 0, PSID-LEN 6, PSID 0x2 (left padded with zeros to 16 bits)
In RFC 7598, to select the third port-range, the parameters become OFFSET 0, PSID-LEN 6, PSID 0x800 (leftmost k-bits on this field contain the PSID binary value, which is right padded with zeros to fit 16 bits)
1, Is my understanding of the two RFC's PSID formats correct?
2, What's the reason for the difference in the formats?

Best Regards,

Normen Kowalewski
Deutsche Telekom AG