Subject: Re: [multimob] multimob@IETF69 Meeting summary

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 1 Aug 2007 14:43:25 -0700 (PDT)

----- Original Message ----
From: Marshall Eubanks <[email-masked]>
To: Thomas C Schmidt <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; [email-masked]
Sent: Wednesday, August 1, 2007 12:49:25 PM
Subject: Re: [multimob] multimob@IETF69 Meeting summary

On Aug 1, 2007, at 1:38 PM, Thomas C Schmidt wrote:

> Hi all,
>
> Marshall Eubanks wrote:
>> On Aug 1, 2007, at 10:51 AM, Behcet Sarikaya wrote:
>>> Let me clarify. Bidirectional tunneling mentioned in Suresh's  
>>> meeting summary refers to the tunnel between MN and HA as in MIP6/ 
>>> HMIP6. There could be Bi-Dir PIM and as Thomas says it could be  
>>> of interest to mobopts. Bi-Dir PIM is not of interest to  
>>> multimob. This is also clear from the meeting summary.
>> Why ? I was at the meeting and I did not get that impression.  
>> Please be specific.
>
> I would not see such differentiation ...
> to make things clear: bidirectional tunneling and bi-dir PIM only  
> share the "bi-directional" in the name - Bi-Dir PIM is not a  
> tunneling protocol.
>

Absolutely correct. It is a means of setting up PIM to pass multicast  
packets to and from a Rendezvous Point. No
tunneling is involved.

> On the other hand, bi-dir PIM is of special interest for source  
> mobility, for receiver mobility it should admit similar behaviour  
> as PIM-SM.

I would also agree here, with the addition that it might also be  
useful when the sources are also receivers (the service model  
basically assumes that nodes will be both).

[behcet] I looked at draft-ietf-pim-bidir-09.txt which is to become an RFC soon. It is about modifying PIM-SM with bidirectional trees. I can see value for us if bidirectional tree (not bidirectional tunnel as I originally thought )  routing will help reduce the latency for the mobile nodes.
So I stand corrected.

Regards
Marshall

>
> Cheers,
>
> thomas
>
>>> ----- Original Message ----
>>> From: Thomas C Schmidt <[email-masked]>
>>> To: Marshall Eubanks <[email-masked]>
>>> Cc: [email-masked]; mobopts <[email-masked]>
>>> Sent: Tuesday, July 31, 2007 6:24:13 PM
>>> Subject: Re: [multimob] multimob@IETF69 Meeting summary
>>>
>>> Hi Marshall,
>>>
>>> Marshall Eubanks wrote:
>>>
>>> >> Three approaches to multicast mobility were discussed
>>> >>
>>> >> * Remote Subscription
>>> >> * Bidirectional tunneling
>>> >
>>> > I suspect this could be done using Bi-Dir PIM more or less as  
>>> is. There
>>> > would have to be changes to support
>>> > SSM, and Bi-Dir has never been made interdomain, but neither  
>>> should be
>>> > that difficult in IPv6.
>>> >
>>> > If anyone is interested in exploring this, please let me know.
>>> >
>>> This remark on source-mobility agnostics of Bi-Dir PIM we already
>>> started to discuss in MOBOPTS, cf.
>>> http://tools.ietf.org/html/draft-irtf-mobopts-mmcastv6-ps ... and we
>>> started keeping an eye on it a while ago: it's really interesting!
>>>
>>> And yes, we are looking at this and are interested in working a way
>>> further down there ...
>>>
>>> For the moment I personally doubt, though, that Bi-Dir can easily be
>>> extended to scale beyond domains.
>>>
>>> Anyway, Bi-Dir PIM can at least be embedded in (mobility-agnostic)
>>> hybrid approaches, cf.
>>> http://samrg.org/about/meetings/ietf69/mw69-foilsV2.pdf
>>>
>>> Cheers,
>>>
>>> thomas
>>> -- 
--behcet

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

---

From: "Bryan McLaughlin \(brmclaug\)" <[email-masked]>
Date: Thu, 2 Aug 2007 08:51:12 +0200

Apologies for the late reply

Please remember my comments regarding  state persistence after a host
moves. 

Bryan 
 
-----Original Message-----
From: Suresh Krishnan [mailto:[email-masked]] 
Sent: 31 July 2007 23:24
To: [email-masked]
Subject: [multimob] multimob@IETF69 Meeting summary

Hi Folks,
   Here is a summary of the multimob meeting we had at IETF69. It is a
subjective view of what happened at the meeting. Let me know if you have
any issues, comments, or corrections.

multimob@IETF69 Summary
=======================
The goal of the bar BOF was to identify the problems that need to be
solved in the near future. The secondary goal of the bar BOF was to
identify the working groups in the IETF that can do the work (if any). 
The attendance for the bar BOF was as expected (27 people) covering
researchers, implementers and operators. The problem statements were
presented. The presentations were followed, and sometimes interrupted,
by related discussions.

* Remote Subscription
* Agent based

Some of the people in the meeting believed that the problems to be
solved need to be defined by the operator (The majority,I believe). 
There were other vocal critics who believed that this is not the right
approach to follow since the operators typically lag behind in
multicast.

After the ensuing discussions, it became clear that the problems that
need to be solved are the following

* Receiver mobility
   Issues due to latency
   * join latency - can be fixed with link layer indicators
   * leave latency - much harder to fix, may require changes to MLD,PIM

* SSM issues with mobility

Problems which are out of scope for now

* Sender mobility

These problems can theoretically be solved by extensions to existing
unicast mobility protocols like {,f,h,p}mipv6 and extensions to
multicast protocols like MLD and pmip6.

Conclusion
==========
We need to put in further effort to investigate if these fall under the
charter of current working groups or not. We also need to come up with a
collective list of requirements to work on. Further work will be done on
the mailing list.

Cheers
Suresh