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

"Syam Madanapalli" <smadanapalli@gmail.com> Sat, 13 January 2007 15:27 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kmn-0005wa-Rc; Sat, 13 Jan 2007 10:27:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5kmm-0005vE-EW for 16ng@ietf.org; Sat, 13 Jan 2007 10:27:12 -0500
Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5kml-0000Fe-3K for 16ng@ietf.org; Sat, 13 Jan 2007 10:27:12 -0500
Received: by nf-out-0910.google.com with SMTP id l36so1535441nfa for <16ng@ietf.org>; Sat, 13 Jan 2007 07:27:10 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=N5Zytu7Hh4G2yH9cYBnd0MbwX17jGPLjwH7OA1K0NT8Ks4JUlqgAoDBXbDr5CckATQ1lj1OQmdmC11jJkLCxYjTX/saep0Ww6phIEhWiAwQWziGFioum4jUPwEsufpJzbXQDs3/NrcYmSCIX7stNwywSwIwMwg628L0ELB0Evqg=
Received: by 10.49.57.1 with SMTP id j1mr1817062nfk.1168702030046; Sat, 13 Jan 2007 07:27:10 -0800 (PST)
Received: by 10.49.92.12 with HTTP; Sat, 13 Jan 2007 07:27:09 -0800 (PST)
Message-ID: <10e14db20701130727o1cd4671er1b1b3a238a5e3353@mail.gmail.com>
Date: Sat, 13 Jan 2007 20:57:09 +0530
From: "Syam Madanapalli" <smadanapalli@gmail.com>
To: "Alexandru Petrescu" <alexandru.petrescu@motorola.com>
Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [1]
In-Reply-To: <45A76BB7.9070604@motorola.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <C1CBFB73.2C040%basavaraj.patil@nokia.com> <45A6AA0C.7040508@motorola.com> <92e919fb0701111820k3aa970aft5001f778e8e46d93@mail.gmail.com> <45A76BB7.9070604@motorola.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
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>
Errors-To: 16ng-bounces@ietf.org

some text inline.

>
> JinHyeock Choi wrote:
> > Dear Alex
> >
> > Thanks for your feedback. Kindly find my in-line comments.
> >
> >>> and there is no reason for the host to depend on RAs to detect if
> >>>  it has moved across ARs. Hence there is no reason for any change
> >>>  w.r.t 3775 and I do not see RFC3775 over-riding the values
> >>> specified here.
> >>
> >> There is no other means for an IP stack on top of IPv6CS to know
> >> that the subnet has changed.  This is where MIP6 reacts, on subnet
> >> change, not on PHY change.  So the 802.16 BS, if it sends RAs, it
> >> should send them quickly.
> >
> > Allow me to make is more clear.
> >
> > A 802.16 host doesn't have to rely on unsolicited PERIODIC RAs for
> > movement detection. Upon network attachment, either 1) the access
> > router sends an unsolicted RA as of FRD (draft-ietf-dna-frd-02) or 2)
> >  the host sends an RS to get a solicited RA as of DNAv6
> > (draft-ietf-dna-protocol-03.txt).
>
> I am not sure what you mean by 'network attachment'?  I suppose you mean
> the network entry procedure of 802.16?  ('Attach' in 802.16 mostly means
> to attach a part of message to another part, and only in one single
> place a SS to a BS).
> In the network entry procedure of the 802.16 document there is nothing
> that suggests the behaviour you suggest above (DNA).   Only ND is
> suggested, not DNA.

DNA is nothing to do with 802.16, it is layer 3 mechanism, you can find
the details at
http://www.ietf.org/internet-drafts/draft-ietf-dna-protocol-03.txt

>
> 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).

Frequent periodic RAs consume the air bandwidth and may cause problems
for dormant devices.

Even if the above is not a problem, still depending RAs for movement detection
may not be a good idea. The better way is to solicit for an RA when the device
observes a L2 movement, to check if the device is on the same link or new one.

Thanks,
Syam

>
> 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