Re: [Softwires] PSID format as described in rfc 7597 vs. rfc 7598
yannis nikolopoulos <yanodd@otenet.gr> Tue, 26 July 2016 07:52 UTC
Return-Path: <yanodd@otenet.gr>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D3612D666 for <softwires@ietfa.amsl.com>; Tue, 26 Jul 2016 00:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 jtxHc3lsAjNc for <softwires@ietfa.amsl.com>; Tue, 26 Jul 2016 00:52:30 -0700 (PDT)
Received: from calypso.otenet.gr (calypso.otenet.gr [83.235.67.36]) by ietfa.amsl.com (Postfix) with ESMTP id 738C612D15E for <softwires@ietf.org>; Tue, 26 Jul 2016 00:52:29 -0700 (PDT)
Received: from [212.205.221.32] (loco.otenet.gr [212.205.221.32]) by calypso.otenet.gr (ESMTP) with ESMTPSA id 2FF9C138051 for <softwires@ietf.org>; Tue, 26 Jul 2016 10:52:28 +0300 (EEST)
To: softwires@ietf.org
References: <423a5f59a11b4ed289c75c21f2869695@HE102221.emea1.cds.t-internal.com> <19F4B994-F033-4470-BFEE-FA4BE320634D@employees.org> <5796A7CE.30308@cernet.edu.cn>
From: yannis nikolopoulos <yanodd@otenet.gr>
Message-ID: <bbb55811-f129-8c45-597e-c598d0b560af@otenet.gr>
Date: Tue, 26 Jul 2016 10:52:27 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <5796A7CE.30308@cernet.edu.cn>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/softwires/DaWeCxlt5vnsbAQp9GeoaFrzqew>
Subject: Re: [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: Tue, 26 Jul 2016 07:52:32 -0000
hello, On 07/26/2016 02:59 AM, Xing Li wrote: > otroan@employees.org ει: >> Normen, >> >>> 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) >>> >>> So, >>> 1, Is my understanding of the two RFC's PSID formats correct? >> >> I believe so. >> >>> 2, What's the reason for the difference in the formats? >> >> Good question. The 7597 PSID in the IID is mainly there for pretty >> printing / troubleshooting, and it makes sense to left pad it. >> I can only guess about the 7598 format, possibly to keep the PSID >> field consistent with the other fields (prefix) which are all right >> padded. > this might create some confusion about the way the lwB4 will construct the IID for the tunnel endpoint (use "2" or "800" for the last 16 bits?) > I agree with Ole. For your information, our implementation has a > configuration function to select the format of PSID. Regards, xing where is this function implemented? best regards, Yannis > >> Best regards, >> Ole > > > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires -- Yannis Nikolopoulos OTE S.A e-mail: yanodd@otenet.gr IP Network Planning & Engineering tel: +302106116293 ----------------------------------------------------------------------------
- Re: [Softwires] PSID format as described in rfc 7… Xing Li
- Re: [Softwires] PSID format as described in rfc 7… otroan
- [Softwires] PSID format as described in rfc 7597 … normen.kowalewski
- Re: [Softwires] PSID format as described in rfc 7… Xing Li
- Re: [Softwires] PSID format as described in rfc 7… otroan
- Re: [Softwires] PSID format as described in rfc 7… yannis nikolopoulos