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

From: <[email-masked]>
Date: Mon, 25 Jul 2016 15:29:30 +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)
 
So, 
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

---

From: [email-masked]
Date: Mon, 25 Jul 2016 21:05:22 +0200

Normen,

> 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.

Best regards,
Ole

---

From: Xing Li <[email-masked]>
Date: Tue, 26 Jul 2016 07:59:10 +0800

> 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.

I agree with Ole. For your information, our implementation has a 
configuration function to select the format of PSID. Regards, xing

---

From: yannis nikolopoulos <[email-masked]>
Date: Tue, 26 Jul 2016 10:52:27 +0300

hello,

On 07/26/2016 02:59 AM, Xing Li wrote:
> [email-masked] ει:
>>> RFC 7597, section 6 describes the last 16 Bits of the construction 
>>> of the Ipv6 interface identifier as follows:
>>>
>>>    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,
>> 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?)

> configuration function to select the format of PSID. Regards, xing

where is this function implemented?

best regards,
Yannis

>
>> Best regards,
>> Ole
>
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

-- 
Yannis Nikolopoulos		OTE S.A
e-mail: [email-masked]	IP Network Planning & Engineering
tel: +302106116293
----------------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 26 Jul 2016 10:50:26 +0200

Yannis,

> 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?)

it shouldn't. in 7596 it states that the IID is created as specified in 7597.
that 7598 uses a different on-the-wire format doesn't change that.
in MAP data packets those bits are again represented in a different bit position.

>> I agree with Ole. For your information, our implementation has a configuration function to select the format of PSID. Regards, xing
> 

I don't know, but just a point to the IID generation, it must be a consistent method used across the domain (in algorithmic mapping), but in LW46 it could pretty much be anything you like, if you have a way to coordinate that between the BR and CEs.

Best regards,
Ole

---

From: Xing Li <[email-masked]>
Date: Fri, 29 Jul 2016 17:16:55 +0800

> where is this function implemented?

They are both in MAP-BR and MAP-CE, since for a MAP domain the format 
must be matched. xing