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

From: Jari Arkko <[email-masked]>
Date: Mon, 05 Jul 2010 10:31:30 +0300

Thomas,

>>>     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  <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 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.
>>
>
> 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 ... "

OK

(Though I must say that if I was writing this, I would probably just 
talk about the actual effect and leave the term transparent end-to-end 
connectivity out.)

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

OK

>
>>
>>> It therefore needs to
>>>     implement an instance of the MLD proxy function [RFC4605  
>>> <http://tools.ietf.org/html/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?
>>
>
> Good point: we will have to think about this and will be back on the 
> question later.
>
>
>>>
>>>       7. A Note on Explicit Tracking
>>>
>>>
>>>
>>>     IGMPv3/MLDv2 [RFC3376  <http://tools.ietf.org/html/rfc3376>], 
>>> [RFC3810  <http://tools.ietf.org/html/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.
>>
>
> 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.

OK, but then make this draft have some pointer for further information.

>>>     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]  <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.

OK

Jari

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 08 Jul 2010 10:06:08 +0200

Hi Jari,

many thanks for the feedback.

> talk about the actual effect and leave the term transparent end-to-end

Then let's weaken the statement. How about

  "With these entities in place, the mobile node experiences an 
exceptional
   access topology towards 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 ... "

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: Jari Arkko <[email-masked]>
Date: Thu, 08 Jul 2010 13:06:24 +0300

Thomas,

>   In the particular case of multicast communication, group membership 

Good. Thanks.

Jari