From nobody Mon Jun 2 09:14:31 2014 Return-Path: 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 E9B051A038E for ; Mon, 2 Jun 2014 09:14:29 -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 meHXunln-Z_h for ; Mon, 2 Jun 2014 09:14:28 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EA01A0256 for ; Mon, 2 Jun 2014 09:14:27 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so5295947wgg.33 for ; Mon, 02 Jun 2014 09:14:21 -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=62xVHLY30mJq9KKVtJyCsSTxBspHDzZsYcCDfEm26FM=; b=x3eF4i4SoSv5l99IIkTTmxRHZdcfcrAcoK8OWCQs8JLu8rTSyc7tenmKxwRqYenY7w dI56F1WNt6fFOF7zFMxK8AD4ET+Eu8zEfeglGJcNin8WfHLk3oO1RtkmmExTQUhVeTQO T//Yv9wPRV6tuh6XHyMFB9Rlhls5v0SChjgD94dpYgSaRh6/sxveKP5kjEGUT6Q8FRYh AB6O3ZD/55v2Y9AB4QoeXo3gE6iFVLyO+DMSwgqJ6WI+uuu26EYC+lFqZKVu1Ms8+Im9 zLdISkUiFjtjM1ICtJI7l2xvy2v3ed0LJ7OJH8pPXKta9O/gROhYYdDcgrMtJwz0ezHj RFOQ== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr51023186wjx.8.1401725660082; Mon, 02 Jun 2014 09:14:20 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Mon, 2 Jun 2014 09:14:20 -0700 (PDT) In-Reply-To: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> Date: Mon, 2 Jun 2014 18:14:20 +0200 Message-ID: From: Wojciech Dec To: Ian Farrer Content-Type: multipart/alternative; boundary=047d7beb9c800ac0ff04fadcb037 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/YRE9jvjmnZ_8XMMPN8ymYWEQazU Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 16:14:30 -0000 --047d7beb9c800ac0ff04fadcb037 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Uhm, this appears to mean that the RECOMMENDED a-bits SHOULD be 6. On 26 May 2014 13:24, Ian Farrer wrote: > Hi, > > This one slipped my mind=E2=80=A6. > > 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=E2=80=99s 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.=E2=80=9D > > 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 describ= ed > 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=E2= =80=99ll > 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 > --047d7beb9c800ac0ff04fadcb037 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Uhm, this appears to mean that the RECOMMENDED a-bits SHOU= LD be 6.


On 26 May 2014 13:24, Ian Farrer <ianfarrer@gmx.com> wr= ote:
Hi,

This one slipped my mind=E2=80=A6.

>From a discussion with Ole during the MAP dhcp last call, there was a discu= ssion about the exclusion of provisioning WKPs to CPEs - http://www.ietf.org/mail-archive/web/softwires/current/msg06010.html<= /a>

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 los= t when changing to reference map-dhcp for PSID format.

Here=E2=80=99s a wording change proposal to resolve this:

Section 5.1

Original text (last sentence, para 7):

"For lw4o6, the =C2=A0number of a-bits SHOULD be 0."

Proposed change:

"For lw4o6, the number of a-bits SHOULD be 0 to allocate a single cont= iguous port set to each lwB4.

Unless a lwB4 is being allocated a full IPv4 address, it is RECOMMENDED tha= t PSIDs containing the well-known ports (0-1023) are not allocated to lwB4s= .=E2=80=9D

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, =C2=A0the port configuration was = described in sun-dhc-port-set-option, which also stated that the WKPs shoul= d not be assigned. This advice got lost when changing to reference map-dhcp= . I=E2=80=99ll 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

--047d7beb9c800ac0ff04fadcb037-- From nobody Mon Jun 2 10:51:12 2014 Return-Path: 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 24BF51A03A4 for ; Mon, 2 Jun 2014 10:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 BNYz9lt5PWUN for ; Mon, 2 Jun 2014 10:51:08 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602941A03A1 for ; Mon, 2 Jun 2014 10:51:05 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id tp5so4668209ieb.25 for ; Mon, 02 Jun 2014 10:50:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=sEGJjcrmsSAQ42kqFN7W2t+1ppn7edohXRFMbYajmtU=; b=08KhMpNgvtxFvsNlzB003vNJjdjjn65bdCyyeP6qSKKOeQebkxuBN6KZnAbm0ISLtn +SnwM+t8S3W3S8r8ZnLXQD1hcyOCf/hCW3MHfvhpdlEAFeafihYbLQ5Mi+Je2MjpYtfL E5rcYxe+O0KP+9Nd84GKzCyL2PTiLFeE3nrsoKrvI2yqxnYAj1NNVffGpVGJJpyR4cLD XzuFr9PiWEdyyuhz+NuYxOCDuPRFNFUYK1zmQ/9xme33QHy8Wy8bpnofEHMAVFwlVJ5E IHxO2uGvcXruPj+Kp21EQ36WVJsNeVIqQh6G6C/EhKwWYh0opK8TMxC/Bu81Eh4xYvBl Hs0w== X-Received: by 10.43.164.136 with SMTP id ms8mr3733408icc.93.1401731459813; Mon, 02 Jun 2014 10:50:59 -0700 (PDT) Received: from [192.168.0.100] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id fx1sm30359726igd.1.2014.06.02.10.50.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 10:50:59 -0700 (PDT) Message-ID: <538CB982.2060502@gmail.com> Date: Mon, 02 Jun 2014 13:50:58 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wojciech Dec , Ian Farrer References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/PzQJAZ_LDzQavgYKocVQ6AIgXiw Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 17:51:11 -0000 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 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 > From nobody Mon Jun 2 12:27:34 2014 Return-Path: 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 9A5FD1A0275 for ; Mon, 2 Jun 2014 12:27:32 -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 DbkU1AQX95k2 for ; Mon, 2 Jun 2014 12:27:31 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1C81A0223 for ; Mon, 2 Jun 2014 12:27:30 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id l18so5678266wgh.35 for ; Mon, 02 Jun 2014 12:27:24 -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=TUrY0veiKPXMufQQhT+hvOQnAitYUI1We+S3mKxVEFM=; b=M5X1bhRdqIRobMG0L3DTRqUwJAUrkyoAHoLJGZdlQXAYV39PcgPQJH2GlOTZI5LTwa ToXQKEZfEQDgDUeFsWOipw3oIV61OzEyAXrUlYV10kJ2KIIPIF9/E7X7ychyD3VniJHF 7iW86dDYxHo30kY03Xcau5lEtD7EculZ7hkRCAKIGDak6GLz78gVGfnEcraBbnGPzVRh 8huvPNmY+GPU0zXwbJo7mz1Cg5SE/mccCpAJGtaj0e5ek88F+XcY6bhZ8Nv1jdcNfiFr cHQxF21f4o/Cq40QbdEe2Lj1NHrli8RNlnKzjlqBEEIx7sq0GZF5aK16GkxwIAAkthni L4Cg== MIME-Version: 1.0 X-Received: by 10.180.210.237 with SMTP id mx13mr25203177wic.49.1401737243879; Mon, 02 Jun 2014 12:27:23 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Mon, 2 Jun 2014 12:27:23 -0700 (PDT) In-Reply-To: <538CB982.2060502@gmail.com> References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> Date: Mon, 2 Jun 2014 21:27:23 +0200 Message-ID: From: Wojciech Dec To: Tom Taylor Content-Type: multipart/alternative; boundary=001a11c258607d6fc704fadf6295 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/lBILhfFeYmrLQsPqvyy3JIQ4G5I Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:27:33 -0000 --001a11c258607d6fc704fadf6295 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D6. 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=3D6 looks like the SHOULD. If anyone wants t= he full port set, then a=3D0 would be an obvious consequence. On 2 June 2014 19:50, Tom Taylor 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 wrote: >> >> Hi, >>> >>> This one slipped my mind=E2=80=A6. >>> >>> 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=E2=80=99s 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 t= o >>> lwB4s.=E2=80=9D >>> >>> 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= =E2=80=99ll >>> 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 >> >> --001a11c258607d6fc704fadf6295 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Well, I'm referring to the "RECOMMENDED"= ; part. If the recommendation is NOT to allocate ports 0-1024, then this ef= fectively recommends that a-bits=3D6.
Moreover the meaning of SHO= ULD vs RECOMMEND should be questioned. The latter is not a regular normativ= e term, and arguably if the recommendation is for excluding 0-1024 then a= =3D6 looks like the SHOULD. If anyone wants the full port set, then a=3D0 w= ould be an obvious consequence.


On 2 Ju= ne 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
Not sure how you read that, but it can be fi= xed 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=E2=80=A6.

=C2=A0From 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/softwir= es/current/msg06010.html

In previous versions, the lw4o6 used to reference sun-dhc-port-set-option,<= br> which also stated that the WKPs should not be assigned. This advice got
lost when changing to reference map-dhcp for PSID format.

Here=E2=80=99s a wording change proposal to resolve this:

Section 5.1

Original text (last sentence, para 7):

"For lw4o6, the =C2=A0number 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.=E2=80=9D

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, =C2=A0the port configuration was desc= ribed
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=E2=80= =99ll
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<= /a>
https://www.ietf.org/mailman/listinfo/softwires




_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires


--001a11c258607d6fc704fadf6295-- From nobody Mon Jun 2 12:49:44 2014 Return-Path: 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 39FF81A0271 for ; Mon, 2 Jun 2014 12:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 AlJjAIZtwx0U for ; Mon, 2 Jun 2014 12:49:41 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E6821A0223 for ; Mon, 2 Jun 2014 12:49:41 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id lx4so4927750iec.4 for ; Mon, 02 Jun 2014 12:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=QZuewAhlSpWRXar16bNUjr5cWDuTgnjoqSVlswSCZOM=; b=g1nGqmbCRYCK9IQHVoizYXW/yHaiO13QYmJSzlvBohodSPdZiHVIZ8Uqgj1qncea3m olfNtAf5Runxh1DJtpRggnQw4Ed3vG0j9SSfaocjglRbvRgaTm5in1TXjSCjbtmZZgTr AtCSWLRg7JoDMo7cv7V0Z1uT7+UgkH9cD7BZYyJ/NCreo4gD7u9fz1b/2t8SaONPhVi3 XQCj6sA4gn4T9TXHWDg2U76P7FvFp1q4MQ8t5UVR8gz/z7LwT9lVPHNuFN27Tor8EyQi EHCHxL5KX58JqKDlRneOrX8d8Hap/IOvzlZ9AMotMafihJWjKWaUKIUrbzPo870/PePr ejZA== X-Received: by 10.43.58.203 with SMTP id wl11mr5218828icb.76.1401738575978; Mon, 02 Jun 2014 12:49:35 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id qh3sm31004907igb.17.2014.06.02.12.49.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 12:49:35 -0700 (PDT) Message-ID: <538CD547.8070108@gmail.com> Date: Mon, 02 Jun 2014 15:49:27 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Wojciech Dec References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/s0VdlZBZIcTx7F57Sxyz766uLcw Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 19:49:43 -0000 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. 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 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 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 >>> >>> > From nobody Tue Jun 3 01:10:55 2014 Return-Path: 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 2C4AC1A0172 for ; Tue, 3 Jun 2014 01:10:54 -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 ClXK7-hhL9sZ for ; Tue, 3 Jun 2014 01:10:52 -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 E11D71A0162 for ; Tue, 3 Jun 2014 01:10:51 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so6390526wes.13 for ; Tue, 03 Jun 2014 01:10:45 -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=fBrMjNouX/62q8wuXf/JJ0pvny+iyyPF9effM6+Bzxw=; b=0pMSe0xotAwhmce6qAq0IJsADK90UkOACi385PDFLiBDDoTCkbdnQ2vot7MyPk1wi7 3DRPYsjkOgW+2uarCskeT9MAPxmIrym2+nkVT9ZCjZ53Yhs+LZvkLfTX8MWnBJkATavp og/0ZxBZ3q3C6HHRV1z5OD4VDulmExUP68h8eRUStqAfaTjlJPfOdmOmTgYmmekRl6dR ChmD9sWoZaM9+cmfUFE2X6y3vYJJFUpZLgF4uHqYi7XU/xTSVigPZxvyCDHvgoqKz4yT Ovek+VTsT5FpNDCRx6NA1Tr/f8wexxoyvPcYKvM81eZDf23Xmc8r4XSgM87dCdrTP6uP mRfg== MIME-Version: 1.0 X-Received: by 10.194.58.79 with SMTP id o15mr58510837wjq.62.1401783044906; Tue, 03 Jun 2014 01:10:44 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Tue, 3 Jun 2014 01:10:44 -0700 (PDT) In-Reply-To: <538CD547.8070108@gmail.com> References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> Date: Tue, 3 Jun 2014 10:10:44 +0200 Message-ID: From: Wojciech Dec To: Tom Taylor Content-Type: multipart/alternative; boundary=047d7ba972da71a69904faea0ca2 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/UoqTXQb8jStljUsk7bqxUUDW5dc Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:10:54 -0000 --047d7ba972da71a69904faea0ca2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2 June 2014 21:49, Tom Taylor wrote: > There's a difference between setting a=3D6 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=3D6 arrives precisely at what the goal is here, exclude port= s 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= =3D6. >> Moreover the meaning of SHOULD vs RECOMMEND should be questioned. The >> latter is not a regular normative term, and arguably if the recommendati= on >> is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone want= s >> the >> full port set, then a=3D0 would be an obvious consequence. >> >> >> On 2 June 2014 19:50, Tom Taylor wrote: >> >> Not sure how you read that, but it can be fixed by putting a comma afte= r >>> "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 wrote: >>>> >>>> Hi, >>>> >>>>> >>>>> This one slipped my mind=E2=80=A6. >>>>> >>>>> 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 g= ot >>>>> lost when changing to reference map-dhcp for PSID format. >>>>> >>>>> Here=E2=80=99s 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 RECOMMEND= ED >>>>> that PSIDs containing the well-known ports (0-1023) are not allocated >>>>> to >>>>> lwB4s.=E2=80=9D >>>>> >>>>> 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 no= t >>>>> be >>>>> assigned. This advice got lost when changing to reference map-dhcp. >>>>> I=E2=80=99ll >>>>> make a suggested text update for the lw4o6 draft to fix this. Does th= at >>>>> 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 >>>> >>>> >>>> >> --047d7ba972da71a69904faea0ca2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On 2 June 2014 21:49, Tom Taylor <tom.taylor.stds@gmail.co= m> wrote:
There's a difference between setting a= =3D6 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 n= ot 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=3D6= arrives precisely at what the goal is here, exclude ports 0-1024. So if th= ere is a need to have another way of achieving that, by creating some exclu= ded 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.
=C2=A0

RECOMMENDED is part of the RFC 2119 boilerplate. The (unintentionally) miss= ing 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 recomme= ndation is NOT
to allocate ports 0-1024, then this effectively recommends that a-bits=3D6.=
Moreover the meaning of SHOULD vs RECOMMEND should be questioned. The
latter is not a regular normative term, and arguably if the recommendation<= br> is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone wants t= he
full port set, then a=3D0 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 "th= us 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:

=C2=A0 Hi,

This one slipped my mind=E2=80=A6.

=C2=A0 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/softwir= es/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=E2=80=99s a wording change proposal to resolve this:

Section 5.1

Original text (last sentence, para 7):

"For lw4o6, the =C2=A0number 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.=E2=80=9D

Please let me know if you are OK with the proposed change.

cheers,
Ian


=C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draft was updated t= o

reference map-dhcp for configuration, =C2=A0the 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=E2=80= =99ll
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<= /a>
https://www.ietf.org/mailman/listinfo/softwires




_______________________________________________
Softwires mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires




--047d7ba972da71a69904faea0ca2-- From nobody Tue Jun 3 01:51:42 2014 Return-Path: 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 64C3B1A017D for ; Tue, 3 Jun 2014 01:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 dkc8E_s_k8qr for ; Tue, 3 Jun 2014 01:51:38 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F100D1A0172 for ; Tue, 3 Jun 2014 01:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5036; q=dns/txt; s=iport; t=1401785492; x=1402995092; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Ua2GtrRexrLpBdIKSTinPbPuTYZiJovogX2xSN9e8Ss=; b=i2NJXo8EImFTFWcCDCES/vqCAR9t++q5E5EQdJLZn4imnM+ozchfi83K 1kTSieklE1x+kz1BefeOiSdZ12URtIv63cTsWnyQyWySNt2Uz7cC5r8vq IfkAlNHYOrrE6T60dN9r7ITnP3xTNKAZav3bTZstuz6WUScIHFMjen120 M=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcEAAqMjVOtJssW/2dsb2JhbABZg1lVuyWGaFEBgSJ0giUBAQEDAQEBAWsLEAsOCi4hBjAGEwmIJQMJCA3LZQ2FQheMPIFFAQFPB4MrgRUEkVKGNoF4jTqFc4M6Oy+BCg X-IronPort-AV: E=Sophos;i="4.98,963,1392163200"; d="asc'?scan'208";a="72933864" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 03 Jun 2014 08:51:30 +0000 Received: from dhcp-10-61-110-62.cisco.com (dhcp-10-61-110-62.cisco.com [10.61.110.62]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s538pOYS027503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2014 08:51:28 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_2E05E88C-4BC6-4986-961D-38AD3024FE20"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ole Troan In-Reply-To: Date: Tue, 3 Jun 2014 10:51:24 +0200 Message-Id: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/jhx9TdIIX4PlnE-xWjRefe_dOvU Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Softwires WG , Yong Cui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 08:51:40 -0000 --Apple-Mail=_2E05E88C-4BC6-4986-961D-38AD3024FE20 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Woj, in the LW46 case, you can still do a=3D0, and ensure that you don't = provision any PSID which results in the well known ports. cheers, Ole >=20 > On 2 June 2014 21:49, Tom Taylor wrote: > There's a difference between setting a=3D6 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. >=20 > I think that you should illustrate how you think this would work = before we reach a conclusion.=20 > A setting of a=3D6 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. >=20 > Regards. > =20 >=20 > RECOMMENDED is part of the RFC 2119 boilerplate. The (unintentionally) = missing term is NOT RECOMMENDED. >=20 > Tom >=20 >=20 > 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=3D6. > 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=3D6 looks like the SHOULD. If anyone = wants the > full port set, then a=3D0 would be an obvious consequence. >=20 >=20 > On 2 June 2014 19:50, Tom Taylor wrote: >=20 > 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". >=20 > Tom >=20 >=20 > On 02/06/2014 12:14 PM, Wojciech Dec wrote: >=20 > Uhm, this appears to mean that the RECOMMENDED a-bits SHOULD be 6. >=20 >=20 > On 26 May 2014 13:24, Ian Farrer wrote: >=20 > Hi, >=20 > This one slipped my mind=85. >=20 > =46rom 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 >=20 > 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. >=20 > Here=92s a wording change proposal to resolve this: >=20 > Section 5.1 >=20 > Original text (last sentence, para 7): >=20 > "For lw4o6, the number of a-bits SHOULD be 0." >=20 > Proposed change: >=20 > "For lw4o6, the number of a-bits SHOULD be 0 to allocate a single > contiguous port set to each lwB4. >=20 > 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.=94 >=20 > Please let me know if you are OK with the proposed change. >=20 > cheers, > Ian >=20 >=20 > Good spot on the WKP exclusion. Before the lw4o6 draft was updated = to >=20 > 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=92ll > make a suggested text update for the lw4o6 draft to fix this. Does = that > work for you? >=20 >=20 > yes, that would be good. >=20 > cheers, > Ole >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 >=20 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires >=20 >=20 >=20 >=20 --Apple-Mail=_2E05E88C-4BC6-4986-961D-38AD3024FE20 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjYyNAAoJEP0up8EdT99JG/sIANdI8vNcXrdiTPjsgIQXCMNR YRyO9VrM8H0nRWJ2wLPhSIs2HJye8CKPywQLwT+2Ez/hXQQYbsDIYBTzLJzPmDG+ Lql/czOk9AmM2VAbFbAs/5ctz7YtpLMNC5zxTI9Je/Xpie0jPikZLWkhBKcAencH SAGhvmP5RJE+BYHouMG0WGUDWhgdH1Ngq3X1nmsEwptU63F+ZMQNifkY2HcXOUn6 LL/BVxADXA/TvwmZGptEzSEEIgDL6qL55GxkWKvc04oGFEFLdiFJdi8JBTnbjniZ Q5pf9fCMqpV0r1/pdg92LT4sAOJGoVBIviUPZgQZd0dwzn8NMqupcW5snznCwIk= =F1lg -----END PGP SIGNATURE----- --Apple-Mail=_2E05E88C-4BC6-4986-961D-38AD3024FE20-- From nobody Tue Jun 3 02:11:05 2014 Return-Path: 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 DEF661A0188 for ; Tue, 3 Jun 2014 02:11:03 -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 wdvBmLzGvNH3 for ; Tue, 3 Jun 2014 02:11:00 -0700 (PDT) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 372EB1A017F for ; Tue, 3 Jun 2014 02:11:00 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id x12so6270088wgg.18 for ; Tue, 03 Jun 2014 02:10:53 -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=vqGjX6eC9QsXVVqOKeHlTbqekMuL4cmAa6o3R/lkAQI=; b=fjFxm3dQYYP2c7HKrFgxzw/jY/gwpn5hK8nWph9IJikGrQhiHedaVR27/dA+BBdZFB 3p6GOBFxmi3yMkzGMEXx41syE9zwMyelyIAPMRqScNZDyZIOfCAh048Snm0g0Mg12KpS DrLMzoPzbPNVgCF1g+DfUXasGP9hU6ycsWlrzP7y5pV6bHjhZOsJUY7QIcJiBGNgYk/6 6HHeV5ZgC0g+XYwqGnCLDlHo4HWpmTsfYXyg+jVeA/1P2AkA3z94WzdRxaodlspCxBKK EctGczH9IGFQF7CnezTEalTTOj+OJt4Rkxly7TLRevFGhLQ6Gwz59qHQpiyN3CntDfXR 5YfQ== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr31029188wiy.50.1401786653224; Tue, 03 Jun 2014 02:10:53 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Tue, 3 Jun 2014 02:10:53 -0700 (PDT) In-Reply-To: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> Date: Tue, 3 Jun 2014 11:10:53 +0200 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=f46d04428c9884343204faeae31e Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/PWGJAgUDfSE7skPvMXirqdKIbpA Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Softwires WG , Yong Cui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:11:04 -0000 --f46d04428c9884343204faeae31e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Could you show a working example of that in action, along with the set of PSIDs containing the usable port ranges? Cheers On 3 June 2014 10:51, Ole Troan wrote: > Woj, > > in the LW46 case, you can still do a=3D0, 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 wrote: > > There's a difference between setting a=3D6 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=3D6 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= =3D6. > > 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=3D6 looks like the SHOULD. If anyone wan= ts > the > > full port set, then a=3D0 would be an obvious consequence. > > > > > > On 2 June 2014 19:50, Tom Taylor wrote: > > > > Not sure how you read that, but it can be fixed by putting a comma afte= r > > "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 wrote: > > > > Hi, > > > > This one slipped my mind=E2=80=A6. > > > > 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=E2=80=99s 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 t= o > > lwB4s.=E2=80=9D > > > > 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= =E2=80=99ll > > 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 > > > > > > > > > > --f46d04428c9884343204faeae31e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Could you show a working example of that in action, a= long with the set of PSIDs containing the usable port ranges?

= Cheers




On 3 June 2014 10:51, Ole Troan <ot@cisco.com> wrote:
Woj,

in the LW46 case, you can still do a=3D0, and ensure that you don't pro= vision 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=3D6 and setting aside the l= owest 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 nu= mbering space.
>
> I think that you should illustrate how you think this would work befor= e we reach a conclusion.
> A setting of a=3D6 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 re= commendation is NOT
> to allocate ports 0-1024, then this effectively recommends that a-bits= =3D6.
> Moreover the meaning of SHOULD vs RECOMMEND should be questioned. The<= br> > latter is not a regular normative term, and arguably if the recommenda= tion
> is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone wa= nts the
> full port set, then a=3D0 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 aft= er
> "SHOULD be 0" and replacing "to allocate" with &qu= ot;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:
>
> =C2=A0 Hi,
>
> This one slipped my mind=E2=80=A6.
>
> =C2=A0 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 go= t
> lost when changing to reference map-dhcp for PSID format.
>
> Here=E2=80=99s a wording change proposal to resolve this:
>
> Section 5.1
>
> Original text (last sentence, para 7):
>
> "For lw4o6, the =C2=A0number 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 RECOMMENDE= D
> that PSIDs containing the well-known ports (0-1023) are not allocated = to
> lwB4s.=E2=80=9D
>
> Please let me know if you are OK with the proposed change.
>
> cheers,
> Ian
>
>
> =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draft was upda= ted to
>
> reference map-dhcp for configuration, =C2=A0the 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= =E2=80=99ll
> make a suggested text update for the lw4o6 draft to fix this. Does tha= t
> 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
>
>
>
>


--f46d04428c9884343204faeae31e-- From nobody Tue Jun 3 02:32:11 2014 Return-Path: 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 9B0901A00D7 for ; Tue, 3 Jun 2014 02:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 OOcBA9a52G6x for ; Tue, 3 Jun 2014 02:32:08 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CF71A0191 for ; Tue, 3 Jun 2014 02:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5631; q=dns/txt; s=iport; t=1401787922; x=1402997522; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=95lSPdv2w0IcCUm0oFP/VsXiDVwnmnJmL9o/ZxWhR14=; b=cS8aErzfv4C4XckdzwT1fMApmi/gvcLZ3thhmqoIOMkDBJ1GgbF94Tw2 +yCNekjCcqDunA7GPDgO1aVkc3bLm3jPZqW08SNpjLO81xKtqgMf9w6a4 VNKC0vdRDAOUhqEquN5lGBqY0ZDFRq+bgL/fSZ/tMftNKOwm482J8Fq2+ 8=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEACqVjVOtJssW/2dsb2JhbABZg1m7e4ZoUQGBInSCJQEBAQMBAQEBawsFCwsOCi4hBjAGEwmIJQMJCA3Ldw2FQheMPIFFAQFPB4MrgRUEkVWGNoF4jT2FdIM6Oy+BCg X-IronPort-AV: E=Sophos;i="4.98,964,1392163200"; d="asc'?scan'208";a="72310144" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 03 Jun 2014 09:32:00 +0000 Received: from dhcp-10-61-110-62.cisco.com (dhcp-10-61-110-62.cisco.com [10.61.110.62]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s539VvcX031581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2014 09:31:58 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_6EA562D9-3D9E-46D4-BB38-D706ED4EF6CA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ole Troan In-Reply-To: Date: Tue, 3 Jun 2014 11:31:57 +0200 Message-Id: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/4BFZKmA5bjS7-GrnXJYRzI0_5cc Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Softwires WG , Yong Cui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 09:32:09 -0000 --Apple-Mail=_6EA562D9-3D9E-46D4-BB38-D706ED4EF6CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 >=20 > Cheers >=20 >=20 >=20 >=20 > On 3 June 2014 10:51, Ole Troan wrote: > Woj, >=20 > in the LW46 case, you can still do a=3D0, and ensure that you don't = provision any PSID which results in the well known ports. >=20 > cheers, > Ole >=20 > > > > On 2 June 2014 21:49, Tom Taylor wrote: > > There's a difference between setting a=3D6 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=3D6 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=3D6. > > 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=3D6 looks like the SHOULD. If anyone = wants the > > full port set, then a=3D0 would be an obvious consequence. > > > > > > On 2 June 2014 19:50, Tom Taylor 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 wrote: > > > > Hi, > > > > This one slipped my mind=85. > > > > =46rom 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=92s 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.=94 > > > > 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=92ll > > 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 > > > > > > > > >=20 >=20 --Apple-Mail=_6EA562D9-3D9E-46D4-BB38-D706ED4EF6CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjZYNAAoJEP0up8EdT99JtOMH/1ORgHP7afqaIcyIDwm4VuEG IfuhSz/zp6GiCcR4tuFWeMYZbRBcxS06LBYKH+qEqqKVmdlo693nReDwKSe+MiVE q5crBqEFcy5YKRkZqw+iRCvdTJ01b1a0/g3+xIUSCuC/CYBHMVTdAo13oLq01tN6 wfjxUdlImDBrMUMy7yFDVMtQcuIfWauBEBLeKLK5fq6BJZc38GdStcNI0lJLjEAQ Wj2v5ja3VU2YEjVIGpT5ocajpkFDBysKu9whCoaAhcr8SU8y/b+pGGjyw6qPmeuR xu/HRH7bIuMNbi3vaUNYKPHRAOxaF5HW8uMHqEiGurnQm3HuZ3f5OVAE/FafQrI= =Zn+O -----END PGP SIGNATURE----- --Apple-Mail=_6EA562D9-3D9E-46D4-BB38-D706ED4EF6CA-- From nobody Tue Jun 3 03:01:53 2014 Return-Path: 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 6C3DA1A00C0 for ; Tue, 3 Jun 2014 03:01:52 -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 ESYj2L7LArKz for ; Tue, 3 Jun 2014 03:01:50 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C21941A00A3 for ; Tue, 3 Jun 2014 03:01:49 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id f8so6184099wiw.2 for ; Tue, 03 Jun 2014 03:01:41 -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=W6OB1Fu3mlI/QUy2S3DTvcX3EO9kIMILJD+OQpRjrP8=; b=q3wL0IZ7DRIqm94uLgkgj6ccGQFDXvBniLSN7dgCzE3kjk7y0qMq8GC3cuEmrv8OaC Y/wMw//3Tz4Rzyc6kacnE/Gzl17nYNatrMDAt4+1Ldvodt2BtvZkM/aB+Nx78ThZQr13 YonWgBiEWB6telE/KB6x65prK0QcM4ce5+F4MJwxAi2z8TeVU/20U8wJPZDHSZbhW3Z+ 1tT2Z5AQFlt/f6q+BL4TCV5I1v4UQOLze6vaADaI8alwij6+5W+KcWbaBbJS0iq+1aWu IrhyAmBPt/GLr+F7UkxqR1A67+Kzvjo4JVR5fUxYr38Wn11Tlj0o3KX3/0Z3q3H45C2Y LW6g== MIME-Version: 1.0 X-Received: by 10.194.80.7 with SMTP id n7mr58837457wjx.8.1401789701444; Tue, 03 Jun 2014 03:01:41 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Tue, 3 Jun 2014 03:01:41 -0700 (PDT) In-Reply-To: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> Date: Tue, 3 Jun 2014 12:01:41 +0200 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=047d7beb9c80345b2704faeb9923 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/YdcSmld2x97nD1Edd-4XcdgBk1w Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Softwires WG , Yong Cui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:01:53 -0000 --047d7beb9c80345b2704faeb9923 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D6... On 3 June 2014 11:31, Ole Troan 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 yo= u > 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 wrote: > > Woj, > > > > in the LW46 case, you can still do a=3D0, 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 wrote: > > > There's a difference between setting a=3D6 and setting aside the lowe= st > 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=3D6 arrives precisely at what the goal is here, exclud= e > 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=3D6. > > > 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=3D6 looks like the SHOULD. If anyone > wants the > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > On 2 June 2014 19:50, Tom Taylor 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 wrote: > > > > > > Hi, > > > > > > This one slipped my mind=E2=80=A6. > > > > > > 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 g= ot > > > lost when changing to reference map-dhcp for PSID format. > > > > > > Here=E2=80=99s 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 RECOMMEND= ED > > > that PSIDs containing the well-known ports (0-1023) are not allocated > to > > > lwB4s.=E2=80=9D > > > > > > 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 no= t > be > > > assigned. This advice got lost when changing to reference map-dhcp. > I=E2=80=99ll > > > make a suggested text update for the lw4o6 draft to fix this. Does th= at > > > 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 > > > > > > > > > > > > > > > > > > --047d7beb9c80345b2704faeb9923 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks. I'm not sure I get your example though. To exc= lude ports 0-1023, the excluded port "subnet" would be 0x0000/6. = Which would be equivalent to a=3D6...


=


On 3 June 2014 11:31, Ole Troan <ot@cisco.com> wrote:<= br>
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=3D0, 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=3D6 and setting aside = the lowest PSIDs because they occupy that port space. The value of a determ= ines how ports are assigned to each PSID, but does not affect the usable PS= ID numbering space.
> >
> > I think that you should illustrate how you think this would work = before we reach a conclusion.
> > A setting of a=3D6 arrives precisely at what the goal is here, ex= clude 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 (unintention= ally) 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 t= he recommendation is NOT
> > to allocate ports 0-1024, then this effectively recommends that a= -bits=3D6.
> > Moreover the meaning of SHOULD vs RECOMMEND should be questioned.= The
> > latter is not a regular normative term, and arguably if the recom= mendation
> > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyo= ne wants the
> > full port set, then a=3D0 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 comm= a after
> > "SHOULD be 0" and replacing "to allocate" wit= h "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:
> >
> > =C2=A0 Hi,
> >
> > This one slipped my mind=E2=80=A6.
> >
> > =C2=A0 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/soft= wires/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 advi= ce got
> > lost when changing to reference map-dhcp for PSID format.
> >
> > Here=E2=80=99s a wording change proposal to resolve this:
> >
> > Section 5.1
> >
> > Original text (last sentence, para 7):
> >
> > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0." > >
> > Proposed change:
> >
> > "For lw4o6, the number of a-bits SHOULD be 0 to allocate a s= ingle
> > contiguous port set to each lwB4.
> >
> > Unless a lwB4 is being allocated a full IPv4 address, it is RECOM= MENDED
> > that PSIDs containing the well-known ports (0-1023) are not alloc= ated to
> > lwB4s.=E2=80=9D
> >
> > Please let me know if you are OK with the proposed change.
> >
> > cheers,
> > Ian
> >
> >
> > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draft was= updated to
> >
> > reference map-dhcp for configuration, =C2=A0the port configuratio= n was
> > described
> > in sun-dhc-port-set-option, which also stated that the WKPs shoul= d not be
> > assigned. This advice got lost when changing to reference map-dhc= p. I=E2=80=99ll
> > make a suggested text update for the lw4o6 draft to fix this. Doe= s 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
> >
> >
> >
> >
>
>


--047d7beb9c80345b2704faeb9923-- From nobody Tue Jun 3 03:17:16 2014 Return-Path: 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 889BE1A018A for ; Tue, 3 Jun 2014 03:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 oGojDAHPg_7t for ; Tue, 3 Jun 2014 03:17:11 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F991A0190 for ; Tue, 3 Jun 2014 03:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6270; q=dns/txt; s=iport; t=1401790625; x=1403000225; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=9hckuizAGuCCA1RKCVZl3111L9fjH0DyFdTRM0KYxQA=; b=ArLv9B386/1vMx/glKShKFwfdJEBfSfD6bnMNV7tY5wsIby53ulZbwAJ Jp6WXhkTAvc/QgcpsfrRjpF86vLu73YLHRMKXUnQHRecdmsxGBnmC9/x2 kfFFmUJEv8jS9KAN3iLT3CZth5n/wzZX9gwN5CuOKiWCFogK5S8Rqn5Ni o=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMEALOfjVOtJssW/2dsb2JhbABZg1m7fIZoUQGBI3SCJQEBAQMBAQEBawsFCwsOCi4hBjAGEwmIJQMJCA3MCA2FQheMPIFFAQFPB4MrgRUEkVWGNoF4jT2FdIM6Oy+BCg X-IronPort-AV: E=Sophos;i="4.98,964,1392163200"; d="asc'?scan'208";a="68241595" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 03 Jun 2014 10:17:03 +0000 Received: from dhcp-10-61-110-62.cisco.com (dhcp-10-61-110-62.cisco.com [10.61.110.62]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s53AH030032317 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 3 Jun 2014 10:17:02 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_DB507E6B-7AF2-406F-AE25-408BA4C3CA2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ole Troan In-Reply-To: Date: Tue, 3 Jun 2014 12:17:00 +0200 Message-Id: <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> To: Wojciech Dec X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/pGj8EX7mUff6VOIk9IzxNBKFv1A Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Softwires WG , Yong Cui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:17:13 -0000 --Apple-Mail=_DB507E6B-7AF2-406F-AE25-408BA4C3CA2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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=3D6... sorry, yes, you'd not assign 0000/6. that's not equivalent to a=3D6 though. cheers, Ole >=20 >=20 >=20 >=20 >=20 >=20 > On 3 June 2014 11:31, Ole Troan wrote: > Wojciech, >=20 > > Could you show a working example of that in action, along with the = set of PSIDs containing the usable port ranges? >=20 > 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 >=20 > cheers, > Ole >=20 >=20 > > > > Cheers > > > > > > > > > > On 3 June 2014 10:51, Ole Troan wrote: > > Woj, > > > > in the LW46 case, you can still do a=3D0, 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 = wrote: > > > There's a difference between setting a=3D6 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=3D6 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=3D6. > > > 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=3D6 looks like the SHOULD. If = anyone wants the > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > On 2 June 2014 19:50, Tom Taylor = 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 wrote: > > > > > > Hi, > > > > > > This one slipped my mind=85. > > > > > > =46rom 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=92s 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.=94 > > > > > > 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=92ll > > > 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 > > > > > > > > > > > > > > > > >=20 >=20 --Apple-Mail=_DB507E6B-7AF2-406F-AE25-408BA4C3CA2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTjaCcAAoJEP0up8EdT99JRJoIAIZS/CCGRd895gKsckGWTIES gLpEB1aVU4YZzn3SSA07lnrHgXB3p8ZMcaJatNrv1rxWEU5KI1qXhNXbWJTDh/r6 QBCvjXrcVBzhyInz3/DtMo/ckaswr5AYlN9qUj9GfKj/4LlRjX9OCKlx7+347tbS 785TOXL74Fi6gXTdEOv49yoU8GCGaXYZ1cn5xX3D5aPTTNXYDHnTn1NdAVhD62zG D3b3tTKcL9Bs/gNweEvE71l56y1nUJZ0g6keJULVhFIYj/vhj/Me7b7a/txOOC4p nUl27Q02qPsaOwOK6ORnHgfr9cOIubtPwGBYo+8A7ZDy9sLtqh0rSfdbIxDKDVw= =o1dA -----END PGP SIGNATURE----- --Apple-Mail=_DB507E6B-7AF2-406F-AE25-408BA4C3CA2C-- From nobody Tue Jun 3 03:24:21 2014 Return-Path: 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 8B07B1A01A8 for ; Tue, 3 Jun 2014 03:24:17 -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 DS3UcK10cuAV for ; Tue, 3 Jun 2014 03:24:15 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFC81A018A for ; Tue, 3 Jun 2014 03:24:14 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so12883601qge.12 for ; Tue, 03 Jun 2014 03:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=O+/dktJDeJoM7+pW930WJNPnFvo/Bnhez1jqrtI+pOg=; b=PjP7V0KGHeywXr8cIFFSv97T02YyWePNx4oMYgxoOJZqpAPcb00dZDzmZmhqHJluIP Ff4j61Iw+eFpX2O4ogw50l+YueSpEppiYQ/Xu7E8JTI1vRegeAsETWFsHtmp/zCx7YC3 gEUtnH3hebP4+yLh7gBfQvY99HBMZXBAH+yQlWB5ZOGN8MvmUYW/bgeKbzOwMJCqTauY pwjfoiZB0yn15E2nJIDIFol/MgTfqb9LtFGt3O2mywaW/fbtvjFO0XohW6sZO1wvd1hO 29YXBWheaOh+gw0aFv7MIAZoo0LoJg0B5o1edEQV3hDlBvOgJceGem94yKoEz55wOc3T 8Mzg== X-Received: by 10.140.49.76 with SMTP id p70mr54121296qga.86.1401791048828; Tue, 03 Jun 2014 03:24:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.149.2 with HTTP; Tue, 3 Jun 2014 03:23:48 -0700 (PDT) In-Reply-To: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> From: Cong Liu Date: Tue, 3 Jun 2014 18:23:48 +0800 Message-ID: To: Wojciech Dec Content-Type: multipart/alternative; boundary=001a11370a3483ceb604faebe929 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/um0Ae4NIG4GZqxDt9cj7BLNY8rY Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:24:17 -0000 --001a11370a3483ceb604faebe929 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Woj, Assume a=3D0 and PSID-len=3D5, then the ports are divided into [0,2047], [2048,4095], ... Just drop the first piece, and allocate others to clients. That's how a=3D0 works. a=3D6 can also work, but I don't think it's a SHOULD for a=3D6 to solve the= WKP issue. Best Regards, Cong 2014-06-03 18:01 GMT+08:00 Wojciech Dec : > 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 t= o > a=3D6... > > > > > > On 3 June 2014 11:31, Ole Troan 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 wrote: >> > Woj, >> > >> > in the LW46 case, you can still do a=3D0, 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 wrote: >> > > There's a difference between setting a=3D6 and setting aside the low= est >> 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=3D6 arrives precisely at what the goal is here, exclu= de >> ports 0-1024. So if there is a need to have another way of achieving tha= t, >> by creating some excluded magic PSID value that corresponds to 0-1024, w= e >> would like to know why is that relevant and how it is supposed to work i= n 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=3D6. >> > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. Th= e >> > > latter is not a regular normative term, and arguably if the >> recommendation >> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone >> wants the >> > > full port set, then a=3D0 would be an obvious consequence. >> > > >> > > >> > > On 2 June 2014 19:50, Tom Taylor 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 wrote: >> > > >> > > Hi, >> > > >> > > This one slipped my mind=E2=80=A6. >> > > >> > > From a discussion with Ole during the MAP dhcp last call, there wa= s >> 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=E2=80=99s 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 allocate= d >> to >> > > lwB4s.=E2=80=9D >> > > >> > > 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=E2=80=99ll >> > > 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 mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires > > --001a11370a3483ceb604faebe929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Woj,

Assume a=3D0 and=C2=A0PSID-len=3D5, then the ports are divi= ded into [0,2047], [2048,4095], ...
Just drop the first piece, and allocate others to clients. That's how= a=3D0 works.

= a=3D6 can also work, but I don't think it's a SHOULD for a=3D6 to s= olve the=C2=A0WKP issue.

Best Regards,
Cong


2014-06-03 18:01 GMT+08:00 Wojciech Dec <wdec.ietf@gmail.com&g= t;:
Thanks. I'm not sure I get your examp= le though. To exclude ports 0-1023, the excluded port "subnet" wo= uld be 0x0000/6. Which would be equivalent to a=3D6...


On 3 June 2014 11:31, Ole Troa= n <o= t@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=3D0, 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=3D6 and setting aside = the lowest PSIDs because they occupy that port space. The value of a determ= ines how ports are assigned to each PSID, but does not affect the usable PS= ID numbering space.
> >
> > I think that you should illustrate how you think this would work = before we reach a conclusion.
> > A setting of a=3D6 arrives precisely at what the goal is here, ex= clude 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 (unintention= ally) 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 t= he recommendation is NOT
> > to allocate ports 0-1024, then this effectively recommends that a= -bits=3D6.
> > Moreover the meaning of SHOULD vs RECOMMEND should be questioned.= The
> > latter is not a regular normative term, and arguably if the recom= mendation
> > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyo= ne wants the
> > full port set, then a=3D0 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 comm= a after
> > "SHOULD be 0" and replacing "to allocate" wit= h "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:
> >
> > =C2=A0 Hi,
> >
> > This one slipped my mind=E2=80=A6.
> >
> > =C2=A0 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/soft= wires/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 advi= ce got
> > lost when changing to reference map-dhcp for PSID format.
> >
> > Here=E2=80=99s a wording change proposal to resolve this:
> >
> > Section 5.1
> >
> > Original text (last sentence, para 7):
> >
> > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0." > >
> > Proposed change:
> >
> > "For lw4o6, the number of a-bits SHOULD be 0 to allocate a s= ingle
> > contiguous port set to each lwB4.
> >
> > Unless a lwB4 is being allocated a full IPv4 address, it is RECOM= MENDED
> > that PSIDs containing the well-known ports (0-1023) are not alloc= ated to
> > lwB4s.=E2=80=9D
> >
> > Please let me know if you are OK with the proposed change.
> >
> > cheers,
> > Ian
> >
> >
> > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draft was= updated to
> >
> > reference map-dhcp for configuration, =C2=A0the port configuratio= n was
> > described
> > in sun-dhc-port-set-option, which also stated that the WKPs shoul= d not be
> > assigned. This advice got lost when changing to reference map-dhc= p. I=E2=80=99ll
> > make a suggested text update for the lw4o6 draft to fix this. Doe= s 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 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


--001a11370a3483ceb604faebe929-- From nobody Tue Jun 3 03:40:05 2014 Return-Path: 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 1B8391A01A0 for ; Tue, 3 Jun 2014 03:40:03 -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 UIbvUIkHYWSl for ; Tue, 3 Jun 2014 03:39:59 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A4C1A01B1 for ; Tue, 3 Jun 2014 03:39:58 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so6410247wgg.33 for ; Tue, 03 Jun 2014 03:39:51 -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=xnVdeCGgGJTrliv/KPEtfyZhYVrQ/j5R5HreEC3uApU=; b=WTYKpT4oMFaLt4pIwUpbiWDxWJEEcMbqDjOX79XSkJxKbY7EYZLpYU2ErH6Qx+/lDX LcTOdckKWtZASWBeJ8UJmN+wT4wS44pk4Af6aAWMwgTQa3w8njtXRRtAdCAEJRPFFW9V QCjqSNhbq4ZWHZO+SeKg97iD6R8jk7ySJlDxBSRJPOHJ5SkedeOkOH8Y2d9cpS3Y+ueg VShkcI3b9W/xvH2dms80jc94sk37OBvnuQZE1zcpvY1x9uR9Pel0+KtrK9O532Kb1WIt MW2Gnm0AYDouEnBmLqwTI102xds8UatFmct3RWGfnEnD9opQjG3lGVvM2Cp9pFoa946y rOFw== MIME-Version: 1.0 X-Received: by 10.194.58.79 with SMTP id o15mr59835189wjq.62.1401791991058; Tue, 03 Jun 2014 03:39:51 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Tue, 3 Jun 2014 03:39:50 -0700 (PDT) In-Reply-To: <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> Date: Tue, 3 Jun 2014 12:39:50 +0200 Message-ID: From: Wojciech Dec To: Ole Troan Content-Type: multipart/alternative; boundary=047d7ba972daad190d04faec2153 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/Hma4oH7xN7K5iXAfXb0l9RC8n48 Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Softwires WG , Yong Cui 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:40:03 -0000 --047d7ba972daad190d04faec2153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How so, could you give an example? On 3 June 2014 12:17, Ole Troan 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 t= o > a=3D6... > > sorry, yes, you'd not assign 0000/6. > that's not equivalent to a=3D6 though. > > cheers, > Ole > > > > > > > > > > > > > > > > On 3 June 2014 11:31, Ole Troan wrote: > > Wojciech, > > > > > Could you show a working example of that in action, along with the se= t > 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 wrote: > > > Woj, > > > > > > in the LW46 case, you can still do a=3D0, 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 wrote: > > > > There's a difference between setting a=3D6 and setting aside the > lowest PSIDs because they occupy that port space. The value of a determin= es > 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=3D6 arrives precisely at what the goal is here, excl= ude > 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 recommendatio= n > is NOT > > > > to allocate ports 0-1024, then this effectively recommends that > a-bits=3D6. > > > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. T= he > > > > latter is not a regular normative term, and arguably if the > recommendation > > > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone > wants the > > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > > > > On 2 June 2014 19:50, Tom Taylor 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 wrote: > > > > > > > > Hi, > > > > > > > > This one slipped my mind=E2=80=A6. > > > > > > > > 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.htm= l > > > > > > > > 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=E2=80=99s 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.=E2=80=9D > > > > > > > > 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 update= d > 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=E2=80=99ll > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > --047d7ba972daad190d04faec2153 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
How so, could you give an example?


On 3 June 2014 12:17, Ole T= roan <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=3D6...

sorry, yes, you'd not assign 0000/6.
that's not equivalent to a=3D6 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 th= e 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 p= orts 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=3D0, 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=3D6 and setting a= side the lowest PSIDs because they occupy that port space. The value of a d= etermines how ports are assigned to each PSID, but does not affect the usab= le PSID numbering space.
> > >
> > > I think that you should illustrate how you think this would = work before we reach a conclusion.
> > > A setting of a=3D6 arrives precisely at what the goal is her= e, exclude ports 0-1024. So if there is a need to have another way of achie= ving 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 (uninte= ntionally) 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 t= hat a-bits=3D6.
> > > Moreover the meaning of SHOULD vs RECOMMEND should be questi= oned. The
> > > latter is not a regular normative term, and arguably if the = recommendation
> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If= anyone wants the
> > > full port set, then a=3D0 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:
> > >
> > > =C2=A0 Hi,
> > >
> > > This one slipped my mind=E2=80=A6.
> > >
> > > =C2=A0 From a discussion with Ole during the MAP dhcp last c= all, 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=E2=80=99s a wording change proposal to resolve this: > > >
> > > Section 5.1
> > >
> > > Original text (last sentence, para 7):
> > >
> > > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0.&quo= t;
> > >
> > > Proposed change:
> > >
> > > "For lw4o6, the number of a-bits SHOULD be 0 to allocat= e 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.=E2=80=9D
> > >
> > > Please let me know if you are OK with the proposed change. > > >
> > > cheers,
> > > Ian
> > >
> > >
> > > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draf= t was updated to
> > >
> > > reference map-dhcp for configuration, =C2=A0the port configu= ration 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 ma= p-dhcp. I=E2=80=99ll
> > > 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
> > >
> > >
> > >
> > >
> >
> >
>
>


--047d7ba972daad190d04faec2153-- From nobody Tue Jun 3 03:49:01 2014 Return-Path: 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 89EF11A01B6 for ; Tue, 3 Jun 2014 03:48:58 -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 pwzu3jTzIGsu for ; Tue, 3 Jun 2014 03:48:55 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E66271A01B4 for ; Tue, 3 Jun 2014 03:48:54 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id w62so6628543wes.16 for ; Tue, 03 Jun 2014 03:48:48 -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=SzSfhzQ+5GBo6kEIcKGbjlCjc0vZnL94oKkkpUnKXCU=; b=ywsiWD1Ecj5ZUB8rwXkIpCLrnii+0W/49eZYAY3bE6L5X9y6ngrP9uGFxr0RuAXPAM HXcmhNkc0kwQPVFQSoOi+4fDgZbmeZt9FlFpSzyJBGmCMhQPfDW865BWVAOyPuvQczYs EVtqPFS/POLX1IXPzlfxBUmPaHwKzbG2daiWPGZafja+0ktvzdo8CmKTHdhH5JhUgmjM eFnAFC7JYNmrE2FVEtqzjsmjJyOh6/cfGLZ9DhKLG+xNvrBLTUkOID2aLOdmSTKTcvwi UV0pYL6H+8MxOHNRHc0hBeCDBslZGownAhGNLhYaFO0gfgcr/4H30M4u5LzOasZWRGa6 ISDA== MIME-Version: 1.0 X-Received: by 10.180.82.133 with SMTP id i5mr31845606wiy.50.1401792528165; Tue, 03 Jun 2014 03:48:48 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Tue, 3 Jun 2014 03:48:48 -0700 (PDT) In-Reply-To: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> Date: Tue, 3 Jun 2014 12:48:48 +0200 Message-ID: From: Wojciech Dec To: Cong Liu Content-Type: multipart/alternative; boundary=f46d04428c98b0b19704faec4199 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/bjeXMb0ik7GLUdpobjeZNHR5u64 Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, Ole Troan , Yong Cui , Softwires WG 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 10:48:58 -0000 --f46d04428c98b0b19704faec4199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Cong, right, but wouldn't you agree that this example is equivalent to a=3D5, wit= h whatever PSID-len you choose? The bigger point here is that if this "exclusion" is meant to be configurable on a dhcp server, as in using the S46 Port parameters option then doing so by "dropping" a PSID seems like a duff way to do it, given that the a-bits are already defined specifically for that purpose. Unless, there is some other reason here, I'm of the opionion that having a single way of excluding ports is better than two. Cheers. On 3 June 2014 12:23, Cong Liu wrote: > Hi Woj, > > Assume a=3D0 and PSID-len=3D5, then the ports are divided into [0,2047], > [2048,4095], ... > Just drop the first piece, and allocate others to clients. That's how a= =3D0 > works. > > a=3D6 can also work, but I don't think it's a SHOULD for a=3D6 to solve > the WKP issue. > > Best Regards, > Cong > > > 2014-06-03 18:01 GMT+08:00 Wojciech Dec : > > 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=3D6... >> >> >> >> >> >> On 3 June 2014 11:31, Ole Troan wrote: >> >>> Wojciech, >>> >>> > Could you show a working example of that in action, along with the se= t >>> 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 port= s >>> 0000/10 >>> >>> cheers, >>> Ole >>> >>> >>> > >>> > Cheers >>> > >>> > >>> > >>> > >>> > On 3 June 2014 10:51, Ole Troan wrote: >>> > Woj, >>> > >>> > in the LW46 case, you can still do a=3D0, 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 wrote: >>> > > There's a difference between setting a=3D6 and setting aside the >>> lowest PSIDs because they occupy that port space. The value of a determ= ines >>> how ports are assigned to each PSID, but does not affect the usable PSI= D >>> numbering space. >>> > > >>> > > I think that you should illustrate how you think this would work >>> before we reach a conclusion. >>> > > A setting of a=3D6 arrives precisely at what the goal is here, excl= ude >>> ports 0-1024. So if there is a need to have another way of achieving th= at, >>> 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 recommendatio= n >>> is NOT >>> > > to allocate ports 0-1024, then this effectively recommends that >>> a-bits=3D6. >>> > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. T= he >>> > > latter is not a regular normative term, and arguably if the >>> recommendation >>> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone >>> wants the >>> > > full port set, then a=3D0 would be an obvious consequence. >>> > > >>> > > >>> > > On 2 June 2014 19:50, Tom Taylor 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 wrote: >>> > > >>> > > Hi, >>> > > >>> > > This one slipped my mind=E2=80=A6. >>> > > >>> > > 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.htm= l >>> > > >>> > > 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=E2=80=99s 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.=E2=80=9D >>> > > >>> > > 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 update= d >>> 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=E2=80=99ll >>> > > 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 mailing list >> Softwires@ietf.org >> https://www.ietf.org/mailman/listinfo/softwires >> >> > --f46d04428c98b0b19704faec4199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Cong,

right, but would= n't you agree that this example is equivalent to a=3D5, with whatever P= SID-len you choose?

The bigger point here is that if thi= s "exclusion" is meant to be configurable on a dhcp server, as in= using the S46 Port parameters option then doing so by "dropping"= a PSID seems like a duff way to do it, given that the a-bits are already d= efined specifically for that purpose. Unless, there is some other reason he= re, I'm of the opionion that having a single way of excluding ports is = better than two.

Cheers.



On 3 June 2014 12:23, C= ong Liu <gnocuil@gmail.com> wrote:
Hi Woj,

= Assume a=3D0 and=C2=A0PSID-l= en=3D5, then the ports are divided into [0,2047], [2048,4095], ...
Just drop the first piece, and allocate others= to clients. That's how a=3D0 works.

= a=3D6 can also work, but I don't think it's a SHOULD for a=3D6 to s= olve the=C2=A0WKP issue.

Best Regards,
Cong


2014-06-03 18:01 GMT+08:00 Wojciech Dec <wdec.ietf@gmail.com&g= t;:

Thanks. I'm not sure I get your examp= le though. To exclude ports 0-1023, the excluded port "subnet" wo= uld be 0x0000/6. Which would be equivalent to a=3D6...


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=3D0, 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=3D6 and setting aside = the lowest PSIDs because they occupy that port space. The value of a determ= ines how ports are assigned to each PSID, but does not affect the usable PS= ID numbering space.
> >
> > I think that you should illustrate how you think this would work = before we reach a conclusion.
> > A setting of a=3D6 arrives precisely at what the goal is here, ex= clude 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 (unintention= ally) 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 t= he recommendation is NOT
> > to allocate ports 0-1024, then this effectively recommends that a= -bits=3D6.
> > Moreover the meaning of SHOULD vs RECOMMEND should be questioned.= The
> > latter is not a regular normative term, and arguably if the recom= mendation
> > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyo= ne wants the
> > full port set, then a=3D0 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 comm= a after
> > "SHOULD be 0" and replacing "to allocate" wit= h "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:
> >
> > =C2=A0 Hi,
> >
> > This one slipped my mind=E2=80=A6.
> >
> > =C2=A0 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/soft= wires/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 advi= ce got
> > lost when changing to reference map-dhcp for PSID format.
> >
> > Here=E2=80=99s a wording change proposal to resolve this:
> >
> > Section 5.1
> >
> > Original text (last sentence, para 7):
> >
> > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0." > >
> > Proposed change:
> >
> > "For lw4o6, the number of a-bits SHOULD be 0 to allocate a s= ingle
> > contiguous port set to each lwB4.
> >
> > Unless a lwB4 is being allocated a full IPv4 address, it is RECOM= MENDED
> > that PSIDs containing the well-known ports (0-1023) are not alloc= ated to
> > lwB4s.=E2=80=9D
> >
> > Please let me know if you are OK with the proposed change.
> >
> > cheers,
> > Ian
> >
> >
> > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draft was= updated to
> >
> > reference map-dhcp for configuration, =C2=A0the port configuratio= n was
> > described
> > in sun-dhc-port-set-option, which also stated that the WKPs shoul= d not be
> > assigned. This advice got lost when changing to reference map-dhc= p. I=E2=80=99ll
> > make a suggested text update for the lw4o6 draft to fix this. Doe= s 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 mailing list
Softwires@ietf.org<= /a>
https://www.ietf.org/mailman/listinfo/softwires



--f46d04428c98b0b19704faec4199-- From nobody Tue Jun 3 04:09:15 2014 Return-Path: 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 348C71A01B4 for ; Tue, 3 Jun 2014 04:09:13 -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 pbKoo_fHPdxj for ; Tue, 3 Jun 2014 04:09:09 -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 3A6641A019B for ; Tue, 3 Jun 2014 04:09:08 -0700 (PDT) Received: from he113445.emea1.cds.t-internal.com ([10.134.93.105]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 03 Jun 2014 13:08:47 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113445.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 3 Jun 2014 13:08:47 +0200 From: To: , Date: Tue, 3 Jun 2014 13:09:07 +0200 Thread-Topic: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports Thread-Index: Ac9/HDDMpImitFhoTxyYFglf76H9sQ== Message-ID: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> In-Reply-To: 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_CFB37875C42F9ianfarrertelekomde_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/sE89vKWGgI2SKtMHhFYseY7UIU8 Cc: draft-ietf-softwire-lw4over6@tools.ietf.org, softwires@ietf.org, cuiyong@tsinghua.edu.cn 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 11:09:13 -0000 --_000_CFB37875C42F9ianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Woj, Here=92s an example from an lwAFTR binding table. In this case, there=92s 4= 096 ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn=92t 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 > Date: Tuesday, 3 June 2014 12:39 To: Ole Troan > Cc: Tom Taylor = >, Ian Farrer >, "draft-ietf-so= ftwire-lw4over6@tools.ietf.org" >, Yong Cui >, Softwires WG > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known = Ports Resent-To: Ian Farrer >= , Mohamed Boucadair >, >, >, >, > How so, could you give an example? On 3 June 2014 12:17, Ole Troan > 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=3D6... sorry, yes, you'd not assign 0000/6. that's not equivalent to a=3D6 though. cheers, Ole > > > > > > > On 3 June 2014 11:31, Ole Troan > 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 yo= u 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/1= 0 > > cheers, > Ole > > > > > > Cheers > > > > > > > > > > On 3 June 2014 10:51, Ole Troan > wro= te: > > Woj, > > > > in the LW46 case, you can still do a=3D0, and ensure that you don't pro= vision any PSID which results in the well known ports. > > > > cheers, > > Ole > > > > > > > > On 2 June 2014 21:49, Tom Taylor > wrote: > > > There's a difference between setting a=3D6 and setting aside the lowe= st 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 numbe= ring space. > > > > > > I think that you should illustrate how you think this would work befo= re we reach a conclusion. > > > A setting of a=3D6 arrives precisely at what the goal is here, exclud= e 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-bit= s=3D6. > > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. The > > > latter is not a regular normative term, and arguably if the recommend= ation > > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone w= ants the > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > On 2 June 2014 19:50, Tom Taylor > wrote: > > > > > > Not sure how you read that, but it can be fixed by putting a comma af= ter > > > "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 > wrote: > > > > > > Hi, > > > > > > This one slipped my mind=85. > > > > > > 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 g= ot > > > lost when changing to reference map-dhcp for PSID format. > > > > > > Here=92s 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 RECOMMEND= ED > > > that PSIDs containing the well-known ports (0-1023) are not allocated= to > > > lwB4s.=94 > > > > > > 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 no= t be > > > assigned. This advice got lost when changing to reference map-dhcp. I= =92ll > > > make a suggested text update for the lw4o6 draft to fix this. Does th= at > > > 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 > > > > > > > > > > > > > > > > > > --_000_CFB37875C42F9ianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Woj,

=
Here=92s an example from an lwAFTR binding table. In this case, = there=92s 4096 ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn= =92t in the table.

2001:10f:60:6ff::0:b4 1.2.30.12= 6 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 2048= 0
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.1= 26 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 4= 9152
2001:10f:60:6ff::c:b4 1.2.30.126 PSID 53248
2001:1= 0f:60:6ff::d:b4 1.2.30.126 PSID 57344
2001:10f:60:6ff::e:b4 1.2.3= 0.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:7f= f::9:b4 1.2.30.127 PSID 40960
2001:10f:60:7ff::a:b4 1.2.30.127 PS= ID 45056
2001:10f:60:7ff::b:b4 1.2.30.127 PSID 49152
20= 01: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<= /div>

Cheers,
Ian



How so, c= ould you give an example?


On 3 June 2014 12:17, Ole Troan <= ;ot@cisco.com> wrote:
Wojciech,
<= br> > Thanks. I'm not sure I get your example though. To exclude ports 0-102= 3, the excluded port "subnet" would be 0x0000/6. Which would be e= quivalent to a=3D6...

sorry, yes, you'd not assign 0000/6.
that's not equivalent to a=3D6 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 th= e 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 - 1= 92.168.0.255 in a DHCP pool. in the PSID case you will not assign ports 000= 0/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=3D0, 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=3D6 and setting aside= the lowest PSIDs because they occupy that port space. The value of a deter= mines how ports are assigned to each PSID, but does not affect the usable P= SID numbering space.
> > >
> > > I think that you should illustrate how you think this would = work before we reach a conclusion.
> > > A setting of a=3D6 arrives precisely at what the goal is her= e, exclude ports 0-1024. So if there is a need to have another way of achie= ving 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 (uninte= ntionally) 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 t= hat a-bits=3D6.
> > > Moreover the meaning of SHOULD vs RECOMMEND should be questi= oned. The
> > > latter is not a regular normative term, and arguably if the = recommendation
> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If= anyone wants the
> > > full port set, then a=3D0 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=85.
> > >
> > >   From a discussion with Ole during the MAP dhcp last c= all, 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=92s 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.&quo= t;
> > >
> > > Proposed change:
> > >
> > > "For lw4o6, the number of a-bits SHOULD be 0 to allocat= e 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.=94
> > >
> > > Please let me know if you are OK with the proposed change. > > >
> > > cheers,
> > > Ian
> > >
> > >
> > >   Good spot on the WKP exclusion. Before the lw4o6 draf= t was updated to
> > >
> > > reference map-dhcp for configuration,  the port configu= ration 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 ma= p-dhcp. I=92ll
> > > 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
> > >
> > >
> > >
> > >
> >
> >
>
>


 --_000_CFB37875C42F9ianfarrertelekomde_-- From nobody Tue Jun 3 05:37:57 2014 Return-Path: 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 CC3061A0229 for ; Tue, 3 Jun 2014 05:37:53 -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 MTWfQIdz6EjH for ; Tue, 3 Jun 2014 05:37:50 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58111A01E7 for ; Tue, 3 Jun 2014 05:37:49 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v10so4617642pde.18 for ; Tue, 03 Jun 2014 05:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:mime-version:message-id :content-type; bh=2Ex5xDNan9U5dFdI+/ej7XPP6VGa+LfwxdbBad0n8f0=; b=J2vAWCg9aIhr9LmDvsnL1unFvy6MWBo6r6w87w1NkE+DPjoKKB+/DVIDiSGZWoXWvT spIWBsH7w5165+z9FjSjMA2AwpPlEM0sBbpgaF47DbrKIHbbHotKMn8oAPvl/vjzNIHg 8M/VEYPKOqCFdTgQ3/raeAOrGIx0Xlgxwk+NRqkpqlBeHgLrNV8wiLIDxfnAi+ep3xn5 hgNimdalx7AZgKmPUAqFGgMkidIlolIef6uErt196oTqZPX4PCKE4XKaoGcQWz1GJowG H75CWC8GhQ2IPGntOtJgDspjMjYNEKzbnuo2gpShCzjRuVSPwsDTB/aBzuvztvzN9KUK zZHA== X-Received: by 10.68.245.162 with SMTP id xp2mr50379964pbc.69.1401799064257; Tue, 03 Jun 2014 05:37:44 -0700 (PDT) Received: from netlab-PC ([114.242.249.123]) by mx.google.com with ESMTPSA id iv2sm27669096pbc.19.2014.06.03.05.37.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 03 Jun 2014 05:37:42 -0700 (PDT) Date: Tue, 3 Jun 2014 20:37:36 +0800 From: "Yuchi Chen" To: "Wojciech Dec" , "Cong Liu" References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> , X-Priority: 3 X-GUID: 78708491-3D56-4F21-9881-3BF7523F27CE X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <2014060320372786716329@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart672112364754_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/5dMC1_QjN5ZNi8Fv-KanJeVJyK8 Cc: draft-ietf-softwire-lw4over6 , Ole Troan , Yong Cui , softwires WG Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 12:37:53 -0000 This is a multi-part message in MIME format. ------=_001_NextPart672112364754_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV29qLA0KDQpJIGRvbid0IGFncmVlIHRoYXQgc2V0dGluZyBhPTUgaXMgZXF1aXZhbGVudCB0 byBzZXR0aW5nIGE9MCBhbmQgUFNJRC1sZW49NS4gDQoNCkFzc3VtZSB0aGF0IGE9NSBhbmQgUFNJ RC1sZW49NS4gSW4gdGhpcyBjYXNlLCBlYWNoIG9mIHRoZSBwb3J0IHJhbmdlcyB3aXRoIFBTSUQ9 MHgwMH4weDBGIHdpbGwgY292ZXIgNjQgcG9ydHMgd2l0aGluIFdLUCByYW5nZS4gSW4gb3JkZXIg dG8gZXhjbHVkZSB0aGVzZSBwb3J0cywgdGhlIHZhbHVlIEEgbXVzdCBiZSBsYXJnZXIgdGhhbiAw LiBBcyBhIHJlc3VsdCwgZWFjaCBvZiB0aGVzZSBwb3J0IHJhbmdlcyB3aWxsIGp1c3QgaW5jbHVk ZSAyMDQ4LTY0PTE5ODQgYXZhaWxhYmxlIHBvcnRzLiBOb3RlIHRoYXQgd2hhdGV2ZXIgdGhlIFBT SUQtbGVuIGlzLCB0aGVyZSB3aWxsIGFsd2F5cyBiZSBoYWxmIG9mIGFsbCBwb3J0IHJhbmdlcyBp bnZvbHZlZCBpbiB0aGlzLg0KDQpOb3cgYXNzdW1lIHRoYXQgYT0wIGFuZCBQU0lELWxlbj01LiBJ biB0aGlzIGNhc2UsIGV4Y2x1ZGluZyBXS1BzIGp1c3QgbWVhbnMgZHJvcHBpbmcgdGhlIGZpcnN0 IHBvcnQgcmFuZ2UgKHdpdGggUFNJRD0wKS4gRWFjaCBvZiB0aGUgb3RoZXIgcG9ydCByYW5nZXMg KHdpdGggUFNJRD4wKSBjYW4gZXF1YWxseSBpbmNsdWRlIDIwNDggYXZhbGlhYmxlIHBvcnRzLg0K DQpJZiB3ZSBhcmUgdG8gaGF2ZSBidXQgb25lIG1ldGhvZCB0byBleGNsdWRlIFdLUHMsIHRoZSBv bmUgaW4gTHc0bzYgc2VlbXMgYmV0dGVyIHRvIG1lLiANCg0KUmVnYXJkcywNCg0KDQoNCll1Y2hp IENoZW4NCg0KRnJvbTogV29qY2llY2ggRGVjDQpEYXRlOiAyMDE0LTA2LTAzIDE4OjQ4DQpUbzog Q29uZyBMaXUNCkNDOiBkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2OyBPbGUgVHJvYW47IFlv bmcgQ3VpOyBTb2Z0d2lyZXMgV0cNClN1YmplY3Q6IFJlOiBbU29mdHdpcmVzXSBkcmFmdC1pZXRm LXNvZnR3aXJlLWx3NG92ZXI2IGV4Y2x1ZGluZyBXZWxsIEtub3duIFBvcnRzDQpIaSBDb25nLA0K DQoNCnJpZ2h0LCBidXQgd291bGRuJ3QgeW91IGFncmVlIHRoYXQgdGhpcyBleGFtcGxlIGlzIGVx dWl2YWxlbnQgdG8gYT01LCB3aXRoIHdoYXRldmVyIFBTSUQtbGVuIHlvdSBjaG9vc2U/DQoNCg0K DQpUaGUgYmlnZ2VyIHBvaW50IGhlcmUgaXMgdGhhdCBpZiB0aGlzICJleGNsdXNpb24iIGlzIG1l YW50IHRvIGJlIGNvbmZpZ3VyYWJsZSBvbiBhIGRoY3Agc2VydmVyLCBhcyBpbiB1c2luZyB0aGUg UzQ2IFBvcnQgcGFyYW1ldGVycyBvcHRpb24gdGhlbiBkb2luZyBzbyBieSAiZHJvcHBpbmciIGEg UFNJRCBzZWVtcyBsaWtlIGEgZHVmZiB3YXkgdG8gZG8gaXQsIGdpdmVuIHRoYXQgdGhlIGEtYml0 cyBhcmUgYWxyZWFkeSBkZWZpbmVkIHNwZWNpZmljYWxseSBmb3IgdGhhdCBwdXJwb3NlLiBVbmxl c3MsIHRoZXJlIGlzIHNvbWUgb3RoZXIgcmVhc29uIGhlcmUsIEknbSBvZiB0aGUgb3Bpb25pb24g dGhhdCBoYXZpbmcgYSBzaW5nbGUgd2F5IG9mIGV4Y2x1ZGluZyBwb3J0cyBpcyBiZXR0ZXIgdGhh biB0d28uDQoNCg0KQ2hlZXJzLg0KDQoNCg0KDQoNCg0KT24gMyBKdW5lIDIwMTQgMTI6MjMsIENv bmcgTGl1IDxnbm9jdWlsQGdtYWlsLmNvbT4gd3JvdGU6DQoNCkhpIFdvaiwNCg0KDQpBc3N1bWUg YT0wIGFuZCBQU0lELWxlbj01LCB0aGVuIHRoZSBwb3J0cyBhcmUgZGl2aWRlZCBpbnRvIFswLDIw NDddLCBbMjA0OCw0MDk1XSwgLi4uDQpKdXN0IGRyb3AgdGhlIGZpcnN0IHBpZWNlLCBhbmQgYWxs b2NhdGUgb3RoZXJzIHRvIGNsaWVudHMuIFRoYXQncyBob3cgYT0wIHdvcmtzLg0KDQoNCmE9NiBj YW4gYWxzbyB3b3JrLCBidXQgSSBkb24ndCB0aGluayBpdCdzIGEgU0hPVUxEIGZvciBhPTYgdG8g c29sdmUgdGhlIFdLUCBpc3N1ZS4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpDb25nDQoNCg0KDQoNCjIw MTQtMDYtMDMgMTg6MDEgR01UKzA4OjAwIFdvamNpZWNoIERlYyA8d2RlYy5pZXRmQGdtYWlsLmNv bT46DQoNCg0KVGhhbmtzLiBJJ20gbm90IHN1cmUgSSBnZXQgeW91ciBleGFtcGxlIHRob3VnaC4g VG8gZXhjbHVkZSBwb3J0cyAwLTEwMjMsIHRoZSBleGNsdWRlZCBwb3J0ICJzdWJuZXQiIHdvdWxk IGJlIDB4MDAwMC82LiBXaGljaCB3b3VsZCBiZSBlcXVpdmFsZW50IHRvIGE9Ni4uLg0KDQoNCg0K DQoNCg0KDQoNCk9uIDMgSnVuZSAyMDE0IDExOjMxLCBPbGUgVHJvYW4gPG90QGNpc2NvLmNvbT4g d3JvdGU6DQoNCldvamNpZWNoLA0KDQoNCj4gQ291bGQgeW91IHNob3cgYSB3b3JraW5nIGV4YW1w bGUgb2YgdGhhdCBpbiBhY3Rpb24sIGFsb25nIHdpdGggdGhlIHNldCBvZiBQU0lEcyBjb250YWlu aW5nIHRoZSB1c2FibGUgcG9ydCByYW5nZXM/DQoNCg0KaW4gTFc0NiwgcG9ydHMgYXJlIHByb3Zp c2lvbmVkIHBlciBjbGllbnQuIHNvLCBJIGRvbid0IHVuZGVyc3RhbmQgd2hhdCB5b3Ugd2FudCBh IHdvcmtpbmcgZXhhbXBsZSBvZi4gdGhhdCdzIGp1c3QgbGlrZSBhc3NpZ25pbmcgMTkyLjE2OC4w LjEwIC0gMTkyLjE2OC4wLjI1NSBpbiBhIERIQ1AgcG9vbC4gaW4gdGhlIFBTSUQgY2FzZSB5b3Ug d2lsbCBub3QgYXNzaWduIHBvcnRzIDAwMDAvMTANCg0KY2hlZXJzLA0KT2xlDQoNCg0KDQo+DQo+ IENoZWVycw0KPg0KPg0KPg0KPg0KPiBPbiAzIEp1bmUgMjAxNCAxMDo1MSwgT2xlIFRyb2FuIDxv dEBjaXNjby5jb20+IHdyb3RlOg0KPiBXb2osDQo+DQo+IGluIHRoZSBMVzQ2IGNhc2UsIHlvdSBj YW4gc3RpbGwgZG8gYT0wLCBhbmQgZW5zdXJlIHRoYXQgeW91IGRvbid0IHByb3Zpc2lvbiBhbnkg UFNJRCB3aGljaCByZXN1bHRzIGluIHRoZSB3ZWxsIGtub3duIHBvcnRzLg0KPg0KPiBjaGVlcnMs DQo+IE9sZQ0KPg0KPiA+DQo+ID4gT24gMiBKdW5lIDIwMTQgMjE6NDksIFRvbSBUYXlsb3IgPHRv bS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+IFRoZXJlJ3MgYSBkaWZmZXJlbmNl IGJldHdlZW4gc2V0dGluZyBhPTYgYW5kIHNldHRpbmcgYXNpZGUgdGhlIGxvd2VzdCBQU0lEcyBi ZWNhdXNlIHRoZXkgb2NjdXB5IHRoYXQgcG9ydCBzcGFjZS4gVGhlIHZhbHVlIG9mIGEgZGV0ZXJt aW5lcyBob3cgcG9ydHMgYXJlIGFzc2lnbmVkIHRvIGVhY2ggUFNJRCwgYnV0IGRvZXMgbm90IGFm ZmVjdCB0aGUgdXNhYmxlIFBTSUQgbnVtYmVyaW5nIHNwYWNlLg0KPiA+DQo+ID4gSSB0aGluayB0 aGF0IHlvdSBzaG91bGQgaWxsdXN0cmF0ZSBob3cgeW91IHRoaW5rIHRoaXMgd291bGQgd29yayBi ZWZvcmUgd2UgcmVhY2ggYSBjb25jbHVzaW9uLg0KPiA+IEEgc2V0dGluZyBvZiBhPTYgYXJyaXZl cyBwcmVjaXNlbHkgYXQgd2hhdCB0aGUgZ29hbCBpcyBoZXJlLCBleGNsdWRlIHBvcnRzIDAtMTAy NC4gU28gaWYgdGhlcmUgaXMgYSBuZWVkIHRvIGhhdmUgYW5vdGhlciB3YXkgb2YgYWNoaWV2aW5n IHRoYXQsIGJ5IGNyZWF0aW5nIHNvbWUgZXhjbHVkZWQgbWFnaWMgUFNJRCB2YWx1ZSB0aGF0IGNv cnJlc3BvbmRzIHRvIDAtMTAyNCwgd2Ugd291bGQgbGlrZSB0byBrbm93IHdoeSBpcyB0aGF0IHJl bGV2YW50IGFuZCBob3cgaXQgaXMgc3VwcG9zZWQgdG8gd29yayBpbiBhIHN5c3RlbSB3aGVyZSB0 aGUgUFNJRCBjb252ZXlzIHRvIHRoZSBDRSB0aGUgcG9ydC1yYW5nZS4NCj4gPg0KPiA+IFJlZ2Fy ZHMuDQo+ID4NCj4gPg0KPiA+IFJFQ09NTUVOREVEIGlzIHBhcnQgb2YgdGhlIFJGQyAyMTE5IGJv aWxlcnBsYXRlLiBUaGUgKHVuaW50ZW50aW9uYWxseSkgbWlzc2luZyB0ZXJtIGlzIE5PVCBSRUNP TU1FTkRFRC4NCj4gPg0KPiA+IFRvbQ0KPiA+DQo+ID4NCj4gPiBPbiAwMi8wNi8yMDE0IDM6Mjcg UE0sIFdvamNpZWNoIERlYyB3cm90ZToNCj4gPiBXZWxsLCBJJ20gcmVmZXJyaW5nIHRvIHRoZSAi UkVDT01NRU5ERUQiIHBhcnQuIElmIHRoZSByZWNvbW1lbmRhdGlvbiBpcyBOT1QNCj4gPiB0byBh bGxvY2F0ZSBwb3J0cyAwLTEwMjQsIHRoZW4gdGhpcyBlZmZlY3RpdmVseSByZWNvbW1lbmRzIHRo YXQgYS1iaXRzPTYuDQo+ID4gTW9yZW92ZXIgdGhlIG1lYW5pbmcgb2YgU0hPVUxEIHZzIFJFQ09N TUVORCBzaG91bGQgYmUgcXVlc3Rpb25lZC4gVGhlDQo+ID4gbGF0dGVyIGlzIG5vdCBhIHJlZ3Vs YXIgbm9ybWF0aXZlIHRlcm0sIGFuZCBhcmd1YWJseSBpZiB0aGUgcmVjb21tZW5kYXRpb24NCj4g PiBpcyBmb3IgZXhjbHVkaW5nIDAtMTAyNCB0aGVuIGE9NiBsb29rcyBsaWtlIHRoZSBTSE9VTEQu IElmIGFueW9uZSB3YW50cyB0aGUNCj4gPiBmdWxsIHBvcnQgc2V0LCB0aGVuIGE9MCB3b3VsZCBi ZSBhbiBvYnZpb3VzIGNvbnNlcXVlbmNlLg0KPiA+DQo+ID4NCj4gPiBPbiAyIEp1bmUgMjAxNCAx OTo1MCwgVG9tIFRheWxvciA8dG9tLnRheWxvci5zdGRzQGdtYWlsLmNvbT4gd3JvdGU6DQo+ID4N Cj4gPiBOb3Qgc3VyZSBob3cgeW91IHJlYWQgdGhhdCwgYnV0IGl0IGNhbiBiZSBmaXhlZCBieSBw dXR0aW5nIGEgY29tbWEgYWZ0ZXINCj4gPiAiU0hPVUxEIGJlIDAiIGFuZCByZXBsYWNpbmcgInRv IGFsbG9jYXRlIiB3aXRoICJ0aHVzIGFsbG9jYXRpbmciLg0KPiA+DQo+ID4gVG9tDQo+ID4NCj4g Pg0KPiA+IE9uIDAyLzA2LzIwMTQgMTI6MTQgUE0sIFdvamNpZWNoIERlYyB3cm90ZToNCj4gPg0K PiA+IFVobSwgdGhpcyBhcHBlYXJzIHRvIG1lYW4gdGhhdCB0aGUgUkVDT01NRU5ERUQgYS1iaXRz IFNIT1VMRCBiZSA2Lg0KPiA+DQo+ID4NCj4gPiBPbiAyNiBNYXkgMjAxNCAxMzoyNCwgSWFuIEZh cnJlciA8aWFuZmFycmVyQGdteC5jb20+IHdyb3RlOg0KPiA+DQo+ID4gICBIaSwNCj4gPg0KPiA+ IFRoaXMgb25lIHNsaXBwZWQgbXkgbWluZOKApi4NCj4gPg0KPiA+ICAgRnJvbSBhIGRpc2N1c3Np b24gd2l0aCBPbGUgZHVyaW5nIHRoZSBNQVAgZGhjcCBsYXN0IGNhbGwsIHRoZXJlIHdhcyBhDQo+ ID4gZGlzY3Vzc2lvbiBhYm91dCB0aGUgZXhjbHVzaW9uIG9mIHByb3Zpc2lvbmluZyBXS1BzIHRv IENQRXMgLQ0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zb2Z0d2ly ZXMvY3VycmVudC9tc2cwNjAxMC5odG1sDQo+ID4NCj4gPiBJbiBwcmV2aW91cyB2ZXJzaW9ucywg dGhlIGx3NG82IHVzZWQgdG8gcmVmZXJlbmNlDQo+ID4gc3VuLWRoYy1wb3J0LXNldC1vcHRpb24s DQo+ID4gd2hpY2ggYWxzbyBzdGF0ZWQgdGhhdCB0aGUgV0tQcyBzaG91bGQgbm90IGJlIGFzc2ln bmVkLiBUaGlzIGFkdmljZSBnb3QNCj4gPiBsb3N0IHdoZW4gY2hhbmdpbmcgdG8gcmVmZXJlbmNl IG1hcC1kaGNwIGZvciBQU0lEIGZvcm1hdC4NCj4gPg0KPiA+IEhlcmXigJlzIGEgd29yZGluZyBj aGFuZ2UgcHJvcG9zYWwgdG8gcmVzb2x2ZSB0aGlzOg0KPiA+DQo+ID4gU2VjdGlvbiA1LjENCj4g Pg0KPiA+IE9yaWdpbmFsIHRleHQgKGxhc3Qgc2VudGVuY2UsIHBhcmEgNyk6DQo+ID4NCj4gPiAi Rm9yIGx3NG82LCB0aGUgIG51bWJlciBvZiBhLWJpdHMgU0hPVUxEIGJlIDAuIg0KPiA+DQo+ID4g UHJvcG9zZWQgY2hhbmdlOg0KPiA+DQo+ID4gIkZvciBsdzRvNiwgdGhlIG51bWJlciBvZiBhLWJp dHMgU0hPVUxEIGJlIDAgdG8gYWxsb2NhdGUgYSBzaW5nbGUNCj4gPiBjb250aWd1b3VzIHBvcnQg c2V0IHRvIGVhY2ggbHdCNC4NCj4gPg0KPiA+IFVubGVzcyBhIGx3QjQgaXMgYmVpbmcgYWxsb2Nh dGVkIGEgZnVsbCBJUHY0IGFkZHJlc3MsIGl0IGlzIFJFQ09NTUVOREVEDQo+ID4gdGhhdCBQU0lE cyBjb250YWluaW5nIHRoZSB3ZWxsLWtub3duIHBvcnRzICgwLTEwMjMpIGFyZSBub3QgYWxsb2Nh dGVkIHRvDQo+ID4gbHdCNHMu4oCdDQo+ID4NCj4gPiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91 IGFyZSBPSyB3aXRoIHRoZSBwcm9wb3NlZCBjaGFuZ2UuDQo+ID4NCj4gPiBjaGVlcnMsDQo+ID4g SWFuDQo+ID4NCj4gPg0KPiA+ICAgR29vZCBzcG90IG9uIHRoZSBXS1AgZXhjbHVzaW9uLiBCZWZv cmUgdGhlIGx3NG82IGRyYWZ0IHdhcyB1cGRhdGVkIHRvDQo+ID4NCj4gPiByZWZlcmVuY2UgbWFw LWRoY3AgZm9yIGNvbmZpZ3VyYXRpb24sICB0aGUgcG9ydCBjb25maWd1cmF0aW9uIHdhcw0KPiA+ IGRlc2NyaWJlZA0KPiA+IGluIHN1bi1kaGMtcG9ydC1zZXQtb3B0aW9uLCB3aGljaCBhbHNvIHN0 YXRlZCB0aGF0IHRoZSBXS1BzIHNob3VsZCBub3QgYmUNCj4gPiBhc3NpZ25lZC4gVGhpcyBhZHZp Y2UgZ290IGxvc3Qgd2hlbiBjaGFuZ2luZyB0byByZWZlcmVuY2UgbWFwLWRoY3AuIEnigJlsbA0K PiA+IG1ha2UgYSBzdWdnZXN0ZWQgdGV4dCB1cGRhdGUgZm9yIHRoZSBsdzRvNiBkcmFmdCB0byBm aXggdGhpcy4gRG9lcyB0aGF0DQo+ID4gd29yayBmb3IgeW91Pw0KPiA+DQo+ID4NCj4gPiB5ZXMs IHRoYXQgd291bGQgYmUgZ29vZC4NCj4gPg0KPiA+IGNoZWVycywNCj4gPiBPbGUNCj4gPg0KPiA+ DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBTb2Z0d2lyZXMgbWFpbGluZyBsaXN0DQo+ID4gU29mdHdpcmVzQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zb2Z0d2lyZXMNCj4gPg0KPiA+DQo+ ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+IFNvZnR3aXJlc0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4NCj4NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KU29mdHdpcmVz QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NvZnR3aXJl cw== ------=_001_NextPart672112364754_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi Woj,
 
I don't agree that setting a=3D5 is equivalent to setting a=3D0 and P= SID-len=3D5.=20
 
Assume that a=3D5 and PSID-len=3D5. In this case, each of the port&nb= sp;ranges=20 with PSID=3D0x00~0x0F will cover 64 ports within WKP range. In order = to=20 exclude these ports, the value A must be larger than 0. As a result, each = of=20 these port ranges will just include 2048-64=3D1984 available por= ts. Note=20 that whatever the PSID-len is, there will always be half of all port range= s=20 involved in this.
 
Now assume that a=3D0 and PSID-len=3D5. In this case, excluding WKPs = just=20 means dropping the first port range (with PSID=3D0). Each o= f the=20 other port ranges (with PSID>0) can equally include 2048 avaliable= =20 ports.
 
If we are to have but one method to exclude WKPs, the one in Lw4= o6=20 seems better to me. 
 
Regards,
Yuchi=20 Chen
 
Date: 2014-06-03 18:48
To: Cong Liu
CC: draft-ietf-sof= twire-lw4over6;=20 Ole Troan; Yong Cui; Softwires WG
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 exc= luding=20 Well Known Ports
Hi Cong,

right, but wouldn't you agree that this example= is=20 equivalent to a=3D5, with whatever PSID-len you choose?

The=20 bigger point here is that if this "exclusion" is meant to be configurable = on a=20 dhcp server, as in using the S46 Port parameters option then doing so by=20 "dropping" a PSID seems like a duff way to do it, given that the a-bits ar= e=20 already defined specifically for that purpose. Unless, there is some other= =20 reason here, I'm of the opionion that having a single way of excluding por= ts is=20 better than two.

Cheers.



On 3 June 2014 12:23, Cong Liu &l= t;gnocuil@gmail.com>= ;=20 wrote:
Hi Woj,

Assume a=3D0 and PSID-len=3D5, then the ports= are=20 divided into [0,2047], [2048,4095], ...
Just drop the first piece, and allocate other= s to=20 clients. That's how a=3D0 works.

a=3D6 can also work, but I don't think it's a= SHOULD=20 for a=3D6 to solve the WKP issue.

Best Regards,
Cong


2014-06-03 18:01 GMT+08:00 Wojciech Dec <wdec.ietf@gmail.com>:

Thanks. I'm not sure I get your example though. To excl= ude=20 ports 0-1023, the excluded port "subnet" would be 0x0000/6. Which woul= d be=20 equivalent to a=3D6...


On 3 June 2014 11:31, Ole Troan <ot@cisco.com>=20 wrote:
Wojciech,

> Could you show a working example of that in action, al= ong=20 with the set of PSIDs containing the usable port ranges?

in=20 LW46, ports are provisioned per client. so, I don't understand what = you=20 want a working example of. that's just like assigning 192.168.0.10 -= =20 192.168.0.255 in a DHCP pool. in the PSID case you will not assign p= orts=20 0000/10

cheers,
Ole


>
> Cheers
>
>
>
>
= >=20 On 3 June 2014 10:51, Ole Troan <ot@cisco.com> wrote:
> Woj,
>
= > in=20 the LW46 case, you can still do a=3D0, and ensure that you don't pro= vision=20 any PSID which results in the well known ports.
>
>=20 cheers,
> Ole
>
> >
> > On 2 June 2014= =20 21:49, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
> >= ;=20 There's a difference between setting a=3D6 and setting aside the low= est=20 PSIDs because they occupy that port space. The value of a determines= how=20 ports are assigned to each PSID, but does not affect the usable PSID= =20 numbering space.
> >
> > I think that you should=20 illustrate how you think this would work before we reach a=20 conclusion.
> > A setting of a=3D6 arrives precisely at wha= t the=20 goal is here, exclude ports 0-1024. So if there is a need to have an= other=20 way of achieving that, by creating some excluded magic PSID value th= at=20 corresponds to 0-1024, we would like to know why is that relevant an= d how=20 it is supposed to work in a system where the PSID conveys to the CE = the=20 port-range.
> >
> > Regards.
> >
>=20 >
> > RECOMMENDED is part of the RFC 2119 boilerplate. T= he=20 (unintentionally) missing term is NOT RECOMMENDED.
> >
&= gt;=20 > Tom
> >
> >
> > On 02/06/2014 3:27 P= M,=20 Wojciech Dec wrote:
> > Well, I'm referring to the "RECOMME= NDED"=20 part. If the recommendation is NOT
> > to allocate ports 0-= 1024,=20 then this effectively recommends that a-bits=3D6.
> > Moreo= ver the=20 meaning of SHOULD vs RECOMMEND should be questioned. The
> >= ;=20 latter is not a regular normative term, and arguably if the=20 recommendation
> > is for excluding 0-1024 then a=3D6 looks= like=20 the SHOULD. If anyone wants the
> > full port set, then a= =3D0 would=20 be an obvious consequence.
> >
> >
> > On= 2=20 June 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
>=20 >
> > Not sure how you read that, but it can be fixed by= =20 putting a comma after
> > "SHOULD be 0" and replacing "to=20 allocate" with "thus allocating".
> >
> > Tom
&= gt;=20 >
> >
> > On 02/06/2014 12:14 PM, Wojciech Dec=20 wrote:
> >
> > Uhm, this appears to mean that the=20 RECOMMENDED a-bits SHOULD be 6.
> >
> >
> &g= t; On=20 26 May 2014 13:24, Ian Farrer <ianfarrer@gmx.com> wrote:
> >
>= ; >=20   Hi,
> >
> > This one slipped my mind=E2=80= =A6.
>=20 >
> >   From a discussion with Ole during the MAP d= hcp=20 last call, there was a
> > discussion about the exclusion o= f=20 provisioning WKPs to CPEs -
> > http://www.ietf.org/mail-archive/web/softwires/curre= nt/msg06010.html
>=20 >
> > In previous versions, the lw4o6 used to=20 reference
> > sun-dhc-port-set-option,
> > which a= lso=20 stated that the WKPs should not be assigned. This advice got
>= >=20 lost when changing to reference map-dhcp for PSID format.
>=20 >
> > Here=E2=80=99s a wording change proposal to resolv= e=20 this:
> >
> > Section 5.1
> >
> >= ;=20 Original text (last sentence, para 7):
> >
> > "Fo= r=20 lw4o6, the  number of a-bits SHOULD be 0."
> >
>= >=20 Proposed change:
> >
> > "For lw4o6, the number of= =20 a-bits SHOULD be 0 to allocate a single
> > contiguous port= set=20 to each lwB4.
> >
> > Unless a lwB4 is being alloc= ated a=20 full IPv4 address, it is RECOMMENDED
> > that PSIDs contain= ing=20 the well-known ports (0-1023) are not allocated to
> >=20 lwB4s.=E2=80=9D
> >
> > Please let me know if you = are OK with=20 the proposed change.
> >
> > cheers,
> >=20 Ian
> >
> >
> >   Good spot on the W= KP=20 exclusion. Before the lw4o6 draft was updated to
> >
>= ; >=20 reference map-dhcp for configuration,  the port configuration=20 was
> > described
> > in sun-dhc-port-set-option, = which=20 also stated that the WKPs should not be
> > assigned. This = advice=20 got lost when changing to reference map-dhcp. I=E2=80=99ll
> &= gt; make a=20 suggested text update for the lw4o6 draft to fix this. Does that
= >=20 > work for you?
> >
> >
> > yes, that = would=20 be good.
> >
> > cheers,
> > Ole
>=20 >
> >
> >=20 _______________________________________________
> > Softwir= es=20 mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires<= BR>>=20 >
> >
> >
> >
> >=20 _______________________________________________
> > Softwir= es=20 mailing list
> > Softwires@ietf.org
> > https://www.ietf.org/mailman/listinfo/softwires<= BR>>=20 >
> >
> >
>=20 >
>
>



_______________________________________________
Softwi= res=20 mailing list
Softwires@ietf.org
https://www.ietf.org/mailman/listinfo/softwires


------=_001_NextPart672112364754_=------ From nobody Tue Jun 3 06:44:43 2014 Return-Path: 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 1A8681A029A for ; Tue, 3 Jun 2014 06:44:40 -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 ANG0yTAgn1aw for ; Tue, 3 Jun 2014 06:44:36 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE1B91A0297 for ; Tue, 3 Jun 2014 06:44:35 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id a1so6816256wgh.27 for ; Tue, 03 Jun 2014 06:44:29 -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=cPkPuC/qEw52yiXDkKz07II/rKQsLUsUsPxccAFy7fA=; b=qgbhZKKVp3XrheFz3ZqmeqoNBt51UNCYeDzzvCswQMcMmokdlKuscN9XVVfT7yLffQ nsHI3q3frdQLWldIOV2ri64OJxjYnISn5R/QB6AKMLZuSTruzff40SI/mrwpQCN0A8HH 044/KQ8ZWN/UJIWObV/yiUEi95Bz4+uyahdK4IUYpSVE/mB9IbEBnrtVSphK1A6Zn+vJ Np0lgRHHa8QjyYBgZAO9Dd6nl/qs69AzB33PZe6rbz8J47NwLZrf8TpKmayykEAzxZTC K6lzzFQwpQV8OwpLYMZrgGQ7bnqjrqMFVaLVg2Sm68OBjeLRS2MLMtow/YVEn9fFpawE fN1g== MIME-Version: 1.0 X-Received: by 10.180.37.198 with SMTP id a6mr32511091wik.58.1401803068957; Tue, 03 Jun 2014 06:44:28 -0700 (PDT) Received: by 10.194.165.71 with HTTP; Tue, 3 Jun 2014 06:44:28 -0700 (PDT) In-Reply-To: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> Date: Tue, 3 Jun 2014 15:44:28 +0200 Message-ID: From: Wojciech Dec To: "ian.farrer@telekom.de" Content-Type: multipart/alternative; boundary=e89a8f503080f86c6804faeeb555 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/JiAu3vc1RCbdfJFBuz3WnibMQIU Cc: Ole Troan , Softwires-wg , Yong Cui , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 13:44:40 -0000 --e89a8f503080f86c6804faeeb555 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=3D0, 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, wrote: > Hi Woj, > > Here=E2=80=99s an example from an lwAFTR binding table. In this case, the= re=E2=80=99s 4096 > ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn=E2=80=99t 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 > Date: Tuesday, 3 June 2014 12:39 > To: Ole Troan > Cc: Tom Taylor , Ian Farrer , > "draft-ietf-softwire-lw4over6@tools.ietf.org" < > draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui < > cuiyong@tsinghua.edu.cn>, Softwires WG > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well > Known Ports > Resent-To: Ian Farrer , Mohamed Boucadair < > mohamed.boucadair@orange.com>, , = , > , > > How so, could you give an example? > > > On 3 June 2014 12:17, Ole Troan 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=3D6... >> >> sorry, yes, you'd not assign 0000/6. >> that's not equivalent to a=3D6 though. >> >> cheers, >> Ole >> >> >> > >> > >> > >> > >> > >> > >> > On 3 June 2014 11:31, Ole Troan 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 wrote: >> > > Woj, >> > > >> > > in the LW46 case, you can still do a=3D0, 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 wrote= : >> > > > There's a difference between setting a=3D6 and setting aside the >> lowest PSIDs because they occupy that port space. The value of a determi= nes >> 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=3D6 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 correspo= nds >> 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=3D6. >> > > > 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=3D6 looks like the SHOULD. If anyon= e >> wants the >> > > > full port set, then a=3D0 would be an obvious consequence. >> > > > >> > > > >> > > > On 2 June 2014 19:50, Tom Taylor 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 wrote: >> > > > >> > > > Hi, >> > > > >> > > > This one slipped my mind=E2=80=A6. >> > > > >> > > > 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 advic= e >> got >> > > > lost when changing to reference map-dhcp for PSID format. >> > > > >> > > > Here=E2=80=99s 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.=E2=80=9D >> > > > >> > > > 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=E2=80=99ll >> > > > 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 >> > > > >> > > > >> > > > >> > > > >> > > >> > > >> > >> > >> >> > --e89a8f503080f86c6804faeeb555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 spac= e. 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 i= s the k-bits. Thus for the example above k-bits should be 4. This, along wi= th a=3D0, actually works out to be then numerically as per the PSIDs you pr= ovide.
If the meaning the lw46 implementation puts a different meaning = on the k-bits, then there is a problem...

Cheers





On 3 June 201= 4 13:09, <ian.farrer@telekom.de> wrote:
Hi Woj,

Her= e=E2=80=99s an example from an lwAFTR binding table. In this case, there=E2= =80=99s 4096 ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn= =E2=80=99t in the table.

2001:10f:60:6ff::0:b4 1.2.30.126 PSID 4096
20= 01: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 4505= 6
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:1= 0f: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 4096= 0
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 Farre= r <ianfarrer@gmx.= com>, "draft-ietf-softwire-lw4over6@tools.ietf.org&qu= ot; <draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui= <cuiyong@t= singhua.edu.cn>, Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] draft-iet= f-softwire-lw4over6 excluding Well Known Ports
Resent-To: Ian Farrer <ian.farrer@telekom.de>, Mohamed Boucadair = <moham= ed.boucadair@orange.com>, <sunqiong@ctbri.com.cn>, <tena@huawei.com>, <yiu_lee@cable.comcast.co= m>, <yong@csnet1.cs.tsinghua.edu.cn>

How so, could you give an e= xample?


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=3D6...

sorry, yes, you'd not assign 000= 0/6.
that's not equivalent to a=3D6 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 th= e 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 p= orts 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=3D0, 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> w= rote:
> > > There's a difference between setting a=3D6 and setting a= side the lowest PSIDs because they occupy that port space. The value of a d= etermines how ports are assigned to each PSID, but does not affect the usab= le PSID numbering space.
> > >
> > > I think that you should illustrate how you think this would = work before we reach a conclusion.
> > > A setting of a=3D6 arrives precisely at what the goal is her= e, exclude ports 0-1024. So if there is a need to have another way of achie= ving 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 (uninte= ntionally) 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 t= hat a-bits=3D6.
> > > Moreover the meaning of SHOULD vs RECOMMEND should be questi= oned. The
> > > latter is not a regular normative term, and arguably if the = recommendation
> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If= anyone wants the
> > > full port set, then a=3D0 would be an obvious consequence. > > >
> > >
> > > On 2 June 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> w= rote:
> > >
> > > 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:
> > >
> > > =C2=A0 Hi,
> > >
> > > This one slipped my mind=E2=80=A6.
> > >
> > > =C2=A0 From a discussion with Ole during the MAP dhcp last c= all, 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=E2=80=99s a wording change proposal to resolve this: > > >
> > > Section 5.1
> > >
> > > Original text (last sentence, para 7):
> > >
> > > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0.&quo= t;
> > >
> > > Proposed change:
> > >
> > > "For lw4o6, the number of a-bits SHOULD be 0 to allocat= e 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.=E2=80=9D
> > >
> > > Please let me know if you are OK with the proposed change. > > >
> > > cheers,
> > > Ian
> > >
> > >
> > > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draf= t was updated to
> > >
> > > reference map-dhcp for configuration, =C2=A0the port configu= ration 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 ma= p-dhcp. I=E2=80=99ll
> > > 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
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Softwires mailing list
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> >
> >
>
>

--e89a8f503080f86c6804faeeb555-- From nobody Tue Jun 3 07:16:27 2014 Return-Path: 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 ; 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 ; 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 ; 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: To: Date: Tue, 3 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: References: <53422B8F.2020109@ericsson.com> <37A243DD-5249-4070-AB19-6DFFCFE17AA7@gmx.com> <92E51E75-2914-421F-B222-7478EC3D6A02@cisco.com> <538CB982.2060502@gmail.com> <538CD547.8070108@gmail.com> <605EFD7C-AA23-4619-8CBC-EB35342B55F6@cisco.com> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jun 2014 14:16:21 -0000 --_000_CFB3A250C4879ianfarrertelekomde_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Woj, I don=92t think that there is a problem. For the purpose of the example tha= t 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 i= mplementation 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 PS= ID (it needs to be updated now this has stabilised): Here=92s an actual con= fig 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 > Date: Tuesday, 3 June 2014 15:44 To: Ian Farrer > Cc: Ole Troan >, Tom Taylor >, Ian Farrer >, "draft-ietf-softwire-lw4over6@tools.ietf.o= rg" >, Yong Cui >, So= ftwires-wg > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known = Ports Hi Ian, thanks for the example. This helps to illustrate, although the numbers prov= ided don't seem to add up (at least in terms of the algorithm and meaning o= f PSID). For 4096 ports per CE, one needs 12 "freely" bits of address space. The PSI= D, as per the draft, is the fixed code point that uniquely per CE indexes t= hat address space (ie a subnet address). The length of the PSID is the k-bi= ts. Thus for the example above k-bits should be 4. This, along with a=3D0, = 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-bi= ts, then there is a problem... Cheers On 3 June 2014 13:09, >= wrote: Hi Woj, Here=92s an example from an lwAFTR binding table. In this case, there=92s 4= 096 ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn=92t 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 > Date: Tuesday, 3 June 2014 12:39 To: Ole Troan > Cc: Tom Taylor = >, Ian Farrer >, "draft-ietf-so= ftwire-lw4over6@tools.ietf.org" >, Yong Cui >, Softwires WG > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known = Ports Resent-To: Ian Farrer >= , Mohamed Boucadair >, >, >, >, > How so, could you give an example? On 3 June 2014 12:17, Ole Troan > 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=3D6... sorry, yes, you'd not assign 0000/6. that's not equivalent to a=3D6 though. cheers, Ole > > > > > > > On 3 June 2014 11:31, Ole Troan > 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 yo= u 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/1= 0 > > cheers, > Ole > > > > > > Cheers > > > > > > > > > > On 3 June 2014 10:51, Ole Troan > wro= te: > > Woj, > > > > in the LW46 case, you can still do a=3D0, and ensure that you don't pro= vision any PSID which results in the well known ports. > > > > cheers, > > Ole > > > > > > > > On 2 June 2014 21:49, Tom Taylor > wrote: > > > There's a difference between setting a=3D6 and setting aside the lowe= st 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 numbe= ring space. > > > > > > I think that you should illustrate how you think this would work befo= re we reach a conclusion. > > > A setting of a=3D6 arrives precisely at what the goal is here, exclud= e 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-bit= s=3D6. > > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. The > > > latter is not a regular normative term, and arguably if the recommend= ation > > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone w= ants the > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > On 2 June 2014 19:50, Tom Taylor > wrote: > > > > > > Not sure how you read that, but it can be fixed by putting a comma af= ter > > > "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 > wrote: > > > > > > Hi, > > > > > > This one slipped my mind=85. > > > > > > 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 g= ot > > > lost when changing to reference map-dhcp for PSID format. > > > > > > Here=92s 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 RECOMMEND= ED > > > that PSIDs containing the well-known ports (0-1023) are not allocated= to > > > lwB4s.=94 > > > > > > 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 no= t be > > > assigned. This advice got lost when changing to reference map-dhcp. I= =92ll > > > make a suggested text update for the lw4o6 draft to fix this. Does th= at > > > 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 > > > > > > > > > > > > > > > > > > --_000_CFB3A250C4879ianfarrertelekomde_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Woj,

I don=92t think that there is a problem. For the purpose of the examp= le 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 ac= tual implementation that we have is still based on the port-min, port-max f= ormat 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=92s an actu= al config line:

2001:10f:60:1ff::0:b4 1.2.30.121 p= ort 4096 to 8191

So, the problem results from my d= odgy 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@tele= kom.de>
Cc: Ole Troan &l= t;ot@cisco.com>, Tom Taylor <tom.taylor.stds@gmail.com>,= Ian Farrer <ianfarrer@gmx.com&= gt;, "d= raft-ietf-softwire-lw4over6@tools.ietf.org" <draft-ietf-softwire-lw4over6@t= ools.ietf.org>, Yong Cui <cuiyong@tsinghua.edu.cn>, Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excludin= g Well Known Ports

=
Hi Ian,

thanks for the example. This helps to illustrate, altho= ugh the numbers provided don't seem to add up (at least in terms of the alg= orithm and meaning of PSID).
For 4096 ports per CE, one needs 12 "freely" bits of address spac= e. 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 i= s the k-bits. Thus for the example above k-bits should be 4. This, along wi= th a=3D0, actually works out to be then numerically as per the PSIDs you pr= ovide.
If the meaning the lw46 implementation puts a differe= nt 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=92s an example from an lwAFTR binding ta= ble. In this case, there=92s 4096 ports per client (k-bits =3D12, a-bits=3D= 0). PSID 0 just isn=92t 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 P= SID 8192
2001:10f:60:6ff::2:b4 1.2.30.126 PSID 12288
20= 01: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<= /div>
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 4505= 6
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.1= 26 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 122= 88
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
<= div> 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 4096= 0
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.1= 27 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 <ianfarre= r@gmx.com>, "draft-ietf-softwire-lw4over6@tools.ietf.org<= /a>" <draft-ietf-softwire-lw4over6@tools.ietf.org>, Yo= ng Cui <cui= yong@tsinghua.edu.cn>, Softwires WG <softwires@ietf.org>
Subject: Re: [Softwires] draft-ietf-softwire-lw4ove= r6 excluding Well Known Ports
Resent-To= : Ian Farrer <ian.farrer@telekom.de>, Mohamed Boucadair <mohamed.boucadair@oran= ge.com>, <sunqiong@ctbri.com.cn>, <tena@huawei.com>, <yiu_lee@cable.comcast.com>, <yong@csne= t1.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-102= 3, the excluded port "subnet" would be 0x0000/6. Which would be e= quivalent to a=3D6...

sorry, yes, you'd not assign 0000/6.
that's not equivalent to a=3D6 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 th= e 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 - 1= 92.168.0.255 in a DHCP pool. in the PSID case you will not assign ports 000= 0/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=3D0, 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> w= rote:
> > > There's a difference between setting a=3D6 and setting aside= the lowest PSIDs because they occupy that port space. The value of a deter= mines how ports are assigned to each PSID, but does not affect the usable P= SID numbering space.
> > >
> > > I think that you should illustrate how you think this would = work before we reach a conclusion.
> > > A setting of a=3D6 arrives precisely at what the goal is her= e, exclude ports 0-1024. So if there is a need to have another way of achie= ving 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 (uninte= ntionally) 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 t= hat a-bits=3D6.
> > > Moreover the meaning of SHOULD vs RECOMMEND should be questi= oned. The
> > > latter is not a regular normative term, and arguably if the = recommendation
> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If= anyone wants the
> > > full port set, then a=3D0 would be an obvious consequence. > > >
> > >
> > > On 2 June 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> w= rote:
> > >
> > > 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=85.
> > >
> > >   From a discussion with Ole during the MAP dhcp last c= all, 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=92s 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.&quo= t;
> > >
> > > Proposed change:
> > >
> > > "For lw4o6, the number of a-bits SHOULD be 0 to allocat= e 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.=94
> > >
> > > Please let me know if you are OK with the proposed change. > > >
> > > cheers,
> > > Ian
> > >
> > >
> > >   Good spot on the WKP exclusion. Before the lw4o6 draf= t was updated to
> > >
> > > reference map-dhcp for configuration,  the port configu= ration 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 ma= p-dhcp. I=92ll
> > > 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
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Softwires mailing list
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> >
> >
>
>



--_000_CFB3A250C4879ianfarrertelekomde_-- From nobody Wed Jun 4 03:03:27 2014 Return-Path: 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 BAA641A0223; Wed, 4 Jun 2014 03:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pa9rChU0ZJJy; Wed, 4 Jun 2014 03:03:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1831A0216; Wed, 4 Jun 2014 03:03:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140604100322.10293.41506.idtracker@ietfa.amsl.com> Date: Wed, 04 Jun 2014 03:03:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/S1fSVkIZPXXGs2_IpREqY107uzs Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-09.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 10:03:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architecture Authors : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-09.txt Pages : 21 Date : 2014-06-04 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jun 4 21:37:17 2014 Return-Path: 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 37B951A0418 for ; Wed, 4 Jun 2014 21:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dD-1h5dKLebk for ; Wed, 4 Jun 2014 21:37:12 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93AFC1A0414 for ; Wed, 4 Jun 2014 21:37:12 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-74-538fa10842e5 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 0D.2D.11744.801AF835; Thu, 5 Jun 2014 00:43:20 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 00:37:05 -0400 From: Suresh Krishnan To: "ot@cisco.com" , "wdec.ietf@gmail.com" , Yuchi Chen , Cong Liu , Tom Taylor Thread-Topic: New version published (Was RE: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known Ports) Thread-Index: Ac+Ady0HvQHkSwuZRBKJj3dZZgR1Qg== Date: Thu, 5 Jun 2014 04:37:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_E87B771635882B4BA20096B589152EF628724BA1eusaamb107erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLrHT5djYX+wwZvv2hYr276zWXSdOstq 8XBaA4vF1fln2C1W7FrPanF42VYmiwvrf7FYtCy8xezA4THl90ZWj52z7rJ7LFnyk8mj7aWC x5fLn9kCWKO4bFJSczLLUov07RK4MlrOLGEpeK5dcfHUP7YGxvPqXYycHBICJhK3z05hhrDF JC7cW8/WxcjFISRwlFFi0/U7TBDOMkaJP2va2EGq2IA6Nuz8DJYQEdjJKNG/8RwriMMssJ9R YueyZ0AZDg5hgTyJ778yQRpEBIolVt88ygxh60ncXzeNDcRmEVCReHd8JjtIOa+Ar8TGvcIg YUagK76fWsMEYjMLiEvcejKfCeI6AYkle85DXSoq8fLxP1YIW0ni4+/5YGOYBfIl7s+QBwnz CghKnJz5hGUCo/AsJJNmIVTNQlIFUaIjsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1O LctNNzLcxAiMvWMSbI47GBd8sjzEKMDBqMTDm6DWHyzEmlhWXJl7iFGag0VJnHfPtapgIYH0 xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzFC3mnmn6NWZysGKsZ6unzNWJhdGLoLpkPfi3b+Rc4 myx3SbwevbvK4mvwijVJ8sJ53te+nHG83+0naPHPa5FVY4uzzSrutwc3/QhRtuGY+tE9p3RH 3ffNeT1TRSK3XtnbZmd8UHlOWM00riuGTCn66q1c7pPuzA/fzq1jfbPj1ZWal+uzPyixFGck GmoxFxUnAgDDpxNongIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/w_H72rExZNg0o0-viBel4JpykME Cc: "softwires@ietf.org" , "draft-ietf-softwire-lw4over6@tools.ietf.org" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 04:37:14 -0000 --_000_E87B771635882B4BA20096B589152EF628724BA1eusaamb107erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all (specifically people in the To: list), Since you were involved in the discussion on this topic, can you please l= ook over the latest version of the lw4over6 draft and see if the change add= resses 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=3Ddraft-ietf-softwire-lw4over6-09.txt Thanks Suresh --_000_E87B771635882B4BA20096B589152EF628724BA1eusaamb107erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all (specifically peop= le in the To: list),

  Since you were inv= olved 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

 <= /p>

http://tools.ietf.org/html/dr= aft-ietf-softwire-lw4over6-09

 <= /p>

and the diff can be found= here

 <= /p>

http://tools.ie= tf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-09.txt

 <= /p>

Thanks<= /p>

Suresh

 

--_000_E87B771635882B4BA20096B589152EF628724BA1eusaamb107erics_-- From nobody Thu Jun 5 00:50:14 2014 Return-Path: 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 98BDA1A00AD for ; Thu, 5 Jun 2014 00:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5] 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 zOZkQGh7_zBK for ; Thu, 5 Jun 2014 00:50:09 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199B21A009E for ; Thu, 5 Jun 2014 00:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11883; q=dns/txt; s=iport; t=1401954603; x=1403164203; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=bD+qCGMA91FvrwV5ob1wby+4MxBPPhPej0LmKHFkweo=; b=IjiYYKPtyY1fRZgr+Q9PPR0lsJ6B8tPdiBpKH34dstadGasy6hIYEADR 5WbCf9gYyj3ErtilnVfDUOMepmMY69+jbkhJrZBS6hbsMXl295lzRIzj2 8QVf3Itof0Ft66AKuWwuGQ4DAoDzQ/Xe7DwClWYTpQoJ86MFFaCDlQdf9 Q=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEAPkgkFOtJssW/2dsb2JhbABZg1m8GYZoUQGBInSCJQEBAQMBAQEBawsFCwsRAwEBAQEjBAchBh8JCAYTCYglAwkIDc0VDYYNF4w8gUUBAT4RB4MrgRUEkV+GOoF6gT+MA4V3gXiBQjsvgQo X-IronPort-AV: E=Sophos;i="4.98,979,1392163200"; d="asc'?scan'208";a="70503879" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 05 Jun 2014 07:49:53 +0000 Received: from dhcp-lys01-vla250-10-147-112-109.cisco.com (dhcp-lys01-vla250-10-147-112-109.cisco.com [10.147.112.109]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s557nppp012597 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2014 07:49:52 GMT Content-Type: multipart/signed; boundary="Apple-Mail=_85B78D1E-4606-487F-BB67-DAFFEA93930C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ole Troan In-Reply-To: Date: Thu, 5 Jun 2014 09:49:50 +0200 Message-Id: <2A8C06AE-8A6C-4951-9A99-810D36DA318A@cisco.com> References: To: Suresh Krishnan X-Mailer: Apple Mail (2.1878.2) Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/gbqE2KewNwvAma_VGMnsCXdThl8 Cc: "draft-ietf-softwire-lw4over6@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 07:50:12 -0000 --Apple-Mail=_85B78D1E-4606-487F-BB67-DAFFEA93930C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 > =20 > http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-09 > =20 > and the diff can be found here > =20 > http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-09.txt= > =20 > Thanks > Suresh > =20 > =20 > 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 > =20 > Hi Woj, > =20 > I don=92t 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=92s an actual config line: > =20 > 2001:10f:60:1ff::0:b4 1.2.30.121 port 4096 to 8191 > =20 > So, the problem results from my dodgy example rather than anything = else. > =20 > Cheers, > Ian > =20 > =20 > From: Wojciech Dec > Date: Tuesday, 3 June 2014 15:44 > To: Ian Farrer > Cc: Ole Troan , Tom Taylor , = Ian Farrer , = "draft-ietf-softwire-lw4over6@tools.ietf.org" = , Yong Cui = , Softwires-wg > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well = Known Ports > =20 > Hi Ian, >=20 > 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=3D0, 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... > =20 > Cheers > =20 >=20 > =20 > =20 >=20 > On 3 June 2014 13:09, wrote: > Hi Woj, > =20 > Here=92s an example from an lwAFTR binding table. In this case, = there=92s 4096 ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just = isn=92t in the table. > =20 > 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 > =20 > Cheers, > Ian > =20 > =20 > From: Wojciech Dec > Date: Tuesday, 3 June 2014 12:39 > To: Ole Troan > Cc: Tom Taylor , Ian Farrer = , "draft-ietf-softwire-lw4over6@tools.ietf.org" = , Yong Cui = , Softwires WG > Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well = Known Ports > Resent-To: Ian Farrer , Mohamed Boucadair = , , = , , = > =20 > How so, could you give an example? > =20 >=20 > On 3 June 2014 12:17, Ole Troan wrote: > Wojciech, >=20 > > 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=3D6... >=20 > sorry, yes, you'd not assign 0000/6. > that's not equivalent to a=3D6 though. >=20 > cheers, > Ole >=20 >=20 > > > > > > > > > > > > > > On 3 June 2014 11:31, Ole Troan 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 wrote: > > > Woj, > > > > > > in the LW46 case, you can still do a=3D0, 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 = wrote: > > > > There's a difference between setting a=3D6 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=3D6 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=3D6. > > > > 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=3D6 looks like the SHOULD. If = anyone wants the > > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > > > > On 2 June 2014 19:50, Tom Taylor = 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 wrote: > > > > > > > > Hi, > > > > > > > > This one slipped my mind=85. > > > > > > > > =46rom 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=92s 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.=94 > > > > > > > > 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=92ll > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 --Apple-Mail=_85B78D1E-4606-487F-BB67-DAFFEA93930C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTkCEeAAoJEP0up8EdT99JnPQIAIXLzCym5H5l0LauGTca7Pt7 4tKhywR4nzB/l24W7u5F+/fWbg0YcpymS4oX8q8sqAkInAf/JPJX55fTWR8A8dZV aMS3X50MWRgFC/D3KHuAS3M+O75hsmLiUcqSDpv6iC22/n0CsA4M9SmANnfBtL7F DP4qOzBNa98980Rq6wQaXEb27hSyE+YqcePFJTTZASQhyiRBRjc7P7qCxpeLdCZY z/eUrN1BAtcBS5xc5GYb4Wk9oqgAq3W400dA+2396MRmipgQPoQu3PxbHMDCw+WB elFfeVb744QknyzSfaWBn1QB2tNF8v3OPgx+134sRtavZPYy/7BBGhZNVThc3nY= =JJ1c -----END PGP SIGNATURE----- --Apple-Mail=_85B78D1E-4606-487F-BB67-DAFFEA93930C-- From nobody Thu Jun 5 06:04:34 2014 Return-Path: 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 317741A008F for ; Thu, 5 Jun 2014 06:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Te-tituXSSfD for ; Thu, 5 Jun 2014 06:04:29 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AEFB1A0099 for ; Thu, 5 Jun 2014 06:04:25 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id lx4so830917iec.4 for ; Thu, 05 Jun 2014 06:04:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Qn70RTm8ay+O26eNH8q7a5/eVLTOkDX6Z4xy5izkBMA=; b=Cm8dUwyL9VMDKaUxEk3VXzPWfvq2UHilnbLHH5dyN6AFyUua9FYZpu86SzZG9bWPd5 ApDbxvfarAc+LWO64ird4jMTd7Gbo6j0Q3CUKUfJbXj1oRBNir8d7H3MYhh7QtzKzcNL sQE/TATmQevuf9FOPBH7pt5KUsgGPLiBFMn/VUbrqlebMIi2UoUbtPmPGZlhdcnPl3Fn UUPtSaM2+nPmuKzehW67lZ6NFs2kQ/f1x3MZHj7HjxKgPXH6vlN2PIfwNzeHVt5RwnZr z0YM02m2AHXeo3jDWOa84PsSPfwE5y4QnmiNM3+5v9F9o6ig/wEcs5aF7BTU2DtlUoFw q6yQ== X-Received: by 10.50.221.43 with SMTP id qb11mr19465108igc.33.1401973458636; Thu, 05 Jun 2014 06:04:18 -0700 (PDT) Received: from [192.168.0.102] (dsl-173-206-0-110.tor.primus.ca. [173.206.0.110]) by mx.google.com with ESMTPSA id cl7sm14343139igc.9.2014.06.05.06.04.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 06:04:18 -0700 (PDT) Message-ID: <53906ABC.9010809@gmail.com> Date: Thu, 05 Jun 2014 09:03:56 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Suresh Krishnan , "ot@cisco.com" , "wdec.ietf@gmail.com" , Yuchi Chen , Cong Liu References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/VjlOhSJGYuRynJWpZARLn63MhQI Cc: "softwires@ietf.org" , "draft-ietf-softwire-lw4over6@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:04:31 -0000 OK with me. Nits: Section 11 would normally be entitled "Contributors". Within that section, you have Alex Clauberg. s/Alex/Axel/ Tom Taylor On 05/06/2014 12:37 AM, Suresh Krishnan 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 nobody Thu Jun 5 06:58:57 2014 Return-Path: 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 ; 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 ; 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 ; Thu, 5 Jun 2014 03:58:14 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id t60so893677wes.13 for ; 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: References: Date: Thu, 5 Jun 2014 12:58:06 +0200 Message-ID: From: Wojciech Dec To: Suresh Krishnan 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" , "draft-ietf-softwire-lw4over6@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 10:58:19 -0000 --047d7beb9c80ac0ac704fb149eca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Got no issues. Thanks. On 5 June 2014 06:32, Suresh Krishnan 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=3Ddraft-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=E2=80=99t think that there is a problem. For the purpose of the exa= mple 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 form= at > 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=E2=80=99s 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 > *Date: *Tuesday, 3 June 2014 15:44 > *To: *Ian Farrer > *Cc: *Ole Troan , Tom Taylor , > Ian Farrer , " > draft-ietf-softwire-lw4over6@tools.ietf.org" < > draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui < > cuiyong@tsinghua.edu.cn>, Softwires-wg > *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 wi= th > a=3D0, 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, wrote: > > Hi Woj, > > > > Here=E2=80=99s an example from an lwAFTR binding table. In this case, the= re=E2=80=99s 4096 > ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn=E2=80=99t 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 > *Date: *Tuesday, 3 June 2014 12:39 > *To: *Ole Troan > *Cc: *Tom Taylor , 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 > *Subject: *Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well > Known Ports > *Resent-To: *Ian Farrer , Mohamed Boucadair < > mohamed.boucadair@orange.com>, , = , > , > > > > How so, could you give an example? > > > > On 3 June 2014 12:17, Ole Troan 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 t= o > a=3D6... > > sorry, yes, you'd not assign 0000/6. > that's not equivalent to a=3D6 though. > > cheers, > Ole > > > > > > > > > > > > > > > > > On 3 June 2014 11:31, Ole Troan wrote: > > Wojciech, > > > > > Could you show a working example of that in action, along with the se= t > 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 wrote: > > > Woj, > > > > > > in the LW46 case, you can still do a=3D0, 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 wrote: > > > > There's a difference between setting a=3D6 and setting aside the > lowest PSIDs because they occupy that port space. The value of a determin= es > 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=3D6 arrives precisely at what the goal is here, excl= ude > 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 recommendatio= n > is NOT > > > > to allocate ports 0-1024, then this effectively recommends that > a-bits=3D6. > > > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. T= he > > > > latter is not a regular normative term, and arguably if the > recommendation > > > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone > wants the > > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > > > > On 2 June 2014 19:50, Tom Taylor 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 wrote: > > > > > > > > Hi, > > > > > > > > This one slipped my mind=E2=80=A6. > > > > > > > > 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.htm= l > > > > > > > > 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=E2=80=99s 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.=E2=80=9D > > > > > > > > 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 update= d > 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=E2=80=99ll > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --047d7beb9c80ac0ac704fb149eca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Got no issues.

Thanks.


On 5 June 2014 06:32, Suresh Kri= shnan <suresh.krishnan@ericsson.com> wrote:

Hi all (specifically peop= le in the To: list),

=C2=A0 Since you were inv= olved 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 <= /p>

=C2=A0

http://tool= s.ietf.org/html/draft-ietf-softwire-lw4over6-09

=C2=A0

and the diff can be found= here

=C2=A0

http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-09.txt=

=C2=A0

Thanks

Suresh

=C2=A0

=C2=A0

=C2=A0

Hi Woj,

=C2=A0=

I don=E2=80=99t 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 implementati= on that we have is still based on the port-min, port-max format that was de= scribed in an older version of the draft before we settled on PSID (it need= s to be updated now this has stabilised): Here=E2=80=99s an actual config line:

=C2=A0=

2001:10f:60:1ff::0:b4 1.2.3= 0.121 port 4096 to 8191

=C2=A0=

So, the problem results fro= m my dodgy example rather than anything else.

=C2=A0=

Cheers,

Ian

=C2=A0=

=C2=A0=

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 &= lt;cuiyong@tsi= nghua.edu.cn>, Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well= Known Ports

=C2=A0=

Hi Ian,

thanks for the example. This helps to illustrate, although the numbers prov= ided don't seem to add up (at least in terms of the algorithm and meani= ng of PSID).

For 4096 ports per CE, one = needs 12 "freely" bits of address space. The PSID, as per the dra= ft, 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 fo= r the example above k-bits should be 4. This, along with a=3D0, actually wo= rks out to be then numerically as per the PSIDs you provide.

If the meaning the lw46 imp= lementation puts a different meaning on the k-bits, then there is a problem= ...

=C2=A0=

Cheers=

=C2=A0

=C2=A0=

=C2=A0

On 3 June 2014 13:09, <<= a href=3D"mailto:ian.farrer@telekom.de" target=3D"_blank">ian.farrer@teleko= m.de> wrote:

Hi Woj,

=C2=A0=

Here=E2=80=99s an example f= rom an lwAFTR binding table. In this case, there=E2=80=99s 4096 ports per c= lient (k-bits =3D12, a-bits=3D0). PSID 0 just isn=E2=80=99t in the table.

=C2=A0=

2001:10f:60:6ff::0:b4 1.2.3= 0.126 PSID 4096

2001:10f:60:6ff::1:b4 1.2.3= 0.126 PSID 8192

2001:10f:60:6ff::2:b4 1.2.3= 0.126 PSID 12288

2001:10f:60:6ff::3:b4 1.2.3= 0.126 PSID 16384

2001:10f:60:6ff::4:b4 1.2.3= 0.126 PSID 20480

2001:10f:60:6ff::5:b4 1.2.3= 0.126 PSID 24576

2001:10f:60:6ff::6:b4 1.2.3= 0.126 PSID 28672

2001:10f:60:6ff::7:b4 1.2.3= 0.126 PSID 32768

2001:10f:60:6ff::8:b4 1.2.3= 0.126 PSID 36864

2001:10f:60:6ff::9:b4 1.2.3= 0.126 PSID 40960

2001:10f:60:6ff::a:b4 1.2.3= 0.126 PSID 45056

2001:10f:60:6ff::b:b4 1.2.3= 0.126 PSID 49152

2001:10f:60:6ff::c:b4 1.2.3= 0.126 PSID 53248

2001:10f:60:6ff::d:b4 1.2.3= 0.126 PSID 57344

2001:10f:60:6ff::e:b4 1.2.3= 0.126 PSID 61440

2001:10f:60:7ff::0:b4 1.2.3= 0.127 PSID 4096

2001:10f:60:7ff::1:b4 1.2.3= 0.127 PSID 8192

2001:10f:60:7ff::2:b4 1.2.3= 0.127 PSID 12288

2001:10f:60:7ff::3:b4 1.2.3= 0.127 PSID 16384

2001:10f:60:7ff::4:b4 1.2.3= 0.127 PSID 20480

2001:10f:60:7ff::5:b4 1.2.3= 0.127 PSID 24576

2001:10f:60:7ff::6:b4 1.2.3= 0.127 PSID 28672

2001:10f:60:7ff::7:b4 1.2.3= 0.127 PSID 32768

2001:10f:60:7ff::8:b4 1.2.3= 0.127 PSID 36864

2001:10f:60:7ff::9:b4 1.2.3= 0.127 PSID 40960

2001:10f:60:7ff::a:b4 1.2.3= 0.127 PSID 45056

2001:10f:60:7ff::b:b4 1.2.3= 0.127 PSID 49152

2001:10f:60:7ff::c:b4 1.2.3= 0.127 PSID 53248

2001:10f:60:7ff::d:b4 1.2.3= 0.127 PSID 57344

2001:10f:60:7ff::e:b4 1.2.3= 0.127 PSID 61440

=C2=A0=

Cheers,

Ian

=C2=A0=

=C2=A0=

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>, &quo= t;draft-ietf-softwire-lw4over6@tools.ietf.org" <draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui &= lt;cuiyong@tsi= nghua.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.boucad= air@orange.com>, <sunqiong@ctbri.com.cn>, <tena@huawei.com>, <= yiu_lee@cable.comcast.com>, <yong@csnet1.cs.tsinghua.edu.cn>

=C2=A0=

How so, could you give an e= xample?

=C2=A0

On 3 June 2014 12:17, Ole T= roan <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=3D6...

sorry, yes, you'd not a= ssign 0000/6.
that's not equivalent to a=3D6 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 th= e 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 p= orts 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=3D0, 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> w= rote:
> > > There's a difference between setting a=3D6 and setting a= side the lowest PSIDs because they occupy that port space. The value of a d= etermines how ports are assigned to each PSID, but does not affect the usab= le PSID numbering space.
> > >
> > > I think that you should illustrate how you think this would = work before we reach a conclusion.
> > > A setting of a=3D6 arrives precisely at what the goal is her= e, exclude ports 0-1024. So if there is a need to have another way of achie= ving 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 C= E the port-range.
> > >
> > > Regards.
> > >
> > >
> > > RECOMMENDED is part of the RFC 2119 boilerplate. The (uninte= ntionally) 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 t= hat a-bits=3D6.
> > > Moreover the meaning of SHOULD vs RECOMMEND should be questi= oned. The
> > > latter is not a regular normative term, and arguably if the = recommendation
> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If= anyone wants the
> > > full port set, then a=3D0 would be an obvious consequence. > > >
> > >
> > > On 2 June 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> w= rote:
> > >
> > > 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:
> > >
> > > =C2=A0 Hi,
> > >
> > > This one slipped my mind=E2=80=A6.
> > >
> > > =C2=A0 From a discussion with Ole during the MAP dhcp last c= all, 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=E2=80=99s a wording change proposal to resolve this: > > >
> > > Section 5.1
> > >
> > > Original text (last sentence, para 7):
> > >
> > > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0.&quo= t;
> > >
> > > Proposed change:
> > >
> > > "For lw4o6, the number of a-bits SHOULD be 0 to allocat= e 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.=E2=80=9D
> > >
> > > Please let me know if you are OK with the proposed change. > > >
> > > cheers,
> > > Ian
> > >
> > >
> > > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draf= t was updated to
> > >
> > > reference map-dhcp for configuration, =C2=A0the port configu= ration 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 ma= p-dhcp. I=E2=80=99ll
> > > 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
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Softwires mailing list
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> >
> >
>
>

=C2=A0=

=C2=A0=


--047d7beb9c80ac0ac704fb149eca-- From nobody Thu Jun 5 06:58:59 2014 Return-Path: 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 A2D0A1A00D6 for ; Thu, 5 Jun 2014 06:07:04 -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 R7QpXX1wXTgz for ; Thu, 5 Jun 2014 06:07:00 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D22221A008D for ; Thu, 5 Jun 2014 06:06:59 -0700 (PDT) Received: by mail-qg0-f45.google.com with SMTP id z60so1490227qgd.32 for ; Thu, 05 Jun 2014 06:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=sxwA+rWzKvAxQIrJQ+MBC4Xlb9vxV7TnAD5G/jMQoqE=; b=dzYfAQg/jsP3z2SOjFYOP/hHJ3x21YRz+UnMfyAhx5xixwFm3Do5fHLX7dogPK3o1Q 8kFibFPsDJzkTUNpf8SOwHhYQVFJbhbQlQhxrx30gjZCLX0lbyENmXJWWVhLXgmZQayI GAjZXSSqa90UutiGxNOiSbcK3NJvAs0w/oMJ44xPHH5+2HQqYoFmw7sa4Btrd1XXTjL2 I9hs+ncDMf4VPxThY1ZSjJhNF98Ya+hDwpKO5IFkA7YNYKSQ9Ytkb8x43AphSU8PbVwg boU24Ia1aVHngKXNt9cVcOGKu7ZdKfViJrrriDTB1ZQyv9VFrWxYzLeYGTtLkzvSVdHS sgPw== X-Received: by 10.224.53.202 with SMTP id n10mr2569838qag.73.1401973612962; Thu, 05 Jun 2014 06:06:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.96.149.2 with HTTP; Thu, 5 Jun 2014 06:06:32 -0700 (PDT) In-Reply-To: References: From: Cong Liu Date: Thu, 5 Jun 2014 21:06:32 +0800 Message-ID: To: Suresh Krishnan Content-Type: multipart/alternative; boundary=001a1132f4142f66d704fb166b28 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/n2lRJej7KkLJV0LUd573VqQ5DrA X-Mailman-Approved-At: Thu, 05 Jun 2014 06:58:51 -0700 Cc: "ot@cisco.com" , "draft-ietf-softwire-lw4over6@tools.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:07:04 -0000 --001a1132f4142f66d704fb166b28 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It looks good to me. Regards, Cong 2014-06-05 12:32 GMT+08:00 Suresh Krishnan : > 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=3Ddraft-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=E2=80=99t think that there is a problem. For the purpose of the exa= mple 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 form= at > 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=E2=80=99s 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 > *Date: *Tuesday, 3 June 2014 15:44 > *To: *Ian Farrer > *Cc: *Ole Troan , Tom Taylor , > Ian Farrer , " > draft-ietf-softwire-lw4over6@tools.ietf.org" < > draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui < > cuiyong@tsinghua.edu.cn>, Softwires-wg > *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 wi= th > a=3D0, 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, wrote: > > Hi Woj, > > > > Here=E2=80=99s an example from an lwAFTR binding table. In this case, the= re=E2=80=99s 4096 > ports per client (k-bits =3D12, a-bits=3D0). PSID 0 just isn=E2=80=99t 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 > *Date: *Tuesday, 3 June 2014 12:39 > *To: *Ole Troan > *Cc: *Tom Taylor , 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 > *Subject: *Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well > Known Ports > *Resent-To: *Ian Farrer , Mohamed Boucadair < > mohamed.boucadair@orange.com>, , = , > , > > > > How so, could you give an example? > > > > On 3 June 2014 12:17, Ole Troan 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 t= o > a=3D6... > > sorry, yes, you'd not assign 0000/6. > that's not equivalent to a=3D6 though. > > cheers, > Ole > > > > > > > > > > > > > > > > > On 3 June 2014 11:31, Ole Troan wrote: > > Wojciech, > > > > > Could you show a working example of that in action, along with the se= t > 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 wrote: > > > Woj, > > > > > > in the LW46 case, you can still do a=3D0, 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 wrote: > > > > There's a difference between setting a=3D6 and setting aside the > lowest PSIDs because they occupy that port space. The value of a determin= es > 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=3D6 arrives precisely at what the goal is here, excl= ude > 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 recommendatio= n > is NOT > > > > to allocate ports 0-1024, then this effectively recommends that > a-bits=3D6. > > > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned. T= he > > > > latter is not a regular normative term, and arguably if the > recommendation > > > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If anyone > wants the > > > > full port set, then a=3D0 would be an obvious consequence. > > > > > > > > > > > > On 2 June 2014 19:50, Tom Taylor 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 wrote: > > > > > > > > Hi, > > > > > > > > This one slipped my mind=E2=80=A6. > > > > > > > > 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.htm= l > > > > > > > > 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=E2=80=99s 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.=E2=80=9D > > > > > > > > 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 update= d > 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=E2=80=99ll > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --001a1132f4142f66d704fb166b28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It looks good to me.

Regards,
Cong


2014-06-05 12:32 GMT+08:00 Suresh Krishnan <suresh.krishnan= @ericsson.com>:

Hi all (specifically peop= le in the To: list),

=C2=A0 Since you were inv= olved 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 <= /p>

=C2=A0

http://tool= s.ietf.org/html/draft-ietf-softwire-lw4over6-09

=C2=A0

and the diff can be found= here

=C2=A0

http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-09.txt=

=C2=A0

Thanks

Suresh

=C2=A0

=C2=A0

=C2=A0

Hi Woj,

=C2=A0=

I don=E2=80=99t 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 implementati= on that we have is still based on the port-min, port-max format that was de= scribed in an older version of the draft before we settled on PSID (it need= s to be updated now this has stabilised): Here=E2=80=99s an actual config line:

=C2=A0=

2001:10f:60:1ff::0:b4 1.2.3= 0.121 port 4096 to 8191

=C2=A0=

So, the problem results fro= m my dodgy example rather than anything else.

=C2=A0=

Cheers,

Ian

=C2=A0=

=C2=A0=

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 &= lt;cuiyong@tsi= nghua.edu.cn>, Softwires-wg <softwires@ietf.org>
Subject: Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well= Known Ports

=C2=A0=

Hi Ian,

thanks for the example. This helps to illustrate, although the numbers prov= ided don't seem to add up (at least in terms of the algorithm and meani= ng of PSID).

For 4096 ports per CE, one = needs 12 "freely" bits of address space. The PSID, as per the dra= ft, 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 fo= r the example above k-bits should be 4. This, along with a=3D0, actually wo= rks out to be then numerically as per the PSIDs you provide.

If the meaning the lw46 imp= lementation puts a different meaning on the k-bits, then there is a problem= ...

=C2=A0=

Cheers=

=C2=A0

=C2=A0=

=C2=A0

On 3 June 2014 13:09, <<= a href=3D"mailto:ian.farrer@telekom.de" target=3D"_blank">ian.farrer@teleko= m.de> wrote:

Hi Woj,

=C2=A0=

Here=E2=80=99s an example f= rom an lwAFTR binding table. In this case, there=E2=80=99s 4096 ports per c= lient (k-bits =3D12, a-bits=3D0). PSID 0 just isn=E2=80=99t in the table.

=C2=A0=

2001:10f:60:6ff::0:b4 1.2.3= 0.126 PSID 4096

2001:10f:60:6ff::1:b4 1.2.3= 0.126 PSID 8192

2001:10f:60:6ff::2:b4 1.2.3= 0.126 PSID 12288

2001:10f:60:6ff::3:b4 1.2.3= 0.126 PSID 16384

2001:10f:60:6ff::4:b4 1.2.3= 0.126 PSID 20480

2001:10f:60:6ff::5:b4 1.2.3= 0.126 PSID 24576

2001:10f:60:6ff::6:b4 1.2.3= 0.126 PSID 28672

2001:10f:60:6ff::7:b4 1.2.3= 0.126 PSID 32768

2001:10f:60:6ff::8:b4 1.2.3= 0.126 PSID 36864

2001:10f:60:6ff::9:b4 1.2.3= 0.126 PSID 40960

2001:10f:60:6ff::a:b4 1.2.3= 0.126 PSID 45056

2001:10f:60:6ff::b:b4 1.2.3= 0.126 PSID 49152

2001:10f:60:6ff::c:b4 1.2.3= 0.126 PSID 53248

2001:10f:60:6ff::d:b4 1.2.3= 0.126 PSID 57344

2001:10f:60:6ff::e:b4 1.2.3= 0.126 PSID 61440

2001:10f:60:7ff::0:b4 1.2.3= 0.127 PSID 4096

2001:10f:60:7ff::1:b4 1.2.3= 0.127 PSID 8192

2001:10f:60:7ff::2:b4 1.2.3= 0.127 PSID 12288

2001:10f:60:7ff::3:b4 1.2.3= 0.127 PSID 16384

2001:10f:60:7ff::4:b4 1.2.3= 0.127 PSID 20480

2001:10f:60:7ff::5:b4 1.2.3= 0.127 PSID 24576

2001:10f:60:7ff::6:b4 1.2.3= 0.127 PSID 28672

2001:10f:60:7ff::7:b4 1.2.3= 0.127 PSID 32768

2001:10f:60:7ff::8:b4 1.2.3= 0.127 PSID 36864

2001:10f:60:7ff::9:b4 1.2.3= 0.127 PSID 40960

2001:10f:60:7ff::a:b4 1.2.3= 0.127 PSID 45056

2001:10f:60:7ff::b:b4 1.2.3= 0.127 PSID 49152

2001:10f:60:7ff::c:b4 1.2.3= 0.127 PSID 53248

2001:10f:60:7ff::d:b4 1.2.3= 0.127 PSID 57344

2001:10f:60:7ff::e:b4 1.2.3= 0.127 PSID 61440

=C2=A0=

Cheers,

Ian

=C2=A0=

=C2=A0=

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>, &quo= t;draft-ietf-softwire-lw4over6@tools.ietf.org" <draft-ietf-softwire-lw4over6@tools.ietf.org>, Yong Cui &= lt;cuiyong@tsi= nghua.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.boucad= air@orange.com>, <sunqiong@ctbri.com.cn>, <tena@huawei.com>, <= yiu_lee@cable.comcast.com>, <yong@csnet1.cs.tsinghua.edu.cn>

=C2=A0=

How so, could you give an e= xample?

=C2=A0

On 3 June 2014 12:17, Ole T= roan <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=3D6...

sorry, yes, you'd not a= ssign 0000/6.
that's not equivalent to a=3D6 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 th= e 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 p= orts 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=3D0, 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> w= rote:
> > > There's a difference between setting a=3D6 and setting a= side the lowest PSIDs because they occupy that port space. The value of a d= etermines how ports are assigned to each PSID, but does not affect the usab= le PSID numbering space.
> > >
> > > I think that you should illustrate how you think this would = work before we reach a conclusion.
> > > A setting of a=3D6 arrives precisely at what the goal is her= e, exclude ports 0-1024. So if there is a need to have another way of achie= ving 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 C= E the port-range.
> > >
> > > Regards.
> > >
> > >
> > > RECOMMENDED is part of the RFC 2119 boilerplate. The (uninte= ntionally) 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 t= hat a-bits=3D6.
> > > Moreover the meaning of SHOULD vs RECOMMEND should be questi= oned. The
> > > latter is not a regular normative term, and arguably if the = recommendation
> > > is for excluding 0-1024 then a=3D6 looks like the SHOULD. If= anyone wants the
> > > full port set, then a=3D0 would be an obvious consequence. > > >
> > >
> > > On 2 June 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> w= rote:
> > >
> > > 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:
> > >
> > > =C2=A0 Hi,
> > >
> > > This one slipped my mind=E2=80=A6.
> > >
> > > =C2=A0 From a discussion with Ole during the MAP dhcp last c= all, 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=E2=80=99s a wording change proposal to resolve this: > > >
> > > Section 5.1
> > >
> > > Original text (last sentence, para 7):
> > >
> > > "For lw4o6, the =C2=A0number of a-bits SHOULD be 0.&quo= t;
> > >
> > > Proposed change:
> > >
> > > "For lw4o6, the number of a-bits SHOULD be 0 to allocat= e 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.=E2=80=9D
> > >
> > > Please let me know if you are OK with the proposed change. > > >
> > > cheers,
> > > Ian
> > >
> > >
> > > =C2=A0 Good spot on the WKP exclusion. Before the lw4o6 draf= t was updated to
> > >
> > > reference map-dhcp for configuration, =C2=A0the port configu= ration 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 ma= p-dhcp. I=E2=80=99ll
> > > 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
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Softwires mailing list
> > > Soft= wires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
> > >
> > >
> > >
> > >
> >
> >
>
>

=C2=A0=

=C2=A0=


--001a1132f4142f66d704fb166b28-- From nobody Thu Jun 5 06:59:00 2014 Return-Path: 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 420B21A014F for ; Thu, 5 Jun 2014 06:31:11 -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 vZIsaEjGM5wk for ; Thu, 5 Jun 2014 06:31:05 -0700 (PDT) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D381A007C for ; Thu, 5 Jun 2014 06:31:05 -0700 (PDT) Received: by mail-pd0-f175.google.com with SMTP id z10so1092811pdj.34 for ; Thu, 05 Jun 2014 06:30:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:reply-to:subject:references:mime-version:message-id :content-type; bh=Ka2Jj4d8M/biXzRCiwt5mPEt2T6bI8jOzFx29bzGWXA=; b=m2n1PiKncK64G+fmM4cxUCcHRXxY9a5TmSCIZDRFrSwMGIAwiydRwcP9QsaV1TNJHt vSNiOBfdSwqi2dOlPnMBG2D/oWjJi3kNG6A2WsxkjJTMnx967jWcDYmgV6n0gb+wU8bh 0psRzV9nSPQUlMtVu7MHeptBUg1Uzv7TlfEHhu2tTjD3c91+nj50b6mOlf3QwKubvoqp 7MjlLM17IpjAtpnT8KC8d9XhuJ5624188XCuMasFjKRXYP5+M8JSfH2ShqwLMX84ePS7 D44jZU/lkNeLKCE/Lg6WhigtD+xQJGf1wyYABRUe44ZQfDRCXxW61XgwFoCStHYro5nB wGzA== X-Received: by 10.69.31.11 with SMTP id ki11mr76800159pbd.88.1401975058716; Thu, 05 Jun 2014 06:30:58 -0700 (PDT) Received: from netlab-PC ([166.111.68.231]) by mx.google.com with ESMTPSA id bz4sm23069383pbb.12.2014.06.05.06.30.52 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 05 Jun 2014 06:30:57 -0700 (PDT) Date: Thu, 5 Jun 2014 21:30:49 +0800 From: "Yuchi Chen" To: "Suresh Krishnan" References: X-Priority: 3 X-GUID: DF0C083C-D02F-4DA4-B49E-463B92836854 X-Has-Attach: no X-Mailer: Foxmail 7.0.1.92[cn] Mime-Version: 1.0 Message-ID: <201406052130465206240@gmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart404442612788_=----" Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/L00p1_wHNm_pgYVup_EYCqO-o6w X-Mailman-Approved-At: Thu, 05 Jun 2014 06:58:51 -0700 Cc: Ole Troan , draft-ietf-softwire-lw4over6 , softwires WG 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 Reply-To: chenycmx List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jun 2014 13:31:11 -0000 This is a multi-part message in MIME format. ------=_001_NextPart404442612788_=---- Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgU3VyZXNoLA0KDQpJdCdzIG9rIHdpdGggbWUuIFRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4NCg0K QmVzdCByZWdhcmRzIQ0KDQoNCg0KWXVjaGkgQ2hlbg0KDQpGcm9tOiBTdXJlc2ggS3Jpc2huYW4N CkRhdGU6IDIwMTQtMDYtMDUgMTI6MzINClRvOiBvdEBjaXNjby5jb207IHdkZWMuaWV0ZkBnbWFp bC5jb207IFl1Y2hpIENoZW47IENvbmcgTGl1OyBUb20gVGF5bG9yDQpDQzogc29mdHdpcmVzQGll dGYub3JnOyBpYW4uZmFycmVyQHRlbGVrb20uZGU7IGRyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3Zl cjZAdG9vbHMuaWV0Zi5vcmcNClN1YmplY3Q6IE5ldyB2ZXJzaW9uIHB1Ymxpc2hlZCAoV2FzIFJF OiBbU29mdHdpcmVzXSBkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2IGV4Y2x1ZGluZyBXZWxs IEtub3duIFBvcnRzKQ0KSGkgYWxsIChzcGVjaWZpY2FsbHkgcGVvcGxlIGluIHRoZSBUbzogbGlz dCksDQogIFNpbmNlIHlvdSB3ZXJlIGludm9sdmVkIGluIHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMg dG9waWMsIGNhbiB5b3UgcGxlYXNlIGxvb2sgb3ZlciB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhl IGx3NG92ZXI2IGRyYWZ0IGFuZCBzZWUgaWYgdGhlIGNoYW5nZSBhZGRyZXNzZXMgeW91ciBjb25j ZXJuLiBUaGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzIGF0IA0KIA0KaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNi0wOQ0KIA0KYW5k IHRoZSBkaWZmIGNhbiBiZSBmb3VuZCBoZXJlDQogDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYtMDkudHh0DQogDQpUaGFua3MN ClN1cmVzaA0KIA0KIA0KRnJvbTogU29mdHdpcmVzIFttYWlsdG86c29mdHdpcmVzLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpYW4uZmFycmVyQHRlbGVrb20uZGUNClNlbnQ6IEp1bmUt MDMtMTQgMTA6MTYgQU0NClRvOiB3ZGVjLmlldGZAZ21haWwuY29tDQpDYzogb3RAY2lzY28uY29t OyBzb2Z0d2lyZXNAaWV0Zi5vcmc7IGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuOyBkcmFmdC1pZXRm LXNvZnR3aXJlLWx3NG92ZXI2QHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTogW1NvZnR3aXJl c10gZHJhZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNiBleGNsdWRpbmcgV2VsbCBLbm93biBQb3J0 cw0KIA0KSGkgV29qLA0KIA0KSSBkb26hr3QgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIHByb2JsZW0u IEZvciB0aGUgcHVycG9zZSBvZiB0aGUgZXhhbXBsZSB0aGF0IEkgc2VudCB5b3UgKGFuZCB0byBh bnN3ZXIgeW91ciBzcGVjaWZpYyBxdWVzdGlvbiksIEkgcmF0aGVyIHF1aWNrbHkgZGlkIGEgbW9j ayB1cCBvZiB3aGF0IHRoZSBjb25maWcgbWlnaHQgbG9vayBsaWtlIHdpdGggcHNpZC4gVGhlIGN1 cnJlbnQgYWN0dWFsIGltcGxlbWVudGF0aW9uIHRoYXQgd2UgaGF2ZSBpcyBzdGlsbCBiYXNlZCBv biB0aGUgcG9ydC1taW4sIHBvcnQtbWF4IGZvcm1hdCB0aGF0IHdhcyBkZXNjcmliZWQgaW4gYW4g b2xkZXIgdmVyc2lvbiBvZiB0aGUgZHJhZnQgYmVmb3JlIHdlIHNldHRsZWQgb24gUFNJRCAoaXQg bmVlZHMgdG8gYmUgdXBkYXRlZCBub3cgdGhpcyBoYXMgc3RhYmlsaXNlZCk6IEhlcmWhr3MgYW4g YWN0dWFsIGNvbmZpZyBsaW5lOg0KIA0KMjAwMToxMGY6NjA6MWZmOjowOmI0IDEuMi4zMC4xMjEg cG9ydCA0MDk2IHRvIDgxOTENCiANClNvLCB0aGUgcHJvYmxlbSByZXN1bHRzIGZyb20gbXkgZG9k Z3kgZXhhbXBsZSByYXRoZXIgdGhhbiBhbnl0aGluZyBlbHNlLg0KIA0KQ2hlZXJzLA0KSWFuDQog DQogDQpGcm9tOiBXb2pjaWVjaCBEZWMgPHdkZWMuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUdWVz ZGF5LCAzIEp1bmUgMjAxNCAxNTo0NA0KVG86IElhbiBGYXJyZXIgPGlhbi5mYXJyZXJAdGVsZWtv bS5kZT4NCkNjOiBPbGUgVHJvYW4gPG90QGNpc2NvLmNvbT4sIFRvbSBUYXlsb3IgPHRvbS50YXls b3Iuc3Rkc0BnbWFpbC5jb20+LCBJYW4gRmFycmVyIDxpYW5mYXJyZXJAZ214LmNvbT4sICJkcmFm dC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2QHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtaWV0Zi1zb2Z0 d2lyZS1sdzRvdmVyNkB0b29scy5pZXRmLm9yZz4sIFlvbmcgQ3VpIDxjdWl5b25nQHRzaW5naHVh LmVkdS5jbj4sIFNvZnR3aXJlcy13ZyA8c29mdHdpcmVzQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtTb2Z0d2lyZXNdIGRyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYgZXhjbHVkaW5nIFdlbGwg S25vd24gUG9ydHMNCiANCkhpIElhbiwNCg0KdGhhbmtzIGZvciB0aGUgZXhhbXBsZS4gVGhpcyBo ZWxwcyB0byBpbGx1c3RyYXRlLCBhbHRob3VnaCB0aGUgbnVtYmVycyBwcm92aWRlZCBkb24ndCBz ZWVtIHRvIGFkZCB1cCAoYXQgbGVhc3QgaW4gdGVybXMgb2YgdGhlIGFsZ29yaXRobSBhbmQgbWVh bmluZyBvZiBQU0lEKS4NCkZvciA0MDk2IHBvcnRzIHBlciBDRSwgb25lIG5lZWRzIDEyICJmcmVl bHkiIGJpdHMgb2YgYWRkcmVzcyBzcGFjZS4gVGhlIFBTSUQsIGFzIHBlciB0aGUgZHJhZnQsIGlz IHRoZSBmaXhlZCBjb2RlIHBvaW50IHRoYXQgdW5pcXVlbHkgcGVyIENFIGluZGV4ZXMgdGhhdCBh ZGRyZXNzIHNwYWNlIChpZSBhIHN1Ym5ldCBhZGRyZXNzKS4gVGhlIGxlbmd0aCBvZiB0aGUgUFNJ RCBpcyB0aGUgay1iaXRzLiBUaHVzIGZvciB0aGUgZXhhbXBsZSBhYm92ZSBrLWJpdHMgc2hvdWxk IGJlIDQuIFRoaXMsIGFsb25nIHdpdGggYT0wLCBhY3R1YWxseSB3b3JrcyBvdXQgdG8gYmUgdGhl biBudW1lcmljYWxseSBhcyBwZXIgdGhlIFBTSURzIHlvdSBwcm92aWRlLiANCklmIHRoZSBtZWFu aW5nIHRoZSBsdzQ2IGltcGxlbWVudGF0aW9uIHB1dHMgYSBkaWZmZXJlbnQgbWVhbmluZyBvbiB0 aGUgay1iaXRzLCB0aGVuIHRoZXJlIGlzIGEgcHJvYmxlbS4uLg0KIA0KQ2hlZXJzDQogDQogDQog DQpPbiAzIEp1bmUgMjAxNCAxMzowOSwgPGlhbi5mYXJyZXJAdGVsZWtvbS5kZT4gd3JvdGU6DQpI aSBXb2osDQogDQpIZXJloa9zIGFuIGV4YW1wbGUgZnJvbSBhbiBsd0FGVFIgYmluZGluZyB0YWJs ZS4gSW4gdGhpcyBjYXNlLCB0aGVyZaGvcyA0MDk2IHBvcnRzIHBlciBjbGllbnQgKGstYml0cyA9 MTIsIGEtYml0cz0wKS4gUFNJRCAwIGp1c3QgaXNuoa90IGluIHRoZSB0YWJsZS4NCiANCjIwMDE6 MTBmOjYwOjZmZjo6MDpiNCAxLjIuMzAuMTI2IFBTSUQgNDA5Ng0KMjAwMToxMGY6NjA6NmZmOjox OmI0IDEuMi4zMC4xMjYgUFNJRCA4MTkyDQoyMDAxOjEwZjo2MDo2ZmY6OjI6YjQgMS4yLjMwLjEy NiBQU0lEIDEyMjg4DQoyMDAxOjEwZjo2MDo2ZmY6OjM6YjQgMS4yLjMwLjEyNiBQU0lEIDE2Mzg0 DQoyMDAxOjEwZjo2MDo2ZmY6OjQ6YjQgMS4yLjMwLjEyNiBQU0lEIDIwNDgwDQoyMDAxOjEwZjo2 MDo2ZmY6OjU6YjQgMS4yLjMwLjEyNiBQU0lEIDI0NTc2DQoyMDAxOjEwZjo2MDo2ZmY6OjY6YjQg MS4yLjMwLjEyNiBQU0lEIDI4NjcyDQoyMDAxOjEwZjo2MDo2ZmY6Ojc6YjQgMS4yLjMwLjEyNiBQ U0lEIDMyNzY4DQoyMDAxOjEwZjo2MDo2ZmY6Ojg6YjQgMS4yLjMwLjEyNiBQU0lEIDM2ODY0DQoy MDAxOjEwZjo2MDo2ZmY6Ojk6YjQgMS4yLjMwLjEyNiBQU0lEIDQwOTYwDQoyMDAxOjEwZjo2MDo2 ZmY6OmE6YjQgMS4yLjMwLjEyNiBQU0lEIDQ1MDU2DQoyMDAxOjEwZjo2MDo2ZmY6OmI6YjQgMS4y LjMwLjEyNiBQU0lEIDQ5MTUyDQoyMDAxOjEwZjo2MDo2ZmY6OmM6YjQgMS4yLjMwLjEyNiBQU0lE IDUzMjQ4DQoyMDAxOjEwZjo2MDo2ZmY6OmQ6YjQgMS4yLjMwLjEyNiBQU0lEIDU3MzQ0DQoyMDAx OjEwZjo2MDo2ZmY6OmU6YjQgMS4yLjMwLjEyNiBQU0lEIDYxNDQwDQoyMDAxOjEwZjo2MDo3ZmY6 OjA6YjQgMS4yLjMwLjEyNyBQU0lEIDQwOTYNCjIwMDE6MTBmOjYwOjdmZjo6MTpiNCAxLjIuMzAu MTI3IFBTSUQgODE5Mg0KMjAwMToxMGY6NjA6N2ZmOjoyOmI0IDEuMi4zMC4xMjcgUFNJRCAxMjI4 OA0KMjAwMToxMGY6NjA6N2ZmOjozOmI0IDEuMi4zMC4xMjcgUFNJRCAxNjM4NA0KMjAwMToxMGY6 NjA6N2ZmOjo0OmI0IDEuMi4zMC4xMjcgUFNJRCAyMDQ4MA0KMjAwMToxMGY6NjA6N2ZmOjo1OmI0 IDEuMi4zMC4xMjcgUFNJRCAyNDU3Ng0KMjAwMToxMGY6NjA6N2ZmOjo2OmI0IDEuMi4zMC4xMjcg UFNJRCAyODY3Mg0KMjAwMToxMGY6NjA6N2ZmOjo3OmI0IDEuMi4zMC4xMjcgUFNJRCAzMjc2OA0K MjAwMToxMGY6NjA6N2ZmOjo4OmI0IDEuMi4zMC4xMjcgUFNJRCAzNjg2NA0KMjAwMToxMGY6NjA6 N2ZmOjo5OmI0IDEuMi4zMC4xMjcgUFNJRCA0MDk2MA0KMjAwMToxMGY6NjA6N2ZmOjphOmI0IDEu Mi4zMC4xMjcgUFNJRCA0NTA1Ng0KMjAwMToxMGY6NjA6N2ZmOjpiOmI0IDEuMi4zMC4xMjcgUFNJ RCA0OTE1Mg0KMjAwMToxMGY6NjA6N2ZmOjpjOmI0IDEuMi4zMC4xMjcgUFNJRCA1MzI0OA0KMjAw MToxMGY6NjA6N2ZmOjpkOmI0IDEuMi4zMC4xMjcgUFNJRCA1NzM0NA0KMjAwMToxMGY6NjA6N2Zm OjplOmI0IDEuMi4zMC4xMjcgUFNJRCA2MTQ0MA0KIA0KQ2hlZXJzLA0KSWFuDQogDQogDQpGcm9t OiBXb2pjaWVjaCBEZWMgPHdkZWMuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUdWVzZGF5LCAzIEp1 bmUgMjAxNCAxMjozOQ0KVG86IE9sZSBUcm9hbiA8b3RAY2lzY28uY29tPg0KQ2M6IFRvbSBUYXls b3IgPHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20+LCBJYW4gRmFycmVyIDxpYW5mYXJyZXJAZ214 LmNvbT4sICJkcmFmdC1pZXRmLXNvZnR3aXJlLWx3NG92ZXI2QHRvb2xzLmlldGYub3JnIiA8ZHJh ZnQtaWV0Zi1zb2Z0d2lyZS1sdzRvdmVyNkB0b29scy5pZXRmLm9yZz4sIFlvbmcgQ3VpIDxjdWl5 b25nQHRzaW5naHVhLmVkdS5jbj4sIFNvZnR3aXJlcyBXRyA8c29mdHdpcmVzQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtTb2Z0d2lyZXNdIGRyYWZ0LWlldGYtc29mdHdpcmUtbHc0b3ZlcjYgZXhj bHVkaW5nIFdlbGwgS25vd24gUG9ydHMNClJlc2VudC1UbzogSWFuIEZhcnJlciA8aWFuLmZhcnJl ckB0ZWxla29tLmRlPiwgTW9oYW1lZCBCb3VjYWRhaXIgPG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5n ZS5jb20+LCA8c3VucWlvbmdAY3RicmkuY29tLmNuPiwgPHRlbmFAaHVhd2VpLmNvbT4sIDx5aXVf bGVlQGNhYmxlLmNvbWNhc3QuY29tPiwgPHlvbmdAY3NuZXQxLmNzLnRzaW5naHVhLmVkdS5jbj4N CiANCkhvdyBzbywgY291bGQgeW91IGdpdmUgYW4gZXhhbXBsZT8NCiANCk9uIDMgSnVuZSAyMDE0 IDEyOjE3LCBPbGUgVHJvYW4gPG90QGNpc2NvLmNvbT4gd3JvdGU6DQpXb2pjaWVjaCwNCg0KPiBU aGFua3MuIEknbSBub3Qgc3VyZSBJIGdldCB5b3VyIGV4YW1wbGUgdGhvdWdoLiBUbyBleGNsdWRl IHBvcnRzIDAtMTAyMywgdGhlIGV4Y2x1ZGVkIHBvcnQgInN1Ym5ldCIgd291bGQgYmUgMHgwMDAw LzYuIFdoaWNoIHdvdWxkIGJlIGVxdWl2YWxlbnQgdG8gYT02Li4uDQpzb3JyeSwgeWVzLCB5b3Un ZCBub3QgYXNzaWduIDAwMDAvNi4NCnRoYXQncyBub3QgZXF1aXZhbGVudCB0byBhPTYgdGhvdWdo Lg0KDQpjaGVlcnMsDQpPbGUNCg0KDQo+DQo+DQo+DQo+DQo+DQo+DQo+IE9uIDMgSnVuZSAyMDE0 IDExOjMxLCBPbGUgVHJvYW4gPG90QGNpc2NvLmNvbT4gd3JvdGU6DQo+IFdvamNpZWNoLA0KPg0K PiA+IENvdWxkIHlvdSBzaG93IGEgd29ya2luZyBleGFtcGxlIG9mIHRoYXQgaW4gYWN0aW9uLCBh bG9uZyB3aXRoIHRoZSBzZXQgb2YgUFNJRHMgY29udGFpbmluZyB0aGUgdXNhYmxlIHBvcnQgcmFu Z2VzPw0KPg0KPiBpbiBMVzQ2LCBwb3J0cyBhcmUgcHJvdmlzaW9uZWQgcGVyIGNsaWVudC4gc28s IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aGF0IHlvdSB3YW50IGEgd29ya2luZyBleGFtcGxlIG9mLiB0 aGF0J3MganVzdCBsaWtlIGFzc2lnbmluZyAxOTIuMTY4LjAuMTAgLSAxOTIuMTY4LjAuMjU1IGlu IGEgREhDUCBwb29sLiBpbiB0aGUgUFNJRCBjYXNlIHlvdSB3aWxsIG5vdCBhc3NpZ24gcG9ydHMg MDAwMC8xMA0KPg0KPiBjaGVlcnMsDQo+IE9sZQ0KPg0KPg0KPiA+DQo+ID4gQ2hlZXJzDQo+ID4N Cj4gPg0KPiA+DQo+ID4NCj4gPiBPbiAzIEp1bmUgMjAxNCAxMDo1MSwgT2xlIFRyb2FuIDxvdEBj aXNjby5jb20+IHdyb3RlOg0KPiA+IFdvaiwNCj4gPg0KPiA+IGluIHRoZSBMVzQ2IGNhc2UsIHlv dSBjYW4gc3RpbGwgZG8gYT0wLCBhbmQgZW5zdXJlIHRoYXQgeW91IGRvbid0IHByb3Zpc2lvbiBh bnkgUFNJRCB3aGljaCByZXN1bHRzIGluIHRoZSB3ZWxsIGtub3duIHBvcnRzLg0KPiA+DQo+ID4g Y2hlZXJzLA0KPiA+IE9sZQ0KPiA+DQo+ID4gPg0KPiA+ID4gT24gMiBKdW5lIDIwMTQgMjE6NDks IFRvbSBUYXlsb3IgPHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20+IHdyb3RlOg0KPiA+ID4gVGhl cmUncyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBzZXR0aW5nIGE9NiBhbmQgc2V0dGluZyBhc2lkZSB0 aGUgbG93ZXN0IFBTSURzIGJlY2F1c2UgdGhleSBvY2N1cHkgdGhhdCBwb3J0IHNwYWNlLiBUaGUg dmFsdWUgb2YgYSBkZXRlcm1pbmVzIGhvdyBwb3J0cyBhcmUgYXNzaWduZWQgdG8gZWFjaCBQU0lE LCBidXQgZG9lcyBub3QgYWZmZWN0IHRoZSB1c2FibGUgUFNJRCBudW1iZXJpbmcgc3BhY2UuDQo+ ID4gPg0KPiA+ID4gSSB0aGluayB0aGF0IHlvdSBzaG91bGQgaWxsdXN0cmF0ZSBob3cgeW91IHRo aW5rIHRoaXMgd291bGQgd29yayBiZWZvcmUgd2UgcmVhY2ggYSBjb25jbHVzaW9uLg0KPiA+ID4g QSBzZXR0aW5nIG9mIGE9NiBhcnJpdmVzIHByZWNpc2VseSBhdCB3aGF0IHRoZSBnb2FsIGlzIGhl cmUsIGV4Y2x1ZGUgcG9ydHMgMC0xMDI0LiBTbyBpZiB0aGVyZSBpcyBhIG5lZWQgdG8gaGF2ZSBh bm90aGVyIHdheSBvZiBhY2hpZXZpbmcgdGhhdCwgYnkgY3JlYXRpbmcgc29tZSBleGNsdWRlZCBt YWdpYyBQU0lEIHZhbHVlIHRoYXQgY29ycmVzcG9uZHMgdG8gMC0xMDI0LCB3ZSB3b3VsZCBsaWtl IHRvIGtub3cgd2h5IGlzIHRoYXQgcmVsZXZhbnQgYW5kIGhvdyBpdCBpcyBzdXBwb3NlZCB0byB3 b3JrIGluIGEgc3lzdGVtIHdoZXJlIHRoZSBQU0lEIGNvbnZleXMgdG8gdGhlIENFIHRoZSBwb3J0 LXJhbmdlLg0KPiA+ID4NCj4gPiA+IFJlZ2FyZHMuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IFJFQ09N TUVOREVEIGlzIHBhcnQgb2YgdGhlIFJGQyAyMTE5IGJvaWxlcnBsYXRlLiBUaGUgKHVuaW50ZW50 aW9uYWxseSkgbWlzc2luZyB0ZXJtIGlzIE5PVCBSRUNPTU1FTkRFRC4NCj4gPiA+DQo+ID4gPiBU b20NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gMDIvMDYvMjAxNCAzOjI3IFBNLCBXb2pjaWVjaCBE ZWMgd3JvdGU6DQo+ID4gPiBXZWxsLCBJJ20gcmVmZXJyaW5nIHRvIHRoZSAiUkVDT01NRU5ERUQi IHBhcnQuIElmIHRoZSByZWNvbW1lbmRhdGlvbiBpcyBOT1QNCj4gPiA+IHRvIGFsbG9jYXRlIHBv cnRzIDAtMTAyNCwgdGhlbiB0aGlzIGVmZmVjdGl2ZWx5IHJlY29tbWVuZHMgdGhhdCBhLWJpdHM9 Ni4NCj4gPiA+IE1vcmVvdmVyIHRoZSBtZWFuaW5nIG9mIFNIT1VMRCB2cyBSRUNPTU1FTkQgc2hv dWxkIGJlIHF1ZXN0aW9uZWQuIFRoZQ0KPiA+ID4gbGF0dGVyIGlzIG5vdCBhIHJlZ3VsYXIgbm9y bWF0aXZlIHRlcm0sIGFuZCBhcmd1YWJseSBpZiB0aGUgcmVjb21tZW5kYXRpb24NCj4gPiA+IGlz IGZvciBleGNsdWRpbmcgMC0xMDI0IHRoZW4gYT02IGxvb2tzIGxpa2UgdGhlIFNIT1VMRC4gSWYg YW55b25lIHdhbnRzIHRoZQ0KPiA+ID4gZnVsbCBwb3J0IHNldCwgdGhlbiBhPTAgd291bGQgYmUg YW4gb2J2aW91cyBjb25zZXF1ZW5jZS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gMiBKdW5lIDIw MTQgMTk6NTAsIFRvbSBUYXlsb3IgPHRvbS50YXlsb3Iuc3Rkc0BnbWFpbC5jb20+IHdyb3RlOg0K PiA+ID4NCj4gPiA+IE5vdCBzdXJlIGhvdyB5b3UgcmVhZCB0aGF0LCBidXQgaXQgY2FuIGJlIGZp eGVkIGJ5IHB1dHRpbmcgYSBjb21tYSBhZnRlcg0KPiA+ID4gIlNIT1VMRCBiZSAwIiBhbmQgcmVw bGFjaW5nICJ0byBhbGxvY2F0ZSIgd2l0aCAidGh1cyBhbGxvY2F0aW5nIi4NCj4gPiA+DQo+ID4g PiBUb20NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24gMDIvMDYvMjAxNCAxMjoxNCBQTSwgV29qY2ll Y2ggRGVjIHdyb3RlOg0KPiA+ID4NCj4gPiA+IFVobSwgdGhpcyBhcHBlYXJzIHRvIG1lYW4gdGhh dCB0aGUgUkVDT01NRU5ERUQgYS1iaXRzIFNIT1VMRCBiZSA2Lg0KPiA+ID4NCj4gPiA+DQo+ID4g PiBPbiAyNiBNYXkgMjAxNCAxMzoyNCwgSWFuIEZhcnJlciA8aWFuZmFycmVyQGdteC5jb20+IHdy b3RlOg0KPiA+ID4NCj4gPiA+ICAgSGksDQo+ID4gPg0KPiA+ID4gVGhpcyBvbmUgc2xpcHBlZCBt eSBtaW5koa0uDQo+ID4gPg0KPiA+ID4gICBGcm9tIGEgZGlzY3Vzc2lvbiB3aXRoIE9sZSBkdXJp bmcgdGhlIE1BUCBkaGNwIGxhc3QgY2FsbCwgdGhlcmUgd2FzIGENCj4gPiA+IGRpc2N1c3Npb24g YWJvdXQgdGhlIGV4Y2x1c2lvbiBvZiBwcm92aXNpb25pbmcgV0tQcyB0byBDUEVzIC0NCj4gPiA+ IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zb2Z0d2lyZXMvY3VycmVudC9t c2cwNjAxMC5odG1sDQo+ID4gPg0KPiA+ID4gSW4gcHJldmlvdXMgdmVyc2lvbnMsIHRoZSBsdzRv NiB1c2VkIHRvIHJlZmVyZW5jZQ0KPiA+ID4gc3VuLWRoYy1wb3J0LXNldC1vcHRpb24sDQo+ID4g PiB3aGljaCBhbHNvIHN0YXRlZCB0aGF0IHRoZSBXS1BzIHNob3VsZCBub3QgYmUgYXNzaWduZWQu IFRoaXMgYWR2aWNlIGdvdA0KPiA+ID4gbG9zdCB3aGVuIGNoYW5naW5nIHRvIHJlZmVyZW5jZSBt YXAtZGhjcCBmb3IgUFNJRCBmb3JtYXQuDQo+ID4gPg0KPiA+ID4gSGVyZaGvcyBhIHdvcmRpbmcg Y2hhbmdlIHByb3Bvc2FsIHRvIHJlc29sdmUgdGhpczoNCj4gPiA+DQo+ID4gPiBTZWN0aW9uIDUu MQ0KPiA+ID4NCj4gPiA+IE9yaWdpbmFsIHRleHQgKGxhc3Qgc2VudGVuY2UsIHBhcmEgNyk6DQo+ ID4gPg0KPiA+ID4gIkZvciBsdzRvNiwgdGhlICBudW1iZXIgb2YgYS1iaXRzIFNIT1VMRCBiZSAw LiINCj4gPiA+DQo+ID4gPiBQcm9wb3NlZCBjaGFuZ2U6DQo+ID4gPg0KPiA+ID4gIkZvciBsdzRv NiwgdGhlIG51bWJlciBvZiBhLWJpdHMgU0hPVUxEIGJlIDAgdG8gYWxsb2NhdGUgYSBzaW5nbGUN Cj4gPiA+IGNvbnRpZ3VvdXMgcG9ydCBzZXQgdG8gZWFjaCBsd0I0Lg0KPiA+ID4NCj4gPiA+IFVu bGVzcyBhIGx3QjQgaXMgYmVpbmcgYWxsb2NhdGVkIGEgZnVsbCBJUHY0IGFkZHJlc3MsIGl0IGlz IFJFQ09NTUVOREVEDQo+ID4gPiB0aGF0IFBTSURzIGNvbnRhaW5pbmcgdGhlIHdlbGwta25vd24g cG9ydHMgKDAtMTAyMykgYXJlIG5vdCBhbGxvY2F0ZWQgdG8NCj4gPiA+IGx3QjRzLqGxDQo+ID4g Pg0KPiA+ID4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBhcmUgT0sgd2l0aCB0aGUgcHJvcG9z ZWQgY2hhbmdlLg0KPiA+ID4NCj4gPiA+IGNoZWVycywNCj4gPiA+IElhbg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiAgIEdvb2Qgc3BvdCBvbiB0aGUgV0tQIGV4Y2x1c2lvbi4gQmVmb3JlIHRoZSBsdzRv NiBkcmFmdCB3YXMgdXBkYXRlZCB0bw0KPiA+ID4NCj4gPiA+IHJlZmVyZW5jZSBtYXAtZGhjcCBm b3IgY29uZmlndXJhdGlvbiwgIHRoZSBwb3J0IGNvbmZpZ3VyYXRpb24gd2FzDQo+ID4gPiBkZXNj cmliZWQNCj4gPiA+IGluIHN1bi1kaGMtcG9ydC1zZXQtb3B0aW9uLCB3aGljaCBhbHNvIHN0YXRl ZCB0aGF0IHRoZSBXS1BzIHNob3VsZCBub3QgYmUNCj4gPiA+IGFzc2lnbmVkLiBUaGlzIGFkdmlj ZSBnb3QgbG9zdCB3aGVuIGNoYW5naW5nIHRvIHJlZmVyZW5jZSBtYXAtZGhjcC4gSaGvbGwNCj4g PiA+IG1ha2UgYSBzdWdnZXN0ZWQgdGV4dCB1cGRhdGUgZm9yIHRoZSBsdzRvNiBkcmFmdCB0byBm aXggdGhpcy4gRG9lcyB0aGF0DQo+ID4gPiB3b3JrIGZvciB5b3U/DQo+ID4gPg0KPiA+ID4NCj4g PiA+IHllcywgdGhhdCB3b3VsZCBiZSBnb29kLg0KPiA+ID4NCj4gPiA+IGNoZWVycywNCj4gPiA+ IE9sZQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+ID4gU29mdHdpcmVzIG1haWxpbmcgbGlzdA0KPiA+ID4gU29m dHdpcmVzQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NvZnR3aXJlcw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBTb2Z0d2lyZXMg bWFpbGluZyBsaXN0DQo+ID4gPiBTb2Z0d2lyZXNAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc29mdHdpcmVzDQo+ID4gPg0KPiA+ID4NCj4gPiA+ DQo+ID4gPg0KPiA+DQo+ID4NCj4NCj4NCiANCiA= ------=_001_NextPart404442612788_=---- Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Suresh,
 
It's ok with me. Thanks for the update.
 
Best regards!
Yuc= hi=20 Chen
 
Date: 2014-06-05 12:32
To: ot@cisco.com; wdec.ietf@gmail.com; Yuchi Chen; Cong Liu; Tom Taylor
CC: softwires@ietf.= org;=20 ian.farrer@telekom.de; draft-ietf-sof= twire-lw4over6@tools.ietf.org
Subject: New version published (Was RE: [Softwires]=20 draft-ietf-softwire-lw4over6 excluding Well Known Ports)

Hi=20 all (specifically people in the To: list),

 =20 Since you were involved in the discussion on this topic, can you please lo= ok=20 over the latest version of the lw4over6 draft and see if the change addres= ses=20 your concern. The latest version of the draft is at

 

http:/= /tools.ietf.org/html/draft-ietf-softwire-lw4over6-09=

 

and=20 the diff can be found here

 

http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-= 09.txt

 

Thanks

Suresh

 

 

From:=20 Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of=20 ian.farrer@telekom.de
Sent: June-03-14 10:16 AM
To:=20 wdec.ietf@gmail.com
Cc: ot@cisco.com; softwires@ietf.org;=20 cuiyong@tsinghua.edu.cn;=20 draft-ietf-softwire-lw4over6@tools.ietf.org
Subject: Re: [Softwi= res]=20 draft-ietf-softwire-lw4over6 excluding Well Known=20 Ports

 

Hi=20 Woj,

 

I=20 don=A1=AFt think that there is a problem. For the purpose of the example t= hat I sent=20 you (and to answer your specific question), I rather quickly did a mock up= of=20 what the config might look like with psid. The current actual implementati= on=20 that we have is still based on the port-min, port-max format that was desc= ribed=20 in an older version of the draft before we settled on PSID (it needs to be= =20 updated now this has stabilised): Here=A1=AFs an actual config=20 line:

 

2001:10f:60:1ff::0:b4=20 1.2.30.121 port 4096 to 8191

 

So,=20 the problem results from my dodgy example rather than anything=20 else.

 

Cheers,

Ian

 

 

From:=20 Wojciech=20 Dec <wdec.ietf@gmail.com>
Date= :=20 Tuesday, 3 June 2014 15:44
To: Ian Farrer <ian.farrer@telekom.de>
= Cc:=20 Ole Troan <ot@cisco.com>, To= m Taylor=20 <tom.taylor.stds@gmail.com>= ;, Ian=20 Farrer <ianfarrer@gmx.com>,= "draft-ietf-sof= twire-lw4over6@tools.ietf.org"=20 <draft-ietf-sof= twire-lw4over6@tools.ietf.org>,=20 Yong Cui <cuiyong@tsinghua.edu.cn>,=20 Softwires-wg <softwires@ietf.org>
Subjec= t:=20 Re: [Softwires] draft-ietf-softwire-lw4over6 excluding Well Known=20 Ports

 

Hi=20 Ian,

thanks for the example. This helps to illustrate, although the= =20 numbers provided don't seem to add up (at least in terms of the algorithm = and=20 meaning of PSID).

For=20 4096 ports per CE, one needs 12 "freely" bits of address space. The PSID, = as per=20 the draft, is the fixed code point that uniquely per CE indexes that addre= ss=20 space (ie a subnet address). The length of the PSID is the k-bits. Thus fo= r the=20 example above k-bits should be 4. This, along with a=3D0, actually works o= ut to be=20 then numerically as per the PSIDs you provide.

If=20 the meaning the lw46 implementation puts a different meaning on the k-bits= , then=20 there is a problem...

 

Cheers

 

 

 

On=20 3 June 2014 13:09, <ian.farrer@telekom.de> wrote:

Hi=20 Woj,

 

Here=A1=AFs=20 an example from an lwAFTR binding table. In this case, there=A1=AFs 4096 p= orts per=20 client (k-bits =3D12, a-bits=3D0). PSID 0 just isn=A1=AFt in the=20 table.

 

2001:10f:60:6ff::0:b4=20 1.2.30.126 PSID 4096

2001:10f:60:6ff::1:b4=20 1.2.30.126 PSID 8192

2001:10f:60:6ff::2:b4=20 1.2.30.126 PSID 12288

2001:10f:60:6ff::3:b4=20 1.2.30.126 PSID 16384

2001:10f:60:6ff::4:b4=20 1.2.30.126 PSID 20480

2001:10f:60:6ff::5:b4=20 1.2.30.126 PSID 24576

2001:10f:60:6ff::6:b4=20 1.2.30.126 PSID 28672

2001:10f:60:6ff::7:b4=20 1.2.30.126 PSID 32768

2001:10f:60:6ff::8:b4=20 1.2.30.126 PSID 36864

2001:10f:60:6ff::9:b4=20 1.2.30.126 PSID 40960

2001:10f:60:6ff::a:b4=20 1.2.30.126 PSID 45056

2001:10f:60:6ff::b:b4=20 1.2.30.126 PSID 49152

2001:10f:60:6ff::c:b4=20 1.2.30.126 PSID 53248

2001:10f:60:6ff::d:b4=20 1.2.30.126 PSID 57344

2001:10f:60:6ff::e:b4=20 1.2.30.126 PSID 61440

2001:10f:60:7ff::0:b4=20 1.2.30.127 PSID 4096

2001:10f:60:7ff::1:b4=20 1.2.30.127 PSID 8192

2001:10f:60:7ff::2:b4=20 1.2.30.127 PSID 12288

2001:10f:60:7ff::3:b4=20 1.2.30.127 PSID 16384

2001:10f:60:7ff::4:b4=20 1.2.30.127 PSID 20480

2001:10f:60:7ff::5:b4=20 1.2.30.127 PSID 24576

2001:10f:60:7ff::6:b4=20 1.2.30.127 PSID 28672

2001:10f:60:7ff::7:b4=20 1.2.30.127 PSID 32768

2001:10f:60:7ff::8:b4=20 1.2.30.127 PSID 36864

2001:10f:60:7ff::9:b4=20 1.2.30.127 PSID 40960

2001:10f:60:7ff::a:b4=20 1.2.30.127 PSID 45056

2001:10f:60:7ff::b:b4=20 1.2.30.127 PSID 49152

2001:10f:60:7ff::c:b4=20 1.2.30.127 PSID 53248

2001:10f:60:7ff::d:b4=20 1.2.30.127 PSID 57344

2001:10f:60:7ff::e:b4=20 1.2.30.127 PSID 61440

 

Cheers,

Ian

 

 

From:=20 Wojciech=20 Dec <wdec.ietf@gmail.com>
Date: Tuesday, 3 Jun= e 2014=20 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=20 <cuiyong@tsinghua.edu.cn>, Softwires WG <softwires@ietf.org>
Subject: Re: [Softwir= es]=20 draft-ietf-softwire-lw4over6 excluding Well Known Ports
Resent-To: <= /B>Ian=20 Farrer <ian.farrer@telekom.de>, Mohamed Boucadair <mohamed.boucadair@orange.com>, <sunqiong@ctbri.com.c= n>,=20 <tena@huawei.com= >,=20 <yiu_lee@cable.comcast.com>, <yong@csnet1.cs.tsinghua.edu.cn>

 

How=20 so, could you give an example?

 

On=20 3 June 2014 12:17, Ole Troan <ot@cisco.com> wrote:

Wojciech,


>=20 Thanks. I'm not sure I get your example though. To exclude ports 0-1023, t= he=20 excluded port "subnet" would be 0x0000/6. Which would be equivalent to=20 a=3D6...

sorry,=20 yes, you'd not assign 0000/6.
that's not equivalent to a=3D6=20 though.

cheers,
Ole



>
>
>
>
>
>
>=20 On 3 June 2014 11:31, Ole Troan <ot@cisco.com> wrote:
> Wojciech,
>
&= gt; >=20 Could you show a working example of that in action, along with the set of = PSIDs=20 containing the usable port ranges?
>
> in LW46, ports are=20 provisioned per client. so, I don't understand what you want a working exa= mple=20 of. that's just like assigning 192.168.0.10 - 192.168.0.255 in a DHCP pool= . in=20 the PSID case you will not assign ports 0000/10
>
> cheers,>=20 Ole
>
>
> >
> > Cheers
> >
>=20 >
> >
> >
> > On 3 June 2014 10:51, Ole Troa= n=20 <ot@cisco.com>=20 wrote:
> > Woj,
> >
> > in the LW46 case, you c= an=20 still do a=3D0, and ensure that you don't provision any PSID which results= in the=20 well known ports.
> >
> > cheers,
> > Ole
&g= t;=20 >
> > >
> > > On 2 June 2014 21:49, Tom Taylor = <tom.taylor.stds@gmail.com> wrote:
> > >= There's=20 a difference between setting a=3D6 and setting aside the lowest PSIDs beca= use they=20 occupy that port space. The value of a determines how ports are assigned t= o each=20 PSID, but does not affect the usable PSID numbering space.
> >=20 >
> > > I think that you should illustrate how you think th= is=20 would work before we reach a conclusion.
> > > A setting of a= =3D6=20 arrives precisely at what the goal is here, exclude ports 0-1024. So if th= ere is=20 a need to have another way of achieving that, by creating some excluded ma= gic=20 PSID value that corresponds to 0-1024, we would like to know why is that=20 relevant and how it is supposed to work in a system where the PSID conveys= to=20 the CE the port-range.
> > >
> > > Regards.
>= ; >=20 >
> > >
> > > RECOMMENDED is part of the RFC 21= 19=20 boilerplate. The (unintentionally) missing term is NOT RECOMMENDED.
>= ; >=20 >
> > > Tom
> > >
> > >
> >= ; >=20 On 02/06/2014 3:27 PM, Wojciech Dec wrote:
> > > Well, I'm ref= erring=20 to the "RECOMMENDED" part. If the recommendation is NOT
> > > = to=20 allocate ports 0-1024, then this effectively recommends that a-bits=3D6.>=20 > > Moreover the meaning of SHOULD vs RECOMMEND should be questioned= .=20 The
> > > latter is not a regular normative term, and arguably= if=20 the recommendation
> > > is for excluding 0-1024 then a=3D6 lo= oks like=20 the SHOULD. If anyone wants the
> > > full port set, then a=3D= 0 would=20 be an obvious consequence.
> > >
> > >
> >= ; >=20 On 2 June 2014 19:50, Tom Taylor <tom.taylor.stds@gmail.com> wrote:
> > >=
>=20 > > Not sure how you read that, but it can be fixed by putting a com= ma=20 after
> > > "SHOULD be 0" and replacing "to allocate" with "th= us=20 allocating".
> > >
> > > Tom
> > >
= >=20 > >
> > > On 02/06/2014 12:14 PM, Wojciech Dec wrote:>=20 > >
> > > Uhm, this appears to mean that the RECOMMENDED= =20 a-bits SHOULD be 6.
> > >
> > >
> > > = On 26=20 May 2014 13:24, Ian Farrer <ianfarrer@gmx.com> wrote:
> > >
>= >=20 >   Hi,
> > >
> > > This one slipped my=20 mind=A1=AD.
> > >
> > >   From a discussion w= ith Ole=20 during the MAP dhcp last call, there was a
> > > discussion ab= out=20 the exclusion of provisioning WKPs to CPEs -
> > > http://www.ietf.org/mail-archive/web/softwires/current/msg= 06010.html
>=20 > >
> > > In previous versions, the lw4o6 used to=20 reference
> > > sun-dhc-port-set-option,
> > > whi= ch=20 also stated that the WKPs should not be assigned. This advice got
> = >=20 > lost when changing to reference map-dhcp for PSID format.
> >= ;=20 >
> > > Here=A1=AFs a wording change proposal to resolve th= is:
>=20 > >
> > > Section 5.1
> > >
> > >= ;=20 Original text (last sentence, para 7):
> > >
> > >= "For=20 lw4o6, the  number of a-bits SHOULD be 0."
> > >
> = >=20 > Proposed change:
> > >
> > > "For lw4o6, the = number=20 of a-bits SHOULD be 0 to allocate a single
> > > contiguous po= rt set=20 to each lwB4.
> > >
> > > Unless a lwB4 is being=20 allocated a full IPv4 address, it is RECOMMENDED
> > > that PS= IDs=20 containing the well-known ports (0-1023) are not allocated to
> >= >=20 lwB4s.=A1=B1
> > >
> > > Please let me know if you= are OK=20 with the proposed change.
> > >
> > > cheers,
&= gt;=20 > > Ian
> > >
> > >
> > >  = Good=20 spot on the WKP exclusion. Before the lw4o6 draft was updated to
> &= gt;=20 >
> > > reference map-dhcp for configuration,  the por= t=20 configuration was
> > > described
> > > in=20 sun-dhc-port-set-option, which also stated that the WKPs should not be
= >=20 > > assigned. This advice got lost when changing to reference map-dh= cp.=20 I=A1=AFll
> > > make a suggested text update for the lw4o6 dra= ft to fix=20 this. Does that
> > > work for you?
> > >
> = >=20 >
> > > yes, that would be good.
> > >
> = >=20 > cheers,
> > > Ole
> > >
> > >
= >=20 > > _______________________________________________
> > >= ;=20 Softwires mailing list
> > > Softwires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
>= ; >=20 >
> > >
> > >
> > >
> > &g= t;=20 _______________________________________________
> > > Softwire= s=20 mailing list
> > > Softwires@ietf.org
> > > https://www.ietf.org/mailman/listinfo/softwires
>= ; >=20 >
> > >
> > >
> > >
> >>=20 >
>
>

 

 

------=_001_NextPart404442612788_=------ From nobody Fri Jun 6 01:25:00 2014 Return-Path: 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 9E91C1A041C; Fri, 6 Jun 2014 01:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 n7U-8DFgLrPO; Fri, 6 Jun 2014 01:24:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA121A00EC; Fri, 6 Jun 2014 01:24:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606082453.10070.48380.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 01:24:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/MJ1qT00dA_f_UUOHWT_9ujzcu6Y Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-10.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:24:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Lightweight 4over6: An Extension to the DS-Lite Architecture Authors : Yong Cui Qiong Sun Mohamed Boucadair Tina Tsou Yiu L. Lee Ian Farrer Filename : draft-ietf-softwire-lw4over6-10.txt Pages : 21 Date : 2014-06-06 Abstract: Dual-Stack Lite (RFC 6333) describes an architecture for transporting IPv4 packets over an IPv6 network. This document specifies an extension to DS-Lite called Lightweight 4over6 which moves the Network Address and Port Translation (NAPT) function from the centralized DS-Lite tunnel concentrator to the tunnel client located in the Customer Premises Equipment (CPE). This removes the requirement for a Carrier Grade NAT function in the tunnel concentrator and reduces the amount of centralized state that must be held to a per-subscriber level. In order to delegate the NAPT function and make IPv4 Address sharing possible, port-restricted IPv4 addresses are allocated to the CPEs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-lw4over6-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 6 01:38:54 2014 Return-Path: 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 30F2D1A009E for ; Fri, 6 Jun 2014 01:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, 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 NiO0o4qYnk8t for ; Fri, 6 Jun 2014 01:38:52 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DB41A00E9 for ; Fri, 6 Jun 2014 01:38:51 -0700 (PDT) Received: from he113675.emea1.cds.t-internal.com ([10.134.99.28]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 06 Jun 2014 10:37:54 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE113675.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 6 Jun 2014 10:37:54 +0200 From: To: Date: Fri, 6 Jun 2014 10:37:51 +0200 Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-10.txt Thread-Index: Ac+BYpy4L1Zh7A9xRmmGNo9V5DV7XA== Message-ID: References: <20140606082453.10070.48380.idtracker@ietfa.amsl.com> In-Reply-To: <20140606082453.10070.48380.idtracker@ietfa.amsl.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.2.140509 acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/RXFeInbaZu4YPXg99AYwqnw-vC0 Subject: Re: [Softwires] I-D Action: draft-ietf-softwire-lw4over6-10.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jun 2014 08:38:54 -0000 Hi, New version with a very small update correcting one of the contact=B9s details (as identified by Tom) Cheers, Ian On 06/06/2014 10:24, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Softwires Working Group of the IETF. > > Title : Lightweight 4over6: An Extension to the DS-Lite >Architecture > Authors : Yong Cui > Qiong Sun > Mohamed Boucadair > Tina Tsou > Yiu L. Lee > Ian Farrer > Filename : draft-ietf-softwire-lw4over6-10.txt > Pages : 21 > Date : 2014-06-06 > >Abstract: > Dual-Stack Lite (RFC 6333) describes an architecture for transporting > IPv4 packets over an IPv6 network. This document specifies an > extension to DS-Lite called Lightweight 4over6 which moves the > Network Address and Port Translation (NAPT) function from the > centralized DS-Lite tunnel concentrator to the tunnel client located > in the Customer Premises Equipment (CPE). This removes the > requirement for a Carrier Grade NAT function in the tunnel > concentrator and reduces the amount of centralized state that must be > held to a per-subscriber level. In order to delegate the NAPT > function and make IPv4 Address sharing possible, port-restricted IPv4 > addresses are allocated to the CPEs. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-softwire-lw4over6/ > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-softwire-lw4over6-10 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-lw4over6-10 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Softwires mailing list >Softwires@ietf.org >https://www.ietf.org/mailman/listinfo/softwires From nobody Fri Jun 13 01:17:52 2014 Return-Path: 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 E36DB1A01CE; Fri, 13 Jun 2014 01:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 MxrfN1ehJlAs; Fri, 13 Jun 2014 01:17:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 388011A01ED; Fri, 13 Jun 2014 01:17:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140613081746.20159.23076.idtracker@ietfa.amsl.com> Date: Fri, 13 Jun 2014 01:17:46 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/t8yr72MBfcaI4FGGcMSrnk4TYLA Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 08:17:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : Definitions of Managed Objects for MAP-E Authors : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-02.txt Pages : 13 Date : 2014-06-13 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-mib-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 16 07:53:45 2014 Return-Path: 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 892E01A0061 for ; Mon, 16 Jun 2014 07:52:45 -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 xaJ6xtrMi0tA for ; Mon, 16 Jun 2014 07:52:44 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA9A1A0047 for ; Mon, 16 Jun 2014 07:52:44 -0700 (PDT) Received: by mail-ig0-f181.google.com with SMTP id h3so3029081igd.2 for ; Mon, 16 Jun 2014 07:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=193Cnjva+qrWXY91d6G52Ubd/DM7mNB+sFQ8tsSpFqc=; b=v7WqPpXNwBAkb5V0Tx+2jJjeF0BDLrNU4xgYZpkU3ZdFONvbGyKbC2qs0BBO8ukVS1 n73bPpojPcwGfuu7U03YSayWN89CbDEvvCBoWmnavD2/vD49P3Iq0zuQVjpqnIEEST4Q p6i5dNKYuH5K6sdNQT/weeFU69Mh4wbpe7wqQ7c5UnuO3zva/t0T1MH2NDmv4B+efbMM a+6TBJqNEK32GvgHzANJ2HD48I+RdmX6o8k/6dyByyyoM6BVnJHlpevmwQNeQFJSSc+q tPlm4o/Ou05IRsMaBCfup0TJS583aOmGOusXjErBYcd99+T0tqJDMdOf0F72bYIVrKFR I+LA== MIME-Version: 1.0 X-Received: by 10.50.79.232 with SMTP id m8mr25635040igx.33.1402930363718; Mon, 16 Jun 2014 07:52:43 -0700 (PDT) Received: by 10.42.107.148 with HTTP; Mon, 16 Jun 2014 07:52:43 -0700 (PDT) Date: Mon, 16 Jun 2014 22:52:43 +0800 Message-ID: From: Lizhong Jin To: softwires@ietf.org Content-Type: multipart/alternative; boundary=089e013a0606f971a904fbf52d6a Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/8o79AsdbA8I12BI4PZrbSUQjNyQ X-Mailman-Approved-At: Mon, 16 Jun 2014 07:53:41 -0700 Subject: [Softwires] Tunnel question for DS-Lite X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jun 2014 14:52:45 -0000 --089e013a0606f971a904fbf52d6a Content-Type: text/plain; charset=UTF-8 Hi all, DS-Lite RFC6333 defines IPv4-in-IPv6 tunnel as transition tool. But the IPv4-in-IPv6 tunnel will not have good load balance in many legacy network device. Has softwire WG considered to use IPv6 based UDP tunnel to carry the IPv4 traffic? The UDP tunnel will achieve better load balance in the network. Regards Lizhong --089e013a0606f971a904fbf52d6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all,
DS-Lite RFC6333 defines IPv4-in-IPv6 tunnel as=C2=A0transition tool. But the=C2=A0IPv4-in-IPv6 tunnel= will not have good load balance in many legacy network device. Has softwir= e WG considered to use IPv6 based UDP tunnel to carry the IPv4 traffic? The= UDP tunnel will achieve better load balance in the network.

Regards
Lizhong
--089e013a0606f971a904fbf52d6a-- From nobody Thu Jun 19 23:31:02 2014 Return-Path: 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 2D08E1ACD01; Thu, 19 Jun 2014 23:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 SoiJtjKV1yVt; Thu, 19 Jun 2014 23:30:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEBF1A0649; Thu, 19 Jun 2014 23:30:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140620063058.22646.37526.idtracker@ietfa.amsl.com> Date: Thu, 19 Jun 2014 23:30:58 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/sBRH942w2KEEfgYUaN-RmHj9_DY Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 06:31:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for MAP Authors : Sheng Jiang Yu Fu Bing Liu Peter Deacon Filename : draft-ietf-softwire-map-radius-02.txt Pages : 15 Date : 2014-06-19 Abstract: Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-radius-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-softwire-map-radius-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 20 00:17:23 2014 Return-Path: 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 C1B2D1A0320; Fri, 20 Jun 2014 00:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 UUqDg50e3Fpz; Fri, 20 Jun 2014 00:17:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F831A0243; Fri, 20 Jun 2014 00:17:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFR06789; Fri, 20 Jun 2014 07:17:14 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Jun 2014 08:17:13 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.42]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Fri, 20 Jun 2014 15:17:07 +0800 From: "Fuyu (Eleven)" To: "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-radius-02.txt Thread-Index: AQHPjFE69TF3L1mML06dNh1KQzPXlJt5i1Gw Date: Fri, 20 Jun 2014 07:17:06 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/cMYFff_m3B0hdzVeWfvPAv3nVms Cc: "radext@ietf.org" Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-map-radius-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 07:17:18 -0000 Hi, Softwirers, The authors have submitted a new version of map radius. As it related to th= e radius, I also cc the radext WG for review. Please review the latest version and give your comments. The below is the s= ummary of modifications we have made: 1: Specify this draft is especially for the MAP-E mechanism, so delete the = Encapsulation/Translation Flag Sub Option. 2: According to the updating MAP dhcp draft, add two new sub option: BR-ip= v6-address sub option, EA-Len sub option=20 3: Several text refines Many thanks and best regards Yu -----Original Message----- From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of internet-d= rafts@ietf.org Sent: Friday, June 20, 2014 2:31 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-radius-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : RADIUS Attribute for MAP Authors : Sheng Jiang Yu Fu Bing Liu Peter Deacon Filename : draft-ietf-softwire-map-radius-02.txt Pages : 15 Date : 2014-06-19 Abstract: Mapping of Address and Port (MAP) is a stateless mechanism for running IPv4 over IPv6-only infrastructure. It provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 co-existing period. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) MAP options has been defined to configure MAP Customer Edge (CE). However, in many networks, the configuration information may be stored in Authentication Authorization and Accounting (AAA) servers while user configuration is mainly from Broadband Network Gateway (BNG) through DHCPv6 protocol. This document defines a Remote Authentication Dial In User Service (RADIUS) attribute that carries MAP configuration information from AAA server to BNG. The MAP RADIUS attribute are designed following the simplify principle. It provides just enough information to form the correspondent DHCPv6 MAP option. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-radius/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-radius-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-radius-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From nobody Fri Jun 20 00:39:01 2014 Return-Path: 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 A06B21A0065 for ; Fri, 20 Jun 2014 00:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, 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 fKOH7SMa_vXm for ; Fri, 20 Jun 2014 00:38:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65441A01CB for ; Fri, 20 Jun 2014 00:38:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BFR08948; Fri, 20 Jun 2014 07:38:56 +0000 (GMT) Received: from NKGEML406-HUB.china.huawei.com (10.98.56.37) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 20 Jun 2014 08:38:55 +0100 Received: from NKGEML505-MBX.china.huawei.com ([169.254.1.42]) by nkgeml406-hub.china.huawei.com ([10.98.56.37]) with mapi id 14.03.0158.001; Fri, 20 Jun 2014 15:38:52 +0800 From: "Fuyu (Eleven)" To: "softwires@ietf.org" Thread-Topic: [Softwires] I-D Action: draft-ietf-softwire-map-mib-02.txt Thread-Index: AQHPhuAs73xe0CWW6k2yo7hudGCffJt5pJqw Date: Fri, 20 Jun 2014 07:38:51 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/-WcUPmD9eQdrD8FR6yK0ECvZx_c Subject: [Softwires] FW: I-D Action: draft-ietf-softwire-map-mib-02.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2014 07:39:00 -0000 Hi Softwirers, We have updated map mib document with minor editorial revision.=20 Comments are welcome. Thanks Yu -----Original Message----- From: Softwires [mailto:softwires-bounces@ietf.org] On Behalf Of internet-d= rafts@ietf.org Sent: Friday, June 13, 2014 4:18 PM To: i-d-announce@ietf.org Cc: softwires@ietf.org Subject: [Softwires] I-D Action: draft-ietf-softwire-map-mib-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Softwires Working Group of the IETF. Title : Definitions of Managed Objects for MAP-E Authors : Yu Fu Sheng Jiang Bing Liu Jiang Dong Yuchi Chen Filename : draft-ietf-softwire-map-mib-02.txt Pages : 13 Date : 2014-06-13 Abstract: This memo defines a portion of the Management Information Base (MIB) for using with network management protocols in the Internet community. In particular, it defines managed objects for MAP encapsulation mode. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-softwire-map-mib/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-softwire-map-mib-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-softwire-map-mib-02 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Softwires mailing list Softwires@ietf.org https://www.ietf.org/mailman/listinfo/softwires From nobody Thu Jun 26 09:04:19 2014 Return-Path: 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 887321B2D5D for ; Thu, 26 Jun 2014 09:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.654 X-Spam-Level: X-Spam-Status: No, score=-0.654 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-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 n_HKWVVhwRAW for ; Thu, 26 Jun 2014 09:04:12 -0700 (PDT) Received: from tsinghua.edu.cn (smtp01.tsinghua.edu.cn [166.111.204.30]) by ietfa.amsl.com (Postfix) with ESMTP id E3B721B2D9A for ; Thu, 26 Jun 2014 08:08:45 -0700 (PDT) Received: from [192.168.0.104] (unknown [124.126.218.35]) by app6 (Coremail) with SMTP id D8xvpgCnr+d0N6xTGoEJAA--.248S2; Thu, 26 Jun 2014 23:08:37 +0800 (CST) From: Yong Cui Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 26 Jun 2014 23:08:36 +0800 Message-Id: <530359EA-6247-4FBE-B1D9-E73E93A37930@tsinghua.edu.cn> To: "softwires@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) X-CM-TRANSID: D8xvpgCnr+d0N6xTGoEJAA--.248S2 X-Coremail-Antispam: 1UD129KBjDUn29KB7ZKAUJUUUUU529EdanIXcx71UUUUU7v73 VFW2AGmfu7bjvjm3AaLaJ3UjIYCTnIWjp_UUU867k0a2IF6F4UM7kC6x804xWl1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l8cAvFVAK0II2c7xJM2AIxVAIcxkEcVAq07x20x vEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj6x8ErcxFaVAv8VWkJr1UJwAm72CE 4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l42xK82IYc2Ij64vIr41l42xK82IY6x 8ErcxFaVAv8VWkJr1UJwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r10 6r1rMI8E67x28xkI4xCE0xIEc2x0rwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI4 8JYxBIdaVFxhVjvjDU0xZFpf9x0UUjR0UUUUUU= X-CM-SenderInfo: 5fxl50tqj632xlqjx3vdohv3gofq/ Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/Os-W0CLqVVLnw_I71_dsHdMym2o Subject: [Softwires] Call for agenda items in IETF 90 X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2014 16:04:15 -0000 Hi folks, We will have a 2-hour session on THURSDAY afternoon, July 24, 2014. If you intend to present something in the softwire session, please send = your request to Suresh and me by July 4.=20 The preferred format of your request is:=20 (title, link of your draft, presenter's name). Thanks, Yong & Suresh From nobody Sun Jun 29 11:50:02 2014 Return-Path: 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 21A681A02F3 for ; Sun, 29 Jun 2014 11:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[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 p6UAsomoUd4T for ; Sun, 29 Jun 2014 11:49:57 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796C21A02F1 for ; Sun, 29 Jun 2014 11:49:57 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wm4so7808905obc.34 for ; Sun, 29 Jun 2014 11:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=vqJF6rTrS/t8mkxchz6iPBu+TX9M1/b0Jatzqow/QMY=; b=fD69N5uiG9H9WftHa3Qqwl8w8D8etvSwT5R7uOYYCWdSzihjKKr5ntzvA0ocsqVjX0 IoykuJmTLQ3pEMC0T34ko4FNr5Msv8DBI+gYKrOZDX6tmPbPh5zS6NNMwdQtD5IFxAEV mNgh67/fXVv8Gnk13MyE8UblrKWIeK1SKphOENdzgMGgmJYUtdSmwgfYOeqrpfG2jMG1 sP7gkuCCW2v4tEGJzJkUTfaf/w9NFojE0mbGIDUnmPL8pu9EG+j+4WPsp5DIKlkW3vZR UiBnNStGGOOwBpQbfjVyXAqNP547od4DCxIXebi9EsHsBHBQZnSwk4fV8v0lTVp4Wn4P Y+xQ== X-Received: by 10.182.200.132 with SMTP id js4mr34659027obc.3.1404067796783; Sun, 29 Jun 2014 11:49:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.210.197 with HTTP; Sun, 29 Jun 2014 11:49:36 -0700 (PDT) In-Reply-To: <20140629183157.29572.10177.idtracker@ietfa.amsl.com> References: <20140629183157.29572.10177.idtracker@ietfa.amsl.com> From: Cong Liu Date: Mon, 30 Jun 2014 02:49:36 +0800 Message-ID: To: softwires Content-Type: multipart/alternative; boundary=001a11c253584499fc04fcfe0273 Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/vnNQGUXS0n_pGO7--mk6Th3qFcw Subject: [Softwires] Fwd: New Version Notification for draft-cui-softwire-unified-v6-framework-00.txt X-BeenThere: softwires@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: softwires wg discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jun 2014 18:50:00 -0000 --001a11c253584499fc04fcfe0273 Content-Type: text/plain; charset=UTF-8 Hi all, This draft was presented at London softwire meeting, and we revised it according to the comments from the meeting. A summary of modifications: 1. Focus on lw4o6/MAP running mode. 2. Add an example of running 4over6 mode, and also discusses lw4over6 mesh mode. 3. Specify the usage and reference to OpenFlow on Switches and the protocol between Controller and Switches. 4. Discuss NAT issues I hope that you could read the draft and we'd appreciate any comments on it. Best Regards, Cong ---------- Forwarded message ---------- From: Date: 2014-06-30 2:31 GMT+08:00 Subject: New Version Notification for draft-cui-softwire-unified-v6-framework-00.txt To: Yong Cui , Yuchi Chen < chenycmx@gmail.com> A new version of I-D, draft-cui-softwire-unified-v6-framework-00.txt has been successfully submitted by Yong Cui and posted to the IETF repository. Name: draft-cui-softwire-unified-v6-framework Revision: 00 Title: Unified IPv6 Transition Framework With Flow-based Forwarding Document date: 2014-06-29 Group: Individual Submission Pages: 9 URL: http://www.ietf.org/internet-drafts/draft-cui-softwire-unified-v6-framework-00.txt Status: https://datatracker.ietf.org/doc/draft-cui-softwire-unified-v6-framework/ Htmlized: http://tools.ietf.org/html/draft-cui-softwire-unified-v6-framework-00 Abstract: This document describes a software defined networking (SDN) based unified IPv6 transition framework. This framework makes use of the flow-based packet forwarding technology, which can simplify the implementation of both control plane and data plane operations of transition mechanisms. The purpose of this work is to provide an integrated and flexible framework to implement and deploy transition mechanisms, such as MAP-E, Lightweight 4over6, etc. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --001a11c253584499fc04fcfe0273 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

This draft was presented at Lon= don softwire meeting, and we revised it according to the comments from the = meeting.
A summary of=C2=A0modif= ications:
1. Focus on lw4o6/MAP running mode.
2. Add an example = of running 4over6 mode, and also discusses lw4over6 mesh mode.
3.=C2=A0Specify the usage and reference to OpenFlow on Switches and the p= rotocol between Controller and Switches.
4. Discuss NAT issues

I hope that you cou= ld read the draft and we'd=C2=A0appreciate any comments on it.

Best Regards,
Cong

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: 2014-06-30 2:31 GMT+08:00<= br> Subject: New Version Notification for draft-cui-softwire-unified-v6-framew= ork-00.txt
To: Yong Cui <yong@csnet1.cs.tsinghua.edu.cn>, Yuchi Chen <chenycmx@gmail.com>



A new version of I-D, draft-cui-softwire-unified-v6-framework-00.txt
has been successfully submitted by Yong Cui and posted to the
IETF repository.

Name: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-cui-softwire-unified-v6-fram= ework
Revision: =C2=A0 =C2=A0 =C2=A0 00
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Unified IPv6 Transition Framework = With Flow-based Forwarding
Document date: =C2=A02014-06-29
Group: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Individual Submission
Pages: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09
URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://www.ietf.org/internet-drafts/draft-cui-softwire-unified-v6-= framework-00.txt
Status: =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://da= tatracker.ietf.org/doc/draft-cui-softwire-unified-v6-framework/
Htmlized: =C2=A0 =C2=A0 =C2=A0 http://tools.ietf.o= rg/html/draft-cui-softwire-unified-v6-framework-00


Abstract:
=C2=A0 =C2=A0This document describes a software defined networking (SDN) ba= sed
=C2=A0 =C2=A0unified IPv6 transition framework. =C2=A0This framework makes = use of the
=C2=A0 =C2=A0flow-based packet forwarding technology, which can simplify th= e
=C2=A0 =C2=A0implementation of both control plane and data plane operations= of
=C2=A0 =C2=A0transition mechanisms. =C2=A0The purpose of this work is to pr= ovide an
=C2=A0 =C2=A0integrated and flexible framework to implement and deploy tran= sition
=C2=A0 =C2=A0mechanisms, such as MAP-E, Lightweight 4over6, etc.





Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



--001a11c253584499fc04fcfe0273--