Re: [Softwires] New version published (Was RE: draft-ietf-softwire-lw4over6 excluding Well Known Ports)

[Cong Liu <[e-mail]>]

It looks good to me.

Regards,
Cong


2014-06-05 12:32 GMT+08:00 Suresh Krishnan <[e-mail]>:

>  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:[e-mail]] *On Behalf Of *
> [e-mail]
> *Sent:* June-03-14 10:16 AM
> *To:* [e-mail]
> *Cc:* [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> *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 <[e-mail]>
> *Date: *Tuesday, 3 June 2014 15:44
> *To: *Ian Farrer <[e-mail]>
> *Cc: *Ole Troan <[e-mail]>, Tom Taylor <[e-mail]>,
> Ian Farrer <[e-mail]>, "
> [e-mail]" <
> [e-mail]>, Yong Cui <
> [e-mail]>, Softwires-wg <[e-mail]>
> *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, <[e-mail]> 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 <[e-mail]>
> *Date: *Tuesday, 3 June 2014 12:39
> *To: *Ole Troan <[e-mail]>
> *Cc: *Tom Taylor <[e-mail]>, Ian Farrer <
> [e-mail]>, "[e-mail]" <
> [e-mail]>, Yong Cui <
> [e-mail]>, Softwires WG <[e-mail]>
> *Subject: *Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well
> Known Ports
> *Resent-To: *Ian Farrer <[e-mail]>, Mohamed Boucadair <
> [e-mail]>, <[e-mail]>, <[e-mail]>,
> <[e-mail]>, <[e-mail]>
>
>
>
> How so, could you give an example?
>
>
>
> On 3 June 2014 12:17, Ole Troan <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/softwires
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > Softwires mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/softwires
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
>
>
>