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

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Mon, 08 Jul 2013 10:06:46 +0000

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

---

From: Bharat Joshi <[email-masked]>
Date: Mon, 8 Jul 2013 11:04:49 +0000

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,

Any comment is welcome.

Best regards,

Luis

[email-masked]

**************** 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***

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 23 Jul 2013 10:46:28 +0000

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,

Regards,
Bharat

Dear all,

Any comment is welcome.

Best regards,

Luis

[email-masked]

**************** 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***

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 23 Jul 2013 10:59:34 +0000

Hi Luis,

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

Regards,
Bharat

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

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 23 Jul 2013 11:55:25 +0000

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,

Regards,
Bharat

> 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
> potential scenarios of usage for this feature. Probably some others
> can be identified and added.

> interaction required. As far as I know, this is exactly what some of
> the vendors that implement this, used.
> draft-ietf-multimob-pmipv6-ropt-07. Other scenarios are also
> susceptible of such dynamic selection.

---

From: Bharat Joshi <[email-masked]>
Date: Tue, 23 Jul 2013 14:13:15 +0000

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.

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

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

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

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

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

<Bharat>: I agree to the above points.

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,

Regards,
Bharat

---

From: LUIS MIGUEL CONTRERAS MURILLO <[email-masked]>
Date: Tue, 23 Jul 2013 18:51:12 +0000

Hi Bharat,

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

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.

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

Hope this clarifies the raised issues.

Best regards,

Luis

-----Mensaje original-----
De: Bharat Joshi [mailto:[email-masked]]
Enviado el: martes, 23 de julio de 2013 16:13
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,

Regards,
Bharat

Hi Bharat,

About your comments.

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,

Regards,
Bharat

---

From: Bharat Joshi <[email-masked]>
Date: Wed, 24 Jul 2013 03:35:30 +0000

Hi Luis,

Regards,
Bharat

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

Ok.

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

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