Subject: mboned: draft MBONED minutes

From: David Meyer <[email-masked]>
Date: Tue, 9 Nov 2004 10:21:31 -0800

Thanks to Marshall for serving as scribe.

Dave

----

MboneD IETF 61 8 November 2004
------------------------------

Chair:	David Meyer

David Meyer - time is tight, so let's move fast
A new topic is Multi Point LSP's - MPLS Multicast

Brief discussion on drafts in progress :

draft-ietf-mboned-ssm232-08.txt

Ideas for keeping SSM and ASM traffic separate on  real networks.
Waiting on normative reference for the PIM spec

Embedded RP has gone through the IESG and is on track at the editor 
queue

Mroutesec - Also in the editor queue

draft-ietf-mboned-msdp-deploy

This needed a waiver for MSDP (an experimental spec is not generally 
allowed as  a reference in a standards track document ) and is waiting 
on the PIM spec.

IPv6 multicast issue draft - waiting on the AE to approve for the IESG 
or bounce.
It is now out of the WG.

Note that several specs are now being held up by references to the 
still unfinished PIM spec.

Tom Pusateri - the PIM spec is waiting on a few details and needs some 
volunteers
to finish

-------
MSDP MIB.
Bill Fenner - this is making as much progress as usual (i.e., none).
Some changes were promised but now I have forgotten what they were.
Action Item - remember what is needed and ask the group to approve them.

-------
Tom Pusateri  - AMT draft

AMT is a way to have an AMT gateway discover a path from a 
non-multicast site to a native multicast domain

3 way membership handshake has been added, plus a 32 bit nonce based on 
discussions in Seoul.

Why do this ?
Content providers should drive this
  - first at server farms
  - also providers who have multicast enabled upstream provider

3 way handshake
AMT Request with a gateway NONCE (GNONCE) from the gateway
Relay creates a  RNONCE from the  hash  of a secret  with the gateway 
nonce and the group address. It sends the GNONCE and the RNONCE to the 
gateway
the gateway sends back the GNONCE and the RNONCE and the ????

Need - a /16 prefix to deploy and try to do public relay for BGP and 
anycast

Pusateri has FreeBSD gateway / relay code ready for testing.

He wants providers who can provide test relays

Toerless  Eckert :
  Why do we need yet another tunnel mechanism ? Why not IPSec ?
Or another existing tunnel protocol ?

Pusateri - this is based on the IPv6  6to4

This uses the existing tunnel mechanism of 6to4

Dave Thaler - this has been asked in the past. The difference is 
primarily at the server end. The primary benefit is on  the server side

Toerless - I would not worry about the scalability
Hopefully this will lead to adoption, so it is not clear why 
scalability is an issue, and deployment will be self limited.

I do not think that the difference from this and existing tunnels is 
that essential.

Pekka Savola - it is

Toerless - if you cannot provide at least 200 to 300 kbps per tunnel, 
what is the point.

Pekka Savola - for DSL aggregation, there can be a lot of L2TP

Isadore -- This does require state per client per stream. This cannot 
be escaped

Dave Thaler - but there is not  state for idle clients

David Meyer - If you want to see other encapsulations (i.e., existing 
tunnel mechanisms)  used for this purpose, you need to make an 
objection and write a draft.
----
Dave Thaler
Unicast prefix based multicast addresses.

People ask - "Is there interest in this ?", so I sent out a message to 
group. No responses as yet.

This is not intended to replace the  IPv4 GLOP space system, but to 
extend it.

Is there interest - so I asked the group, is there still interest.
There is very little work to do.

Toerless - We should use SSM for interdomain multicast. This draft 
leads in  the wrong way. This  also needs a lot of address space - a 
complete /8

Pekka Savola -  It is important to note that you get one address per 
/24, which is not a lot.

David Meyer - Let's take this to the list.

Pekka Savola. I notice that there is not yet a current and up to date 
documentation for multicast addressing. There are some confusing or 
even wrong earlier documents.

IANA also needs something to point to when people request multicast  
address from then.

I have separated assignment from allocation

Multicast address discovery is an open question but in practice is not 
being done.

Open Issues
Is making RFC2908 historic appropriate.

My question to you is - would this be a useful document ?

Toerless - this would be a nice BCP

It may be that "architecture" should be removed from the document.

Pekka Savola. I think that your interpretation of "architecture" is a 
little more formal than mine.

Toerless - It is

Mark Handley - As an author, I think the RFC2908 should be replaced. 
The word architecture should be kept in the title so that people 
looking for the old one will find this one.

---
Rami Lehtonen
Multicast source discovery for SSM
For the one to many model, sources can be discovered out of band

For many-to many or many to one, need source discovery

Why in the host ?

This can be deployed rapidly and co-exists with existing SD protocols

No RP's are needed, and there is no traffic

New source sends MSDP to a group controller.

This can be implemented in the network or in the edge hosts

Toerless - do all of the channels have to use the same G ? You should 
not
try to  restrict all of the channels to use the same G.

Colin Perkins - what problems does this solve ?
If I am using ASM for service discovery, then

Colin - I cannot see any  applications that can use this.

Steve ? - The idea here is that you can announce the (S.G) for SSM.
Is there a standardized way to do this ?

Colin : SIP

Toerless : It would be useful if Colin could give a presentation to 
describe how do this. Or write a draft.

Colin : There are 3000 pages of RFC that describe this

Toerless : That's too many pages for this purpose. Write us a draft.

Steve - I have applications that I know how to do this with ASM. I 
would like an easy way on how to do this for SSM.

Colin - Go and talk the SIPPING working group. That is what they do.

-----
H. Ohta

"Well managed IP multicasting"

Network operators want to
- build efficient networks
- create value added services
- build manageable networks

IGMP / MLD does not provide accounting

Network cannot identify or authenticate or authorize users or keep 
track of usage

This is not sufficient for carrier class services (high quality premium 
or fee based).

Content providers also want this

Dave Thaler : Are the existing mechanisms sufficient ?

Pekka Savola : I think that existing ISPs can do all of this using 
existing mechanisms

Haixiang He : Layer 2 authentication is not good enough as the link 
account provider and the  content provider  may not be the same party.

Dave Thaler : Layer 3 solutions involving only
IGMP and MLD are not at the right layer. For the last hop L2 mechanisms 
  are a much better fit. If you are talking about end to end then I can 
agree that this is necessary. You might want to remove the IGMP and MLD 
from this discussion.

Ohta :
We need to make it possible for network operators and content providers 
cooperate and both make money. They need to share revenue, and this 
means that they need to measure usage. Content providers are not good 
for networks and network providers are not good for network, They both 
need to cooperate.

I want to find out if the MBONED network

[email-masked]

http://standards.nortelnetworks.com/archives/mac-external.html

Dan Alveraz: MBONED needs to support different business models for
multicast. I want the MBONED group to be a repository for all
multicast work. I want to evolve this into a framework and
requirements document. 

Pekka Savola : I think that in general this work is useful, and that 
the current approach is not really useful. We need to take this one 
level to a frameworks and requirements draft.

Dan of Cisco  - That is what this draft is trying to do.

David Meyer - How many in the WG think that we should take this on ?
(Show of hands - a majority yes, but definitely some no.)

-----------------------------
David Meyer - Let's shift gears to P2MP

This is in cooperation with the L3VPN group.

Generic issue - how do we set up multipoint forwarding paths.
This is just getting attention in the MPLS world.

Issues include

  - forwarding state vs tree construction cost

  - efficiency of forwarding path

The last IETF there was the YCAI presentation for L4VPNs and MP-LSP's

Claim : This is still a multipoint tree building problem, and previous 
work should be leveraged. Same issues, some different

Several good attempts to describe a framework, but they also include a 
solution, which muddies the waters.

Can the group come up with a framework via IMDOC ?
I propose that we produce a framework draft and requirements draft and 
cleanly separate those two.

IMDOC and MBONED are focused on functional proposals into a logical 
architecture

Yakov Richter - You mentioned a need to work on a requirements document.
There is ongoing work in L3VPN for multicast requirements. 
There is also a L2VPN requirements document in existence. What will 
this third requirements document service. Requirements document makes 
sense in the

John Meylor - One thing that would be useful is some requirements 
between them. I think that the best thing for MBONED is to extract the 
common points out of this.

Nudula - I think that the applications group should have a requirements 
document. If they feel a need for multicast help, they can come to the 
appropriate multicast working group.

Ne Ching from Cisco - The multicast requirements document should 
include MORE than just the particular and specific requirements for 
each particular area (such as L3VPN

Toerless - what we have is a service model. RFC2547 and other 
architechtures are coming up that have no common frameworks

Yakov. Talking about a service model in the abstract is pointless 
unless you talk about the particular service.

David Meyer - Last one

-----
George Swallow - [email-masked]

The setting

Within MPLS, some people are interested in point to multipoint 
distribution of large (video) flows with QOS and high availability

The MPLS mentions multicast but "I am not sure that that sentence is 
parsable."
Dino F started this work, but it has gone fallow and needs to be 
restarted.

MPLS is NOT chartered to redefine or replace IP multicast

P2MP TE - exists below the IP layer

How the set of destination s is determined is outside of the scope

Iit may be useful to extend PIM and or MBGP to handle P2MP TWE tunnels.

This is not the job of the MPLS WG

We are chartered to think about requirements but not to resolve them.

Eric - I think that your charter is defective

Swallow - When the charter was broader, we got a lot of bozons involved 
who wanted to re-define everything

------
Mike McBride - The PIM charter says that PIMWG will act as consultants 
for proposals for "PIM over foo". The area directors did not want us to 
expand our charter until we finished our basic documents, which we have 
nearly done and now the area directors are willing to allow us to 
expand our charter.

Tom Pusateri - We are not _looking_ for new work in the PIM WG, but we 
will consider new requirements if they are brought to us.

Mike McBride - We are open to this, but we need some guidance from 
MBONED as to what we should do.

-------------
Seisho Yasukawa - P2MP TE

TE is used to provide QOS "guarantees"

MPLS is a suitable solution for this.

What is P2MP TE ?

A TE tunnel with one source and multiple destinations
This should be application agnostic.

P2MP TE tunnels should have unique P2MP ID's

Need mechanisms for tunnel establishment, teardown, failure reporting, 
call admission control, QOS, etc.

GMPLS should be applicable

Some issues

LSP (Label Switched Path) variation on different LSP branches ?
Can short term data duplication be tolerated when there is tree 
modification ?
What are the limits and design targets?
------
Dimitri Papadimitrou

P2MP solutions and properties based on RSVP

Features include ;

    explicit source routing

    tree is expected to show homogeneous QOS parameters

    need means to delete parts of the tree without affecting other parts 
of the tree

Specific issues are still under discussion and we invite advice from 
the multicast community.

John Meylor  - we need a complete survey of the different multipoint 
solutions that are available.

Yakov - That is an excellent suggestion, for the L2VPN or L3VPN working 
groups.

David Meyer - We wanted to have MPLS in this group as the multicast 
people were not providing input into those working groups.

Adrian Farrel - Detecting P2MP Data Plane Failures.

There is a need to create analogues of the traditional internet tools 
such as ping and trace for P2MP solutions.

For PING, the ping hits all of the egresses, and if it them all, it can 
flood the ingress.
Two solutions - rate limiting, or specifying a specific receiver.

Traceroute has a similar problem.

Dave Thaler - For multicast, the mtrace goes from the receiver to sender

Haixiang He  - using mtrace the response is unicast

Bill Fenner - the group is specified in the request. It can be either 
unicast or multicast.
----
Pekka Savola

Documentation on multicast threats has been lacking. We just finished 
one document, but we need another for first hop multicast threats.

This falls between PIM and MAGMA working groups.

Dave Thaler - I think that this should be done in MAGMA and PIM as 
appropriate.
These threats are not really protocol independent

David Meyer - We are talking about threat analysis, not the solution

Tom Pusateri - As we advance the PIM spec, we could and should include 
this in the PIM WG

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Nov 2004 13:59:09 +0200 (EET)

Just one question.. because I seem to be forgetting what was the 
result of the "Well managed IP multicasting" discussion; below:

> (Show of hands - a majority yes, but definitely some no.)

Was the last one what was asked?  My recollection of the events is 
pretty dim, but at least I seemed to recall the WG was just asked 
whether they considered this as an important problem space (and not 
so much about the draft itself).  Maybe 'this' in the minutes needs be 
expanded, at least...

What about others-- anyone remember?

I think I'd definitely remember if there would have been consensus to 
take this as WG item, for which there wasn't AFAIR.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: David Meyer <[email-masked]>
Date: Fri, 19 Nov 2004 08:27:25 -0800

>> take this as WG item, for which there wasn't AFAIR.

	There wasn't.

	Dave

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 19 Nov 2004 12:28:58 -0500

On Fri, 19 Nov 2004 13:59:09 +0200 (EET)
> result of the "Well managed IP multicasting" discussion; below:

You are correct and the "this" refers to the general expansion of work.
There was clearly no consensus on the draft. 

Sorry if this was confusing.

Marshall

---

From: "Daniel Alvarez" <[email-masked]>
Date: Fri, 19 Nov 2004 10:30:56 -0800

Since there was a fairly large majority in support of this work, I'm curious
to see what changes to the draft would be necessary to adopt it as a WG doc.
Currently the goal of the draft is to present requirements for new comercial
deployments of mcast; with the objective of developing solutions, and
addressing gaps in those solutions via new architectures, combination of
existing protocols or new protocols if necessary. 

dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of David Meyer
Sent: Friday, November 19, 2004 8:27 AM
To: Pekka Savola
Cc: [email-masked]
Subject: Re: mboned: draft MBONED minutes

On Fri, Nov 19, 2004 at 01:59:09PM +0200, Pekka Savola wrote:
>> >This is not sufficient for carrier class services (high quality 
>> >premium or fee based).
>> >
>> >Dave Thaler : Layer 3 solutions involving only IGMP and MLD are not 
>> >at the right layer. For the last hop L2 mechanisms  are a much 
>> >better fit. If you are talking about end to end then I can agree 
>> >that this is necessary. You might want to remove the IGMP and MLD 
>> >from this discussion.
>> >
>> >Ohta :
>> >We need to make it possible for network operators and content 
>> >providers cooperate and both make money. They need to share revenue, 
>> >and this means that they need to measure usage. Content providers 
>> >are not good for networks and network providers are not good for 
>> >network, They both need to cooperate.
>> >
>> so much about the draft itself).  Maybe 'this' in the minutes needs 
>> be expanded, at least...
>> 

	There wasn't.

	Dave

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Nov 2004 20:42:01 +0200 (EET)

On Fri, 19 Nov 2004, Daniel Alvarez wrote:
> Since there was a fairly large majority in support of this work, I'm 
> curious to see what changes to the draft would be necessary to adopt 
> it as a WG doc. Currently the goal of the draft is to present 
> requirements for new comercial deployments of mcast; with the 
> objective of developing solutions, and addressing gaps in those 
> solutions via new architectures, combination of existing protocols 
> or new protocols if necessary.

IMHO, FWIW, It needs to be completely untangled from the mindset of 
IGMP/MLD-based solutions, not to be assumptive of them -- and 
describing better and in more general the actual problems and 
requirements.

The first version was pretty much "see, we need IGMP-based 
accounting".  The second version was much better, but there is still 
some way to go.

---

From: "Daniel Alvarez" <[email-masked]>
Date: Fri, 19 Nov 2004 12:05:19 -0800

Pekka,

Fully agree, the detailing of the solution(s) will be left to other drafts.
The goal of this draft should be to explain and agree on the problem set.

Thanks

dan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Pekka Savola
Sent: Friday, November 19, 2004 10:42 AM
To: Daniel Alvarez
Cc: 'David Meyer'; [email-masked]
Subject: RE: mboned: draft MBONED minutes

On Fri, 19 Nov 2004, Daniel Alvarez wrote:
> solutions via new architectures, combination of existing protocols or 
> new protocols if necessary.

IMHO, FWIW, It needs to be completely untangled from the mindset of
IGMP/MLD-based solutions, not to be assumptive of them -- and describing
better and in more general the actual problems and requirements.

The first version was pretty much "see, we need IGMP-based accounting".  The
second version was much better, but there is still some way to go.

---

From: Hiroaki Satou <[email-masked]>
Date: Tue, 30 Nov 2004 17:44:31 +0900

Hi

As an author of the "Accouting Issues In Well Managed IP
Multicasting Services" (draft-hayashi-maccnt-01.txt)  I would
like to emphasize what Dan said that our goal is to develop a
requirement draft upon which we can reach a consensus and which
will lay the groundwork for a framework draft.  It was clear at
the IETF mboned session that people think this is an important
issue that deserves attention and the first step in my opinion
is to come to a consensus on what requirements there are for
multicasting services in accounting to better support commercial
deployments.

We have received feedback about "Accouting Issues In Well
Managed IP Multicasting Services" (draft-hayashi-maccnt-01.txt)
from a few sources including this 1) mboned mailing list, 2) the
mac-external mailing list
http://standards.nortelnetworks.com/archives/mac-external.html
3) and the mboned session at IETF 61.
and are considering the feedback as we work on the next version
of draft-hayashi-maccnt-02.txt.(within Dec.)  We would like any further input
from people who have a stake in these issues to improve the
document and make it acceptable to the WG.

---

From: "Marshall Eubanks" <[email-masked]>
Date: Tue, 30 Nov 2004 10:20:23 -0500

On Tue, 30 Nov 2004 17:44:31 +0900
> http://standards.nortelnetworks.com/archives/mac-external.html

Dear Hiroaki;

Is this an open list ? Do you join in the usual fashion ? There is
no indication of such administrivia on this web page.

Regards
Marshall Eubanks

---

From: Haixiang He <[email-masked]>
Date: Tue, 30 Nov 2004 11:30:30 -0500

Marshall,

It is an open list.

To join the mailing list, just send a blank mail to
<[email-masked]> and reply to the
confirmation mail you will receive.  Please note that the
confirmation message indicates to reply to a different address
from the one the 'reply' command generates.  Please do not
worry and just reply using 'reply' command.

thanks,
haixiang

Marshall Eubanks wrote:

> <http://darkwing.uoregon.edu/%7Ellynch/mboned.html>
> <http://darkwing.uoregon.edu/%7Ellynch/mboned/>
> >  >
> <http://darkwing.uoregon.edu/%7Ellynch/mboned.html>
> <http://darkwing.uoregon.edu/%7Ellynch/mboned/>
> >
> <http://darkwing.uoregon.edu/%7Ellynch/mboned.html>
> <http://darkwing.uoregon.edu/%7Ellynch/mboned/>
>
> <http://darkwing.uoregon.edu/%7Ellynch/mboned.html>
> <http://darkwing.uoregon.edu/%7Ellynch/mboned/>
>

---

From: Hiroaki Satou <[email-masked]>
Date: Wed, 01 Dec 2004 10:12:27 +0900

Hi

Yes, it's open.
You can join this list, just to send a blank mail to
<[email-masked]> and to reply to the
confirmation mail you will receive.