Subject: mboned: updated MBONED minutes

From: David Meyer <[email-masked]>
Date: Tue, 22 Mar 2005 11:51:17 -0800

MBONE Deployment WG (mboned)

MONDAY, March 7, 2005 (0900-1130) 
=================================

CHAIR: David Meyer <[email-masked]>
MINUTES: Marshall Eubanks <[email-masked]>

AGENDA

 o Administriva

   - Mailing list: [email-masked]
     subscribe mboned

   - Scribe(s)?

   - Blue Sheets

 o Agenda Bashing                                                5 minutes
   Meyer                                           

 o Review and status of work items                      

   Active Drafts
   -------------
   draft-ietf-mboned-addrarch-01.txt				 5 minutes 
     Savola
   draft-ietf-mboned-auto-multicast-04.txt			 5 minutes
     Thaler, et al.
   draft-ietf-mboned-ipv6-multicast-issues-02.txt		10 minutes
     Savola

   Expired Drafts
   -------------
   draft-ietf-mboned-rfc3171bis-03.txt				 5 minutes 
      Meyer

   Potential WG Drafts
   ------------------
   draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-01.txt	 7 minutes
     Durand
   draft-jdurand-ipv6-multicast-ra-00.txt			 8 minutes
     Durand 
   draft-lehtonen-mboned-dynssm-req-00.txt			10 minutes
    Venaas
   draft-savola-mboned-address-discovery-problems-00.txt	10 minutes
     Savola
   draft-savola-mboned-routingarch-01.txt			 5 minutes
     Savola

   Status/Update
   -------------
   Multicast VPN	 				        20 minutes
     TBD

TUESDAY, March 8, 2005 (1530-1630)
==================================
CHAIR: David Meyer <[email-masked]>
MINUTES: Marshall Eubanks <[email-masked]>

AGENDA

 o Administriva

   - Mailing list: [email-masked]
     subscribe mboned

   - Scribe(s)?

   - Blue Sheets

   Status/Update
   -------------
     Issues Related to Receiver Access Control in the Current  10 minutes
      Multicast Protocols
      draft-hayashi-rac-issues-00.txt
       Hiroaki Sato

     Accounting, Authentication and Authorization Issues in    8 minutes
      Well Managed IP Multicasting Services 
       draft-hayashi-maccnt-02.txt
       Tsunemasa Hayashi

     Using SIP for Multicast Source discovery		       14 minutes
       Eubanks     

Minutes
=======

Greg Shepard is not here
ssm232-07 is hung on the PIM - SM spec, as is
msdp-deploy-5

Pekka Savola - Multicast Address Architecture

Idea is a BCP for multicast addressing

Document is close to convergence and it would be a good
time for the group to read it, before it goes to WG Last call.

Tom Pusateri - Dave Thaler's automatic multicast

AMT -03 to -04 just came out with minor updates.

Media Access Code is generated and verified by the same host,
so the algorithm does not have to be standardized.

An example technique was put in the spec, but it is not required.

Added a UDP source port to MAC

IANA has assigned 2268 as the port number for AMT

Need a /16 prefix for an anycast address, to find relays.

Some firewalls require that the host send traffic out to keep
state in the firewall. IGMP refresh may not be frequent enough.
They recommend making this a tunable parameter.

Dave Meyer : I am going to get together with IANA today to discuss this.

How many people are away of the TC BOF that is at 3:30 today ?
There are a bunch of application specific automatic tunnel protocols 
floating around. People should go to this BOF to see if there is a way 
to use the multicast ideas to create a single
tunnel standard.

Toerless E : Isn't there also a problem with a multicast-like API ?

Dave : That is one possible solution.

Pekka Savola : IPv6 Multicast Deployment

Critique in December was harsh but to the point.
This was not reviewed adequately in the working group.

Issues : Structure and purpose of the document is not clear enough.

Comment by Allison Mankin that she was doubtful about further work on 
ASM, but embedded RP is already there, so ASM is not going away.

Comment that SSM deployment issues are not IPv6 specific, but these do 
not appear elsewhere, and this document seems a good place for them.

Directions : Abandon the work, or get more readers and reviewers.

Dave Meyer : My Internet Draft, Some Issues for Multicast Deployment, 
has timed out a long time ago, but it could be revived. Many of these 
concerns are still there and are coming back, what with multicast L3 
VPN's, etc.

Toerless : Why does this have to be limited to IPv6 ? That would solve 
the SSM scope issues.

Dave Meyer

rfc3171bis-03 timed out inadvertently.
This isn't really helping right now. The intent was to find the way to 
solve the problem of people asking for multicast addresses to solve the 
embedded application problem.

I need to know from the group whether it is worth reviving.

IANA gets two or three of these group address requests per week from 
application writers

Marshall Eubanks - Does that mean that there really a lot more, 10 or 
20 or more per week, as many people won't apply ? That seems like a 
lot.

Dave Meyer : Some history. After Jon Postel passed away, IANA made some 
applications of multicast addresses, particularly to the NASDAQ. Now, 
every financial house comes to them and says, we need a class 16, and 
NASDAQ has space, so why can't we get one ?
I say no, and I get overruled.

Lenny Giuliano : Why can't IANA say, that was then, this is now ?

Dave : That is a legal issue. IANA has exposure.

Dave : With respect to GLOP and every other address application, I have 
built an address state web site that you should follow. I tell
them to do that,
and they just say no.

We have not build a lightweight service discovery protocol that can be 
used in a embedded application devices.

Lenny : What about SAP ?

Dave : It's not reliable enough.

Toerless : It's not as if we haven't gone through the motions before. 
Why not just charge for them ?

Dave : That's the e-glop idea. We tried that, and we could never get it 
instantiate.

Operations AD - I have talked to RIPE and they should be
coming back to this.

Steve Minas - I really can't understand why these people want global 
deployment. Can't we explain why this is not a good idea.

Pekka : We can discuss this later. Even if we gave addresses to RIR
to allocate, they would still go to to IANA.

Dave : But then IANA could just tell them to go to the RIR, and that 
would be sufficient.

[Audience Member] If people think that this is an important issue, I 
would like to take this back to the RIR's.

J. Durand :

[email-masked]

IPV6 Multicast Deployment.

ASM + SSM is working now. Only existing solution for ASM is
RFC 3956 for embedded RP.

The problem is not about address uniqueness, the problem is making sure 
that addresses are picked  which map to a proper RP.

The RP is "chosen" by the application. It could be topologically far 
from the application or the user.

Solutions : MADCAP - can do what we want, but is not deployed and
is rather complex.

Want to use protocols already used for multicast.

Ideas

DHCPv6

Multicast address assignment was easy to add. We can even assign 
prefixes to the host for the host to pick from.

Another ideda was NDP
draft-jdurand-ipv6-multicast-ra-00

Collisions are very unlikely to happen in IPv6 but could be
dealt with if people thought it was necessary.

The problem is different than for IPv4. Only addresses derived from a 
working RP will lead to a working multicast group.

With NDP + DHCPv6, multicast and unicast addressing architecture
becomes the same.

Another idea : What if every DR is a RP ? The RP address is now the
subnet anycast router address. Then embedded RP multicast address can 
be figured out by the application. It seems strange but it should work.

Dave Meyer : Do you run into state synchronization problem with this ?

Durand - with a mechanism like this I do not think that you have any 
redundancy in the RP's/

Pekka - I think that the redundancy comes at the DR level.

Durand : Do we need anything more than MADCAP + manual assignment ?

If yes, which of the 3 proposed solutions (or others) should be
pursued.

Bill Fenner : MADCAP started as a DHCP v4 subset, and was
turned into a different protocol, as it was not a good fit to DHCP.

Pekka : I think it is important to analyze what sort of features
MADCAP have and what IPv6 needs, to make sure we don't make the same 
mistakes.

Steve Vignus : I think DHCP v6 is a much better fit than the
v4 case.

If you do this, do you need to solve other problems than just embedded 
RP, or is that enough ?

Pekke : We are trying to address the 90% case.

Bill Fenner : I would have said that that was the 20% case.

Something to remember is that PIM gives the RP a lot of work, while
the DR does not have a lot to do. If every DR becomes an RP, then small 
boxes may become overloaded.

Durand : Don't you think that the work will be more distributed ?

Bill : For a small edge router, being the RP for even one group may be 
too much work.

Isadore : I do not understand something. If you create the address at 
the time the first sender starts sending, how do the other members 
learn about it.

Toerless : I think that the original ASM model was focused on peer to 
peer applications, but now the focus is on client server applications. 
If there are P2P applications, then embedded RP in this fashion has 
problems - if it's really just the first member in the group, then what 
if his RP goes away ? So you have reliability problems.

Marshall Eubanks - I would personally like to see a solution that 
solves the lightweight discovery problem in v4 and v6 using the same 
tools.

Dave Meyer : Is this a topic that the working group should take on ? 
(Inconclusive show of hands). I think we need to take this to the list.
---
Stig Venaas
Rami Lehtonen / Mickael Hoerdt

SSM applications need to know source addresses. In a videoconferencing 
type environment, this may be difficult, as people may come and go.

We could use embedded RP, but we are trying to do this in the 
application with SSM. Different applications, say in the
same video conference, need to work together. It might be useful to
have an "application RP".

Requirements :

Want performance comparable to ASM
No network requirements except to SSM
Multiple applications on the same host should work
Need to know when sources leaves to tear down the state.

The signally might follow different traffic paths from the data.

Questions : Is this a problem worth looking at ?
Should it be solved here ?

Pekka : I am a bit concerned what we are trying to accomplish. Why do 
we want to do this in SSM ?

Stig : We are trying to have ASM applications work with SSM.

John Meylor : I think that there is value in investigating the 
requirements here.

It was dawning on me that this applies to the multi-point scenarios. A 
lot of the discussions there overlook the dynamics of the applications. 
I think that a little work on a requirements document would be useful.

[Japanese member] : Are you interested in doing this in this WG ?
I think doing requirements and solutions in one place is useful.

Dave : We can do requirements for operations, but officially we do not 
do protocols.

Stig Venaas : Maybe the biggest problem is actually getting in touch 
with application developers.

The end goal is to have a lightweight solution that has no requirements 
on the network except for SSM.

Lenny  : The last two presentations were basically on how to discover 
stuff. If those two are in the charter, why shouldn't this be ?

Stig : We are interested in very dynamic situations, where applications 
  come and go very fast.

---

Pekka

Lightweight Address Discovery

Debated many times, but nothing ever happens.
The discussion does not seem to be converging.

So, it seems to me that the only way to do this is to write drafts.

4 Problems :

- Static Assignments

  - mess up local scoping plans
  - depletes resources
  - doesn't work with embedded RP, as addresses are not correct
  - it's difficult to filter in MSDP

Dave Meyer's insight is that application writers expect that the app 
might have to be used between sites, so they want global addresses.

Problem Scopes

  - locally scoped addresses from IANA
  - Address discovery within one domain, with a configured domain
  - zero-config single admin address discovery
  - global multiple administration address discovery

We need people to work on this and create I-D's if this is to go
forward.

Dave Meyer : I think that there needs to be some consensus about what 
the problem space really is.

John  Meylor : There was a comment about the expectations of 
application writers. Wasn't there an attempt to write a document about 
this.

Dave Meyer : MADCAP was part of a unified field theory that is no 
longer unified.

Bill Fenner : It is part of an infrastructure and architecture that 
never got deployed.

In the context of embedded RP in IPv6, I think that MADCAP could be a 
reasonable solution.

Dave Thaler was more involved. Maybe he remembers more about what the 
problems were.

Dave Meyer : I  think that it would be worthwhile to document this.

Stig : I think that the most complex parts of MADCAP was the problem of 
sharing state between servers (different parts of the
organization might be running different DHCP servers).

---
Pekka - Multicast Addressing Architecture

We need a short overview for new-comers and operators.

This also obsoletes MOSPF, BGMP and CBT.

About five people have reviewed this so far.

Any document with a lot of references to other protocols has trouble 
with new protocols, so we suggest that we don't discuss protocols that 
haven't gone to the IESG yet.

Tom Pusateri :

Why do you consider MOSPF to be historic ?

Pekka : If I understand it correctly, neither Juniper nor
Cisco implements it.

Tom : It has its place

Dave Meyer : I think that NASA Science Internet has a large MOSPF 
deployment.

Pekka : Historic doesn't mean that its obsolete or not used,
just that it's not the current state of the art.

This reflects my understanding of what historic meant.

Tom P. I think that MOSPF could be placed in the same category as DVMRP.

Dave M. Personally I think that we haven't done enough

I also think that the term historic is loaded and should be avoided.

Dave Meylor : I think that we are beginning to see other
working groups make assumptions about what multicast protocols are 
supported.

Pekka : As an ISP, I was trying to give some signal about what is 
legacy and what the real status of the protocols is.

Dave Meyer : Bill [Fenner], can you give me an indication of the status 
of the MSDP MIB ?

Bill Fenner : I have to add some words to the MIB saying why the MSDP 
MIB is IPv4 only. So I need to add two sentences to the draft and 
resubmit.

-----
Multicast VPN

Yiqun Cai
[email-masked]

Development really started in the 1990's, but first draft is
draft-rosen-vpn-mcast-00.txt

Multicast was added to the charter in Seoul, 2004

Last year in San Diego, draft-rosen-vpn-mcast-07.txt was accepted as a 
L3 VPN document.

Also, start of scaling discussion, including SSM.

A number of drafts were submitted for the IETF in DC in Fall 2004.

Since there are multiple solutions, there was a need to merge them.

New draft will be l3vpn-2547bis-mcast-00.txt

This missed the meeting curfew.

Cisco has implemented the 07 version of the rosen draft.

Juniper has shipped a solution based on rosen draft 06.

Other vendors are developing  multicast VPN as well.
Some interop testing.

Significant and growing deployment world-wide since 2003.

A note on the Rosen draft

It's a complete solution

- a balance between optimal traffic distribution and state maintenance

- Inter-AS

- Features have several years of deployment.

The most heated recent discussion topics have been about scaling.

- Control plane scaling
- balance between traffic delivery versus cost.

Ideas :

Use SSM in the core to establish forwarding trees.
- Use of PIM-SM / BiDir is never considered.

PIM Adjacency between PE routers.

Overhead includes PIM Hello's and PIM Join/Prunes.

Is there any Order(MVPN) states in the core ?

In the unicast case, the core does not keep any VPN state.

The trade=off

- No state in the core means that the ingress PE has to maintain all of 
the dynamic membership information

- Aggregation reduces the state in the core, but may result in
sub-optimal forwarding.

- Optimal traffic distribution requires extra states on the
ingress PE and/or in the core.

So, the optimal solution is likely to be some combination of native 
multicast, unicast replication, and P2MP LSP.

Existing deployments are providing empirical data.

- the base proposal seems to work well for existing multicast.

I do not think that there is a simple one size fits all solution.
Service provider and enterprise networks can have very different 
characteristics. I believe different solutions will be needed.

Questions for the group :

What do we need to do to scale the P routers ? The PE
routers ? Do we want to do both ?

-----------------------------------------------------
2005/3/08
MBONED WG (second session)

=========================================
Tsune Hayashi presents draft-hayashi-maccnt-02.txt

Pekka Savola : minor editorial issue, recommends changing 
title "well-managed multicasting" 
Quick response, channel changes, not a AAA item

consensus to take as working group item, take to mailing 
list for any.

=========================================
Hiroaki Satou presents draft-hayashi-rac-issues-00.txt

Pekka:
Resource protection
  between SP and user can't it be done be existing protocols?
  not clear what draft's relation is to other document
  want to signal admission control?

Hiaxang He: need SLA, intelligent decision based on existing 
  resourcing, 

Pekka: unclear where you want to do between SP and CP, from 
  the last link

Steven Wright, Bellsouth:  many service providers are 
  interested in these issues and it is valuable to document 
  the question.. it is in scope.
  since unicasting has many of the features we are looking 
  for maybe it would be possible to import multicast into 
  unicast.. make unicast protocols support multicasting.

Dave Meyer: need to be careful about pulling protocol 
  not out of scope, but haven't done

Toerless:  less friction if we talk about adding to 
  multicasting protocols, not step on other groups toes.

consensus is to accept this draft as working group item but 
with condition that overlap between drafts is removed.

=========================================
Marshall Eubanks
Using SIP
how do you find out about sources out there?
A little history
- original "package" of multicast media included SAP (2974)
  well though out 
 was well known and simple
- This described announcements that were multicast to a well 
 known group and port 224.2.127.254
- bandwidth was limited 
announce included MIME type followed by SPP file (or equiv)

question is how do I join?

SAP troubles
- SAP in conjunction with sdr was pretty cool
 - TV Guide like capability
 - used for address allocation

ASM oriented
doesn't scale

SIP was orrignally build for th Mbone

Multicast has faded

SIP- 
user agent use edge box, allows user services
is a "push" model send invite, invite contains SDP file

three-way handshare to set up session
URIs are used to identify agents

SIP is ASCII, so the packets are easy to prepare
Applications could send a SIP register packet

- a proxy server on the LAN could listen for this
- no way to force usage of this mechanism to announce info
 - but application writers aren't doing things like that

SIP Session Discovery
-SIP could be used to Multicast INVITEs
 -TTL is RECOMMENDED but not a MUST
 - would work over LAN, but so what?
 - what is gain over SAP
    -not much 
        - still scaling issues
        - however can send to list of names

SIP subscribe
 -RFC sets up a soft-state SUBSCRIPTION list
 - can keep track of users by this mechanism
 - would at least know who joined the group.

Source Discover:
 Forward & Inverse Problems
  - SIP SUBSCRIVE could solve the "forward" source discovery 
 problem Inverse problem
 lehtonen-mboned-dynssm-req-00.txt

  - not likely to be purely "in band" (multicast)
 - cannot be a single central server
  -some purity is likely to be list
  Probably would be more like DNS

 Does not directly solve the TV Guide problem

Collin Perkins:  for TV Guide problems, work in MMUSIC group
   SIP not good for discovery but good for negotiation

Toreless: whether using multicast is used or not is not most 
  important, worried about negotiations in dynamic application

Stig: interested in multiparty SSM.