Re: Re: Using DNS for SSM

[Hugh Holbrook <holbrook@cisco.com>]

>    Just the fact a network operator can ask over the phone, "what are you
>    trying to get to and who are you?", and the answer is radio.example.com and
>    customer.broken-dsl.com, would allow the netadmin to do:
>
>        mtrace radio.example.com customer.broken-dsl.com
>
>    would go a long way to isolating problems from the NOC.

I can see that it would be nice to be able to mtrace using DNS name(s)
for SSM content rather than a bunch of random numbers.

So I'm trying to imagine how all of this fits together.  How does the
customer get the SSM DNS name so that it can tell the NOC?  Would the
DNS name be stored in the SDP record?  Or is the idea that the
application does a reverse lookup on the address pair in the SDP
record?  Or does this information come from somewhere else?

I'm not sure it's really necessary to have channels represented as
first-class objects in the DNS, though.  I think it would be nice if
we could get the benefits of simple channel names without requiring a
new RR and associated upgrade to bind.  Here's an idea that relies on
a naming convention for channels that achieves the same purpose, at
least for mtrace.  A simple change to mtrace would support the exact
syntax that you suggest without requiring any DNS changes at all.

So you invoke mtrace like this

      mtrace kqed.radio.example.com  customer.broken-dsl.com

The first thing that mtrace does is to resolve kqed.radio.example.com
and get back an A record that says that kqed.radio.example.com maps to
232.1.2.3.  mtrace knows this is an SSM destination address and then
strips off the component of the DNS name (kqed) to find the DNS name
of the source, radio.example.com which it then resolves to get the
source address.  I just wrote a perl script in about ten minutes that
does this.

If a content provider doesn't want to have a four-component name for
all of its SSM content, then it can use a PTR record to make
kqed.example.com be an alias for kqed.radio.example.com.

Given this, I'm not seeing a strong case for having a new RR.

Thoughts?

-Hugh

> Date: Wed, 21 Feb 2001 09:33:34 -0800
> From: Beau Williamson <bwilliam@cisco.com>
> Cc: ssm-interest@external.cisco.com
> 
> At 05:13 PM 2/15/2001, Dino Farinacci wrote:
> >>> My reading of Toerless's message was that he was questioning the "need" at 
> >>> least as much as the "urgency".
> >
> >    Here's a basic need which I think would make managing multicast networks
> >    one step easier:
> >
> >        mtrace radio.example.com
> >
> >>> As Toerless noted, knowing a SSM channel address (S,G) alone doesn't tell 
> >>> you much.  In order to be able to usefully receive the session, you still 
> >
> >    Right, so what's your point. Did you think the DNS was suppose to solve 
> >    that?
> >
> >    It's hard enough to remember source and group addresses when debugging
> >    problems in the network infrastructure without adding any more issues
> >    to the problem statement.
> >
> >    Just the fact a network operator can ask over the phone, "what are you
> >    trying to get to and who are you?", and the answer is radio.example.com and
> >    customer.broken-dsl.com, would allow the netadmin to do:
> >
> >        mtrace radio.example.com customer.broken-dsl.com
> >
> >    would go a long way to isolating problems from the NOC.
> 
> Boy, this sort of thing would have come in handy in the past.  This has merit.
> 
> Beau Williamson
> 
>