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

[Alexandru Petrescu <[e-mail]>]

gabriel montenegro wrote:
> 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,

Thanks for referring to the two mails.  They indeed provide liaison
explanation about what multicast and broadcast mean in the context of
802.16 links, topology and PHY.

However, what an IPv6 stack needs to know is what to put in dst
addresses when sending IP multicast packets.  The resolution of this as
suggested by IPv6-over-IPv6CS is to not care at all about what to put
there, one can put anything, the other end will see it because
point-to-point.

This is incomplete, underspecified and as vague as fog, but can be
however inline with both implementation and with some other RFCs.
Depends how one reads it the word 'join' and the word 'multicast'.

Let me raise another case where link-layer multicast is needed even for
ptp links - OSPF advertisements.  If the AR sees all packets from SS (ie
no multicast filtering on ptp) then SS sees all packets from SS too.
This means that without a link-layer multicast technique the SS will see
things only routers are interested in.  For example if AR multicasts
OSPF messages (SS is not interested in, but new MR software on SS may).
Without a multicast feature in the link-layer the SS will see these
messages, and they'll also consume air interface.  A solution to this
problem is to have that MR software on SS to send MLD report when it
starts, it's known - so only then will the OSPF advs sent over the air
interface.  But without a clear means from the link-layer to have
multicast on the ptp link it won't work.

And also I wanted to say that if in the group the necessity for
link-layer multicast over the 802.16 ptp (IPv6-over-IPv6CS) is not felt
as necessary then I align with the group.

Alex

> 
> -gabriel
> 
> ----- Original Message ---- From: Alexandru Petrescu 
> <[e-mail]> To: Basavaraj Patil 
> <[e-mail]> Cc: [e-mail] 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" 
>> <[e-mail]> 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 
> [e-mail] https://www1.ietf.org/mailman/listinfo/16ng
> 


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