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

From: Ole Troan <[email-masked]>
Date: Thu, 5 Jun 2014 09:49:50 +0200

Suresh,

all my comments have been addressed.

cheers,
Ole

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

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 5 Jun 2014 12:58:06 +0200

Got no issues.

Thanks.

On 5 June 2014 06:32, Suresh Krishnan <[email-masked]> wrote:

>   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
>
>
>
> *From:* Softwires [mailto:[email-masked]] *On Behalf Of *
> [email-masked]
> *Sent:* June-03-14 10:16 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> *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:
>
>
>
> *From: *Wojciech Dec <[email-masked]>
> *Date: *Tuesday, 3 June 2014 15:44
> *To: *Ian Farrer <[email-masked]>
> *Cc: *Ole Troan <[email-masked]>, Tom Taylor <[email-masked]>,
> Ian Farrer <[email-masked]>, "
> [email-masked]" <
> [email-masked]>, Yong Cui <
> [email-masked]>, Softwires-wg <[email-masked]>
> *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.
>
> 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.
>
>
>
> *From: *Wojciech Dec <[email-masked]>
> *Date: *Tuesday, 3 June 2014 12:39
> *To: *Ole Troan <[email-masked]>
> *Cc: *Tom Taylor <[email-masked]>, Ian Farrer <
> [email-masked]>, "[email-masked]" <
> [email-masked]>, Yong Cui <
> [email-masked]>, Softwires WG <[email-masked]>
> *Subject: *Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well
> Known Ports
> *Resent-To: *Ian Farrer <[email-masked]>, Mohamed Boucadair <
> [email-masked]>, <[email-masked]>, <[email-masked]>,
> <[email-masked]>, <[email-masked]>
>
>
>
> > 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...
>
> > > 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
> > >
> > >
> > >
> > >
> > > 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
> > >
> > > >
> > > > 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.
> > > >
> > > > 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
> > > >
> > > >

---

From: Cong Liu <[email-masked]>
Date: Thu, 5 Jun 2014 21:06:32 +0800

It looks good to me.

Regards,
Cong

---

From: "Yuchi Chen" <[email-masked]>
Date: Thu, 5 Jun 2014 21:30:49 +0800

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-masked]; [email-masked]; Yuchi Chen; Cong Liu; Tom Taylor
CC: [email-masked]; [email-masked]; [email-masked]
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 

 
 
Thanks
Suresh

Hi Woj,

 
 
Cheers,
Ian

Hi Ian,

Cheers

 

Cheers,
Ian

 

cheers,
Ole