>If in talking of an IGP/EGP split folks mean that different path selection
>algorithms need to run "inside" and "outside", then I agree that this
>shouldn't be axiomatic for IRTF. I think, however, what is meant is that
>new routing protocols need to support different policy domains, under
>control of autonomous peers. That fits better with the argument that an
>"IGP/EGP" split has been an enabling factor in the growth of a unicast
>Internet and that the lack of such a split has been an inhibiting factor in
>the growth of a multicast Internet.
In practice there are two IGP/EGP splits in the currently deployed
multicast protocols:
- For ASM (conventional-style) multicast, PIM-SM is used intra-domain
and MSDP is used inter-domain. The problem here is that MSDP has
major problems. BGMP was meant to solve those problems, but we
don't see many ISPs asking for it, so we don't see any router vendors
implementing it.
- For SSM (single-source) multicast, PIM-SSM (a subset of PIM-SM) is
used both intra-domain and inter-domain. But PIM doesn't do path
selection - that's typically done using the conventional IGP in
combination with MBGP. So you've got the same IGP/EGP split with
path selection as you have with unicast (although the paths may be
different because it's a different RIB).
Personally I don't think the lack of an IGP/EGP split has inhibited
multicast. What has inhibited multicast is a combination of:
- Initial early implementaion and specification bugs that made PIM-SM
very unreliable, so all the momentum we'd gained with the DVMRP
Mbone was lost.
- Deploymemt of PIM mechanisms before the architecture was finished
(especially regarding RP mapping) which made deploying better
solutions harder.
- Lack (until relatively recently) of well evolved debugging tools.
- MSDP as an interrim solution which diverted a lot of effort away
from more viable solutions.
- MSDP's many bugs which continue to cause ASM multicast to be a
pretty unreliable service.
- Our failing to recognise that ASM was a hard service model for ISPs
to implement safely (from a DoS point of view). SSM largely
addresses this issue.
- Our over-ambitious schemes to do multicast address allocation that
focussed too much on scaling with the result that we didn't really
satisfy the people who needed to deploy and use multicast.
- Slowness of IGMPv3 implementation so we can so SSM.
- Edge equipment that doesn't support it (eg PPPoE).
- Cable providers that don't want the competition with their TV services.
There are probably many others, but this is what comes to mind right
now. Hindsight is a wonderful thing.
We've now got SSM, which is a service model that is probably
deployable. We've got a new PIM-SM spec that should reduce the bugs
significantly. SSM and IGMPv3 solve the address allocation issues.
We've got IGMPv3 implemented in Windows XP. With the exception of the
last mile issues, most of the problems above are now solved. It will
be interesting to see if multicast will start to take off in the next
few years.
BTW, there are probably some lessons to be learned from the above for
new unicast routing schemes too.
Cheers,
Mark
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT