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

<ian.farrer@telekom.de> Tue, 03 June 2014 14:16 UTC

Return-Path: <ian.farrer@telekom.de>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 496D01A02B3 for <softwires@ietfa.amsl.com>; Tue, 3 Jun 2014 07:16:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.9
X-Spam-Level:
X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ej9AzW-rwMSi for <softwires@ietfa.amsl.com>; Tue, 3 Jun 2014 07:16:16 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09CA1A0227 for <softwires@ietf.org>; Tue, 3 Jun 2014 07:16:13 -0700 (PDT)
Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 03 Jun 2014 16:16:06 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by he110890 ([10.134.92.131]) with mapi; Tue, 3 Jun 2014 16:16:05 +0200
From: ian.farrer@telekom.de
To: wdec.ietf@gmail.com
Date: Tue, 03 Jun 2014 16:16:23 +0200
Thread-Topic: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports
Thread-Index: Ac9/NlrR40HLqp/NRh+QqjGGpaQnIA==
Message-ID: <CFB3A250.C4879%ian.farrer@telekom.de>
References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <DC98AF70-DBF1-48AD-8699-2FC4E645FF40@cisco.com> <C3B32B71-79EE-408F-A92C-D40021DC9A5A@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <BBFBDEAA-0D2B-4A74-86E4-88824712EA26@gmx.com> <CAFFjW4igsiqS5yNUECerMzpZSkmPaL28sqef1usZdxt87y1jEw@mail.gmail.com> <538CB982.2060502@gmail.com> <CAFFjW4jxY=fjCszomzHyWhYtb+1QE+bN-afp_Qi5_32WxUydJg@mail.gmail.com> <538CD547.8070108@gmail.com> <CAFFjW4hqGQ0-oxTcgtFeWgbZRBj5d+82YWJT5Dfh763PORZCYw@mail.gmail.com> <CEE0FE7C-9204-494D-8229-E055E57FAF85@cisco.com> <CAFFjW4gE2byQ7YYZMQfZ3YksmjF2pGYYMp6=A+G1HhY8WHmqTg@mail.gmail.com> <D1054450-6A7E-4EF8-A3D2-D535C60E70DA@cisco.com> <CAFFjW4jAFMe3Zc4FcfXB8CHdHMzns71dP86hRJ7jPiqT738+eg@mail.gmail.com> <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> <CAFFjW4geTuPn5km-cjjt7bUcqSJxo0v8dmjhHewOvHhhaOFNbw@mail.gmail.com> <CFB37875.C42F9%ian.farrer@telekom.de> <CAFFjW4hYpGpqv3KHgXGGFu7fStgqU7zFTMxsjGXo4LG_ohT1Fw@mail.gmail.com>
In-Reply-To: <CAFFjW4hYpGpqv3KHgXGGFu7fStgqU7zFTMxsjGXo4LG_ohT1Fw@mail.gmail.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.1.140326
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_CFB3A250C4879ianfarrertelekomde_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/AccIW6gOsLKvGwPP2NC6OCl9t6E
Cc: ot@cisco.com, softwires@ietf.org, cuiyong@tsinghua.edu.cn, draft-ietf-softwire-lw4over6@tools.ietf.org
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jun 2014 14:16:21 -0000

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 <wdec.ietf@gmail.com<mailto:wdec.ietf@gmail.com>>
Date: Tuesday, 3 June 2014 15:44
To: Ian Farrer <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>>
Cc: Ole Troan <ot@cisco.com<mailto:ot@cisco.com>>, Tom Taylor <tom.taylor.stds@gmail.com<mailto:tom.taylor.stds@gmail.com>>, Ian Farrer <ianfarrer@gmx.com<mailto:ianfarrer@gmx.com>>, "draft-ietf-softwire-lw4over6@tools.ietf.org<mailto:draft-ietf-softwire-lw4over6@tools.ietf.org>" <draft-ietf-softwire-lw4over6@tools.ietf.org<mailto:draft-ietf-softwire-lw4over6@tools.ietf.org>>, Yong Cui <cuiyong@tsinghua.edu.cn<mailto:cuiyong@tsinghua.edu.cn>>, Softwires-wg <softwires@ietf.org<mailto:softwires@ietf.org>>
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, <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>> 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 <wdec.ietf@gmail.com<mailto:wdec.ietf@gmail.com>>
Date: Tuesday, 3 June 2014 12:39
To: Ole Troan <ot@cisco.com<mailto:ot@cisco.com>>
Cc: Tom Taylor <tom.taylor.stds@gmail.com<mailto:tom.taylor.stds@gmail.com>>, Ian Farrer <ianfarrer@gmx.com<mailto:ianfarrer@gmx.com>>, "draft-ietf-softwire-lw4over6@tools.ietf.org<mailto:draft-ietf-softwire-lw4over6@tools.ietf.org>" <draft-ietf-softwire-lw4over6@tools.ietf.org<mailto:draft-ietf-softwire-lw4over6@tools.ietf.org>>, Yong Cui <cuiyong@tsinghua.edu.cn<mailto:cuiyong@tsinghua.edu.cn>>, Softwires WG <softwires@ietf.org<mailto:softwires@ietf.org>>
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports
Resent-To: Ian Farrer <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>>, Mohamed Boucadair <mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>>, <sunqiong@ctbri.com.cn<mailto:sunqiong@ctbri.com.cn>>, <tena@huawei.com<mailto:tena@huawei.com>>, <yiu_lee@cable.comcast.com<mailto:yiu_lee@cable.comcast.com>>, <yong@csnet1.cs.tsinghua.edu.cn<mailto:yong@csnet1.cs.tsinghua.edu.cn>>

How so, could you give an example?


On 3 June 2014 12:17, Ole Troan <ot@cisco.com<mailto:ot@cisco.com>> 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 <ot@cisco.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Softwires@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Softwires mailing list
> > > Softwires@ietf.org<mailto:Softwires@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> >
> >
>
>