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

[Alexandru Petrescu <[e-mail]>]

Basavaraj Patil wrote:
> 
> Issues raised during the LC of I-D:
> 
> [Junghoon Jee] 1. [Page 8] For transmission of IPv6 packets via the 
> IP specific part of the Packet CS of 802.16, the IPv6 layer 
> interfaces with the 802.6 MAC directly.
> 
> s/802.6/802.16
> 
> Raj> Done.
> 
> 2. 13.2.  Informative References
> 
> [FRD]      Choi, JH., Shin, DongYun., and W. Haddad, "Fast Router 
> Discovery with L2 support", August 2006, <http:// 
> www.ietf.org/internet-drafts/draft-ietf-dna-frd-02.txt>gt;.
> 
> [RFC4135]  Choi, JH. and G. Daley, "Goals of Detecting Network 
> Attachment in IPv6", RFC 4135, August 2005, 
> <ftp://ftp.isi.edu/in-notes/rfc4135>.
> 
> Raj> Based on feedback and earlier discussion, we decided to not 
> reference the DNA work. However the reference section has not been 
> revised. I have deleted both these references from the IR section.
> 
> 
> [Alex Petrescu]

Raj, thanks for taking into account my comments.

> 3. draft says:
>> The AdvDefaultLifetime in the router advertisement MUST be either 
>> zero or between MaxRtrAdvInterval and 43200 seconds.  The default 
>> value is 2 * MaxRtrAdvInterval.
> 
> This formulation is ambiguous.  I'd prefer using 'MUST' followed by a
>  single sentence, not by an 'or'.
> 
> If the Router Lifetime is 0 then the BS or AR is not a Default 
> Router. Or I don't see a deployment scenario where the BS/AR are not
>  default routers for the SS.
> 
> Raj> If you look at the AdvDefaultLifetime specification in 2461bis, 
> its is specified the same way (MUST be either zero or between 
> MaxRtrAdvInterval and 9000 seconds). So I think the sentence is 
> acceptable as written.

Ok.

> There are situations when you would want to configure a RTR that you 
> are adding to the network with Lifetime=0. For hosts that are being 
> served by an AR, the lifetime is obviously non-zero. I think this is 
> pretty well understood.

Yes, the situation is understood in general (not necessarily pretty
well), where there may be several access routers  on the same link, for
reliability.  But I'm pretty sure this is not a 802.16 capability, nor a
requirement.  Maybe in WiMax?

> 4. draft:
>> The MaxRtrAdvInterval value specified in this document over-rides 
>> the recommendation in RFC2461 [RFC2461].  The MaxRtrAdvInterval 
>> MUST be no less than 4 seconds and no greater than 21600 seconds. 
>> Thee default value for MaxRtrAdvInterval is 10800 seconds.
> 
> [nit: Thee]
> 
> Raj> Fixed.
> 
> Actually it only over-rides the upper limit and the default value 
> (2461 says 1800s vs draft 21600s, and 600s vs draft 10800s 
> respectively). This draft does not override 2461's lower limit of 4s.
> 
> 
> Raj> True. Practically speaking you would not want to send periodic 
> RAs over an air-interface.

YEs, but also practically speaking that depends largely on the type of
the air interface.  Much simpler air interfaces (than 802.16e) send many
messages on the air interfaces, not related to IP, and still works.  One
RA every second on a high-bandwidth  air interface is not overkill.  One
can compute that easily: on a 1Mbps air interface there are that many
messages possible.  1RA more or less...

> I had co-authored an I-D earlier where I had proposed that it should
>  be possible to configure an RA to not send periodic RAs at all 
> (draft-madanapalli-ipv6-periodic-rtr-advts-00.txt). However because 
> of backward compatibility issues this is not possible. The next best 
> thing is to have a large gap (time) between periodic RAs. Hence the 
> lower limit of 4s is just fine.

So maybe too because of backward compatibility issues with MIP6 it
shouldn't be possible to limit the upper limit on the frequency of RAs
to 4s.

> It means that an IPv6-over-IPv6CS handover would take a long 4s in 
> the worst case; which is too long.  But Mobile IPv6 3775 allows for 
> MaxRtrAdvInterval as low as 0.03s.  How does this draft position with
>  respect to 3775?  Can this draft be over-ridden by 3775 in addition
>  to over-riding 2461?
> 
> Raj> Movement detection as specified in RFC3775 is based on RAs. 
> Hence it makes sense to have a small value in that case. However 
> movement detection in 802.16 is handled by the lower layer

I am not sure 802.16e specifies movement detection.  I believe it
doesn't, at least not for the IP layer, and not in the IEEE 802.16e doc.
  It may do it for its PHY but that's irrelevant for IP: IP doesn't see
PHY changing BS.

If you look at the 802.16 network-entry procedure there's no clear sign
of which of the messages should be considered as a trigger of movement
for the IP stack; none contains IPv6 subnet prefix or default router
address.  There's only DHCP(v4) in that scheme and RA.  RA is best
candidate.  The procedure doesn't even say an RS could be sent right
after a certain message, instead of waiting for next RA.

Besides, you seemed to oppose completely any change or clarification to
802.16e network-entry procedure.

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

One may think that 802.16 link layer triggers are possible to speed up
the handover - yes, ok, but there's no documented method for that.  Not
to mention agreed upon.

Until 802.21 figures out how to normalize all IEEE MACs plus 3G links, I
suggest leave place for fast RAs in IPv6overIPv6CS.  Maybe a MAY would
suffice.

Thanks,

Alex

_______________________________________________
16NG mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng