Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports

Hi Woj,

I don't agree that setting a=5 is equivalent to setting a=0 and PSID-len=5. 

Assume that a=5 and PSID-len=5. In this case, each of the port ranges with PSID=0x00~0x0F will cover 64 ports within WKP range. In order to exclude these ports, the value A must be larger than 0. As a result, each of these port ranges will just include 2048-64=1984 available ports. Note that whatever the PSID-len is, there will always be half of all port ranges involved in this.

Now assume that a=0 and PSID-len=5. In this case, excluding WKPs just means dropping the first port range (with PSID=0). Each of the other port ranges (with PSID>0) can equally include 2048 avaliable ports.

If we are to have but one method to exclude WKPs, the one in Lw4o6 seems better to me. 

Regards,

Yuchi Chen

From: Wojciech Dec
Date: 2014-06-03 18:48
To: Cong Liu
CC: draft-ietf-softwire-lw4over6; Ole Troan; Yong Cui; Softwires WG
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports
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 <gnocuil@gmail.com> 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 <wdec.ietf@gmail.com>:

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 <ot@cisco.com> 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 <ot@cisco.com> 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 <tom.taylor.stds@gmail.com> 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 <tom.taylor.stds@gmail.com> 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 <ianfarrer@gmx.com> 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
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> >
> >
> >
> >
> > _______________________________________________
> > Softwires mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires
> >
> >
> >
> >
>
>

_______________________________________________
Softwires mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires