Re: Some SM observations

[Tony Ballardie <ballardie@dial.pipex.com>]

-----Original Message-----
From: Cheng-Yin Lee <leecy@nortelnetworks.com>
To: Tony Ballardie <ballardie@dial.pipex.com>
Cc: radia.perlman <radia.perlman@sun.com>; j.crowcroft
<j.crowcroft@cs.ucl.ac.uk>; zhwang <zhwang@dnrc.bell-labs.com>
Date: 23 April 1999 00:10
Subject: Re: Some SM observations


>yeah, it's not easy whether sender or receiver indicates a new tree needs
to be
>setup.
>
>If the router which discards the pkt is an SM router then it could inform
the
>downstream members to join a new tree and inform the source that should
become
>root of a new tree. Usually i think it's a pkt filter that drops the pkt.

umm, still I don't think this is a practical approach. My suggestion was
just to
let the recvr domain (boundary) take care of it. The source doesn't need to
know it is becoming the root of a src tree for this (or any) receiver. This
is also
in sync with BGMP's way of doing it.

>> In thinking about multicast BGP (BGP-4+), interestingly, it allows a
domain
>> to independently choose a "come from" path, BUT non-chosen paths aren't
>> announced backwards (to nhbr domain nearer src prefix) to say: "don't
>> send me the traffic srcd under this prefix". This means there will be
wasted
>> inter-domain traffic flow.
>
>This is a problem both in unicast and mcast policy routing.
>The routers on the path could indicate it can fwd the mcast pkt to the
>group/dest (regardless of source of pkts) and yet discard it if the source
is
>invalid. i think we have a more fundamental problem, policy rtg and
>inter-domain peering...

it's not a problem in *unicast* rtng because you're advertising a "go to"
path;
the data travels in the reverse direction of the route update - the path is
announced
_towards_ the source, so the src follows a very "strict" path. With "come
from" paths
the data is travelling in the _same_ direction as the route update; because
an
accepted route isn't announced one-AS-hop backwards, the forwarded data can
go to ASs that don't want it via that particular path. Without this
"feature" inter-domain
shared trees wouldn't work at all (some domains wouldn't recv a src's data
via the
core because the domain's come-from path for a src was via a different
path). At least
the way it is now the data gets to the rcvr domain, albeit via the wrong
path for a src.
The recvr domain can then take steps to getting it via its preferred path.

cheers,

Tony

ps. thought this policy stuff might be of interest to sm-interest, hence cc: