MBONED Nov 11, 2003

MSDP is finally through

Cannot close the working group because there is not a MIB yet.

Dave Thaler :
I do not know what the current status of the MIB is. Bill Fenner is the  
primary owner.

Bill Fenner:
So, the update is that I have polled for MIB implementations. I know  that 
Cisco has one. Looking at the evolution of the MSDP MIB and  protocol, I 
backed the MIB down to more or less what Cisco has  implemented. A couple 
tweaks and it should be ready for last call.

Dave Meyer:
Do you think we can working group last call it after the IETF.

Bill Fenner:
Yes.

Meyer:
Drafts on MSDP deployment and SSM 232 are both at the IESG waiting on  last 
call.

Bill Nickless :

draft-ietf-mboned-ipv4-mcast-unusable-00.txt

I ran into problems with IGMP snooping switches, because of MAC  
collisions. I thought these should be brought out in a document. 
However, I had feedback from the group suggesting

The two approaches are

- accept everything except those that are globally "unusable" (because  of 
MAC collisions, because of  their site local only use, etc.)

- deny everything except what IANA has reserved specifically for  
multicast.

Which should we do ?

Beau Williamson :
I think that there should be a big address space that is allowed, and  then 
everything else

Dave Meyer I think that this should become like unicast addresses. Never 
allocate  anything unless it is absolutely necessary. Most people who ask 
for  multicast addresses do not really know what they are asking for.

I do not want this or any other working group to become the multicast  
address space routing registry.

Also, there is the extended GLOP space which the IANA and a Routing  
Registry - we  need to push this through and we need volunteers to help  
with this.

Audience Member:
I think we are heading for trouble if we block out lots of address  
space.

Marshall Eubanks:
I agree. If we do this I fear that the space blocked out will never be  
useable due to the inertia of the system.

Also, I see need for extended GLOP address space and want to work to help 
get that set up.

Beau Williamson:
We need to make sure that we can limit what is unusable to a 
reasonable  amount.

Hugh Holbrook:
For SSM snooping, these are more operational practice issue than Many 
companies, including my own, are going to Layer 3 snooping, where  we look at 
IP addresses instead of MAC addresses, so we don't have the  problems with 
MAC address. Maybe this should be a BCP or informational.

Beau Williamson:
I am starting to see address allocation problems inside enterprises -  
where they do not understand the relationship between their address  usage 
which causes problems.

I want to work on a multicast address allocation document.

My goal is to put together an informational draft that explains the  
issues for everyone, both inside the enterprise and globally.

Dave Meyer:
The problem that we are facing is that people want unique addresses,  and 
they use one they got a long time ago or just make one up.

So we get requests from financial organizations for /18 in the  
multicast address range, which they don't need, and this is a problem.

Kevin Almeroth:
Does this relate to the updated 3171 ?

Dave Meyer:
Yes.

I updated rfc3171 because there were /8's that were not being used.

<Consensus was obtained to update and finish the draft as is (i.e.,  with 
narrow scoping).>


---------------------------------------------------------- Pekka Savola / 
Toerless Eckert

Embedded RP for IPv6 - Issues

Focused on PIM-SM not BiDir - it is more complex and not clear how to  make 
it work.

Hugh Holbrook :
Why doesn't BiDir work ?

Toerless Eckert:
The problem is that the Designated Forwarder (DF) election would have  to be 
done before you send the first packet - it needs to be  
pre-calculated and embedded in the group address. It is too much work  to do 
this globally.

Pekka:
Open issues.

SPT threshold is not addressed in current implementations.

- There are security issues

Sender side DOS attacks Old ASM - MSDP floods SSM - Only first hop router is 
flooded Embedded RP - the embedded RP is flooded No multicast state, 
though

Receiver Side is very similar to SSM

Is this critical ?

Marshall Eubanks:
The vulnerabilities seem similar in danger to SSM, which I think renders 
them acceptable.

Also, if I embed your IP address (not a router, just a random address)  in a 
embedded RP address, can't I DOS your (or any arbitrary) IP address. This is a 
little different from SSM, where I can only DOS your RP.

Pekka:
Yes.

Tom Pusateri:
This will require changes to RPs and elsewhere. Does a protocol change  
belong in an operational group ?

Dave Meyer:
Yes, this is an operational group, but if we see something that's  
needed, and its not getting done, we need to do it.

----- Toerless Eckert :

We need to create an IP Multicast Address-Plan This is enforced today by 
manual allocation & scoping within a PIM  domain. In a PIM domain, this is 
fine, as it sits inside an AS.

With embedded RP, the PIM domain becomes bigger than an AS, so the  
binary discussion between inter and intra domain becomes no longer 
adequate.

This is too simple - the inter vs intra domain decision should become a  
sliding scale.

Dave Meyer:
I have never seen a document which says how to allocate RFC1918  
addresses. Why do we need one now ?

Toerless Eckert:
Proposal :
Leave the lower 7 bits of the Group ID bit open for different service  
models, to be defined later.

For example, a bit saying "only accept multicast data from sources in  the 
same address block as the source" would help avoid traffic  
interference in few to many ASM multicasts.

Lenny Guilani :
If you want to do interdomain multi source does that mean that the  
sources DF is going to register with the RP?

This is basic to any embedded RP. I just think that we need to decide  how to 
handle the multi-domain case.

Lenny Guiliani:
How is anycast RP done in embedded RP ?

Toerless:
I took this slide out, but I do not think that this is a problem.

Dave Meyer:
Is it possible to merge this up into one document ?

Toerless Eckert:
I don't think that we should do this. What's the need to allocate all  of 
the bits right from the start.

Hugh Holbrook:
It seems that this a point with minor operational issues which should  be 
moved forward.

<consensus was obtained to continue moving forward with the embedded RP  
proposals>

------- Lenny Guiliani:
Framework for deploying IPv6 Multicast

Competing idea :
Just do SSM interdomain for IPv6 Intradomain - do what you want.

Dave Meyer:
The authors felt that since the embedded RP draft is moving  forward, this 
draft was dead. I wanted to explore to see if this could  be continued as a 
BCP or something similar.

Lenny Guilani:
We could do anything from simply deprecating ASM to saying that SSM is  the 
long term solution.

The authors favor the deprecating ASM option.

Kevin Almeroth:
I would say that it should say that SSM must be done.

Dave Thaler:
I do not want for application developers to say that "we need ASM, so  we 
can't use IPv6." I do not want disincentives to not to use IPv6.

I suggest Option 3.b, just telling people that SSM is the way to go.

John Meylor:
It is a moot point to a degree, as there are embedded RP solutions out  
there already. Maybe the market will deprecate ASM in the long run.

Pekka S.:
One thing that might be useful is a framework document describing when  to 
use SSM and when to use embedded RP.

Tim C:
In the Op6 group there are documents on how to move applications to  IPv6. Is 
there such a document on how you move to SSM ?

Lenny Guilani:

John Meylor:
Is there a detailed description on how to do multisource with SSM ?

Hugh Holbrook :
This is missing.

Dave Meyer:
What we really need is a deployment document that describes  
functionalities we have and how to achieve them.

Lenny Guiliani:
Wouldn't this be a "yeah we already know that"

Dave Meyer:
I do not think that anyone has a done a detailed gap analysis on either  
side.

Kevin Almeroth:
Isn't SSM the lowest common denominator ? If they support any PIM,  
shouldn't we say that they have to support SSM ?

Dave Meyer:
The analysis needs to be done before we say that.

Dave Meyer:
I do not think that there is any consensus here, so I will take this to  the 
list.

------- Dave Meyer:

The 3171 guidelines to IANA has expired.

There are 4 other drafts that have expired. I want to try and revive  all of 
these.

Dave Thaler:
My draft was at the IESG waiting for approval. I can revive it easily  if 
there is interest.

------- Hugh Holbrook - Update on the Apple IPR issue for SSM

Apple claims that a patent that they own is infringed on by SSM.  It  says 
that they want reasonable and non-discriminatory licenses

SSM is a core technology, so this issue cannot be fudged. This will be 
discussed at the SSM WG

We do use a lot of IPR-impacted technology in the IETF. We need to make  a 
risk-benefit decision before we move forward.

Mike Luby:
Have you talked to Apple recently ?

Hugh Holbrook:
I talked to Apple through the back door recently, but they were not  very 
open to changing the wording. They point to all of the similar  wording on 
the IETF IPR.

Audience Member:
When was this patent granted?

Hugh Holbrook:
Granted 1996 - the creator was Mark Green, who is still around.

Dino F. I was working with Mark Green on this, and they would not likely 
view  this applying to the ASM parts of PIM-SM.

Kevin Almeroth:
This same risk applies to pretty much everything

Bill Fenner:
You are only required to disclose IPR if you are working on a spec. The  
simple fact that Apple has come forward with this when they could have 
waited should not be viewed as requiring us to do anything about it.

Dino F.:
Apple didn't wait. We were worried that PIM was infringing, so it was  
brought to their attention.

------ Kevin Almeroth:
We need better feedback tools. If we are not receiving traffic, we need  
tools to decide what is going wrong.

Ideas :
SSM ping - establish SSM reachability. Is there a new ICMP message  
needed ? What are the security issues ?

The mechanism for trying multicast now - join and wait - is just not  
robust enough.

Kamil Sarac wrote a preliminary draft. Is there interest ?

Pekka S. There is a similar problem with embedded RP. There is a 
potential for DOS attacks

Louis Lamenkis:
In my previous life as an operator, there was a definite need for this.

Beau Williamson:
What we really need is a replacement for mtrace, which seems to be  
broken now.

Kevin Almeroth:
We also need to get feedback from first hop routers - do they support  
IGMPv3 ? Am I sending (S,G)  in an ASM range or a (*,G) in an SSM range  ? We 
need better feedback.

There have been a lot of us who have worked on this. The tools are  still 
really primitive.

Louis Lamenkis:
There are overlapping problems here. One problem I had was, "is the  first 
hop router multicast capable" ? One size does not fit all.

Dave Thaler:
What are the problems with the current mtrace ? (Besides MSDP.)

Bill Fenner:
Are these implementation problems or protocol problems ?

Dave Thaler:
Before MSDP, mtrace seemed to work fine

Bill Nickless:
mtrace is not useful for when you have a RP with any sort of tree  
switching

Dave Meyer:
Our charter (when revised) will definitely include

Marshall Eubanks:
What about the various multicast beacon groups and their software tools    ?

Kevin Almeroth:
That doesn't help application writers

Marshall Eubanks:
So you would put mping in an application ?

Kevin Almeroth:
Yes.

John Meylor:
Is mping the most important thing ? I would say that mtrace is.

Kevin Almeroth:
That's an implementation issue, not a WG issue.

John Meylor:
A posted draft for mtrace would be really useful.

-------------------- FLUTE:

Rod Walsh

FLUTE == File delivery over Unidirectional Transport

Based on ALC & LCT but fully specified

3 genetically different implementations now

FLUTES from INRIA TUT (Tampere Finland) Nokia U. Bremen

Interop testing 2 and 3 way testing - multicast and unicast working 
towards a 4 way test.

Need a new Interoperability Testing Guideline document.

RMT is likely to go dormant soon, so we need to know if we can do this  in 
MBONED.

Toerless Eckert:
This is router based, right ? Are there any implementations that do the  
router based congestion control ?

  Lorenzo Vicisano There are no implementations with built in (non end to 
end) congestion  control.

Dave Meyer:
I think that this is outside the scope of this working group.

Tom Pusateri:
I don't think that being in or out of scope of the  charter is relevant to 
this working group!

Dave Meyer:
Point taken. I would be concerned about our competency to do this.

Lorenzo Vicisano We will continue this in RMT. The only question was the  
interoperability testing.

Rod Walsh:
There will be a document for interoperability guidelines

Mike Luby:
Where will it be published ?

Rod Walsh:
This is open, but it sounds like it should be RMT.

------- John Meylor IMDOC Internet Multicast Documentation

Problem :
There tends to be holes in deployment. Some Issues -

Multisource use for SSM ? or Tunnel use for initial deployment .

Topics fall through the cracks, as so much is spread over various  
working groups.

Also, build it and they will come has not worked in practice.

Need :
Process to track these issues across working groups

draft-meyer-mboned-ipmcarch-00.txt

Handle in MBONED with no extra WG needed.

Dave Meyer:
People have asked - is this a directorate ? This comes from the AD's.  
Unless and until the ADs ask for a Directorate we will do this here.

If IMDOC did recognize a real gap or hole in the current work, then  they 
could propose to the AD's that a given working group be pushed to  handle 
it.

Toerless Eckert:
Couldn't this lead to protocol changes or enhancements ?

Dave Meyer:
IMDOC is a process. It is not our intention to write protocols - that  
should be left to others.

John Meylor:
Our goals are to 1.) write down a framework 2.) discuss input 3.) set 
priorities !