Subject: [multimob] 答复: multimob Digest, Vol 62, Issue 21

From: [email-masked]
Date: Mon, 30 Jul 2012 10:27:52 +0800

Hi Luis,
Many thanks for your comments and we are very sorry for the late 
reply,please see answers inline:

[email-masked] 写于 2012/07/27 18:15:22:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to 
> 
> https://www.ietf.org/mailman/listinfo/multimob
> 
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
> 
> 
> 
> Send multimob mailing list submissions to
>    [email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/multimob
> or, via email, send a message with subject or body 'help' to
>    [email-masked]
> 
> You can reach the person managing the list at
>    [email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of multimob digest..."
> 
> 
> Today's Topics:
> 
>    1.  Comments on draft-liu-multimob-pmipv6-multicast-ro-01
>       (LUIS MIGUEL CONTRERAS MURILLO)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Fri, 27 Jul 2012 12:15:16 +0200
> From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [multimob] Comments on
>    draft-liu-multimob-pmipv6-multicast-ro-01
> Message-ID:
>    <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Dear Juan, Wen, Wei,
> 
> Please, find here below some comments on your draft.
> 
> 1/ You propose the MAGs to be multicast enabled routers. However, to
> enabling the solution you propose to set-up a tunnel among the MAGs 
> where the source and the listener are attached to. Why do you need 
> such tunnel? Why the communication cannot be directly routed without
> any additional tunnel (assuming the domain is multicast enabled)? In
> fact the tunnel probably will follow the same path as the PIM 
> messages would follow.
I think that depends on how the MRIB is generated. In our draft,the 
MAG-MAG tunnel needs to be included into the MRIB.
Otherwise,source-specific Join message will follow the LMA-MAG tunnel to 
the source.
> 
> 2/ When you describe the establishment of bidirectional tunnels 
> between MAGs you refer RFC5213 for further detail, but RFC5213 does 
> not include tunnel establishment between MAGs. This is not covered 
> by standard PMIP (it implies an extension).
You are right that RFC5213 does not include tunnel establishment between 
MAGs.we will correct the description in the next version.
we can refer to section6.2 of draft-ietf-netext-pmip-lr for tunneling 
between the MAGs.
> 
> 3/ For the mobile node operation you are restricting the 
> optimization proposal to the case where the listener is an SSM-aware
> host. In my opinion this restricts the solution, not being generic 
> (ASM case is not covered)
You are right that our solution should cover the ASM scenario,we have 
planned to add it in the next version.
In the phase three of PIM-SM(ASM Scenario),when the MAG on the receiver's 
side initiates a transfer from the shared tree to a source-specific 
shortest-path tree,the solution can be used in this phase to reestablish 
the optimized SPT.
> 
> 4/ Through the PBU-Q/PBA-Q sequence of messages you are able to 
> obtain the CoA for the MN source. However, how do you know in 
> advance that the MN source is attached to the domain? There is no 
> way of knowing it in advance, and because the MN HoA is not an 
> address of the PMIPv6 domain, how do you deduce that it is a MN 
> source? Do you send the PBU-Q for all kind of SSM subscriptions? 
> Additionally, what happens (what is the message) in case the source 
> is effectively not attached to the PMIPv6 domain
Yes,we can not know in advance that the MN source is attached to the same 
domain.So if the MAG in the listener side figures(through the PBU-Q/PBA-Q 
messages) that the MN source is not attached to a MAG in the domain, it 
will process the multicast message as normal.
We send the PBU-Q every time when the MAG in the listener side first joins 
the (S,G) channel.
We don't solve the case when the source is not attached to the PMIPv6 
domain, the draft assumes that the MN source and MN listener are both 
mobile nodes attached to their own MAG.
> 
> Finally, as a minor comment, the heading of the txt file mention 
> "RELOAD Client Extension", which is not the subject of the draft.
Thank you for pointing out this,it's our negligence,we will correct it in 
the next version.

More comments are very welcomed!
BR,
Juan
> 
> Best regards,
> 
> Luis
> 
> _____________________________
> Luis M. Contreras
> Technology / Global CTO / Telef?nica
> Efficiency Projects / Telef?nica I+D
> 
> Don Ram?n de la Cruz 82-84
> 28006 Madrid
> Espa?a / Spain
> 
> [email-masked]
> 
> 
> ________________________________
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra pol?tica de env?o y recepci?n de correo electr?
> nico en el enlace situado m?s abajo.
> This message is intended exclusively for its addressee. We only send
> and receive email on the basis of the terms set out at
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/multimob/attachments/20120727/decb0cc9/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
> 
> 
> End of multimob Digest, Vol 62, Issue 21
> ****************************************
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Sun, 29 Jul 2012 20:19:54 -0700 (PDT)

Hi,

> Otherwise,source-specific Join message will follow the LMA-MAG tunnel to 

At first, all scenarios related to PIM-capable MAG are described in;
http://tools.ietf.org/html/draft-asaeda-multimob-pmip6-extension-10

I'd say people who are interested in the optimized solution done by
PIM-callable MAG had better read above draft.

> we can refer to section6.2 of draft-ietf-netext-pmip-lr for tunneling 

See M-tunnel configuration described in section 4 of above draft.

> shortest-path tree,the solution can be used in this phase to reestablish 

If the standard PIM-SM is supported by the proposed solution, RPT-SPT
switch must be dependent on PIM-SM itself. In other words, it is not
necessary to change the standard PIM-SM behavior for RPT-SPT switch.

> mobile nodes attached to their own MAG.

I don't understand why other query message (except IGMP/MLD query) is
needed.

Regards,
--
Hitoshi Asaeda

---

From: [email-masked]
Date: Mon, 30 Jul 2012 13:17:09 +0800

Hi Hitoshi,
Please see answers inline:

> PIM-callable MAG had better read above draft.
Yes,the scenarios in our draft are related to PIM-capable MAG.But the 
optimized solution is different from yours.
> See M-tunnel configuration described in section 4 of above draft.
There can be vavious tunnel negotiation mechanisms between MAG,better 
based on existing mechanism.
> necessary to change the standard PIM-SM behavior for RPT-SPT switch.
By doing this,we can establish a optimized SPT instead of a LMA-MAG 
tunnel(towards the MN source) based SPT.
> I don't understand why other query message (except IGMP/MLD query) is
The query message in our solution is used to locate the MN source in the 
PMIPv6 domain.
BR,
Juan Liu

---

From: Hitoshi Asaeda <[email-masked]>
Date: Mon, 30 Jul 2012 09:35:40 -0700 (PDT)

Hi,

> based on existing mechanism.

Does your draft assume MAG acts as MLD proxy for remote subscription
and also acts as PIM router for local routing?

> The query message in our solution is used to locate the MN source in the 

Then I may ask the same question Luis did.
Does this extension properly work with moving source?

Regards,
--
Hitoshi Asaeda

---

From: [email-masked]
Date: Tue, 31 Jul 2012 09:41:39 +0800

Hi Hitoshi,
Thank you for your comments,please see answers inline:

> and also acts as PIM router for local routing?
Our draft does't put any assumption on remote subscription and local 
routing.
MAG acts as PIM router in our solution.
> Does this extension properly work with moving source?
Please see above answer for Luis's question.
This extension can work with source mobility, you can refer to the link 
below to have a rough knowledge on how it works: 
http://www.ietf.org/id/draft-liu-multimob-pmipv6-multicast-ro-02.txt
Details will be included in the next version.
BR,
Juan Liu