Subject: [multimob] review of draft-ietf-multimob-pmipv6-base-solution

From: Jari Arkko <[email-masked]>
Date: Thu, 24 Jun 2010 12:52:51 +0300

I have read this draft. Here are my comments.

Overall, I think the spec is in good shape and should move forward. A
couple of relatively minor issues and questions below, however:

With these entities in place, the mobile node loses transparent end-
to-end connectivity to the static Internet, and in the particular
case of multicast communication, group membership management as
signaled by the Multicast Listener Discovery protocol (MLD)
[RFC3810], [RFC2710] requires dedicated treatment at the network
side, see [I-D.deng-multimob-pmip6-requirement].

The loss of transparenet e2e connectivity is a strong claim. What basis
is there for making this statement? Its not like there is a NAT on the
path, or if the mobile node would be prevented from sending some
packets. I do agree though that group membership management requires
care. Also, perhaps the reference to the draft can be moved to an
acknowledgment section as prior work, since you do describe the issues
yourself later in the document.

It therefore needs to
implement an instance of the MLD proxy function [RFC4605] for each
upstream tunnel interface that has been established with an LMA.

4.4. IPv4 Support

Question: Are there any special things that you have to take care of
for overlapping IPv4 address space situations and GRE-keyed tunnels?

7. A Note on Explicit Tracking

IGMPv3/MLDv2 [RFC3376], [RFC3810] may operate in combination with
explicit tracking, which allows routers to monitor each multicast
receiver. This mechanism is not standardized yet, but widely
implemented by vendors as it supports faster leave latencies and
reduced signaling.

Enabling explicit tracking on downstream interfaces of the LMA and
MAG would track a single MAG and MN respectively per interface. It
may be used to preserve bandwidth on the MAG-MN link.

This does not tell me what explicit tracking is. Is there any reference
that could be used here? If there is no clear description of the what
explicit tracking is, perhaps this part should not be in the document.

At the MAG, MLD queries and multicast data will arrive on the
(tunnel) interface that is assigned to a group of access links as
identified by its Binding Update List (cf., section 6 of [RFC5213]).

Does this specification handle the case of multicast traffic
originating from the mobile host? If not, please state so.

Jari

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 24 Jun 2010 12:30:17 +0200

Hi Jari,

thanks for reviewing - please see answers inline:

On 24.06.2010 11:52, Jari Arkko wrote:
>>     [RFC3810  <http://tools.ietf.org/html/rfc3810>], [RFC2710  <http://tools.ietf.org/html/rfc2710>] requires dedicated treatment at the network
>>     side, see [I-D.deng-multimob-pmip6-requirement  <http://tools.ietf.org/html/draft-ietf-multimob-pmipv6-base-solution-03#ref-I-D.deng-multimob-pmip6-requirement>].
>>
>

The "loss of transparent e2e connectivity"-argument is referring to the 
setup that the MAG (tunnel entry) introduces a routing hop in 
situations, were the LMA architecturally acts as the next hop (or 
designated) router for the MN. This plays the particular role mentioned 
in MLD signaling (but may be relevant in other situations).

Suggestion for clarification/improvement:

    "With these entities in place, the mobile node loses transparent end-
     to-end connectivity to the static Internet in the sense that the MAG
     introduces a routing hop also in situations, were the LMA 
architecturally acts
     as the next hop (or designated) router for the MN. In the particular
     case of multicast communication, group membership ... "

As for the draft reference: This was only to indicate that some 
requirements-work has been done. We will move it to the acknowledgment.

>
>> It therefore needs to
>>     implement an instance of the MLD proxy function [RFC4605  <http://tools.ietf.org/html/rfc4605>] for each
> Question: Are there any special things that you have to take care of for
> overlapping IPv4 address space situations and GRE-keyed tunnels?
>

Good point: we will have to think about this and will be back on the 
question later.

>>     IGMPv3/MLDv2 [RFC3376  <http://tools.ietf.org/html/rfc3376>], [RFC3810  <http://tools.ietf.org/html/rfc3810>] may operate in combination with

Explicit tracking is discussed in "A.2. Host Suppression" of RFC 3810 
(MLDv2). However, it is not a standardized procedure and I agree that 
the term is somewhat colloquial. We will review the exact wording and 
propose a more concise formulation in the following mail.

The technique of explicit multicast state tracking at routers 
facilitates a fast reaction of routers on state changes (without 
querying), which is useful (not only) in mobile regimes and actually 
used a lot in deployed systems. This is why we felt it is important to 
mention.

>>     identified by its Binding Update List (cf.,section  6 of [RFC5213]  <http://tools.ietf.org/html/rfc5213#section-6>).
>>
> Does this specification handle the case of multicast traffic originating
> from the mobile host? If not, please state so.

No, it doesn't according to the current Multimob charter. We will add 
the straight-forward statement in the abstract and the introduction.

Thanks,

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: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 25 Jun 2010 10:22:57 +0900 (JST)

Hi Thomas and Jari,

> propose a more concise formulation in the following mail.

RFC3376 also mentions "track per-host membership status" and "explicit
membership tracking".
The word of "explicit tracking function" has been specified in my
IGMP/MLD optimization draft and its primary draft
igmp-mld-mobility-extensions-01 published in July 14, 2008.
It is not a good idea to use different words meaning the same
function. Moreover, this PMIP base solution draft does not have a
mission to define IGMP/MLD related function or wording.
Therefore I recommend to keep the word as is and refer the RFC or my
draft.

Regards,
--
Hitoshi Asaeda

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 25 Jun 2010 16:11:36 +0200

Hi Jari,

now we are back on the remaining open issues:

> overlapping IPv4 address space situations and GRE-keyed tunnels?

You are referring to RFC5845 here and the scenario in which overlapping 
private address spaces of different operators can be hosted in a PMIP 
domain by using GRE encapsulation with key identification. This scenario 
implies that unicast communication in the MAG-LMA tunnel can be 
individually identified per MN by the GRE keys.

This looks like an issue for multicast, but IMHO is not for the 
following reasons:

   MLD/IGMP signaling between MNs and the MAG is on point-to-point links 
(identical to unicast).

   Aggregated MLD/IGMP signaling between the MAG proxy instance and the 
LMA is link-local between the routers and independent of an individual 
MN. So the MAG-proxy and the LMA would not use GRE key identifiers, but 
plain GRE encapsulation to exchange MLD queries and reports.

   Similarly, multicast traffic sent from LMA to MAG is a 
router-to-router forwarding according to the MFIB of the LMA, 
independent of MN unicast addresses, while the MAG proxy instance 
distributes multicast data down the point-to-point links (interfaces) 
according to its MFIB, independent of MN's IP addresses.

   The question remains in a multi-operator scenario, where the LMA 
pulls multicast traffic from, i.e., how multicast traffic is routed to 
the LMA. This could be Operator-A, Operator-B or a third party. However, 
this backbone routing in general is out of scope of the document, and 
most likely more a matter of contracts.

We will add this explanation and the reference to RFC5845 to the draft.

> explicit tracking is, perhaps this part should not be in the document.

Also following the comment of Hitoshi, we would suggest to just add the 
references to RFC3376 and RFC3810.

Does this clarify / resolve the issues?

Best regards,

Thomas

--