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

[Bharat Joshi <[e-mail]>]

Hi Luis,

        Thanks for your reply. Please see my replies in line.

Regards,
Bharat

> 
> I get your point. For sure there can be aspects not subject of
> standardization. Let's explore and discuss.

Ok.

> I concentrate now in the two points where you ask for more elaboration.
> 
> .- multicast sender support: in RFC 4605 it is mentioned (sec. 3.2) that
> all the traffic delivered by the senders from inside the tree is
> forwarded towards the root. When having more than one upstream interface
> there is more than one root. So different options could be in place:
> send the traffic for all the possible upstreams; send the traffic just
> for one upstream; send the traffic for that upstream that maintains more
> subscriptions to the content; etc.

I am not sure if I understand. 'Root' of a multicast tree is always one. It could be RP in case if PIM-SM is used. There could be different RP responsible for different groups.

I think it can be decided based on the configuration of multiple upstream interfaces to send the traffic towards the Root.

> .- SSM: in case a certain source is reachable through more than one
> upstream interface a decision mechanism should be used to determine to
> what upstream interface is send the content subscription request. For
> instance, the decision could be the selection of the interface with
> better (IGP) metric to the source. More sophisticated mechanisms could
> be in place e.g. for load balancing (for a certain content or among
> different contents).

Are we talking about routing protocols here? Because IGMP/MLD will not do RPF lookup for the source. They will just send it out on upstream interface as configured.

> Hope this clarifies the raised issues.
> 
> Best regards,
> 
> Luis
> 
> -----Mensaje original-----
> De: Bharat Joshi [mailto:[e-mail]]
> Enviado el: martes, 23 de julio de 2013 16:13
> 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,
> 
> 
>         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
> 
> ________________________________
> 
> 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
>