Hi Ian, thanks for the example. This helps to illustrate, although the numbers provided don't seem to add up (at least in terms of the algorithm and meaning of PSID). For 4096 ports per CE, one needs 12 "freely" bits of address space. The PSID, as per the draft, is the fixed code point that uniquely per CE indexes that address space (ie a subnet address). The length of the PSID is the k-bits. Thus for the example above k-bits should be 4. This, along with a=0, actually works out to be then numerically as per the PSIDs you provide. If the meaning the lw46 implementation puts a different meaning on the k-bits, then there is a problem...
Cheers On 3 June 2014 13:09, <[email protected]> wrote: > Hi Woj, > > Here’s an example from an lwAFTR binding table. In this case, there’s 4096 > ports per client (k-bits =12, a-bits=0). PSID 0 just isn’t in the table. > > 2001:10f:60:6ff::0:b4 1.2.30.126 PSID 4096 > 2001:10f:60:6ff::1:b4 1.2.30.126 PSID 8192 > 2001:10f:60:6ff::2:b4 1.2.30.126 PSID 12288 > 2001:10f:60:6ff::3:b4 1.2.30.126 PSID 16384 > 2001:10f:60:6ff::4:b4 1.2.30.126 PSID 20480 > 2001:10f:60:6ff::5:b4 1.2.30.126 PSID 24576 > 2001:10f:60:6ff::6:b4 1.2.30.126 PSID 28672 > 2001:10f:60:6ff::7:b4 1.2.30.126 PSID 32768 > 2001:10f:60:6ff::8:b4 1.2.30.126 PSID 36864 > 2001:10f:60:6ff::9:b4 1.2.30.126 PSID 40960 > 2001:10f:60:6ff::a:b4 1.2.30.126 PSID 45056 > 2001:10f:60:6ff::b:b4 1.2.30.126 PSID 49152 > 2001:10f:60:6ff::c:b4 1.2.30.126 PSID 53248 > 2001:10f:60:6ff::d:b4 1.2.30.126 PSID 57344 > 2001:10f:60:6ff::e:b4 1.2.30.126 PSID 61440 > 2001:10f:60:7ff::0:b4 1.2.30.127 PSID 4096 > 2001:10f:60:7ff::1:b4 1.2.30.127 PSID 8192 > 2001:10f:60:7ff::2:b4 1.2.30.127 PSID 12288 > 2001:10f:60:7ff::3:b4 1.2.30.127 PSID 16384 > 2001:10f:60:7ff::4:b4 1.2.30.127 PSID 20480 > 2001:10f:60:7ff::5:b4 1.2.30.127 PSID 24576 > 2001:10f:60:7ff::6:b4 1.2.30.127 PSID 28672 > 2001:10f:60:7ff::7:b4 1.2.30.127 PSID 32768 > 2001:10f:60:7ff::8:b4 1.2.30.127 PSID 36864 > 2001:10f:60:7ff::9:b4 1.2.30.127 PSID 40960 > 2001:10f:60:7ff::a:b4 1.2.30.127 PSID 45056 > 2001:10f:60:7ff::b:b4 1.2.30.127 PSID 49152 > 2001:10f:60:7ff::c:b4 1.2.30.127 PSID 53248 > 2001:10f:60:7ff::d:b4 1.2.30.127 PSID 57344 > 2001:10f:60:7ff::e:b4 1.2.30.127 PSID 61440 > > Cheers, > Ian > > > From: Wojciech Dec <[email protected]> > Date: Tuesday, 3 June 2014 12:39 > To: Ole Troan <[email protected]> > Cc: Tom Taylor <[email protected]>, Ian Farrer <[email protected]>, > "[email protected]" < > [email protected]>, Yong Cui < > [email protected]>, Softwires WG <[email protected]> > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well > Known Ports > Resent-To: Ian Farrer <[email protected]>, Mohamed Boucadair < > [email protected]>, <[email protected]>, <[email protected]>, > <[email protected]>, <[email protected]> > > How so, could you give an example? > > > On 3 June 2014 12:17, Ole Troan <[email protected]> wrote: > >> Wojciech, >> >> > Thanks. I'm not sure I get your example though. To exclude ports >> 0-1023, the excluded port "subnet" would be 0x0000/6. Which would be >> equivalent to a=6... >> >> sorry, yes, you'd not assign 0000/6. >> that's not equivalent to a=6 though. >> >> cheers, >> Ole >> >> >> > >> > >> > >> > >> > >> > >> > On 3 June 2014 11:31, Ole Troan <[email protected]> wrote: >> > Wojciech, >> > >> > > Could you show a working example of that in action, along with the >> set of PSIDs containing the usable port ranges? >> > >> > in LW46, ports are provisioned per client. so, I don't understand what >> you want a working example of. that's just like assigning 192.168.0.10 - >> 192.168.0.255 in a DHCP pool. in the PSID case you will not assign ports >> 0000/10 >> > >> > cheers, >> > Ole >> > >> > >> > > >> > > Cheers >> > > >> > > >> > > >> > > >> > > On 3 June 2014 10:51, Ole Troan <[email protected]> wrote: >> > > Woj, >> > > >> > > in the LW46 case, you can still do a=0, and ensure that you don't >> provision any PSID which results in the well known ports. >> > > >> > > cheers, >> > > Ole >> > > >> > > > >> > > > On 2 June 2014 21:49, Tom Taylor <[email protected]> wrote: >> > > > There's a difference between setting a=6 and setting aside the >> lowest PSIDs because they occupy that port space. The value of a determines >> how ports are assigned to each PSID, but does not affect the usable PSID >> numbering space. >> > > > >> > > > I think that you should illustrate how you think this would work >> before we reach a conclusion. >> > > > A setting of a=6 arrives precisely at what the goal is here, >> exclude ports 0-1024. So if there is a need to have another way of >> achieving that, by creating some excluded magic PSID value that corresponds >> to 0-1024, we would like to know why is that relevant and how it is >> supposed to work in a system where the PSID conveys to the CE the >> port-range. >> > > > >> > > > Regards. >> > > > >> > > > >> > > > RECOMMENDED is part of the RFC 2119 boilerplate. The >> (unintentionally) missing term is NOT RECOMMENDED. >> > > > >> > > > Tom >> > > > >> > > > >> > > > On 02/06/2014 3:27 PM, Wojciech Dec wrote: >> > > > Well, I'm referring to the "RECOMMENDED" part. If the >> recommendation is NOT >> > > > to allocate ports 0-1024, then this effectively recommends that >> a-bits=6. >> > > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. >> The >> > > > latter is not a regular normative term, and arguably if the >> recommendation >> > > > is for excluding 0-1024 then a=6 looks like the SHOULD. If anyone >> wants the >> > > > full port set, then a=0 would be an obvious consequence. >> > > > >> > > > >> > > > On 2 June 2014 19:50, Tom Taylor <[email protected]> wrote: >> > > > >> > > > Not sure how you read that, but it can be fixed by putting a comma >> after >> > > > "SHOULD be 0" and replacing "to allocate" with "thus allocating". >> > > > >> > > > Tom >> > > > >> > > > >> > > > On 02/06/2014 12:14 PM, Wojciech Dec wrote: >> > > > >> > > > Uhm, this appears to mean that the RECOMMENDED a-bits SHOULD be 6. >> > > > >> > > > >> > > > On 26 May 2014 13:24, Ian Farrer <[email protected]> wrote: >> > > > >> > > > Hi, >> > > > >> > > > This one slipped my mind…. >> > > > >> > > > From a discussion with Ole during the MAP dhcp last call, there >> was a >> > > > discussion about the exclusion of provisioning WKPs to CPEs - >> > > > >> http://www.ietf.org/mail-archive/web/softwires/current/msg06010.html >> > > > >> > > > In previous versions, the lw4o6 used to reference >> > > > sun-dhc-port-set-option, >> > > > which also stated that the WKPs should not be assigned. This advice >> got >> > > > lost when changing to reference map-dhcp for PSID format. >> > > > >> > > > Here’s a wording change proposal to resolve this: >> > > > >> > > > Section 5.1 >> > > > >> > > > Original text (last sentence, para 7): >> > > > >> > > > "For lw4o6, the number of a-bits SHOULD be 0." >> > > > >> > > > Proposed change: >> > > > >> > > > "For lw4o6, the number of a-bits SHOULD be 0 to allocate a single >> > > > contiguous port set to each lwB4. >> > > > >> > > > Unless a lwB4 is being allocated a full IPv4 address, it is >> RECOMMENDED >> > > > that PSIDs containing the well-known ports (0-1023) are not >> allocated to >> > > > lwB4s.” >> > > > >> > > > Please let me know if you are OK with the proposed change. >> > > > >> > > > cheers, >> > > > Ian >> > > > >> > > > >> > > > Good spot on the WKP exclusion. Before the lw4o6 draft was >> updated to >> > > > >> > > > reference map-dhcp for configuration, the port configuration was >> > > > described >> > > > in sun-dhc-port-set-option, which also stated that the WKPs should >> not be >> > > > assigned. This advice got lost when changing to reference map-dhcp. >> I’ll >> > > > make a suggested text update for the lw4o6 draft to fix this. Does >> that >> > > > work for you? >> > > > >> > > > >> > > > yes, that would be good. >> > > > >> > > > cheers, >> > > > Ole >> > > > >> > > > >> > > > _______________________________________________ >> > > > Softwires mailing list >> > > > [email protected] >> > > > https://www.ietf.org/mailman/listinfo/softwires >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > Softwires mailing list >> > > > [email protected] >> > > > https://www.ietf.org/mailman/listinfo/softwires >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > >> > >> >> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
