Re: [Softwires] New version published (Was RE: draft-ietf-softwire-lw4over6 excluding Well Known Ports)
Wojciech Dec <wdec.ietf@gmail.com> Thu, 05 June 2014 10:58 UTC
Return-Path: <wdec.ietf@gmail.com>
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 85B141A021C for <softwires@ietfa.amsl.com>; Thu, 5 Jun 2014 03:58:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 NJw2opvp1WNq for <softwires@ietfa.amsl.com>; Thu, 5 Jun 2014 03:58:15 -0700 (PDT)
Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 975951A0245 for <softwires@ietf.org>; Thu, 5 Jun 2014 03:58:14 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id t60so893677wes.13 for <softwires@ietf.org>; Thu, 05 Jun 2014 03:58:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jnMrEOJfY0RtEKcbHTAKcX7tw6T29Mu4IxB2vcdkFIc=; b=KIisqf6vxsvK7ei/s8nh6lgKjNfXRGph/ZqdzvG65f6JYjcaLofVxR4O8BnyvVMZ7f ozf7fChI8MKyBNO7IuGKn6tCqk8ldrjQBpVJW/UOSz9o40JJLC26u9gJMJTYySR9K53D Nbn1WvHakmHGUwzy/cwugzJd6wMfV7axkQ+rwPC7R/bc7LWigRlW/o/75X0GI3gIbu9S p0UP30vNe5cekYW4PJMmLFpZEPLz7TOqmHnB4FKcV/cAFGeKukrNU/89CguQEgrpHTuv lAOWckqhy/3cPmsFgw/Tr5ptJgsipG1H6L5Eu3JIEW2cwiIu/lyHClh0MpUINbq8OdVP zhbg==
MIME-Version: 1.0
X-Received: by 10.194.80.7 with SMTP id n7mr80599927wjx.8.1401965886833; Thu, 05 Jun 2014 03:58:06 -0700 (PDT)
Received: by 10.194.165.71 with HTTP; Thu, 5 Jun 2014 03:58:06 -0700 (PDT)
In-Reply-To: <E87B771635882B4BA20096B589152EF628724B6F@eusaamb107.ericsson.se>
References: <E87B771635882B4BA20096B589152EF628724B6F@eusaamb107.ericsson.se>
Date: Thu, 05 Jun 2014 12:58:06 +0200
Message-ID: <CAFFjW4jm1vq6jQPoBq0QZh6qeW75LwFnCE8jmwOjb+AciQ=Anw@mail.gmail.com>
From: Wojciech Dec <wdec.ietf@gmail.com>
To: Suresh Krishnan <suresh.krishnan@ericsson.com>
Content-Type: multipart/alternative; boundary="047d7beb9c80ac0ac704fb149eca"
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/Dzraa08RPzM1-ieTGPjvzTP_4bw
X-Mailman-Approved-At: Thu, 05 Jun 2014 06:58:51 -0700
Cc: "ot@cisco.com" <ot@cisco.com>, "draft-ietf-softwire-lw4over6@tools.ietf.org" <draft-ietf-softwire-lw4over6@tools.ietf.org>, "softwires@ietf.org" <softwires@ietf.org>
Subject: Re: [Softwires] New version published (Was RE: 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: Thu, 05 Jun 2014 10:58:19 -0000
Got no issues. Thanks. On 5 June 2014 06:32, Suresh Krishnan <suresh.krishnan@ericsson.com> wrote: > 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:softwires-bounces@ietf.org] *On Behalf Of * > ian.farrer@telekom.de > *Sent:* June-03-14 10:16 AM > *To:* wdec.ietf@gmail.com > *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 > > > > 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> > *Date: *Tuesday, 3 June 2014 15:44 > *To: *Ian Farrer <ian.farrer@telekom.de> > *Cc: *Ole Troan <ot@cisco.com>, Tom Taylor <tom.taylor.stds@gmail.com>, > Ian Farrer <ianfarrer@gmx.com>, " > draft-ietf-softwire-lw4over6@tools.ietf.org" < > draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui < > cuiyong@tsinghua.edu.cn>, Softwires-wg <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> 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> > *Date: *Tuesday, 3 June 2014 12:39 > *To: *Ole Troan <ot@cisco.com> > *Cc: *Tom Taylor <tom.taylor.stds@gmail.com>, Ian Farrer < > ianfarrer@gmx.com>, "draft-ietf-softwire-lw4over6@tools.ietf.org" < > draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui < > cuiyong@tsinghua.edu.cn>, Softwires WG <softwires@ietf.org> > *Subject: *Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well > Known Ports > *Resent-To: *Ian Farrer <ian.farrer@telekom.de>, Mohamed Boucadair < > mohamed.boucadair@orange.com>, <sunqiong@ctbri.com.cn>, <tena@huawei.com>, > <yiu_lee@cable.comcast.com>, <yong@csnet1.cs.tsinghua.edu.cn> > > > > How so, could you give an example? > > > > On 3 June 2014 12:17, Ole Troan <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> 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] New version published (Was RE: draft-… Suresh Krishnan
- Re: [Softwires] New version published (Was RE: dr… Ole Troan
- Re: [Softwires] New version published (Was RE: dr… Tom Taylor
- Re: [Softwires] New version published (Was RE: dr… Wojciech Dec
- Re: [Softwires] New version published (Was RE: dr… Cong Liu
- Re: [Softwires] New version published (Was RE: dr… Yuchi Chen