Hi Cong, right, but wouldn't you agree that this example is equivalent to a=5, with whatever PSID-len you choose?
The bigger point here is that if this "exclusion" is meant to be configurable on a dhcp server, as in using the S46 Port parameters option then doing so by "dropping" a PSID seems like a duff way to do it, given that the a-bits are already defined specifically for that purpose. Unless, there is some other reason here, I'm of the opionion that having a single way of excluding ports is better than two. Cheers. On 3 June 2014 12:23, Cong Liu <[email protected]> wrote: > Hi Woj, > > Assume a=0 and PSID-len=5, then the ports are divided into [0,2047], > [2048,4095], ... > Just drop the first piece, and allocate others to clients. That's how a=0 > works. > > a=6 can also work, but I don't think it's a SHOULD for a=6 to solve > the WKP issue. > > Best Regards, > Cong > > > 2014-06-03 18:01 GMT+08:00 Wojciech Dec <[email protected]>: > > 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... >> >> >> >> >> >> 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 >> >> >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
