Hi Suresh,

It's ok with me. Thanks for the update.

Best regards!



Yuchi Chen

From: Suresh Krishnan
Date: 2014-06-05 12:32
To: [email protected]; [email protected]; Yuchi Chen; Cong Liu; Tom Taylor
CC: [email protected]; [email protected]; 
[email protected]
Subject: New version published (Was RE: [Softwires] 
draft-ietf-softwire-lw4over6 excluding Well Known Ports)
Hi all (specifically people in the To: list),
  Since you were involved in the discussion on this topic, can you please look 
over the latest version of the lw4over6 draft and see if the change addresses 
your concern. The latest version of the draft is at 
 
http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-09
 
and the diff can be found here
 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-09.txt
 
Thanks
Suresh
 
 
From: Softwires [mailto:[email protected]] On Behalf Of 
[email protected]
Sent: June-03-14 10:16 AM
To: [email protected]
Cc: [email protected]; [email protected]; [email protected]; 
[email protected]
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports
 
Hi Woj,
 
I don’t think that there is a problem. For the purpose of the example that I 
sent you (and to answer your specific question), I rather quickly did a mock up 
of what the config might look like with psid. The current actual implementation 
that we have is still based on the port-min, port-max format that was described 
in an older version of the draft before we settled on PSID (it needs to be 
updated now this has stabilised): Here’s an actual config line:
 
2001:10f:60:1ff::0:b4 1.2.30.121 port 4096 to 8191
 
So, the problem results from my dodgy example rather than anything else.
 
Cheers,
Ian
 
 
From: Wojciech Dec <[email protected]>
Date: Tuesday, 3 June 2014 15:44
To: Ian Farrer <[email protected]>
Cc: Ole Troan <[email protected]>, 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
 
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

Reply via email to