Subject: Re: AW: [multimob] comments on draft-von-hugo-multimob-agents

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 16 Oct 2007 12:41:21 -0700 (PDT)

My comments inline.

Regards,

Behcet

----- Original Message ----
From: "Von-Hugo, Dirk" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Tuesday, October 16, 2007 4:09:18 AM
Subject: AW: [multimob] comments on draft-von-hugo-multimob-agents

<!--

_filtered {font-family:Batang;panose-1:2 3 6 0 0 1 1 1 1 1;}
_filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
_filtered {panose-1:2 3 6 0 0 1 1 1 1 1;}
_filtered {margin:70.85pt 70.85pt 2.0cm 70.85pt;}
_filtered {font-family:Batang;panose-1:2 3 6 0 0 1 1 1 1 1;}
_filtered {panose-1:2 3 6 0 0 1 1 1 1 1;}
_filtered {margin:70.85pt 70.85pt 2.0cm 70.85pt;}

 _filtered {font-family:Batang;panose-1:2 3 6 0 0 1 1 1 1 1;}
 _filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}
 _filtered {panose-1:2 3 6 0 0 1 1 1 1 1;}
/* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;text-decoration:underline;}
p
	{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:"Times New Roman";}
pre
	{margin:0cm;margin-bottom:.0001pt;font-size:10.0pt;font-family:"Courier New";}
span.emailformatvorlage17
	{font-family:Arial;color:navy;}
span.emailformatvorlage20
	{font-family:Arial;color:navy;}
span.EmailFormatvorlage21
	{font-family:Arial;color:navy;}
 _filtered {margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.Section1
	{}
-->

Dear Behcet,

you are right that [9]
mainly describes the MLD proxying within the NEMO and I should have instead
pointed to the draft referenced there as [1] where MLD proxy is introduced (the
later RFC 4605 on 'IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')’) 

>>OK, agreed, maybe [1] is a better reference in this case.

but within [9] already the MR tunnel was introduced by saying 

   ‘If the mobile
network moves to a foreign link where multicast is

   not supported, MR can
still maintain ongoing multicast sessions by

   performing re-subscription
to the group, with MLD Report messages,

   through the MR-HA bi-directional
tunnel.  Several approaches can be

   envisaged for the
multicast support on the HA.  It can be

   configured as a
multicast router, or simply as an MLD-proxy.’

Sorry, DMA in Fig. 1 is a
typo – it should read more generally MAA for Multicast Anchor Agent (expression
DMA for Dynamic Multicast Agent is introduced in draft-zhang-mipshop-multicast-dma-03.txt).

MAA may be a DMA or the
HA or a future AR – the decision is made based on criteria as most
efficient routing paths or less tree re-construction effort etc.

>>If MR moves to another AR then this is a good time to change MAA. If MR's rate of change becomes high then change to HA with RS. 

So maybe a more rigid text can be written for the decision algorithm?

 The problem is if MR does not move. Is there a good reason to change MAA?

Kind regards

Dirk 

-----Ursprüngliche Nachricht-----

Von: Behcet Sarikaya
[mailto:[email-masked]] 

Gesendet: Dienstag, 16. Oktober
2007 01:10

An: von Hugo, Dirk;
[email-masked]

Betreff: [multimob] comments on
draft-von-hugo-multimob-agents

Hi
Dirk,

  Regarding Reference 9 in your draft, you said:

Corresponding multicast traffic received at the MAA is subsequently 

   forwarded by the MAA back to the MR via the bi-directional tunnel.

   This MLD-proxy functionality has been described for the HA as MAA
in 

   [9].

However, in [9], MLD-proxy functionality is defined for routing multicast
traffic inside NEMO in case where MNNs are more than one hop away from MR.

In Fig. 1, you have:

     |      Decision on new MCR
(DMA)  |

what is the difference between an AR and a DMA? Is DMA another AR? How is the
decision made?

Regards,

Behcet

-----
Original Message ----

From: "Von-Hugo, Dirk" <[email-masked]>

To: [email-masked]

Sent: Monday, October 15, 2007 2:20:37 AM

Subject: AW: AW: [multimob] FW: comments on the BOF proposal

Dear all,

 just to inform you that my already announced draft is now officially available at http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt

Agent-based multicast support for moving networks (NEMO)

Best regards

Dirk

 

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

---

From: "Von-Hugo, Dirk" <[email-masked]>
Date: Wed, 17 Oct 2007 14:52:09 +0200

Please see inline

Sincerely

Dirk

-----Ursprüngliche Nachricht-----
Von: Behcet Sarikaya [mailto:[email-masked]] 
Gesendet: Dienstag, 16. Oktober 2007 21:41
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: AW: [multimob] comments on draft-von-hugo-multimob-agents

My comments inline.

Regards,

Behcet

----- Original Message ----
From: "Von-Hugo, Dirk" <[email-masked]>
To: [email-masked]; [email-masked]
Sent: Tuesday, October 16, 2007 4:09:18 AM
Subject: AW: [multimob] comments on draft-von-hugo-multimob-agents

Dear Behcet,

you are right that [9] mainly describes the MLD proxying within the NEMO and I should have instead pointed to the draft referenced there as [1] where MLD proxy is introduced (the later RFC 4605 on 'IGMP/MLD-based Multicast Forwarding ('IGMP/MLD Proxying')') 

>>OK, agreed, maybe [1] is a better reference in this case.

DH: I will change this in version 01 

   'If the mobile network moves to a foreign link where multicast is

   not supported, MR can still maintain ongoing multicast sessions by

   performing re-subscription to the group, with MLD Report messages,

   through the MR-HA bi-directional tunnel.  Several approaches can be

   envisaged for the multicast support on the HA.  It can be

   configured as a multicast router, or simply as an MLD-proxy.'

Sorry, DMA in Fig. 1 is a typo - it should read more generally MAA for Multicast Anchor Agent (expression DMA for Dynamic Multicast Agent is introduced in draft-zhang-mipshop-multicast-dma-03.txt).

MAA may be a DMA or the HA or a future AR - the decision is made based on criteria as most efficient routing paths or less tree re-construction effort etc.

>>If MR moves to another AR then this is a good time to change MAA. If MR's rate of change becomes high then change to HA with RS. 

DH: It depends - changing to a new MAA after each move to a new AR should be avoided. E.g. in case the new AR is only a few hops away from the old a tunnel between old AR  as MAA and the MR via the new AR may be more efficient, especially if there are other subscribers to same MC groups present at old AR. 

DH: Similarly - if all other subscribers at the current AR move to a new one it may be more efficient also fort he static MR to change MAA to that new AR - because of the plurality of subscriptions.

DH: However I have to admit that we had in mind also MC transmissions from the MR, where a tree update means much more effort - for pure MC listeners this may no more hold true.  

Kind regards

Dirk 

-----Ursprüngliche Nachricht-----
Von: Behcet Sarikaya [mailto:[email-masked]] 
Gesendet: Dienstag, 16. Oktober 2007 01:10
An: von Hugo, Dirk; [email-masked]
Betreff: [multimob] comments on draft-von-hugo-multimob-agents

Hi Dirk,
  Regarding Reference 9 in your draft, you said:
Corresponding multicast traffic received at the MAA is subsequently 
   forwarded by the MAA back to the MR via the bi-directional tunnel. 
   This MLD-proxy functionality has been described for the HA as MAA in 
   [9].
However, in [9], MLD-proxy functionality is defined for routing multicast traffic inside NEMO in case where MNNs are more than one hop away from MR.

In Fig. 1, you have:
     |      Decision on new MCR (DMA)  |
what is the difference between an AR and a DMA? Is DMA another AR? How is the decision made?

Regards,

Behcet

----- Original Message ----
From: "Von-Hugo, Dirk" <[email-masked]>
To: [email-masked]
Sent: Monday, October 15, 2007 2:20:37 AM
Subject: AW: AW: [multimob] FW: comments on the BOF proposal

Dear all,

just to inform you that my already announced draft is now officially available at http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt <http://ietfreport.isoc.org/all-ids/draft-von-hugo-multimob-agents-00.txt> 

Best regards

Dirk

---

From: Matthias Waehlisch <[email-masked]>
Date: Thu, 18 Oct 2007 13:26:22 +0200

Hi Dirk,

  some quick comments on your draft:

  In the abstract you mentioned, that the draft "describes an approach to 
support mobile IPv6 multicast listeners and senders located within a 
moving network (NEMO)." Why have to be the senders and listeners MIPv6 
aware? As far as I understand, your suggestion does not require this 
assumption. You are not looking at dedicated moving nodes, you are looking 
at the network.

  In section 2.1 is said, that "Advantage of this approach is that the 
access network infrastructure is less affected by required update of 
functionality." Can you elaborate that?

On Wed, 17 Oct 2007, Von-Hugo, Dirk wrote:

> Sorry, DMA in Fig. 1 is a typo - it should read more generally MAA for 
> Multicast Anchor Agent (expression DMA for Dynamic Multicast Agent is 
> introduced in draft-zhang-mipshop-multicast-dma-03.txt).
> 
  Than you have to remove NEMO-HA and AR, because they can also be a MAA. 
Nevertheless I don't understand in detail the meaning of figure 1.

  You want to sketch the message flow between NEMO-MR and MAA. I think 
that the transition from HA to another MAA is sufficient, as every other 
change of decision should show the same. Btw: You should not send a "MLD 
done", if you refer to MLDv2. It's just for backward compatiblity. And you 
should introduce MCR, which means probably Multicast router... Why does 
the NEMO-MR send a MLD query to the DMA/MAA?

  And the last question: How does the NEMO-MR know to switch sending 
multicast data from, e.g. in fig. 1, NEMO-HA to AR? It's not obviously 
uninterruptible.

Cheers
  matthias
  
--
Matthias Waehlisch
:. HAW Hamburg, Dept. Informatik        :. link-lab
:. Berliner Tor 7, 20099 Hamburg        :. Hoenower Str. 35, 10318 Berlin
:. Germany, mailto:[email-masked]   :. Germany, mailto:[email-masked]
:. http://home.fhtw-berlin.de/~mw       :. http://www.link-lab.net

---

From: "Von-Hugo, Dirk" <[email-masked]>
Date: Thu, 18 Oct 2007 16:21:40 +0200

Dear Matthias,
thank you for the comments. See my responses inline - hope that clarifies:

Kind regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: Matthias Waehlisch [mailto:[email-masked]] 
Gesendet: Donnerstag, 18. Oktober 2007 13:26
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents

Hi Dirk,

DH: you are right - I should have said
"describes an approach to support multicast listeners and senders located within a moving IPv6 network (NEMO)."

DH: The idea is to bind this mobile multicast feature to the MR functionality instead of the need to update every AR in any network with the intelligence to decide on best suited MAA. That is the approach followed in draft-zhang-mipshop-multicast-dma-03.txt.

DH: Exactly - or I may remove MAA completely from the figure which should visualise potential MAA changes during MR movement and say in an explanatory text that MAA functionality will change between NEMO-HA and AR and any other properly suited entity.

DH: I'll check this and introduce the acronym. MLD query is used to learn about current subscription status at potential MAA to re-use existing Multicast subscriptions and to derive the distance between MR and MAA for decision on best suited MAA.

DH: I hope I understood the questions correctly: In case the MR does not move for a long enough time period (e.g. when a train stops at the station) it decides to switch to AR as MAA to follow remote subscription mode because then routing is optimised. Of course in this case the old multicast tree with NEMO-HA as root has to be re-constructed and replaced by a new tree with AR as root. Advantage of the switch has to exceed the disadvantage due to potential data loss and time delay during this process. That is a challenge which still has to be solved ... 

Cheers
  matthias

---

From: Matthias Waehlisch <[email-masked]>
Date: Fri, 19 Oct 2007 12:42:21 +0200

Hi Dirk,

On Thu, 18 Oct 2007, Von-Hugo, Dirk wrote:

> done", if you refer to MLDv2. It's just for backward compatiblity. And 
> you should introduce MCR, which means probably Multicast router... Why 
> does the NEMO-MR send a MLD query to the DMA/MAA?
> 
> DH: I'll check this and introduce the acronym. MLD query is used to 
> learn about current subscription status at potential MAA to re-use 
> existing Multicast subscriptions and to derive the distance between MR 
> and MAA for decision on best suited MAA.
> 
  Yes, but maybe you can write something in the draft about the tradeoff 
between distance, subscription state and handover rate. You should also 
explain, why the MR does not send a MLD query to the AR in the figure.

Cheers
  matthias
 
-- Matthias Waehlisch :. HAW Hamburg, Dept. Informatik        :. link-lab
:. Berliner Tor 7, 20099 Hamburg        :. Hoenower Str. 35, 10318 Berlin
:. Germany, mailto:[email-masked]   :. Germany, mailto:[email-masked]
:. http://home.fhtw-berlin.de/~mw       :. http://www.link-lab.net

---

From: "Von-Hugo, Dirk" <[email-masked]>
Date: Thu, 25 Oct 2007 15:28:52 +0200

Dear all,
today I have submitted an update of the draft incorporating most of your issues - I hope.
As I will be out of office the next 3 weeks I surely will not be able to work on this topic until IETF-70 deadline.
Until it is published officially you may find version 01 at http://www3.ietf.org/proceedings/staging/draft-von-hugo-multimob-agents-01.txt 

Best regards
Dirk 

-----Ursprüngliche Nachricht-----
Von: Matthias Waehlisch [mailto:[email-masked]] 
Gesendet: Freitag, 19. Oktober 2007 12:42
An: von Hugo, Dirk
Cc: [email-masked]
Betreff: Re: AW: AW: AW: [multimob] comments on draft-von-hugo-multimob-agents

Hi Dirk,

Cheers
  matthias