Re: [pim] Draft submission on MLD with multiple upstreams

[Bharat Joshi <[e-mail]>]

Hi Luis,


        As mentioned before, I am not against standardizing this, I am just trying to understand the need.

        My thinking is that we can standardize the external visibility of a feature and how it should behave. I am not sure whether we can really standardize the configuration for a feature or how a particular feature is implemented internally by a router. But yes, there can surely be a guidance given to help implementer and administrator.

        Please see in line with <Bharat>.

Regards,
Bharat

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.

<Bharat>: As its already implemented by vendors, its been taken care. But I agree that there is some more state/information to be maintained.

.- operation with IGMP and MLD: separate upstream for each of them? Separated versions of protocols for each upstream interface?

<Bharat>: Yes. Again, this could be decided based on the configuration. They both can use same or different upstream interfaces.

.- loop prevention: think that you can find chained IGMP/MLD proxies in some deployments.

<Bharat>: Currently, this is mostly taken care by network design and configuration. This is something which I would like to know more about.

.- 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)?

<Bharat>: Did not get you? What do you mean by selecting appropriate upstream interface for sender? Can you please elaborate?

.- SSM: what upstream interface is selected? RPF-like mechanism?

<Bharat>: Again did not get you? Is this similar to the previous point? Can you please elaborate?

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.

<Bharat>: I agree to the above points.

In my opinion these are arguments in favor of standardizing this feature.

Best regards,

Luis


-----Mensaje original-----
De: Bharat Joshi [mailto:[e-mail]]
Enviado el: martes, 23 de julio de 2013 13:00
Para: LUIS MIGUEL CONTRERAS MURILLO; [e-mail]
CC: Zuniga, Juan Carlos ([e-mail]); [e-mail]
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