[16NG] Re: AD review of draft-ietf-16ng-ipv6-link-model

[Jari Arkko <[e-mail]>]

I checked the new revision against my comments
and it seems fine. Thanks. The draft will be moved
forward now.

Jari

> Hi,
>
> I have reviewed this document again.
> Please see a few comments below:
>
>   
>> 3.1.  Shared IPv6 Prefix Link Model
>>     
> This section should start with a definition of
> the model.
>
>   
>> 3.1.4.5.  Changes to Host Implementation
>>
>>    This link model requires no other implementation changes except that
>>    the hosts are required to perform duplicate address detection for all
>>    addresses even if the host is reusing the interface identifier.
>>     
> Is this a remnant from an earlier revision? If you employ
> MLD snooping as opposed to looking at NAs, it would
> appear that the above is not true.
>   
>>    802.16 [1] [2] is a connection oriented access technology for the
>>    last mile without bi-directional native multicast support. 802.16 has
>>    only downlink multicast support and there is no mechanisms defined
>>    for mobile stations to be able to send multicast packets that can be
>>    mapped to downlink multicast connection.  This could be a problem for
>>    IP protocols (e.g.  ARP, IPv6 ND) that traditionally assume the
>>    availability of multicast at the link layer. 
>>     
> This statement may need to be revised according to DJ's
> recent comments on the list.
>   
>>    3.  If neither PPP nor VLAN is used, the set of 802.16 connections
>>        can be viewed as a virtual point-to-point link for the purpose of
>>        neighbor discovery and address configuration.  For IPv6 CS, this
>>        may be used to implement the point-to-point link.
>>     
> The key issue is not what you do with ND, but rather
> what the scope of the link local multicast is; that
> determines what happens to RAs, NAs, etc.
>
>   
>>    When the p2p link model is used, the BS acts as a bridge.  For each
>>    MS, the BS bridges the unique prefix or set of prefixes assigned by
>>    the AR to the link between itself and the MS.  This means, in
>>    particular, that the per MS prefix or set of prefixes are routed on
>>    both sides (wireless and wired) of the BS, and that the BS needs to
>>    participate in all 802 standard bridging protocols.
>>     
> The expression "routed on both sides" may not be
> appropriate here. The BS is not a router.
>
> Question: why is it that the BS needs to participate in
> all bridging protocols? From the perspective of the
> MS it shouldn't even see the existence of a tunnel
> behind the BS.
>
>   
>>    One way to construct an Ethernet like link is to implement bridging
>>    [13] between BSs and AR like switched Ethernet.  In the Figure 4,
>>    bridging performs link aggregation between BSs and AR.  Bridging also
>>    supports multicast packet filtering.  Another way to implement this
>>    model is by using VLAN function [11].
>>     
>
> I do not understand how VLANs relate to this. Please explain or
> remove.
>
>   
>>    In this model, an IPv6 prefix is shared by multiple MSs on top of
>>    IEEE 802.16 point-to-multipoint links.  Also this model supports
>>    multiple access routers and multiple hosts behind an MS as shown in
>>    Figure 4.
>>     
>
> Yes, but a question: should this be taken as a claim that the
> other models do not support multiple hosts? The document
> does not say anything about this.
>   
>>    conjunction with IP convergence sublyaer with IPv6 classifiers.
>>     
> Typo.
>
> Jari
>
>
>   



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