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

From: Basavaraj Patil <[email-masked]>
Date: Thu, 11 Jan 2007 14:34:27 -0600

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

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

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

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

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

-Raj

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Jan 2007 22:20:12 +0100

Basavaraj Patil wrote:
> [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.
> 
> 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.

> 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.
> 
> MaxRtrAdvInterval and 9000 seconds). So I think the sentence is 
> acceptable as written.

Ok.

> served by an AR, the lifetime is obviously non-zero. I think this is 

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

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

---

From: "JinHyeock Choi" <[email-masked]>
Date: Fri, 12 Jan 2007 11:20:25 +0900

Dear Alex

Thanks for your feedback. Kindly find my in-line comments.

> not on PHY change.  So the 802.16 BS, if it sends RAs, it should send

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

So RA interval won't affect movement detection (or DNA) delay.

Thanks for your kind consideration.

Best Regards

JinHyeock

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 12:06:31 +0100

Hi JinHyeock,

JinHyeock Choi wrote:
>>> 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.
> 

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.

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

Alex

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 12 Jan 2007 11:35:02 -0600

Hi Alex,

> (remark arguments of air interface gains are different on high-bandwidth

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Jan 2007 19:07:05 +0100

Basavaraj Patil wrote:
>>  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.
> 
>  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

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 12 Jan 2007 12:19:20 -0600

Alex,

> because no message in the network entry procedure delivers BS's

Why do you need UL multicast capability in order to send the RS?
Once the IPv6 link has been established between the MS and the AR (a PtP
link BTW in the context of this I-D), the MS can send an RS to the
all-routers multicast address.

I don't see any problem with the MS sending an RS at all once the IPv6 link
is up (implying a PtP connection between the MS and AR).

-Raj

---

From: "Syam Madanapalli" <[email-masked]>
Date: Sat, 13 Jan 2007 20:57:09 +0530

some text inline.

> that suggests the behaviour you suggest above (DNA).   Only ND is

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

> (remark arguments of air interface gains are different on high-bandwidth

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 13 Jan 2007 21:50:34 +0100

Hi Syam, thanks for the reply,

Syam Madanapalli wrote:
>>>>> 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.
>>> 
>>> 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 

Yes, it is a layer 3 mechanism.  Only layer 3 mechanisms can be designed
at IETF, or layer-2-3, but not layer 3.  I think we agree.

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

I agree they may be an issue.  But to what extent?

Dormant devices always have something listening and executing code.

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

YEs, it is a very good idea to send an RS to get an RA and compare the
prefix see whether MIP6 needs to be triggered.  But where to send this
RS?  To the IP all-nodes multicast address?  I agree it works to send it
and the BS will receive it, and respond RA.  But remark it will receive
it even if SS puts the digit '5' there, not necessarily 'ff02::1'.
Which to me is a door open to incompatibilities and potential
inter-operability issues.

But, if it's thought that this is not an issue I will not insist.  I
agree with the group.  The mechanism to send an RS is good enough to
detect a subnet-layer handover and many implementations can do.

Alex