Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1]

gabriel montenegro <gabriel_montenegro_2000@yahoo.com> Fri, 12 January 2007 20:00 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SaB-0007ET-KH; Fri, 12 Jan 2007 15:00:59 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sa9-0007EO-G4 for 16ng@ietf.org; Fri, 12 Jan 2007 15:00:57 -0500
Received: from web81907.mail.mud.yahoo.com ([68.142.207.186]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5Sa6-0002Yu-Ud for 16ng@ietf.org; Fri, 12 Jan 2007 15:00:57 -0500
Received: (qmail 61804 invoked by uid 60001); 12 Jan 2007 20:00:54 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=Y7YVz0kaOAw41cD7DhxmtmyA5nhiR4aul0B7xcn46BlnjFrOh3JFDfLCLjI3pbTyg8wemX2SP3N/Pj7oAlu5tC4WciLXCwiQmy113xIgXqIOdDtWGh3d1vOouhrzqkKHfmQTkgfS7ol/9z1VoW48n6nf4EyMSCF5udrOs69g5s4= ;
Message-ID: <20070112200054.61802.qmail@web81907.mail.mud.yahoo.com>
Received: from [131.107.0.103] by web81907.mail.mud.yahoo.com via HTTP; Fri, 12 Jan 2007 12:00:54 PST
Date: Fri, 12 Jan 2007 12:00:54 -0800 (PST)
From: gabriel montenegro <gabriel_montenegro_2000@yahoo.com>
Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1]
To: Alexandru Petrescu <alexandru.petrescu@motorola.com>, Basavaraj Patil <basavaraj.patil@nokia.com>
MIME-Version: 1.0
X-Spam-Score: 1.4 (+)
X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6
Cc: 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0465700099=="
Errors-To: 16ng-bounces@ietf.org

Alex,

Just looking at this statement of yours below:

"Do you agree that (1) an SS can't multicast an RS because 802.16e IPv6CS
doesn't support ul multicast?"

For this issue of multicast support, I refer you again 
to clarification by our 802.16 liaison, e.g.,

http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20061106/000392.html
http://eeca16.sogang.ac.kr/pipermail/16ng/Week-of-Mon-20061106/000394.html

-gabriel

----- Original Message ----
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Cc: 16ng@ietf.org
Sent: Friday, January 12, 2007 10:07:05 AM
Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1]

Basavaraj Patil wrote:
> Hi Alex,
> 
> On 1/12/07 5:06 AM, "ext Alexandru Petrescu" 
> <alexandru.petrescu@motorola.com> wrote:
> 
>> Periodic RA is in widespread use for movement detection.  I do not
>>  understand the opposition to use periodic RAs as allowed by 
>> rfc3775. What breaks if we use periodic RAs with a frequency higher
>>  than 1/4s? (remark arguments of air interface gains are different 
>> on high-bandwidth links).
> 
> The fact is that sending periodic RAs on an air interface 
> irrespective of BW capacity is suboptimal. A host in Idle mode is not
>  listening for periodic RAs. Listening for periodic RAs would prevent
>  the host from transitioning to idle mode which has an adverse impact
>  on battery life. 802.16 has defined paging and Idle mode support. In
>  air-interfaces that do not support such capability, sending of very 
> frequent RAs is possible but IMO still not the most efficient usage 
> of the bandwidth. In licensed spectrum the optimization and 
> efficiency of the air interface is critical. Periodic RAs are 
> unavoidable at this time. The best that we can do without breaking 
> backward compatibility is to send it with large time intervals as the
>  I-D suggests. Movement detection can be done be accomplished by
> other means. If the host is only relying on RAs for movement
> detection (at the IP layer), then it could just as well send a Rtr
> solicitation. This is not prevented.
> 
> In Unlicensed spectrum you may have a bit more liberty about how the
>  air-interface is used but even in those cases, optimizing it is a 
> better choice.

Raj, I understand a strong pushback from you about having periodic RAs
with less than 4s.  I think it's not motivated.

Let's then discuss the RS method for quick movement detection.

Do you agree that (1) an SS can't multicast an RS because 802.16e IPv6CS
doesn't support ul multicast?  and that (2) there's no means for SS to
unicast the RS because it doesn't know the BS's link-local address
because no message in the network entry procedure delivers BS's
link-local address?

What do you think?

Alex


_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng




_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng