Subject: Re: [Mtp] the more things change, the more they stay the same

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 13:47:33 -0700

I guess the more things change, the more they stay the
	same. 

	So another thing occurred to me while reading the
	Multicast Last-Mile Solutions drafts on Greg's site: Why
	are we defining yet another ad-hoc signaling protocol
	(that is one way to looks at these proposals)? The IETF
	literature is littered with signaling proposals, some
	host-based, some router-based, at varying degrees of
	generality. 

	Straw person: why not have the host send a PATH message
	towards the source (since it knows the source) and have
	the first multicast capable router in the path send back
	the its tunnel endpoint, have the host set up GRE (or
	user space encap) to that router and ...

	What I am suggesting is we really don't have a general
	purpose host-to-router signaling protocol (well,
	maybe). So if we pick one of the current drafts (or a
	hybrid, or even new), will we have to build a new
	signaling infrastructure for the next feature not
	supported by the directly connected routers? 

	Seems like we should be able to answer this question in a
	more general way than is done in these drafts.

	Dave

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Jul 2003 14:07:34 -0700

>> 	user space encap) to that router and ...

    Are you suggesting to use RSVP?

Dino

---

From: [email-masked]
Date: Wed, 9 Jul 2003 15:56:57 -0700 (PDT)

> 	host-based, some router-based, at varying degrees of

Agreed.
 
> 	user space encap) to that router and ...

Well, that is quite similar (from a straw prospective) to what I'd
like. My personal preference is for user-space so it could be easily
deployed. But why not just translate the destination address? You know the
receiver address so change the destination address of the replicated mcast
stream for each unicast reciever. No encap, no decap, no fragmentation.

The trouble has been that many of the proposal seem to get mired in
'features' outside of a routed infrastructure, or steers toward a biz-plan
of deploying special-purpose boxes (reading between the lines..).

> 	maybe). 

IGMP sure.. but its link-local. IF IGMP (and PIM as well) were capable of
multi-hop signalling from the beginning, we wouldn't have this gap.

>       So if we pick one of the current drafts (or a

Sorry, I don't follow.. Can you clarify?

> 	more general way than is done in these drafts.

And I hope to use the BOF to set some direction.

Greg

---

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 14:12:55 -0700

>>     Are you suggesting to use RSVP?

	Not really. Just wondering if there is a more general way
	to solve the problem (rather than cooking up a yet
	another special purpose solution for this case).  

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 14:24:04 -0700

>> Sorry, I don't follow.. Can you clarify?

	It would seem that the general form of this particular
	deployment problem is:

	   The router on directly the directly connected network,
	   or that router and some number of subsequent routers
	   in the path towards some resource, can't or won't do
	   <foo>. 

	Now, what is being discussed here is an instantiation
	<foo> for the special case of multicast (or in the case
	of a few of the drafts, even narrower: SSM). 

	Now, what happens when I have a different <foo>, say
	<bar>? Is what is the signaling built for <foo> useful
	useful when deploying <bar>, or do I have to go build
	the (new) <bar> signaling protocol?

	It's more a discussion about the Internet architecture
	(in general) and less about multicast, although if we
	could build something general, instantiating it with
	this case (multicast) would be nice example.

	Does that help?

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 14:41:42 -0700

>> Yup, thanks. I understood the desire for a general purpose solution, but
>> wasn't clear whether you already had an example. I guess I was just being
>> hopefull. ;-)

	It turns out that you might be able to choose, depending
	on how much you want to implement in a host. RSVP is a
	signaling protocol that could be used to do this, and is
	extensible, and can be/is implemented in user space on
	the host side (an objective for the last mile work, as I
	understand it).

	Going to the other end spectrum you find things like the
	control plane specified in draft-ietf-l2tpext-l2tp-base*
	(L2TPv3 control plane). If you keep going you get to
	draft-kompella-mpls-l2vpn-*, and the like. 

	I'm really not advocating any solution at this
	point. What I was after was some more general thinking
	about the problem (in the event that turns out to be
	useful).  

	Dave

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 Jul 2003 14:07:34 -0700

Dino

---

From: [email-masked]
Date: Wed, 9 Jul 2003 15:56:57 -0700 (PDT)

Agreed.

Greg

---

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 14:12:55 -0700

Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 14:24:04 -0700

Does that help?

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 9 Jul 2003 14:41:42 -0700

Dave

---

From: Bill Nickless <[email-masked]>
Date: Wed, 09 Jul 2003 17:30:39 -0500

-----BEGIN PGP SIGNED MESSAGE-----

At 03:20 PM 7/9/2003 -0700, Keyur Patel wrote:

>Single signaling infrastructure should work for SSM and ASM model. One 
>could use well known anycast address to direct all the control traffic to 
>a specific location within a network.
>
>-Keyur

...or towards an IPv6 embedded RP address.  (Hi Pakkola!)

Earlier, Lenny wrote:

>Making the source host a tunnel endpoint is already supported.  This is
>called unicast.

Yes, at Layer 3.  But not at Layer 4 and higher.  The people I work with 
care about Layer 4 (and above).  More generally, I predict that enabling 
the Layer 4 service will drive deployment at Layer 3 and below.

===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     [email-masked]

---

From: Bill Nickless <[email-masked]>
Date: Wed, 09 Jul 2003 17:30:39 -0500

-----BEGIN PGP SIGNED MESSAGE-----

===

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 09 Jul 2003 17:08:47 -0700

In message <[email-masked]> you write:
>On Wed, Jul 09, 2003 at 02:52:46PM -0700, Joel Jaeggli wrote:
>> On Wed, 9 Jul 2003, Lorenzo Vicisano wrote:
>> 
>> > On Wed, Jul 09, 2003 at 02:17:38PM -0700, Joel Jaeggli wrote:
>> > > 
>> > > It was never clear to me why a host to router signaling mechanism had 
>> > > to be different from the router to router signaling mechanism.
>> > 
>> > one reason is because a host just needs to signal that is wants to
>> > receive multicast on a link, while a router cooperates with other
>> > routers to forward multicast in some optimized way. Hence the
>> > statement "I want to receive from this link" is typically not
>> > sufficient.
>> 
>> so why can't I just send an s,g join towards s using pim instead of nicely 
>> using igmp to get my first hop router to do it for me?
>
>because you, the host, would have to have routing information to find
>out who the 1st hop towards the source is... you would also have to
>take part to the PIM routing protocol to find out who's responsible to
>forward in your lan for that source.
>
>	Lorenzo

More than that, routers are particular about the state they keep and
who they exchange routing information with. Running PIM on the hosts
is a fast way to get PIM turned off on the routers.

I won't be at the BOF so here are some suggestions I would like to see
come out of this work:

1. I don't think we should throw out the idea of a new signaling protocol
   too quickly. If we can reuse someone else's packet formats, then
   great but the characteristics of the signaling should be decided first
   and then we can determine if an existing protocol will fit our needs.

   The characteristics I would like to see are:

   a. Host application can send join requests without any special
      privileges on the largest variety of operating systems. This
      speeds deployment and puts users in control without having to
      get approval from Administrators. This dictates that the
      protocol be UDP or TCP based.

   b. A server or router listening to these join requests should not
      have to guess what type of join this is. The server may be doing
      encapsulation or it may be doing header rewriting (translating
      from multicast to unicast). It needs to know how many "users" it
      can handle and know if resources become limited that it can drop
      these hosts instead of dropping something like real multicast
      PIM neighbor adjacencies which will affect many "users".

      A way to clearly distinguish this application is essential if
      you want router/switch vendors to be willing to replicate or
      accept tunnel requests at the edge of your network.

2. Don't make encapsulation a requirement.

   This complicates the host implementation requiring it to decapsulate.
   While this may be one way to get the multicast to the hosts,
   simply having servers sit at the edge of a network and replicating
   a multicast stream to a bunch of hosts by replacing the multicast
   destination address with the hosts unicast address eliminates
   much complication from the host application. It simply sees a
   regular UDP unicast stream coming in.

3. The address the join is sent to should be specified the same way
   as the group and the source address is learned. This will likely be
   in the SDP description. The join address may in fact be the source,
   or it may be an anycast address or some other invention. But we're
   free to try different approaches and we don't lock ourselves in.

4. The join should use the router alert option in the IP header.
   This will allow routers along the path from the receiver to
   the source to process the unicast join or send it to a server
   it knows about.

Lets nail down some more requirements of the signaling protocol
and then decide if we need to invent something new or we can
reuse some existing mechanism.

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 09 Jul 2003 17:08:47 -0700

Thanks,
Tom

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Jul 2003 14:52:46 -0700 (PDT)

> > > Mtp mailing list
> > > [email-masked]
> > > http://www.shepfarm.com/mailman/listinfo/mtp
> > > 
> > 
> > -- 
> > -------------------------------------------------------------------------- 
> > Joel Jaeggli	      Academic User Services   [email-masked]    
> > --    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
> >   In Dr. Johnson's famous dictionary patriotism is defined as the last
> >   resort of the scoundrel.  With all due respect to an enlightened but
> >   inferior lexicographer I beg to submit that it is the first.
> > 	   	            -- Ambrose Bierce, "The Devil's Dictionary"
> > 
> 

-- 
-------------------------------------------------------------------------- 
Joel Jaeggli	      Academic User Services   [email-masked]    
--    PGP Key Fingerprint: 1DE9 8FCA 51FB 4195 B42A 9C32 A30D 121E      --
  In Dr. Johnson's famous dictionary patriotism is defined as the last
  resort of the scoundrel.  With all due respect to an enlightened but
  inferior lexicographer I beg to submit that it is the first.
	   	            -- Ambrose Bierce, "The Devil's Dictionary"

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Jul 2003 14:17:38 -0700 (PDT)

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 9 Jul 2003 14:29:09 -0700 (PDT)

Thanks again,
Greg

---

From: Keyur Patel <[email-masked]>
Date: Wed, 09 Jul 2003 15:20:37 -0700

Dave:

Single signaling infrastructure should work for SSM and ASM model. One 
could use well known anycast address to direct all the control traffic 
to a specific location within a network.

-Keyur

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 9 Jul 2003 14:28:20 -0700

Lorenzo

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Jul 2003 14:52:46 -0700 (PDT)

---

From: Keyur Patel <[email-masked]>
Date: Wed, 09 Jul 2003 15:20:37 -0700

Dave:

-Keyur

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Jul 2003 16:52:24 -0700 (PDT)

On Wed, 9 Jul 2003, Lorenzo Vicisano wrote:
> out who the 1st hop towards the source is...

Do situations exist where a host that isn't running an igp or egp has 
multiple first hop routers available on the interface that it's default 
route is pointing out (excluding the special case of hsrp)?

> you would also have to

yes

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 9 Jul 2003 14:29:09 -0700 (PDT)

Thanks again,
Greg

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Jul 2003 14:17:38 -0700 (PDT)

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 9 Jul 2003 14:28:20 -0700

Lorenzo

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 9 Jul 2003 15:06:22 -0700

Lorenzo

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 9 Jul 2003 15:06:22 -0700

Lorenzo

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 9 Jul 2003 16:52:24 -0700 (PDT)

yes