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

From: gabriel montenegro <[email-masked]>
Date: Fri, 9 Mar 2007 00:29:19 -0800 (PST)

Syam,

Could you please confirm whether your subsequent revision took care of Jari's comments?

-gabriel

----- Original Message ----
From: Jari Arkko <[email-masked]>
To: Syam Madanapalli <[email-masked]>
Cc: [email-masked]
Sent: Monday, January 29, 2007 5:55:53 AM
Subject: [16NG] AD review of draft-ietf-16ng-ipv6-link-model

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 09 Mar 2007 12:36:40 +0200

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

Jari