All things related to multicast

[<>]

On Wed, 9 Jul 2003, David Meyer wrote:

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

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

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

>       What I am suggesting is we really don't have a general
>       purpose host-to-router signaling protocol (well,
>       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
>       hybrid, or even new), will we have to build a new
>       signaling infrastructure for the next feature not
>       supported by the directly connected routers? 

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

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

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

Greg

>       Dave
> 
> _______________________________________________
> routing-discussion mailing list
> 
> https://www1.ietf.org/mailman/listinfo/routing-discussion
>