Re: [multimob] Comments on draft-liu-multimob-pmipv6-multicast-ro-01(JUAN LIU)

[[e-mail]]

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

[e-mail] 写于 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
>    [e-mail]
> 
> 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
>    [e-mail]
> 
> You can reach the person managing the list at
>    [e-mail]
> 
> 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 <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Subject: [multimob] Comments on
>    draft-liu-multimob-pmipv6-multicast-ro-01
> Message-ID:
>    <[e-mail]>
> 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
> 
> [e-mail]
> 
> 
> ________________________________
> 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
> [e-mail]
> 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.