Subject: Re: [pim] pim Digest, Vol 111, Issue 13

From: Javed Asghar <[email-masked]>
Date: Fri, 16 Aug 2013 17:21:22 -0700

Hi Bharat,

Thanks, we'll proceed to the next stage.
Please comments inline.

Cheers,
-Javed.

On 7/23/2013 4:55 AM, [email-masked] wrote:
> 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/pim
>
> 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 pim mailing list submissions to
> 	[email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/pim
> 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 pim digest..."
>
>
> Today's Topics:
>
>     1. Draft 'Explicit RPF Vector' (Bharat Joshi)
>     2. Re: Draft submission on MLD with multiple upstreams
>        (LUIS MIGUEL CONTRERAS MURILLO)
>     3. Re: Draft submission on MLD with multiple upstreams (Bharat Joshi)
>     4. Re: Draft submission on MLD with multiple upstreams
>        (LUIS MIGUEL CONTRERAS MURILLO)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 Jul 2013 10:09:43 +0000
> From: Bharat Joshi <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [pim] Draft 'Explicit RPF Vector'
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="Windows-1252"
>
> Hi Authors,
>
>         I read through this draft. I think its ready to more to the next stage. However I have some small questions/suggestions below.
>
> Regards,
> Bharat
>
> ? In Introduction, last para, "that the Explicit RPF Vector join may" -> "that the PIM join may"

JA>>> ok.

>
> ? In section 8, as mentioned before, metric may not be zero. Even then do we not want to use metric here? BTW, I wanted to understand why do you want to give special mention for this here. Even if metric is zero, PIM assert uses preference and IP address as well so whether we use metric or not, the outcome will remain same. Or am I missing something here?

JA>>> This is standard behavior and nothing different. This was not so 
necessary at all but we added this "only" based on your insistence for 
completeness, I'll correct the wording to avoid confusing interpretation 
if any.

>
> ? In section 8, in following sentence:
>
> There is minor behavioral difference, the routing protocol's Metric that is included in the PIM Assert should be taken from the first Explicit vector in the list.
>
>         Did you mean 'route metric' instead of routing protocol's Metric here. Also, sentence seems to suggest that routing protocol metric is available in the Explicit vector in the list. Can you please reword it accordingly?
>
> ? How does PIM prune override works? If override is supported, will all PIM routers that have joined a group will override this prune. I checked RFC 5384 and that does not mention this.
>
> ? Section 10, in title, 'Explicit Vector' -> 'Explicit RPF Vector'. Please fix this in the text of this section as well.

JA>>> ok

>
> ? Please read through Section 10 once. There is some conflict coming the way third sentence is framed. The second sentence using 'will not be able to remove' does not look correct.

JA>>> No, I really disagree. Its looks fine to me in the context. Your 
comments are inconsistent. We had changed this very early based on your 
comments and then there was no more issue raised after the change by 
you. Its coming back again after long time.

As the author I feel the WGLC adoption is getting stalled unfairly.

>
> ? In section 12, "the RPF Vector attribute" -> "the Explicit RPF Vector attribute"

JA>>> ok.

>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 23 Jul 2013 10:46:28 +0000
> From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
> To: Bharat Joshi <[email-masked]>, "[email-masked]"
> 	<[email-masked]>
> Cc: "Zuniga, Juan Carlos \([email-masked]\)"
> 	<[email-masked]>
> Subject: Re: [pim] Draft submission on MLD with multiple upstreams
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset=iso-8859-1
>
> Hi Bharat,
>
> Sorry for my late response. Regarding your two questions on the topic:
>
>> 1. Something similar already exist and being used by the operators. Are we trying to standardize this?
> Having more than one upstream interface for IGMP/MLD proxy is not standard today. As you mention, if this feature is something being used today through some proprietary mechanism, this reveals the interest on the topic. Network operators definitely support standard solutions rather that proprietary mechanism. So, in my opinion, it is worthy to work on an standard solution for this. In draft-contreras-pim-multiple-upstreams-00 there are a number of potential scenarios of usage for this feature. Probably some others can be identified and added.
>
>> 2. As this is device specific, won't a simple configuration is enough? The configuration could be vendor specific as there is no protocol interaction required. As far as I know, this is exactly what some of the vendors that implement this, used.
> There are existing proposal for automating the upstream selection process, as described in section 5.1 of draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also susceptible of such dynamic selection.
>
> Best regards,
>
> Luis
>
>
> -----Mensaje original-----
> De: Bharat Joshi [mailto:[email-masked]]
> Enviado el: lunes, 08 de julio de 2013 13:05
> Para: LUIS MIGUEL CONTRERAS MURILLO; [email-masked]
> CC: Zuniga, Juan Carlos ([email-masked])
> Asunto: RE: Draft submission on MLD with multiple upstreams
>
> Hi,
>
>         I had posted some general question on this work. Its available in the message http://www.ietf.org/mail-archive/web/pim/current/msg02696.html
>
>         Now that there are three docuemtns resolving the same problem, I request all the authors to reply to my questions.
>
> Regards,
> Bharat
> ________________________________________
> From: [email-masked] [[email-masked]] on behalf of LUIS MIGUEL CONTRERAS MURILLO [[email-masked]]
> Sent: Monday, July 08, 2013 3:36 PM
> To: [email-masked]
> Cc: Zuniga, Juan Carlos ([email-masked])
> Subject: [pim] Draft submission on MLD with multiple upstreams
>
> Dear all,
>
> This is to announce that the draft-contreras-pim-multiple-upstreams have been already submitted to the PIM WG as mentioned during the last IETF meeting  in Orlando. This draft was originally submitted to the multimob WG but presented to the PIM WG as well during the last two IETF meetings.
>
> The draft can be found in https://datatracker.ietf.org/doc/draft-contreras-pim-multiple-upstreams/
>
> Any comment is welcome.
>
> Best regards,
>
> Luis
>
> ________________________________
> Luis M. Contreras
>
> Technology / Global CTO / Telef?nica
> Efficiency Projects / Telef?nica I+D
>
> Distrito Telef?nica, Edificio Sur 3, Planta 3
> 28050 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
>
> **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
> ________________________________
>
> 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
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 23 Jul 2013 10:59:34 +0000
> From: Bharat Joshi <[email-masked]>
> To: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>, "[email-masked]"
> 	<[email-masked]>
> Cc: "Zuniga, Juan Carlos \([email-masked]\)"
> 	<[email-masked]>
> Subject: Re: [pim] Draft submission on MLD with multiple upstreams
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
>
> Hi Luis,
>
>          Thanks for your reply. Please see my replies in line.
>
> Regards,
> Bharat
>
>> Sorry for my late response. Regarding your two questions on the topic:
>>
>>> 1. Something similar already exist and being used by the operators.
>> Are we trying to standardize this?
>> Having more than one upstream interface for IGMP/MLD proxy is not
>> standard today. As you mention, if this feature is something being used
>> today through some proprietary mechanism, this reveals the interest on
>> the topic. Network operators definitely support standard solutions
>> rather that proprietary mechanism. So, in my opinion, it is worthy to
>> work on an standard solution for this. In
>> draft-contreras-pim-multiple-upstreams-00 there are a number of
>> potential scenarios of usage for this feature. Probably some others can
>> be identified and added.
> I am yet to read through any of the drafts. Before getting into that, I wanted to understand the need for the standardization of this purely because:
>
> 1. A solution already exist and different vendors have implemented it (differently) and deployed it.
> 2. I cannot see how a standard solution will be better when this does not involve more than one router.
>
>>> 2. As this is device specific, won't a simple configuration is enough?
>> The configuration could be vendor specific as there is no protocol
>> interaction required. As far as I know, this is exactly what some of the
>> vendors that implement this, used.
>> There are existing proposal for automating the upstream selection
>> process, as described in section 5.1 of
>> draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also susceptible
>> of such dynamic selection.
> So what if configuration is vendor specific? Our requirement is to choose a specific upstream interface for a specific group. Right? This can be done with whatever vendors support today. So what I am not able to understand is that why do we need a standard algorithm to do this?
>
>> Best regards,
>>
>> Luis
>>
>>
> **************** CAUTION - Disclaimer *****************
> This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
> for the use of the addressee(s). If you are not the intended recipient, please
> notify the sender by e-mail and delete the original message. Further, you are not
> to copy, disclose, or distribute this e-mail or its contents to any other person and
> any such actions are unlawful. This e-mail may contain viruses. Infosys has taken
> every reasonable precaution to minimize this risk, but is not liable for any damage
> you may sustain as a result of any virus in this e-mail. You should carry out your
> own virus checks before opening the e-mail or attachment. Infosys reserves the
> right to monitor and review the content of all messages sent to or from this e-mail
> address. Messages sent to or from this e-mail address may be stored on the
> Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 23 Jul 2013 11:55:25 +0000
> From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
> To: Bharat Joshi <[email-masked]>, "[email-masked]"
> 	<[email-masked]>
> Cc: "Zuniga, Juan Carlos \([email-masked]\)"
> 	<[email-masked]>
> Subject: Re: [pim] Draft submission on MLD with multiple upstreams
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset=utf-8
>
> Hi Bharat,
>
> About your comments.
>
> The usefulness of an standardized feature is that the expected behavior is the same even if implemented by different vendors. The network operator does not need to adapt to particular solutions, but to well defined and generic ones. No particular hidden problems nor issues. Also thanks to the standard behavior, the hardware from a vendor can be substituted by other in the future (for instance, due to obsolescence) without need of re-customizing the network. This clearly reduces operational costs.
>
> Even if only one router is involved in the implementation of this feature, there are some issues to address (as per comparison with RFC4605 contents):
> .- membership database structure: now more information would be needed because more than one upstream interface is in place.
> .- operation with IGMP and MLD: separate upstream for each of them? Separated versions of protocols for each upstream interface?
> .- loop prevention: think that you can find chained IGMP/MLD proxies in some deployments.
> .- multicast sender support: what is the process for selecting the appropriate upstream interface? How to do it dynamically (for instance, as a function of the received subscriptions)?
> .- SSM: what upstream interface is selected? RPF-like mechanism?
> Plus some additional interesting issues like:
> .- dynamic selection of the upstream in use: e.g., for maintenance reasons or due to a change in the multicast routing in the core network
> .- redundancy: how to implement redundancy method taking advantage of a different upstream interface
> .- load balancing: how to share the demand between distinct interfaces
> .- service demarcation: how to smoothly integrate different multicast streams from different providers on the same distribution tree.
> .- handover support in mobile services: simultaneous subscription of the same multicast streams for mitigating service disruption.
>
> In my opinion these are arguments in favor of standardizing this feature.
>
> Best regards,
>
> Luis
>
>
> -----Mensaje original-----
> De: Bharat Joshi [mailto:[email-masked]]
> Enviado el: martes, 23 de julio de 2013 13:00
> Para: LUIS MIGUEL CONTRERAS MURILLO; [email-masked]
> CC: Zuniga, Juan Carlos ([email-masked]); [email-masked]
> Asunto: RE: Draft submission on MLD with multiple upstreams
>
> Hi Luis,
>
>          Thanks for your reply. Please see my replies in line.
>
> Regards,
> Bharat
>
>> Sorry for my late response. Regarding your two questions on the topic:
>>
>>> 1. Something similar already exist and being used by the operators.
>> Are we trying to standardize this?
>> Having more than one upstream interface for IGMP/MLD proxy is not
>> standard today. As you mention, if this feature is something being
>> used today through some proprietary mechanism, this reveals the
>> interest on the topic. Network operators definitely support standard
>> solutions rather that proprietary mechanism. So, in my opinion, it is
>> worthy to work on an standard solution for this. In
>> draft-contreras-pim-multiple-upstreams-00 there are a number of
>> potential scenarios of usage for this feature. Probably some others
>> can be identified and added.
> I am yet to read through any of the drafts. Before getting into that, I wanted to understand the need for the standardization of this purely because:
>
> 1. A solution already exist and different vendors have implemented it (differently) and deployed it.
> 2. I cannot see how a standard solution will be better when this does not involve more than one router.
>
>>> 2. As this is device specific, won't a simple configuration is enough?
>> The configuration could be vendor specific as there is no protocol
>> interaction required. As far as I know, this is exactly what some of
>> the vendors that implement this, used.
>> There are existing proposal for automating the upstream selection
>> process, as described in section 5.1 of
>> draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also
>> susceptible of such dynamic selection.
> So what if configuration is vendor specific? Our requirement is to choose a specific upstream interface for a specific group. Right? This can be done with whatever vendors support today. So what I am not able to understand is that why do we need a standard algorithm to do this?
>
>> Best regards,
>>
>> Luis
>>
>>
> **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system.
> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>
> ________________________________
>
> 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
>
> ------------------------------
>
> _______________________________________________
> pim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pim
>
>
> End of pim Digest, Vol 111, Issue 13
> ************************************
> .
>

---

From: Bharat Joshi <[email-masked]>
Date: Sat, 17 Aug 2013 06:39:11 +0000

Hi Javed,

       My replies in line.

Chairs and members,
       One question for you at the end of my reply.

Regards,
Bharat

> > ? In section 8, as mentioned before, metric may not be zero. Even then
> do we not want to use metric here? BTW, I wanted to understand why do
> you want to give special mention for this here. Even if metric is zero,
> PIM assert uses preference and IP address as well so whether we use
> metric or not, the outcome will remain same. Or am I missing something
> here?
> 

I think this was not added based on my comment. It was always there. When I first mentioned about this in my first set of suggestions, you did made some changes but I was still not convinced and so asked the same question again.

I think Stig also asked about the need to mention this in the draft.

I am not sure if you really need to mention this at all.

> > ? Please read through Section 10 once. There is some conflict coming
> the way third sentence is framed. The second sentence using 'will not be
> able to remove' does not look correct.
> 

I am not sure what exactly you mean by saying 'Its coming back again after long time'.

I had made some suggestions in previous revision of this draft. Authors agreed and made those changes and submitted the new revision. I read through the changed revision and felt that the changes made is not proper and so mention that in this mail. So first of all, this is not coming back after long time. Second, I am fine with you not agreeing to my suggestion. If you think this makes sense as it is, please leave this as it is.
 
> As the author I feel the WGLC adoption is getting stalled unfairly.

I am not sure what do you mean by this. I did only two rounds of review of two different revisions of this drafts. Whatever suggestions I provided, you agreed to take care most of these suggestions. I kind of tried to generate some quality discussion on your draft and I am really shocked to know that you feel I am stalling your draft.

Do you really mean to say that people reviewing your draft and providing suggestions (which most of you have agreed to) is stalling your draft unfairly?

As I am not sure what to say/do about this, I would request chairs and any other member of the mailing-list to let me know if this is what they also feel about such reviews.

---

From: Mike McBride <[email-masked]>
Date: Sat, 17 Aug 2013 00:16:27 -0700

Bharat,

Thank you for your reviews. The working group appreciates the time
you, and others, take to comment and help the quality of the drafts.
We don't believe you are stalling any drafts, quite the contrary. We
are in no particular hurry with this, or other, drafts and will error
on the side of being thorough. We will progress this draft once your
comments are addressed and we have consensus.

mike

---

From: Stig Venaas <[email-masked]>
Date: Sun, 18 Aug 2013 12:38:08 -0700

> comments are addressed and we have consensus.

Thanks for the reviews and discussion Bharat. This is exactly what we
need. It would be great if more people in our WG would review and
comment on the draft as well, so that we can get some good discussions
and increase the quality of the documents.

Stig