MBONE Deployment WG (mboned)
WEDNESDAY, November 9, 2005 0900-1130 (Morning Session I)
=========================================================
CHAIR: David Meyer
AGENDA
o Administriva
- Mailing list: majordomo@lists.uoregon.edu
subscribe mboned
- Scribe(s)?
- Blue Sheets
o Agenda Bashing
Meyer
o Review and status of work items
Passed WGLC
-----------
draft-ietf-mboned-addrarch-02.txt 2 minutes
Savola
This document has been revised. John Kristoff requested editorial
changes and meta-context. This draft is on hold pending for the
additional content.
Active Drafts
-------------
draft-ietf-mboned-addrdisc-problems-00.txt 5 minutes
Savola
The author requested additional WG review of this document.
draft-ietf-mboned-routingarch-01.txt 5 minutes
Savola
The author wondered if outside comments should be solicited.
draft-ietf-mboned-maccnt-req-01.txt 7 minutes
Hayashi, et al.
The authors have revised the document with comments and hope to
go to WGLC with a revised draft.
draft-ietf-mboned-rac-issues-01.txt 7 minutes
Sato
The author plans to update including multicast AAA frameworks
with multi-provider networks.
draft-ietf-mboned-msdp-mib-00.txt 5 minutes
Fenner
The author feels that this is ready for WGLC.
Expired Drafts
-------------
draft-ietf-mboned-rfc3171bis-02.txt 5 minutes
Meyer
The WG Chair proposed to leave this one expired.
draft-ietf-mboned-auto-multicast-04.txt 5 minutes
Pusateri, et al.
This draft is not expired, and the author's seek further
implementations.
draft-ietf-mboned-ipv6-multicast-issues-02.txt 5 minutes
Savola
This draft is currently dead, and will not be revived without
interest from the WG.
draft-savola-mboned-address-discovery-problems-00.txt 10 minutes
Savola
This draft is currently dead, and will not be revived without
interest from the WG.
Other
-----
AAA Framework for Multicasting 7 minutes
draft-satou-multiaaa-framework-00.txt
Satou
The authors request that this be considered as a WG item.
Multicast Address Discovery 10 minutes
Williamson
This was not a draft but a proposal for a solution to the
lightweight discovery problem. After extended discussion the
sense of the room seemed supportive of moving towards a solution.
Label Switched Multicast Solutions 10 minutes
Bhaskar/Cia
Experience With Multicast VPN 5 minutes
draft-ycai-mvpn-experience-00.txt
Cai
These two presentations described work in the L3VPN WG and
elsewhere on Multicast VPN's. There was considerable discussion
about the relative role of PIM and BGP in MVPN's.
IP Multicast MIB 5 minutes
McWalter
McWalter briefly described extensions to the PIM MIB. The PIM WG
suggested that this work be done in MBoneD. There was concerns
that the WG may not have the required expertise. This issue will
be taken to the mailing list.
Organizational Issues
Kessens
David Kessens (the AD for this WG) announced that Dave Meyer
would be stepping down as WG chair. He questioned whether the WG
should be shut down; the consensus in the room was that it should
not be.
The room expressed strong appreciation to Dave Meyer for his
efforts as Chair. The question of whether the WG should
re-charter or change direction will be taken to the list.
-----------
Narrative Minutes :
Dave : Welcome. Here is where the list is.
Do we have a jabber scribe ?
Blue sheets are circulating.
We will look at active, expired, and new drafts, and there will be a few
minutes at the end for our AD.
Pekka: draft-ietf-mboned-addrarch-02.txt ? This document passed WGLC
Pekka Savola : OK. This has been revised twice since March. There
were some good comments about eGlop and other things that hadn't
been mentioned. Then after WGLC John Kristoff made some editorial
comments. He also said that he wanted some meta context. I didn't
respond as I didn't have that context. We have similar issues for
the Architecture draft.
Dave : Active drafts - draft-ietf-mboned-addrdisc-problems-00.txt
- Pekka ?
Pekka :
Lightwieght MADPS: There isn't much to say about this
document. The WG hasn't been very active. The last discussion was
in March, and was around whether the enterprises can use the
whole of the 239 scoped block if they want to. It is not clear to
me whether or not we should proceed with this document.
[the scribe agreed to review this document]
[the AD asked for a show of hands re review]
John Meylor : There are going to be a couple of address spots
related to addressing. We should hold the discussion until then.
[draft-ietf-mboned-routingarch-01.txt] Pekka : There has been
some discussion since the last meeting. I added text to explain
by biDir doesn't work in Interdomain. The document has been very
stable.
I am not sure whether or not we should solicit comments from
outside the WG. It might be useful to add historical context. I
don't have all of that information myself.
Dave : I am trying to figure out if we WGLC this whether people
will read it.
Next is Hayashi [draft-ietf-mboned-maccnt-req-01.txt] - Hiroshi
Ohta is presenting.
Ohta : Concerning IP multicast, there are 3 players, content
providers, network operators, and end users. The network
operators want to have the same management capabilities as for
unicast.
Concerning content providers : they want an affordable
infrastructure, QOS, content protection. They also want detailed
usage info.
End users want reliable service.
The draft was updated since two meetings ago. Duplications with
the related draft were removed. The drafts were reorganized to
clarify the role of each draft. There were editorial changes
reflecting the feedback from the meeting.
Recently, we received some comments that were helpful. We propose
to address the comments and publish the revised draft in a few
weeks and then go to last call.
Next steps will include find solutions which meet the requirements.
Dave : If this is stable with the comments from the next round we
will go to WGLC.
draft-ietf-mboned-rac-issues-01.txt
Satou : Many of the issues are not well covered by existing
standards. The first figure shows the multiple entity model,
where a user may subscribe to more than one content provider.
Changes include
- removed unnecessary overlap with requirement draft.
- changed title of section 5.2 to clarify this
- added detailed description of IGMP/MLD with unicast control
- added detailed description of Layer 2 and 3 authentication in section 6.4
[presented a figure showing that current architectures do not
cover their requirements]
Next steps are to update with comments and start discussion on
multicast AAA frameworks with multi-provider networks.
Dave : Next is the MSDP MIB. I think that this piece of history
is ready for WGLC. It's the last piece of the MSDP universe, and
we will WGLC it.
Bill Fenner : There were holes that we were going to clean up
when MSDP went to standards track, but MSDP is not going to
standards track.
Dave : And it's IPv4 only
Dave : Now we will deal with some expired drafts.
draft-ietf-mboned-rfc3171bis-02.txt. I don't know what we can do
with this.
I am proposing to leave this one expired.
AMT [draft-ietf-mboned-auto-multicast-04.txt] : Tom ?
Tom Pusateri : The draft has been updated and it's active. There
was a period when I was learning XML when it went to expired
state, but now it's active. I have to do one more version, and
hopefully we will get that done.
We have got a second implementation going, and if you know of any
others, please let me know.
After this meeting, anyone with any interest, we are going to get
together and discuss deployment
Dave Thaler : We have an implementation in progress.
Dave Thaler : Me and my co-authors.
Dave : Next is IPv6 Multicast Issues
[draft-ietf-mboned-ipv6-multicast-issues-02.txt]. Pekka ?
Pekka : I didn't make a presentation as this document is
basically dead. There was a feeling that this wasn't useful
enough. There was discussion that this should be combined with
other expired drafts. If people are interested, I would encourage
them to pick up the ball and write something.
Marshall : I think that this should be dealt with in the context
of a general review of expired drafts.
Dave : Any of these things requires someone who is going to step
up and work on it. Otherwise, they become academic, if nobody is
going to work on it.
Dave Kessens : Quite frankly, I feel that we should let the
expired rest in peace. If new people want to bring up the topic,
they can work on it.
Dave : As part of the process, we want to make sure we air all of
this stuff.
Next is draft-savola-mboned-address-discovery-problems-00.txt
Pekka : There was stuff in this one that wasn't in other drafts,
but currently it is dead.
Dave : So 3171bis is dead, AMT is not expired, multicast-issues,
and address discovery is RIP.
Next is AAA Framework for Multicasting [draft-satou-multiaaa-framework-00.txt].
Hiroaki Satou : We want to start discussion. We have a
requirements draft and an issues draft.
We present a new framework, where content providers functions
include user ID assignment, network providers are responsible for
forwarding requests to the appropriate content providers. We
define user access requests, UNI (user -> network) and NNI
(network -> content providers) requests.
We want feedback from the WG, and wish for acceptance as a WG
item.
Dave : This is something that will have to go to the list.
Dave Thaler : I don't think this should be a working group
document in this WG. It should be in the AAA WG. This is an OPS
area.
Also, can I ask a clarifying question or two ? (Please.)
There was a earlier presentation. Does this architecture mirror
the way that things are done for unicast ? Is the proposal
similar
Hiroaki : We want the capability. We don't have the same
framework. We want the capability but don't need the same
framework.
John Meylor : I think that the objective is very good. Whether or
not you can achieve it here is another question.
Within unicast AAA there are a number of different models. The
objective is a good general objective.
I think that this is an opportunity for the operational WG to
take on these documents and try and achieve parity. Ultimately,
it might be better to move to AAA, but at this point in time this
WG is where the required expertise is.
Dave Thaler : My comment was about this draft specifically, not
the requirements and issues one.
Ohta : I agree that this is not the place to discuss protocol,
but I think it is a goods place to discuss framework. I believe
framework can be discussed here.
John Meylor : I agree with that. We need to work out the parts
that are unique to multicast before we go forward. Once that's
done, I am not sure that AAA WG will even understand what to do
with that.
Dave Thaler : I agree with what John said.
Is the assumption that every network provider of interest knows
who the content provider is ? Are there no intermediaries ?
In other words, every network provider must have a direct
relationship with the CP for AAA ?
Hiroshi Ohta : That is our assumption.
Dave T : Is that the same assumption as in unicast ?
Dave M : No. It is not the case in unicast.
John M : And that is why it would be good for us to do a little
homework. There are some parallels with unicast, but there are
some things where there are differences.
Dave M : This is a question of who actually owns the subscriber,
Dave T : This has been discussed in many previous MBones. Given
that the its not clear to me that the network actually cares
about Content AAA, this
That was the case where you had the single and multiple CP model,
where it is true on the single CP side.
Hiroshi Ohta : This is a frame work and an initial
proposal. There can be several frameworks.
Dave M : The question is what the disposition is. I think that we
need to focus more on requirements, and I feel that is the sense
of the room. [did a hum - it was]
Next is Beau Williamson with Ideas on multicast address discovery
[there was no draft].
Beau : Ok, the basic problem is that enterprise networks want to
run scoped zones, admin scoping, with enterprise wide multicast.
Things like Norton Ghost and Altiris are then suddenly enterprise
wide, and many of these use non-IANA hardwired addresses. Many
people do this because there is no good mechanism to get suitable
addresses.
This makes scope range maintenance into a bit of a nightmare. We
need some way to give application developers some very light
weight zero config multicast address discovery.
In RFC 2365, the 239 space is given scopes, but most enterprises
view this as private address space.
We have the 2365 scoped relative addresses. Within each scoped
zone the top 255 addresses are available, as was used by Madcap.
Currently 239 has only two well known scopes, the local scope and
the org-local scope.
We have well known scoped relative addresses for these two well
known scopes. Typically, enterprises go further and define more
scopes, say campus scopes, regional scopes, what ever makes
sense.
They allocate these out of org local in 239. Often they'll keep
the local scope separate.
What we are proposing is a light weight MADP that assumes nothing
except multicast, and runs entirely in application clients and
servers, and is completely under the control of the application
writers.
So, I am proposing a single scope-relative address from IANA.
Client issues a request on local scope first, making a query, the
server responds saying, "here is the address, this is what we
use."
Maybe we don't even need to do an RFC to do it, but I think it
would be useful to define the process.
Dino Farinacci : Why not use DNS ?
Beau : They don't want to assume any infrastructure in the local
enterprise.
They put this in their code.
Dino : I still think that DNS is better
Beau : They can't count on it, so it won't happen.
Pekka : This is re-inventing a small part of DNS for this
purpose. This looks a bit like multicast DNS.
Dave M : The problem space is not the same, it's embedded
applications that are very tightly constrained.
Beau : The reality is that if you make them rely on anything
being present in the network they will not use it.
Toerless : Can you explain how it compares to SLP ?
Dave M : SLP was a pretty heavy piece that was intended for
workstations and the like.
Toerless : If SLP is too heavy, then we should rewrite it.
Dave T : I think this is a good idea. This is multicast address
discovery. There is zero overlap with MADCAP.
This is not defined as being link local. The other mechanisms are
defined as being link local. You didn't propose exactly what the
protocol is.
Beau : Except that there is a single multicast packet you send
out and you wait for a response.
The next step is to define the protocol. This doesn't preclude
the use of other mechanism for address discovery.
Dave T : There is no enterprise wide multicast DNS, and
applications cannot count on being able to insert an A record.
Dave M : I am sympathetic about updating the A records but
anything that has DNSsec in the path of deployment is a hurdle.
Dave T : I do not disagree.
Pekka : This will require that the admin will configure a group
address.
Dave T: This does not mention how the application would get this
configuration.
Beau : It reduces the problem set to configuring one or a few
servers.
Pekka : If the server has to get the address anyhow, what's the
difference with manually configuring in the DNS ?
Beau : It goes back to controlling your own destiny. A lot of
times the application gets deployed by other groups.
Dino F : This is not simple enough. It can't be any simpler than
DNS. We've done this on many unicast applications. Use one level
of indirection with a name.
Beau : We are not precluding that. This has been there all the
time - if they wanted to use DNS, they could have.
Lenny Giuliano : Could this problem be solved using SAP ?
Wouldn't that solve this problem ?
Beau : Who controls that particular mechanism ? If the app
developer has to rely on someone else then it won't work.
Dave T : SAP may be a valid solution.
Dino : What group ?
Dave T : Beau answered that - it's scope relative.
Dino : Nothing needs to be hard coded at all.
Stig : I think that this solution is promising. I am still
worried that people might hard code addresses in solutions.
Beau : It is guaranteed that if we don't do anything then they
will continue to hard code addresses.
Dave M : Right now, if you had a lightweight solution, you could
tell IANA. Right now we can't.
Pekka : Would it be sufficient if we had a document describing
how to use DNS so we could tell IANA to point to that ?
Pekka : I am curious that there are devices with no site local DNS
Dave M : The way they're discovering their addresses is that they
are asking IANA (or not) and hard coding.
Dave M : OK, we have two talks on MPLS Multicast. We seem to be
on the verge of reinventing a lot of multicast, hopefully we can
learn from history.
Nidhi Bhaskar : I am here to talk about PE-PE signally options
being discussed in L3VPN.
Today, PE-PE signally is deployed using PIM-LAN solutions. There
is a push to replace this with BGP.
The enhancements required are fairly extensive.
There is a new SAFI, with a specific NLRI with enough information
for detecting a RP and which PE is associated with a given
{S,G}. Both the upstream and the downstream PE is in the NLRI.
In the draft there is a description with new functions in BGP
like aggregating downstream PE information, there is a concept of
RPF lookup, like PIM but sitting in PIM.
There is no extension for unicast reachability.
The slide shows how we might redistribute join information from a
receiver PE to the source PE. If another PE was to join, there
would be a second unique NLRI.
BGP is already deployed as part of the L3VPN infrastructure for
unicast. BGP seems to be the rule, rather than the exception.
The RR stores one multicast as N NLRI's, where N is the number of
downstream PEs interested in a given stream.
It isn't clear that the existing unicast uses of the RR [Router
Reflector] will carry over to multicast.
The RR is now the one thing through which all joins and prunes
and bindings have to pass, so there will be latency implications.
There is nothing that talks about HELLO operations for
negotiations.
There is no Join suppression or Prune override.
There is currently no support for BiDir, DF Election or for PIM
Assert resolution.
It isn't clear if PIM Assert resolution is even possible using
BGP.
The other problem that we see is that in PIM there is the concept
of a full state update. With BGP there is no way to associate
NLRI's, at least with the existing mechanisms. They same is
applicable to BSR mappings.
Other things that need to be addressed are restricting the
multicast binding to the multicast tree, and the SAFI can be so
large it can't be encoded for IPv6.
The LAN-based solutions address most of the issues, but we want
to have BGP do so as well.
[Note from the scribe : In the L3VPN WG, PIM Multicast is
frequently described as the "LAN-based solution" or "LAN
procedures" or variants thereof.]
Dave M : I have a couple of questions.
Well, we have tried to do multicast deployment, without great
success in the inter-domain space. Part of the problem is it was
way too complicated. Is this simpler ?
At some point we have to look at the rate in which we are putting
stuff into the control place.
Second, can you use non-route reflector topology ?
Third, we have already done this one. We have solutions.
This looks more like DVMRP, rather than PIM. There were a lot of
optimizations available in DVMRP. Are they available
N. The purpose [to my talk] is not to propose a solution.
The purpose is describing how we plan to replace LAN procedures
Toerless : This doesn't include the functionality of MSDP. We
would have to expand this to include MSDP.
If I remember history correctly, the whole reason for using MSDP
was to not risk the stability of BGP.
I think that there is a lot of things learned in doing multicast
that weren't written down and so it is hard to point to them.
This started out in one very restricted view of multicast
requirements. Is it appropriate to design something that way ?
John Meylor : Knowing the presenter, I am sure that the intent is
to describe from a tree building multicast perspective what the
issues are getting a tree building multicast service into a
multipoint LSP. What does the signaling look like, and how does
that relate to the BGP solution ?
Eric Rosen : If you want to deflect the BGP proposal, you are
going to have to have a killer issue. It's more attractive to
have a BGP everywhere.
Nidhi put out a whole bunch of issues, but there seem to be
solutions to all of these issues. People won't care that it is
not exactly optimal.
The fact that a Route Reflector is required is not a killer
issue.
The big issue is the rate of change issue. This is to support
enterprise multicast, and it is hard to figure out what the
design standard should be.
Other proposals tend to run into L3VPN issues like properly
respecting control boundaries.
Lorenzo : One point is, "let's just use BGP because we are using
BGP." Are we sure that it will be BGP when it is finished. Are we
inventing a protocol inside a protocol ?
Dave Thaler : It would be great if we could have a little more
[Audience Member] : BGP lately has had extensions. Putting the
whole PIM complexity into BGP
Nidhi : I think that we are not there yet on how we can carry all
of this in BGP.
Hiroaki Satou : Can PIM-DM be supported using BGP ?
Although BGP is a reliable session on TCP, refresh reduction can
be achieved in PIM.
Nidhi : I do not see how we could support PIM-DM by BGP.
Dave Meyer : Next is MVPN Experience by Yiqun Cai
Yiqun : I am going to talk about some of the things we have
learned about MVPN.
Vendors started looking at MVPN 5 years ago, way before the IETF
started dealing with it. It is on of those examples where a pre
standard implementation has been put into place by a number of
people.
After the IETF adopted it, we had a lot of debate, but vendors
and SP's continue to roll out deployments.
We thought it was valuable to document this experience. Also, if
we go for a new routing protocol, what are the concerns that we
have to deal with ?
This draft covers the model described in the Rosen draft, which
has been merged into a new draft. AFAIK this is the most dominant
deployment so far.
It basically builds a VLAN between the PE routers.
I am not aware of any v6 deployments.
PIM is in the core, GRE encapsulation only is supported.
There is default MDT, which puts all customer multicast onto one
overlay broadcast network, and data MDTs, which puts certain
multicasts onto their own overlay network.
MDT SAFI was introduced 2 years ago to provide inter-AS support.
The draft describes the problems that we encountered :
RPF and Load Balancing. If there are multiple routers, what is
the best practice to avoid routing loops.
Addressing - what is the best practice for service providers ?
Summary : This is well deployed, supports existing multicast
applications and has been tested in the world and is running
operationally for production traffic. It provides real end to end
multicast protocol support.
It leverages the existing multicast protocols in the core. It
allows migration for new features like p2mp/mp2mp LSP's.
John Meylor : There is a basic concept that within a PE to PE
service model, you need to convey
- how to construct a tree
- [cross-talk]
This is handled perfectly in PIM. This model uses PIM.
Many of us feel that until we can show that BGP can carry the
models supported in PIM, that we leave the functionalities in PIM
in the L3VPN Model.
Dave M : The last talk is the IP Multicast MIB
David Walter : I am working on a PIM MIB, and we thought that
certain pieces of RFC 2932 should be updated to support IPv6, and
that we need generic SSM IPv4 address range configurations. This
work picks up a few threads from the expired
draft-thaler-idmr-multicast-routemib
Dave M : Did you say that the PIM WG said that this should be
done in MBONED ?
David W : Yes, they did.
Is this WG interested in this work ?
Dave M : I would say that with some notable exceptions that I
don't feel strongly that we have the expertise here to do it.
There are accidents of history, and we are in operations and
management but we are more ops than management.
What alternate WG would take this on ?
I propose that you take this on the list and we will see what the issues are.
David Kessens : This WG has been in existence for a while. Dave
has indicated to me that he would like to step down.
One proposal is to close the WG. Another is to get a new chair,
and re-charter the WG
Dave Meylor : I think that the MBONE WG has been extremely useful
and continues to be.
Dino : I think that if it is shut down it's work will have to be
done elsewhere.
Pekka : I think that this WG has been very useful and continues
to be useful. Instead of expanding I might consider trimming it
down.
Toerless : Can you be more specific.
Pekka : For example, the more extensive AAA work could be done
somewhere else.
Dave M : Let me see if I can use a little history. Over time,
there have been certain protocol things that couldn't find a WG.
MBoneD has been the stop of final resort for Multicast.
Pekka : Yes, for some of them, maybe not all of them.
Joel : I think that a lot of what MBoneD was created to do was to
address problems that we thought we were going to have in
1994.
John Meylor : I think that the notes should reflect the
appreciation that the WG feels for the efforts of
Multicast. [applause]
Eric Rosen : I thought that the first 45 minutes of the meeting
was about expired drafts and nobody wanted to work on this and
nobody wanted to work on that.
Dave Kessens : We have had 10 years of history here; how are we
going to get multicast deployed.
Lenny : History has not been very kind in the last couple of
years. The number of deployments is not growing, or at least in
the ways that we expected.
We need to be working towards identifying why deployments aren't
growing.
Chris [?, of France Telecom] : This WG is very useful for us. We
do need requirements, directives, and the sort of things that
should be addressed in this WG.
John Meylor : We have actually never seen multicast being
deployed more actively than it is today. There is a lot of
activity going on in multicast today, more than a few years ago.
The bulk of the Multicast deployments today are in walled
gardens. I think that there is no correlation in multicast
deployment and what you see announced in MBGP.
Nidhi : I think that this WG is very useful, especially as
multicast tends to be very complex.
Beau : I think that Tony Soprano has a term for the concept of
getting rid of MBONED, which is "forget about it." [laughter]
The deployment tends to be in private network space, in the last
10 months to a year I have seen an explosion in multicast
interest.
John Meylor : If we look at possible ways to re-charter, a lot of
the focus was on the bread and butter of the Multicast
protocols. I think what's still wide open is some of the more
integrated components of the problem space, address allocation,
access control. Maybe the direction that the WG takes on is to
review proposals and to set directions.
David K : I think that the general consensus is that we keep the
MBONED WG in one form or way.
We could do a rechartering on the list.
Beau : Let's start on the list, and see what is brought up. Maybe
it's a re-charter, maybe not. If it appears that there is a need,
we could have a BOF at the next IETF.
Nidhi : Do you have something in mind ?
David K : I believe that this has to be set by the WG itself.
I am going to insist on at least one chair who is a operations
person.
Beau : I think that you should not narrow your scope that
much. There are a lot of us who could speak to operations but who
aren't operators.
Pekka : I might want to narrow it down even further. We should
have an operator who has deployed
Toerless : That is just one access. To me the topics of AAA are
much more interesting.
Beau : If you require someone who is a deployer of MVPN, you have
effectively narrowed the scope and re-chartered it.
Tom P : How many people here would consider themselves to be operators.
David K : Recently we did this on the NSO WG. We wrote a
description of what attributes the WG thought that the Chair
should have. We wrote the description of the people that would
fit this. I thought this worked rather well.
|