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

Basavaraj Patil wrote:
> Alex,
> 
> Inline:
> 
> 
> On 1/12/07 1:16 PM, "ext Alexandru Petrescu" 
> <alexandru.petrescu@motorola.com> wrote:
> 
>> Basavaraj Patil wrote:
>>> Alex,
>>> 
>>> 
>>> On 1/12/07 12:07 PM, "ext Alexandru Petrescu" 
>>> <alexandru.petrescu@motorola.com> wrote:
>>> 
>>>> Basavaraj Patil wrote:
>>>>> Hi Alex,
>>>>> 
>>>>> On 1/12/07 5:06 AM, "ext Alexandru Petrescu" 
>>>>> <alexandru.petrescu@motorola.com> wrote:
> 
>>>> 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?
>>> Why do you need UL multicast capability in order to send the RS?
>> Because a multicasted RS is sent to a multicast address, and that
>> is uplink towards BS.
> 
> When the MS sends the RS to the all-routers multicast address, the
> 802.16 sends this packet as it does any other IPv6 packet via the
> transport connection  that has been established previously on the
> uplink. The host at the IPcv6 layer does not need to know the BS'
> link-local address or even its existence in this case. The RS that is
> carried via the transport connection is delivered to the BS which
> forwards it to the AR (via an L2 tunnel if required) and note that
> the BS does not even look at the IPv6 packet. It simply forwards the
> payload coming on a specific CID to an L2 tunnel which results in the
> RS now arriving at an AR. If you are thinking that the MAC in the
> host will convert the all-routers multicast destination address to a
> BS' link local address or any such thing, then you are mistaken. It
> does not work that way.

Yes, I'm thinking the IP-multicasted RS should be addressed to a
link-layer multicast address.  The 802.16MAC does have 48bit MAC
addresses, so supposedly it has 48bit _multicast_ MAC addresses too.

>>> 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.
>> The AR to be part of that all-routers multicast address it must
>> have joined that group (MUST in 2461 6.2.2).  How does AR join a
>> multicast group at 802.16 MAC level?
> 
> It does not join the multicast group at the .16 MAC level.

Well, this is against, or over-riding, 2461 6.2.2.  That section says
the router must join.

>> Is it by sending an MLD report?  An MCA-REQ/RSP telling all SSs?
>> Is it by configuring a implicit filtering rule in its database?  Is
>> it by not joining that group at all and assuming that on that ptp
>> link it will see all peer's packets?
> 
> On the PtP link it will see all the peers packets.

Yes.

>>> 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).
>> Well, I've configured something similar: "multicast" RS/RA over
>> tunnel ptp interfaces.  It works.  Doesn't mean it's conforming or
>> agreed.
> 
> So you agree that it works.  Good.

Yes, I agree that it works and that it's not specified.

Alex

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