Re: [multimob] Some comments on draft-ietf-multimob-fmipv6-pfmipv6-multicast-03

["Thomas C. Schmidt" <[e-mail]>]

Hi Stig,

many thanks - please see comments inline.

On 13.03.2014 23:30, Stig Venaas wrote:

> Here are my comments on the 03 version.

Oops, sorry ... working on version 03 included unnecessary work ... many 
of the issues below had already been fixed in the 04 preliminary version 
I had sent ...

>
> There may be a line that is too long, and there is one case where a
> "MUST not" needs to be replaced with "MUST NOT". Please see the idnits.
> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-multimob-fmipv6-pfmipv6-multicast-03.txt
>

'MUST NOT' is fixed now. The line issue seems to be an artifact of the 
idnits tool - I could not find a too long line, and there is definitely 
no line that is 67 characters in excess of 72.

>
> One thing is unclear to me in 3.3. It says:
>
>     There are two ways to obtain the multicast
>     membership of an MN.  First, MAGs may perform explicit tracking (see
>     [RFC4605], [RFC6224]) or extract membership status from forwarding
>     states at node-specific point-to-point links.  Second, routers can
>     issue a general MLD query at handovers.  Both methods are equally
>
> Are you assuming point-to-point links in this second case? If not,
> then I don't see how the PAR can find out the MNs subscribed groups
> just by doing an MLD query.
>

Yes, in this PMIPv6 case, the MN is always connected via node-specific 
point-to-point links. It is probably irritating that we mention this 
only for the first case. Here comes a rewording:

"  In a proxy mobile IPv6 environment, the MN remains agnostic of
    network layer changes, and fast handover procedures are operated by
    the access routers or MAGs to which MNs are connected via node-
    specific point-to-point links.  The handover initiation, or the re-
    association respectively are managed by the access networks.
    Consequently, access routers need to be aware of multicast membership
    state at the mobile node.  There are two ways to obtain the multicast
    membership of an MN.  First, MAGs may perform explicit tracking (see
    [RFC4605], [RFC6224]) or extract membership status from forwarding
    states at node-specific links. "


> Also wondering if it should be pointed out here that it's not just
> groups. For SSM it would be (S,G) or channels. I see it says
> groups/channels many other places though. It might be worth explaining
> what the term channel means.
>

O.K. - first we added  channels here:

"  The MLD membership
    information then allows the PMAG (PAR) to learn the multicast group/
    channel subscriptions of the MN."

For the general introduction of groups/channels etc. we added the 
following to the introduction:

"  This document specifies extensions to FMIPv6 and PFMIPv6 that include
    multicast traffic management for fast handover operations in the
    presence of any source or source specific multicast.
    ...
    The solution common to both underlying unicast protocols defines the
    per-group or per channel transfer of multicast contexts between ARs
    or MAGs.  The protocol defines corresponding message extensions
    necessary for carrying (*,G) or (S,G) context information independent
    of the particular handover protocol."

Hope this explains it more clearly.



>     applicable.  However, a router that does not operate explicit
>     tracking needs to query its downstream links after a handover.  The
>     MLD membership information then allows the PAR to know the multicast
>     group subscriptions of the MN.
>
>     In predictive mode, the PMAG (PAR) will learn about the upcoming
>     movement of the mobile node.  Without explicit tracking, it will
>     immediately submit a general MLD query and receive MLD reports for
>     the subscribed group(s).  As displayed in Figure 4, it will initiate
>     binding and context transfer with the NMAG (NAR) by issuing a HI
>     message that is augmented by multicast contexts in the mobility
>     options defined in Section 5.3.  NAR will extract multicast context
>     information and act as described in Section 3.1.
>
> In 4.2.2 it says "it MAY need to issue". I don't think this is the
> appropriate use of MAY. It's not like MAY implement, or MAY do
> something. There is no freedom of choice here. Whether it is done or
> not just depends on the situation. I think you could replace "MAY"
> with "will".
>

Yes, I see - it's changed now.


[Length Corrections]

These lengths issues are somewhat historic ... they have been already 
corrected. It is now conformal to the general design of the Multicast 
Mobility Option.

> In 5.3 it says:
>
>     Length: 8-bit unsigned integer.  The size of this option is 8 octets
>     including the Type, Option-Code, and Length fields.
>
> How can this be 8 octets. It looks like 4 octets when including the
> reserved field, and then the total length varies with the size of the
> report payload? But I guess the payload is always at least 4 octets?
>
> In 5.4 it says:
>
>     Length: 8-bit unsigned integer.  The size of this option in 8 octets.
>     The length is 1 when the MLD (IGMP) Unsupported Report Payload field
>     contains no Mcast Address Record.
>
> Should it say "is" like in 5.3, or should 5.4 say "in"? It looks to me
> like the length is 4 if there is no payload. Or is the payload at least
> 4 octets?
>
--------- end of length issues ------------

> In 5.4 it says:
>     that are not supported or prohibited in the new access network.  This
>     field MUST always contain the first header line (reserved field and
>     No of Mcast Address Records), but MUST NOT contain any Mcast Address
>     Records, if the status code equals 1.
>
> Should it say this in 5.3 as well?
>

I don't think so. This context transfer is organised in a 
request/response manner and only the response message (as of 5.4) 
contains a status code. In the request case (as of 5.3), the PAR/PMAG 
just enumerates the multicast context records it wants to transfer.

> It might be good to make the IANA considerations more explicit. It would
> be good to explicitly specify what the new tables look like.
>


Yes, that was also done.

Thanks again! - we will submit a revised version today that will also 
contain the open subject of Georgios (Appendix on mobile sources).

Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: [phone] °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °