Draft MBONED WG Minutes
47th IETF
Adelaide, Australia
27 March 2000
AGENDA
------
http://www.maoz.com/~dmm/IETF/47/MBONED/agenda
http://www.maoz.com/~dmm/IETF/47/MBONED/mboned.mgp
1. Updates
2. Overview of SSM Activity - Source Specific Multicast
3. Usage in 232/8
4. Sprint's PIM-SO Deployment Plans
5. MSDP Traceroute
6. Anycast-RP for IPv6
7. Inter-Domain Multicast Forwarding
Scribe: Evi Nemeth (evi@cs.colorado.edu)
1. UPDATES
----------
Meyer
o GLOP Addressing (RFC 2770) is done. In addition
the IANA has granted another year for 233/8.
o MZAP (RFC 2776) is done.
o Anycast-RP -- draft-ietf-mboned-anycast-rp-05.txt
There are still some questions about this one. In
particular, should it be Experimental or
Informational. ADs seem to be of the opinion that
Experimental is the appropriate category.
Comments on this point:
Steve Casner - Informational is ok, but its really more
than that, informational ok for things not specifying
protocol, just methods.
Meyer -- BCP inappropriate, too strong.
Randy Bush -- Read the definition of Informational
and Experimental, thinks it should be Experimental.
Steve Casner -- If its deployed in lots of places its BCP.
Jeremy Hall -- Was BGP Experimental or BCP.
Jhawk -- BGP3 is experimental. so it should stay
Experimental.
Meyer said take it to Experimental to advance it.
2. Overview Of SSM Activity - Source Specific Multicast (SSM)
-------------------------------------------------------------
John Meylor (Cisco)
Gave a quick overview of current multicast and how SSM would
relate to it. In particular, how SSM can simplify things
if the source is well-known. Shortest path tree can be created
right away, doesn't need shared tree and data to
renegotiate path. One important point is that the value
of SSM is lost if one mixes shared trees and SPT in
232/8. This turned out to be controversial.
3. Usage in 232/8 -- draft-shepherd-ssm232-00.txt
-------------------------------------------------
Greg Shepherd (Cisco Systems)
232/8 space set aside for source only trees. SSM doesn't
work well if different domains treat 232/8 differently.
Steve Deering -- The original idea was to set aside 232/8
and in this part of the space you have to identify your
sources. Do not wire in knowledge about this piece of
address space (a la the admin. scoped space).
John Meylor -- Agreed with Steve Deering on the above
point. There are knobs to do specific SSM things, but
wont hard code anything.
Steve Deering: Wants to preclude hazards and not lock
things in for all time. I.e, make it an operational
issue, and make the default behavior treat 232/8 this
way.
Greg Shepherd -- Some mechanism needs to be implemented,
filtering or hard coded.
Meyer - some folks are using 232/8. Content providers
wanted more addresses. Among other things, this makes
filtering 232/8 a contentious issue for us.
Dave Thaler -- "Minority Opinion" or application
viewpoint. Point: In order to use SSM in 232/8 with
filtering, both hosts and routers have to be upgraded,
different lans will take different paths from current
IGMP2 to IGMP3. Main point: There are financial
disincentives to filtering (*,g) in 232/8. So don't filter
till most hosts and routers are using IGMP3.
John Meylor -- What is the incentive to move from
traditional to 232/8. Its not enough for iana to say don't
do it. Filtering in the application layer goes away if
they upgrade. But, address collisions can occur.
Suggested middle ground - what about new range or part of
232 that is not filtered.
Jeremy Hall -- Content providers have taken 232 space
when they shouldn't and so if it wont work so what.
John Meylor -- There are only a few and they know the
implications and its ok. do we see a value of precluding
shared trees in an address range. If so we have to filter.
Randy Bush -- What went wrong, why is there this
conflict. We need to find a way to transition content into
that space (232).
Steve Casner - What are the guarantees that need to be
given for 232/8 to be useful?
John Meylor -- Large PIM domains that source content into,
content provider cant guarantee what receiver gets, so
cant do service level agreements with their
customers.
Colin Perkins - They pay per byte, so thats an incentive
to upgrade.
John Meylor - Is not suggesting that we limit source
specific joins to the 232 space, suggesting that in 232
thats the only way to get data. If you know the source,
should be able to join it in any address range.
4. Sprint's PIM-SO Deployment Plans -- draft-bhattach-diot-PIMSO-00.txt
------------------------------------------------------------------------
Gene Bowen (Sprint Labs)
SSM seems to fit what most content providers want, can do
it with hacks to PIM sparse mode. The draft is
available for anyone who wants to contribute, not in IETF
process now. Discussion centered around Sprint's
deployment plans. It was proposed that the Sprint
specific deployment sections be removed and the document
made it to a framework document for SSM. Current
documents relevant to SSM:
draft-holbrook-ssm-00.txt
draft-bhattach-diot-PIMSO-00.txt
draft-bhaskar-pim-ss-00.txt
draft-sandick-pimsm-ssmrules-00.txt
draft-shepherd-ssm232-00.txt
draft-ietf-idmr-igmp-v3-03.txt
draft-ietf-idmr-msf-api-00.txt
5. MSDP Traceroute to MSDP Working Group, out of time
-----------------------------------------------------
6. Anycast-RP for IPv6
----------------------
Brian Haberman (Nortel)
http://www.maoz.com/~dmm/IETF/47/MSDP/IPv6/msdp_and_ipv6.ppt
http://www.maoz.com/~dmm/IETF/47/MSDP/IPv6/pim_for_ipv6_and_anycast_rp.ppt
Described extensions to MSDP and Anycast RP for IPv6.
Draft forthcoming.
7. Inter-Domain Multicast Forwarding -- draft-jibiki-iwata-mboned-idmf-00.txt
-----------------------------------------------------------------------------
Atsushi Iwata
Proposed extension to MSDP forwarding. Time ran short and
discussion was pushed to the MSDP WG.