IETF 56 MBONED WG Minutes
==========================


Embedded IPv6 RP draft (Pekka Savola)
------------------------------------

	- The idea is that it will make interdomain IPv6 multicast work changes the 
model slightly sources send to one RP and join to one RP.

	- Format builds on RFC3306, and removes remnants of the "SPT join to the RP 
only model" 

	- Questions: Is there any need to change the core routers ?

	  What happens when local config (or BSR) says one RP but the group name 
implies another? 

	- Do you need the RP address field at all (RP ad) ?  Is simpler, but 
would loose flexibility Could always use different unicast prefixes if you 
want to use different RP's

	- Do you need to support plen > 64 ?
	  (This would overlap with the 32 bit group ID.)

	- Can this be published before the PIMv2 specs are ?

	- Toerless : Can we assign different meanings to different RP 
addresses ? for different modes of operation for PIM, you would have a 
different RP address 0 is the default another could be for bi-dir PIM 

	- There are enough unicast addresses that there is no reason to have to 
conserve them ! 

	- Pekka: The problem is that this might clash with current unicast IP 
address allocations. 

	- Thaler:  It depends a lot on whether you are going to do the same stuff in 
IPv4.

	- Lenny Guiliani:  Toerless is arguing that the RPad should be changed to be 
a context field 

	- Lenny Guiliani:  As I see it, it makes no sense to have a solution for 
interdomain and a different solution for intradomain multicast. If we 
continue to do this we will replicate MSDP for IPv6. This idea of 
building in all this crap into the network just to make SDR work is not 
wise. I think that we should just say that SSM is the service model for 
IPv6 multicast. (Scattered applause.)

	- Dave Meyer; This is a deployment working group. It is not the place to 
solve the multicast architecture problems. The IESG will have to charter 
that.

	- Dave Thayer: This is still useful for the intradomain case.
	- Greg Shepard: I do not see the need for the intradomain case as you can 
just do it (static application).

	- Dave: The argument has been made that this is simpler than any of the 
existing methods 
	- Greg Shepherd: Including static allocation ?
	- Dave Thaler: Including static.

	- Randy Bush: I have said this before; either someone should sell porn 
over multicast to make it pay, or you should all find something 
worthwhile to do with your time. (Scattered applause.) 

	- Dave Meyer: What I propose is to take this to the list.

Multicast DoS (Tom Pusateri)
----------------------------

	Multicast is sensitive to state explosion. If you want to scale, you have to 
limit (S,G) state to only on the tree. With real multicast traffic, you run 
out of bandwidth way before you run out of state. Not so with attacks.

	What makes state "leak" ?
	PIM shared trees
	MSDP - 330,000 cache entries from the Sapphire worm

	filters and rate limits will reduce the problem at the expense of 
dropping real data. 

	- Toerless: If you limit your customers, then at least the core will not 
die 

	- Dave Meyer:  Filters and limits will put scale limits on multicast 
which will be trouble in the future. 

	How to reduce state
	- Use SSM
	- PIM bi-dir can also reduce state as you can use (*,G) state in the 
forwarding cache 

	Conclusion - Should not be using the network for source discovery, 
therefore - make a plan to turn off MSDP

	- Dave Meyer: So do we think we need a work item to design a 
deployment plan to turn off MSDP?

	- Dino: if we cannot limit MSDP, we can make it look like MBGP policy 

	- Bill Nickless: I believe that going from ASM to SSM is difficult 
enough that it will require a transition period.

	- John Meylor: There is a requirement for ASM

	- John Meylor (after tme talk) 99.99% of all multicast 
applications today use ASM, and they work.  So be careful before you tar ASM 
with a broad brush. 

	- Dave Meyer:  Should there be a BCP to stop encapsulation of 
multicast data in MSDP packets ? --  ratholed.

MCOP (Rami Lehtonen)
-------------------

	Deal with threats - to control which networks / hosts can or cannot send 
traffic to/from a multicast group.

	which networks can / cannot receive a given group, maximum number of 
groups that an individual host can send data to. 

	Multicast control is based on filtering IGMP / MLD packets and 
multicast packets.

	Control information is  used between MCOP router and Multicast control 
server

	- Mark Handley:  when the host leaves the group is the state 
maintained ?

	- Rami:  If the group is inactive, it will time out

	- Mark Handley: For fast joins for layered congestion control, we would 
prefer that when a host leaves the group that the information is cached for a 
few minutes.

	- Dave Thayer: If space is not an issue, there is no reason to remove 
filters at all until some new filter needs the space.  

	- Haixiang He: Given the cheapness of memory, why would the filters ever be 
too large ? 

	- Rami: The problems in Atlanta were more about the dynamical nature of the 
control tables, not their size. 

	- Haixiang He:  what do you authenticate _on_ - if I have two hosts on a 
network, how do I let one get the multicast and the other not ?  

	- Rami: The authentication and filtering is always based on a network, not 
an individual host. 

	- Haixiang He: Is this for one domain ?

	- Answer: This is intradomain only, yes.

	- Dave Thayer: Each router is going to be controled by one 
organization, so each router has a specific MCOP server that it talks to. 

	- Dave Meyer: So what do you want us to do ? We don't generally work on 
protocols in MBONED. 

	- Rami: Maybe it could be shared with Magma.

	- Dave Thayer:  Which working groups owns COPS ? They should  get this 
too.

	- Dave Meyer: I think I would agree with this. One part of this could be 
here, but the protocol is way beyond either this group or MAGMA. 

draft-venaas-mboned-v4v6mcastgw-00.txt (Stig Venaas)

----------------------------------------------------

	IPv4 to IPv6 multicast gateways

	Basic idea is to use PIM-SM

	Idea IPv6 group maps to IPv4 group : a.b.c <--> PREFIX::a.b.c

	Gateway strips off or adds the PREFIX

	Gateway assumes that there always are multicast listeners.

	Issues :
	- NAT issues
	- When resending, all packets get only one IPv6 unicast address

	Question - should be WG take this over ?

	- Brian Haberman: It should be MTP rather than NetTP.  My complete 
comment was that it is something MBONED should look at if v6ops thinks it 
needs to be done for operational transition.  

	- Dave Thayer: Going SSM from v4 to v6 seems doable, but there may not be 
enough v4 addresses to map a v6 SSM source into v4. Also, I think that this 
is the only current working group that could do this. The question is, 
should it ? 

	- Dave Meyer: I think that this needs more research before we take it on; 
Further, we can  v6ops decide if this is required. 

EGLOP (Dave Meyer)
------------------

GLOP is sparse, and a /8 is a lot of address space.
1930 AS space - extended GLOP

The IRR's already do allocation, so why re-invent the wheel ?

Dave Thaler has a scheme to assign 225/8
He went through this and urged that it go to last call.
Dave Meyer noted the complexity of trying to get multicast address space, 
and wondered if it was appropriate to set up another.