Re: [MBONED] Mail regarding draft-tissa-pim-mcastoam

Hi

I see both benefits and some issues with your proposal. For
now I mainly want to make a few comments regarding RFC 6450,
but I have a question about your proposal too.

On 3/21/2012 9:00 AM, Tissa Senevirathne (tsenevir) wrote:
> Hi Ron
>
> Rate limiting as proposed is only needed in the interim until
> implementations include propose extensions. Secondly, these extensions
> can be utilized to discover various roles performed by routers in
> multicast forwarding, which RFC 6450 cannot do.
>
> With RFC 6450 every end stations has to run the required servers and
> need to have the clients. Routers would not be able to perform such a

One of the ideas with 6450 is that a server providing multicast content
can also run a 6450 server. Then hosts interested in receiving can check
their connectivity. Also an operator (some do) can place a few hosts at
various places in their network to check that they can receive. Of
course this does not show that the actual users can receive.

Some operators use 6450 to regularly monitor their network with various
servers and clients spread out in their network, and in some cases
getting customers to deploy clients or servers as needed.

There has been some interest in 6450 support in routers and possibly
combining it with mtrace. I can see both benefits and issues with that
as well.

> thing and operators always have to log in to end devices, consider the
> operational nightmare. Additionally, as pointed out earlier, sometimes
> it is not even administratively possible. In short with RFC 6450, you
> are leaving customers to troubleshoot their own problems.
>
> Like I pointed out earlier, we needed to look forward, so some point to
> the future we will have the required tools in place if we take right
> steps today. If we do agree the problem space is important then we can
> discuss during the WG what best approaches we can take.

 From an operator point of view, getting all user devices to respond in
such a way is certainly useful. My main question right now is about
security. There may be impacts related to both DoS and in identifying
end-points. Of course these are issues today with hosts responding to
regular multicast ICMP echo requests. I've often used that for
debugging, but there are some issues.

Stig

> Thanks
> Tissa
>
> -----Original Message-----
> From: Ronald Bonica [mailto:rbonica@juniper.net]
> Sent: Tuesday, March 20, 2012 9:54 PM
> To: Tissa Senevirathne (tsenevir);
> draft-tissa-pim-mcastoam@tools.ietf.org; mboned@ietf.org
> Subject: RE: Mail regarding draft-tissa-pim-mcastoam
>
> Tissa,
>
> Having thought about your draft a while longer, I think that I can do a
> better job of articulating my objection. That is, that the tool
> described in 6450 is better suited to the problem at hand.
>
> Operators need a tool like this when a customer calls in wanting to know
> why he can't receive a multicast stream. In this case, it makes sense
> for the customer to initiate a test between himself and the server. It
> makes less sense for the server to blast something out to all of its
> clients hoping to elicit only a manageable number of responses.
>
> One drawback of the solution described in RFC 6450 is that it requires
> clients and servers to be deployed on end systems. On the other hand,
> draft-tissa requires protocol changes on senders, receivers and
> intermediate routers. That seems to be a wash.
>
> Furthermore, 6450 is fairly robust. Draft-tissa performance is subject
> to filters and rate limits that are imposed upon ICMP and optioned IP
> packets.
>
>                                              Ron
>
> BTW, In this email and in all previous messages on this thread, I am
> speaking as an individual contributor.
>
>
>
>
>
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned