draft-savola-mboned-mcast-rpaddr-03.txt

[Toerless Eckert]

Folks,

I can not find any reflection of the issue that i asked you to consider
for inclusion into the draft early this year in SF and Paris (and in before
last year on the IETF too): The mayor concern with large interdomain multicast
groups with more than 1 or two sources is the amount of (S,G) state across the
Internet associated with such a group. With embedded-RP groups likely (if we're
successfull in deployment) being the predominantly used form of interdomain
IPv6 ASM groups, i think the draft need to cover this topic.

I would for once consider the few-source many-receivers to be a likely
candidate of an Interdomain application - 20 sources participating in
a videoconference or game (or something in between ;-), and a few thousand
watchers (receivers only). using SPT threshold infinity in this case would
give a 20:1 state reducation in all parts of the network with only
receivers (aka: the mayority).

I suggested to encode wether or not SPT-switchover is to be allowed
for an embedded-RP group in the mechanism itself, eg: by either using
one of the 4 bits of the RP address to encode this or by simply
enumerating the RP 0..15 for specific functions and simply start
allocating and using only the first few to be open to further extensions
in the future, eg:
1 = PIM-SM RP with SPT-threshold 0
2 = PIM-SM RP with SPT-threshold infinity

Yes, i remember some strange arguments why such hard operational
considerations could not become part of this spec, but none of them
sounded persuasive to me (the biggest one was something in the order of
"this is against foo-architecture guidelines"). I just can't see this,
and clearly PIM-SM is operationally two quite different protocols
depending on wether or not you have SPT-threshold infinity. Not even
discussing which mode of operations should be used - even if not
configurable - is i think not an appropriate way of bringing forward
a protocol in the mboned working group (aka: i can understand when
"protocol designers" ignore reality in the PIM working group, but mboned
was specifically meant to take care of such elements too, right ?)

And yes, i still would like to also have this mechanism be applicable
to Bidir-PIM, even if we do have all the necessary knobs in Bidir-PIM
itself today. I don't want to get into a situation in 18 months going to
the IETF and saying: now i want another bit to have this scheme for
a real shared-tree protocol, only to get the answer: gee, those bits are
to expensive, you shouldn't have wasted 4 of them uselessly on PIM-SM,
are all of those well used anyhow ?

And by the way: I think that section 7. describing the mechanism in
terms of PIM-SM state modifications easily confusing to the casual
reader. From where i stand, RP to group mapping is not an integral
part of the PIM-SM protocol, instead it is an external requirement,
and the PIM-SM spec specifies that it does not mandate the use of
a particular mechanism. The embedded RP mechanism qualifies as such
a mechanism in the same way as static-RP, AutoRP or BSR. If this would
be expressed clearer it might reduce the concerns people might have about
the operational impact of the embedded RP mechanism on protocol operations.


Thanks
Toerless

[Pekka Savola]

Thanks for opening this discussion; hopefully the WG will participate in
it.

In particular, I'd like to hear feedback on:
- is this something needed badly
- whether this is something that should be tackled in this specification
(but possibly in some coordination with it, at least)
- which bits people feel we could use if we'd want to use them (roughly
four options)

On Fri, 13 Jun 2003, Toerless Eckert wrote:
[...]

Post by Toerless Eckert
I would for once consider the few-source many-receivers to be a likely
candidate of an Interdomain application - 20 sources participating in
a videoconference or game (or something in between ;-), and a few thousand
watchers (receivers only). using SPT threshold infinity in this case would
give a 20:1 state reducation in all parts of the network with only
receivers (aka: the mayority).

I agree, this would seem to be a very useful feature.

However, this seemed like a largely independent part from embedded RP;
sure, this is a good opportunity to do something like this ("to signal
preferences on which PIM variants should be used"), but still, maybe
independent.

Post by Toerless Eckert
I suggested to encode wether or not SPT-switchover is to be allowed
for an embedded-RP group in the mechanism itself,

Well, to be clear, SPT switchover is always allowed AFAIK; what you really
want is to give a strong hint (or even, an *order*) whether the routers
processing the multicast address should use it or not.

Post by Toerless Eckert
eg: by either using
one of the 4 bits of the RP address to encode this or by simply
enumerating the RP 0..15 for specific functions and simply start
allocating and using only the first few to be open to further extensions
1 = PIM-SM RP with SPT-threshold 0
2 = PIM-SM RP with SPT-threshold infinity

If we had an unlimited number of bits, why not ;-)

Post by Toerless Eckert
Yes, i remember some strange arguments why such hard operational
considerations could not become part of this spec, but none of them
sounded persuasive to me (the biggest one was something in the order of
"this is against foo-architecture guidelines"). I just can't see this,
and clearly PIM-SM is operationally two quite different protocols
depending on wether or not you have SPT-threshold infinity. Not even
discussing which mode of operations should be used - even if not
configurable - is i think not an appropriate way of bringing forward
a protocol in the mboned working group (aka: i can understand when
"protocol designers" ignore reality in the PIM working group, but mboned
was specifically meant to take care of such elements too, right ?)

There are several arguments for and against. You've rather well summed
those for it. For against:

- there is this philosophical argument that glueing any interpretation
about "magic numbers" in addresses is a bad idea. IMO, it's roughly OK as
long as you put them only in the multicast address. But if you want to
make a mapping like "RP address looks like it is using RP threshold
infinity, so perform checks A, B and C", we're venturing into a very
dangerous territory.

- "zero" value should not be used as it overloads the subnet router
anycast address, specified in IPv6 address architecture, but that's just a
minor point you may be referring to above.

- the bits used are limited; the only options to embed these would seem
to be like:

1) steal the last bit of "flgs" (i.e. now specify FF7x and
FFFx); however, I'd rather not do it, as some nicer use of flags could be
invented later

2) use the first 4 bits of "reserved" field; good option, but that would
use up all of reserved bits for embedded-rp (might need some for generic
purposes later)

3) split off 1 bit from current 4-bit RPad field to signal this; ie.,
shrink RPad to enable 8 RPs which all could function in either mode.
b) split off 2 bits where the second would be "0=indeterminate,
1=Bidir")

4) glue different meanings to the RP addresses, like RPad=1 ==>
SPT-infinity, RPad=2 ==> SPT=0, etc. (like you propose) (so that if you
want certain functionality, you would have to use the specific
interface-ID/RP address)

What do folks think about the feasibility of this?

As for my personal opinions..

I don't like 1)-2) because they would take all of our bit reserves.

I like 3) if we could manage to take only 1 bit (ie. not decrease RPad too
much), but that leaves the question whether it is enough, and whether it
is reasonable to assume administrators know which method is preferable
(ie. whether there has to be a "no determination" flag); with sufficient
education about the tradeoffs and applicability of both, this might not be
an issue.

I don't like 4) at all. As an operator, I *don't* like any spec saying
like "if you have prefix FOO::/32, if you want to use embedded RP with SPT
threshold infinity, your RP address MUST BE FOO:BAR::1". It is much more
better (IMHO) to say "if you have prefix FOO::/32, and you want to use
embedded RP with SPT threshold infinity, you can pick one interface ID
("1-7" or "1-15") that's suited for your purposes and set the address
correspondingly.

Post by Toerless Eckert
And yes, i still would like to also have this mechanism be applicable
to Bidir-PIM, even if we do have all the necessary knobs in Bidir-PIM
itself today. I don't want to get into a situation in 18 months going to
the IETF and saying: now i want another bit to have this scheme for
a real shared-tree protocol, only to get the answer: gee, those bits are
to expensive, you shouldn't have wasted 4 of them uselessly on PIM-SM,
are all of those well used anyhow ?

I'm not sure whether I see whether you've a specific proposal on this?

Post by Toerless Eckert
And by the way: I think that section 7. describing the mechanism in
terms of PIM-SM state modifications easily confusing to the casual
reader. From where i stand, RP to group mapping is not an integral
part of the PIM-SM protocol, instead it is an external requirement,
and the PIM-SM spec specifies that it does not mandate the use of
a particular mechanism. The embedded RP mechanism qualifies as such
a mechanism in the same way as static-RP, AutoRP or BSR. If this would
be expressed clearer it might reduce the concerns people might have about
the operational impact of the embedded RP mechanism on protocol operations.

We'll try to see how to clarify that, but please .. if you have some
specific ideas about that, send text :-)! I've tried to make it as clear
as possible, but apparently am not succeeding that well :-)

[David Meyer]

[bunch of stuff deleted...]

Post by Pekka Savola
Well, to be clear, SPT switchover is always allowed AFAIK; what you really
want is to give a strong hint (or even, an *order*) whether the routers
processing the multicast address should use it or not.

Post by Toerless Eckert
eg: by either using
one of the 4 bits of the RP address to encode this or by simply
enumerating the RP 0..15 for specific functions and simply start
allocating and using only the first few to be open to further extensions
1 = PIM-SM RP with SPT-threshold 0
2 = PIM-SM RP with SPT-threshold infinity

If we had an unlimited number of bits, why not ;-)

I would ask you (ed) to consider the effect of spreading
(overloading, really) what is essentially signaling
information all over Internet architecture. IMO this is a
recipe for disaster down the road.

Post by Pekka Savola

Post by Toerless Eckert
Yes, i remember some strange arguments why such hard operational
considerations could not become part of this spec, but none of them
sounded persuasive to me (the biggest one was something in the order of
"this is against foo-architecture guidelines"). I just can't see this,
and clearly PIM-SM is operationally two quite different protocols
depending on wether or not you have SPT-threshold infinity. Not even
discussing which mode of operations should be used - even if not
configurable - is i think not an appropriate way of bringing forward
a protocol in the mboned working group (aka: i can understand when
"protocol designers" ignore reality in the PIM working group, but mboned
was specifically meant to take care of such elements too, right ?)

There are several arguments for and against. You've rather well summed
- there is this philosophical argument that glueing any interpretation
about "magic numbers" in addresses is a bad idea. IMO, it's roughly OK as
long as you put them only in the multicast address. But if you want to
make a mapping like "RP address looks like it is using RP threshold
infinity, so perform checks A, B and C", we're venturing into a very
dangerous territory.

Same argument. Putting what comes down to signaling
semantics into addresses of any kind is going to lead
to problems.

Post by Pekka Savola
3) split off 1 bit from current 4-bit RPad field to signal this; ie.,
shrink RPad to enable 8 RPs which all could function in either mode.
b) split off 2 bits where the second would be "0=indeterminate,
1=Bidir")
4) glue different meanings to the RP addresses, like RPad=1 ==>
SPT-infinity, RPad=2 ==> SPT=0, etc. (like you propose) (so that if you
want certain functionality, you would have to use the specific
interface-ID/RP address)

Again, same argument. Instead of hacking around this
problem, why don't we just fix it (like in the protocol)?


Dave

[Pekka Savola]

On Fri, 13 Jun 2003, David Meyer wrote:
[...]

Post by David Meyer
Again, same argument. Instead of hacking around this
problem, why don't we just fix it (like in the protocol)?

Yes, this is a problem. I certainly can't say I *like* the rpaddr
mechanism, or rather, ASM, architecture-wise.

This overloading was one of the reasons I didn't like the SPT threshold
toggles in the first place (because addresses should be opaque), but the
same argument applies to the whole embedded RP, too.

Fixing it in the protocol would probably be the best choice, but this
doesn't fix the short-term problems of de-facto ASM multicast world (if
you call it "world" :-) which is transitioning to IPv6.

SSM is taking a good step in the right direction, but it doesn't really
appear to be widely available in the short term;
- there are a number of "last-mile" deployment problems, like with
snooping switches
- host support is still new or missing (also for those systems which
weren't shipped yesterday!)
- application API is in progress (though near to finalized), not widely
implemented, and the changes needed in the apps to transition them to SSM
are not not always trivial
- (routers seem to be in a pretty good state, though!)

I'd hope embedded RP might make it easier to transition to IPv6, and to
act as a middle step when moving towards SSM in the long term.

I'd certainly say that some applicability statement is needed, at the very
least, but I'm not sure if it's enough -- or the direction we want to go
towards.

But that's why I've been begging for input. I heartily admit that e.g.
SSM is a better mechanism, but I'm worried about deployment and what can
be made easily available, not theory. It seems to me that a small
modification in the router software is the simplest way to deploy IPv6
multicast...

[Toerless Eckert]

Post by Pekka Savola
SSM is taking a good step in the right direction, but it doesn't really
appear to be widely available in the short term;

Has somebody found the forum where application developers gather ?
That's where we need to preach SSM to. Right now we're mostly enjoying
to preach it to the quire (us networking folks).

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Post by Pekka Savola
- host support is still new or missing (also for those systems which
weren't shipped yesterday!)
- application API is in progress (though near to finalized), not widely
implemented, and the changes needed in the apps to transition them to SSM
are not not always trivial

Yes, everything on the host side is something much harder to fix
quickly *sigh*

Post by Pekka Savola
- (routers seem to be in a pretty good state, though!)
I'd hope embedded RP might make it easier to transition to IPv6, and to
act as a middle step when moving towards SSM in the long term.

I've been pushing SSM as much as i can and will continue to do so,
but i have to say that embedded-RP may come pretty close giving you
all the same advantages that you're doing SSM for:

You can pretty much do all the work needed in the first-hop router
towards the source and get a damned good replacement of SSM:

First-hop router automatically uses InterfaceAddr, let's say <global>::5
for embedded-RP addr. It uses MADCAP to hand out embedded-RP group addresses
to applications only on this LAN. It refuses registers from any source
not on this LAN for this RPaddr. Define a MADCAP extension
groupaddr32 = hash(ClientInterfaceID, LeaseIdentifier), and you get
persistent address assignments that you could use across offline tools
like SDR.

Voila, pretty close to SSM, isn't it ? And it would allow you to
even have some form of redundancy, eg: all sources just need to be on
this LAN (redundancy for SSM without source-server anycast is a pain !).
If you want full SSM: just put one host on a LAN.

(Ok: i of course would want to make this even more DoS safe by stating
that RPaddr=5 would indicate that only sources from the prefix are allowed
to ever be sources for this group - in the EmbedRP mechanism. That avoids
for bogus (S,G) state for this group to ever exist in the network -
but that's just me, and i am already seeming to loose that fight for
even fundamental functions like SPT threshold - of all things - due to
the usual naysayers *sigh*)

Aren't we just afraid to explore these possibilities because they
might derail the SSM story ?

Post by Pekka Savola
I'd certainly say that some applicability statement is needed, at the very
least, but I'm not sure if it's enough -- or the direction we want to go
towards.
But that's why I've been begging for input. I heartily admit that e.g.
SSM is a better mechanism, but I'm worried about deployment and what can
be made easily available, not theory. It seems to me that a small
modification in the router software is the simplest way to deploy IPv6
multicast...

It definitely is. The real threat to Embed-RP is the weak pickup from
adopters. Embed-RP will only fly if it manages to establish itself as
a required implementation functionality for all IPv6 routers in
transit domains. That pretty much depends primarily on customers asking
for it. So it might end up in the same blackhole as SSM - but of course
it stands a much better chance than SSM not to, because it ONLY requires

Cheers
Toerless

[Marshall Eubanks]

Hi Toerless;

Post by Toerless Eckert

Post by Pekka Savola
SSM is taking a good step in the right direction, but it doesn't really
appear to be widely available in the short term;

Has somebody found the forum where application developers gather ?

You want the"advanced" streamingmedia list (IHMO) -

http://ls.streamingmedia.com/cgi-bin/
lyris.pl?site=streamingmedia&page=topic&topic=tech_lists&text_mode=0&lan
g=english

Also, the Kicktam (Apple Quicktime) list deals with mutlicast
surprising often

http://appleseed.apple.com/mailman/listinfo/kicktam5

HOWEVER, you will need something more than "it would be nice" to get
much
traction !

Regards
Marshall

Post by Toerless Eckert
That's where we need to preach SSM to. Right now we're mostly enjoying
to preach it to the quire (us networking folks).

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Post by Pekka Savola
- host support is still new or missing (also for those systems which
weren't shipped yesterday!)
- application API is in progress (though near to finalized), not widely
implemented, and the changes needed in the apps to transition them to SSM
are not not always trivial

Yes, everything on the host side is something much harder to fix
quickly *sigh*

Post by Pekka Savola
- (routers seem to be in a pretty good state, though!)
I'd hope embedded RP might make it easier to transition to IPv6, and to
act as a middle step when moving towards SSM in the long term.

I've been pushing SSM as much as i can and will continue to do so,
but i have to say that embedded-RP may come pretty close giving you
You can pretty much do all the work needed in the first-hop router
First-hop router automatically uses InterfaceAddr, let's say
<global>::5
for embedded-RP addr. It uses MADCAP to hand out embedded-RP group addresses
to applications only on this LAN. It refuses registers from any source
not on this LAN for this RPaddr. Define a MADCAP extension
groupaddr32 = hash(ClientInterfaceID, LeaseIdentifier), and you get
persistent address assignments that you could use across offline tools
like SDR.
Voila, pretty close to SSM, isn't it ? And it would allow you to
even have some form of redundancy, eg: all sources just need to be on
this LAN (redundancy for SSM without source-server anycast is a pain !).
If you want full SSM: just put one host on a LAN.
(Ok: i of course would want to make this even more DoS safe by stating
that RPaddr=5 would indicate that only sources from the prefix are allowed
to ever be sources for this group - in the EmbedRP mechanism. That avoids
for bogus (S,G) state for this group to ever exist in the network -
but that's just me, and i am already seeming to loose that fight for
even fundamental functions like SPT threshold - of all things - due to
the usual naysayers *sigh*)
Aren't we just afraid to explore these possibilities because they
might derail the SSM story ?

Post by Pekka Savola
I'd certainly say that some applicability statement is needed, at the very
least, but I'm not sure if it's enough -- or the direction we want to go
towards.
But that's why I've been begging for input. I heartily admit that e.g.
SSM is a better mechanism, but I'm worried about deployment and what can
be made easily available, not theory. It seems to me that a small
modification in the router software is the simplest way to deploy IPv6
multicast...

It definitely is. The real threat to Embed-RP is the weak pickup from
adopters. Embed-RP will only fly if it manages to establish itself as
a required implementation functionality for all IPv6 routers in
transit domains. That pretty much depends primarily on customers asking
for it. So it might end up in the same blackhole as SSM - but of course
it stands a much better chance than SSM not to, because it ONLY requires
Cheers
Toerless

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Marshall Eubanks]

Hi Toerless;

Post by Toerless Eckert

Post by Pekka Savola
SSM is taking a good step in the right direction, but it doesn't really
appear to be widely available in the short term;

Has somebody found the forum where application developers gather ?

You want the"advanced" streamingmedia list (IHMO) -

http://ls.streamingmedia.com/cgi-bin/
lyris.pl?site=streamingmedia&page=topic&topic=tech_lists&text_mode=0&lan
g=english

Also, the Kicktam (Apple Quicktime) list deals with mutlicast
surprising often

http://appleseed.apple.com/mailman/listinfo/kicktam5

HOWEVER, you will need something more than "it would be nice" to get
much
traction !

Regards
Marshall

Post by Toerless Eckert
That's where we need to preach SSM to. Right now we're mostly enjoying
to preach it to the quire (us networking folks).

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Post by Pekka Savola
- host support is still new or missing (also for those systems which
weren't shipped yesterday!)
- application API is in progress (though near to finalized), not widely
implemented, and the changes needed in the apps to transition them to SSM
are not not always trivial

Yes, everything on the host side is something much harder to fix
quickly *sigh*

Post by Pekka Savola
- (routers seem to be in a pretty good state, though!)
I'd hope embedded RP might make it easier to transition to IPv6, and to
act as a middle step when moving towards SSM in the long term.

I've been pushing SSM as much as i can and will continue to do so,
but i have to say that embedded-RP may come pretty close giving you
You can pretty much do all the work needed in the first-hop router
First-hop router automatically uses InterfaceAddr, let's say
<global>::5
for embedded-RP addr. It uses MADCAP to hand out embedded-RP group addresses
to applications only on this LAN. It refuses registers from any source
not on this LAN for this RPaddr. Define a MADCAP extension
groupaddr32 = hash(ClientInterfaceID, LeaseIdentifier), and you get
persistent address assignments that you could use across offline tools
like SDR.
Voila, pretty close to SSM, isn't it ? And it would allow you to
even have some form of redundancy, eg: all sources just need to be on
this LAN (redundancy for SSM without source-server anycast is a pain !).
If you want full SSM: just put one host on a LAN.
(Ok: i of course would want to make this even more DoS safe by stating
that RPaddr=5 would indicate that only sources from the prefix are allowed
to ever be sources for this group - in the EmbedRP mechanism. That avoids
for bogus (S,G) state for this group to ever exist in the network -
but that's just me, and i am already seeming to loose that fight for
even fundamental functions like SPT threshold - of all things - due to
the usual naysayers *sigh*)
Aren't we just afraid to explore these possibilities because they
might derail the SSM story ?

Post by Pekka Savola
I'd certainly say that some applicability statement is needed, at the very
least, but I'm not sure if it's enough -- or the direction we want to go
towards.
But that's why I've been begging for input. I heartily admit that e.g.
SSM is a better mechanism, but I'm worried about deployment and what can
be made easily available, not theory. It seems to me that a small
modification in the router software is the simplest way to deploy IPv6
multicast...

It definitely is. The real threat to Embed-RP is the weak pickup from
adopters. Embed-RP will only fly if it manages to establish itself as
a required implementation functionality for all IPv6 routers in
transit domains. That pretty much depends primarily on customers asking
for it. So it might end up in the same blackhole as SSM - but of course
it stands a much better chance than SSM not to, because it ONLY requires
Cheers
Toerless

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv


Regards
Marshall Eubanks

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Pekka Savola]

Post by Toerless Eckert

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Certainly.. and you can be sure that's what we're doing at least.

But that does *NOT*, in general, help you with the equipment you have
today -- the equipment you may have to live with for _even_ 3-5+ _years_,
or where upgrades are difficult at best.

Which is one of my reasons why I *pragmatically* am resigned to a much
slower SSM adoption rate. ASM+fixes is a relatively simple mechanism and
it *works* (as far as ASM can work) *today* with equipment in use *today*.

Upgrading a few router softwares for something like embedded RP is a much
simpler task than driving the app developers, ensuring the last mile works
etc.

[s***@shepfarm.com]

Post by Pekka Savola

Post by Toerless Eckert

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Certainly.. and you can be sure that's what we're doing at least.
But that does *NOT*, in general, help you with the equipment you have
today -- the equipment you may have to live with for _even_ 3-5+ _years_,
or where upgrades are difficult at best.
Which is one of my reasons why I *pragmatically* am resigned to a much
slower SSM adoption rate. ASM+fixes is a relatively simple mechanism and
it *works* (as far as ASM can work) *today* with equipment in use *today*.
Upgrading a few router softwares for something like embedded RP is a much
simpler task than driving the app developers, ensuring the last mile works
etc.

First, embedded RP does nothing for the last mile - that is a whole
different problem.

Second, a few routers? How about all of them?? This argument over which is
easier to drive, apps or routers is all coming from router developers. But
I can assure you if you had both a host app and some router code and you
tried to get them both deployed, the app deployment would be be completed
years ahead of the router code.

Greg

[Pekka Savola]

Post by s***@shepfarm.com

Post by Pekka Savola

Post by Toerless Eckert

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Certainly.. and you can be sure that's what we're doing at least.
But that does *NOT*, in general, help you with the equipment you have
today -- the equipment you may have to live with for _even_ 3-5+ _years_,
or where upgrades are difficult at best.
Which is one of my reasons why I *pragmatically* am resigned to a much
slower SSM adoption rate. ASM+fixes is a relatively simple mechanism and
it *works* (as far as ASM can work) *today* with equipment in use *today*.
Upgrading a few router softwares for something like embedded RP is a much
simpler task than driving the app developers, ensuring the last mile works
etc.

First, embedded RP does nothing for the last mile - that is a whole
different problem.

Exactly: it works everywhere where ASM works (which was the point), and
still works where SSM fails (which was also the point).

Post by s***@shepfarm.com
Second, a few routers? How about all of them??

All of them who want to support those groups; partically everywhere where
interdomain multicast is desirable.

Post by s***@shepfarm.com
This argument over which is
easier to drive, apps or routers is all coming from router developers. But

I think there are about two-three IPv6 multicast implementations that are
more-or-less deployed at the moment. A change *now* would still be
possible, and rather easy IMHO; further, a change in an IPv6 ASM
implementation is not large (however, if IPv6 multicast has been
implemented SSM-only, that might be different, but I'm not sure if anyone
has done that..). In two years the situation might be quite different.

Post by s***@shepfarm.com
I can assure you if you had both a host app and some router code and you
tried to get them both deployed, the app deployment would be be completed
years ahead of the router code.

I completely disagree, from the operator point of view. Requiring
features from router vendors is easy (especially they're reasonable and
architecturally OK). You want some feature like line-rate IPv6 and
access-lists, you will get it, period. Smaller features like noted become
available in software upgrades but are arm-wrested in tenders.

However, upgrading all the hosts and other equipment (like unmanaged
switches etc.) which do not reside under your administrative domain (e.g.
your customers, end-nodes, etc.) is *difficult*. Believe me. IP
multicast and IPv6 would be deployed and widely used by now if it was up
to the routers.

Nowadays, routers evolve fast while hosts are slow (or rather, some hosts
are fast and some slow, but you still have to deal with the slow ones!).

Welcome to the next generation Internet :-)

[s***@shepfarm.com]

Post by Pekka Savola

Post by s***@shepfarm.com

Post by Pekka Savola

Post by Toerless Eckert

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Certainly.. and you can be sure that's what we're doing at least.
But that does *NOT*, in general, help you with the equipment you have
today -- the equipment you may have to live with for _even_ 3-5+ _years_,
or where upgrades are difficult at best.
Which is one of my reasons why I *pragmatically* am resigned to a much
slower SSM adoption rate. ASM+fixes is a relatively simple mechanism and
it *works* (as far as ASM can work) *today* with equipment in use *today*.
Upgrading a few router softwares for something like embedded RP is a much
simpler task than driving the app developers, ensuring the last mile works
etc.

First, embedded RP does nothing for the last mile - that is a whole
different problem.

Exactly: it works everywhere where ASM works (which was the point), and
still works where SSM fails (which was also the point).

nope - not without router-code upgrades.

Post by Pekka Savola

Post by s***@shepfarm.com
Second, a few routers? How about all of them??

All of them who want to support those groups; partically everywhere where
interdomain multicast is desirable.

..which is out of the control of the real consumers of multicast.

Post by Pekka Savola

Post by s***@shepfarm.com
This argument over which is
easier to drive, apps or routers is all coming from router developers. But

I think there are about two-three IPv6 multicast implementations that are
more-or-less deployed at the moment. A change *now* would still be
possible, and rather easy IMHO; further, a change in an IPv6 ASM
implementation is not large (however, if IPv6 multicast has been
implemented SSM-only, that might be different, but I'm not sure if anyone
has done that..). In two years the situation might be quite different.

but why? If we are pushing for progress, why push for an interdomain ASM
solution at all? Let's jump over the well-known troubles and go straight
to SSM.

Post by Pekka Savola

Post by s***@shepfarm.com
I can assure you if you had both a host app and some router code and you
tried to get them both deployed, the app deployment would be be completed
years ahead of the router code.

I completely disagree, from the operator point of view. Requiring
features from router vendors is easy (especially they're reasonable and
architecturally OK). You want some feature like line-rate IPv6 and
access-lists, you will get it, period. Smaller features like noted become
available in software upgrades but are arm-wrested in tenders.

You missed the argument. Yes, router vendors respond quickly, but the
point was about what is easier to deploy, host apps or router code -
assuming both are available.

Post by Pekka Savola
However, upgrading all the hosts and other equipment (like unmanaged
switches etc.) which do not reside under your administrative domain (e.g.
your customers, end-nodes, etc.) is *difficult*. Believe me. IP
multicast and IPv6 would be deployed and widely used by now if it was up
to the routers.

off topic.

Post by Pekka Savola
Nowadays, routers evolve fast while hosts are slow (or rather, some hosts
are fast and some slow, but you still have to deal with the slow ones!).

Then why are we putting things like IGMP and MLD in the kernal? If
interested receivers just clicked the applicaiton download to get the
functionality we would be done by now.

Post by Pekka Savola
Welcome to the next generation Internet :-)

No, welcome to the SOS.

Greg

[Pekka Savola]

On Mon, 16 Jun 2003 ***@shepfarm.com wrote:
[...]

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
First, embedded RP does nothing for the last mile - that is a whole
different problem.

Exactly: it works everywhere where ASM works (which was the point), and
still works where SSM fails (which was also the point).

nope - not without router-code upgrades.

Sure, but those are trivial (IMHO) compared to the other necessary
upgrades.

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
Second, a few routers? How about all of them??

All of them who want to support those groups; partically everywhere where
interdomain multicast is desirable.

..which is out of the control of the real consumers of multicast.

I'm not sure if I understand what you mean.

Post by s***@shepfarm.com

Post by Pekka Savola
I completely disagree, from the operator point of view. Requiring
features from router vendors is easy (especially they're reasonable and
architecturally OK). You want some feature like line-rate IPv6 and
access-lists, you will get it, period. Smaller features like noted become
available in software upgrades but are arm-wrested in tenders.

You missed the argument. Yes, router vendors respond quickly, but the
point was about what is easier to deploy, host apps or router code -
assuming both are available.

Yes, that is the point, but please keep in mind that the the number of
routers is much, much smaller than that of hosts, there are a lot, lot
fewer generally deployed router implementations.

[s***@shepfarm.com]

Post by Pekka Savola
[...]

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
First, embedded RP does nothing for the last mile - that is a whole
different problem.

Exactly: it works everywhere where ASM works (which was the point), and
still works where SSM fails (which was also the point).

nope - not without router-code upgrades.

Sure, but those are trivial (IMHO) compared to the other necessary
upgrades.

Oh really? Trivial if you want multicast and have administrative control
over the router. So if everyone whould just set me up with enable/root
access to all the routers in the world I'll turn it on for you.

Post by Pekka Savola

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
Second, a few routers? How about all of them??

All of them who want to support those groups; partically everywhere where
interdomain multicast is desirable.

..which is out of the control of the real consumers of multicast.

I'm not sure if I understand what you mean.

Content owners. Assume I'm one - ShepfarmTV and I understand the value of
mcast and have a bizplan around mcast distribution I can simply go to
Sprint or Verio to get it, right? Wrong. What I get is an mcast transit
cicuit into that provider. What I don't get is mcast into every home which
is what my bizplan had expected. As a content owner, my desired footprint
for mcast is earth... and beyond if possible.

Post by Pekka Savola

Post by s***@shepfarm.com

Post by Pekka Savola
I completely disagree, from the operator point of view. Requiring
features from router vendors is easy (especially they're reasonable and
architecturally OK). You want some feature like line-rate IPv6 and
access-lists, you will get it, period. Smaller features like noted become
available in software upgrades but are arm-wrested in tenders.

You missed the argument. Yes, router vendors respond quickly, but the
point was about what is easier to deploy, host apps or router code -
assuming both are available.

Yes, that is the point, but please keep in mind that the the number of
routers is much, much smaller than that of hosts, there are a lot, lot
fewer generally deployed router implementations.

But you can gaurentee there is a user in front of every interested host -
not so with every router. The host user could just download what they
want/need when they want/need it. The router admin needs a bizcase to
justify any config line.

Greg

[Pekka Savola]

Post by s***@shepfarm.com

Post by Pekka Savola
[...]

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
First, embedded RP does nothing for the last mile - that is a whole
different problem.

Exactly: it works everywhere where ASM works (which was the point), and
still works where SSM fails (which was also the point).

nope - not without router-code upgrades.

Sure, but those are trivial (IMHO) compared to the other necessary
upgrades.

Oh really? Trivial if you want multicast and have administrative control
over the router. So if everyone whould just set me up with enable/root
access to all the routers in the world I'll turn it on for you.

Sure; but the problem is that there is a set of routers (typically low-end
CPE's for homes etc.) which don't do any multicast at all.

Within those networks that *do* want to support multicast, upgrades like
these do not seem to be a problem at all.

What I want is to fix the *current* multicast deployments. Creating new
ones (like enabling easy multicast to homes) is "just" a secondary goal.

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
Second, a few routers? How about all of them??

All of them who want to support those groups; partically everywhere where
interdomain multicast is desirable.

..which is out of the control of the real consumers of multicast.

I'm not sure if I understand what you mean.

Content owners. Assume I'm one - ShepfarmTV and I understand the value of
mcast and have a bizplan around mcast distribution I can simply go to
Sprint or Verio to get it, right? Wrong. What I get is an mcast transit
cicuit into that provider. What I don't get is mcast into every home which
is what my bizplan had expected. As a content owner, my desired footprint
for mcast is earth... and beyond if possible.

You expect multicast to be magically deployed, maybe by the help of SSM;
I don't. It would be nice if it did, but that's a different thing. I
want my IPv6 interdomain multicast to work where it's for IPv4 right now.

Let's picture this scenario:

ShepfarmConference is currently using IPv4 multicast + vic to take part in
the video/teleconferences about raising pigs to save phone bills and to
enable better co-operation (I wonder if anyone really does that).

ShepfarmConference wants to start using IPv6 and multicast. Suddenly, the
only option would be to wait for all the problems relating to apps, hosts,
switches, etc. to resolve if a change to SSM would be required. An
alternative method would be embedded RP which would require a new software
in the IPv6 multicast transit sites and the routers participating in the
IPv6 conference. All IPv6 host systems deployed at the moment already
support MLDv_1_, so multicast works just fine out of the box.

[s***@shepfarm.com]

ShepfarmConference wouldn't bother with Vic. ;-)

Post by Pekka Savola

Post by s***@shepfarm.com

Post by Pekka Savola
[...]

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
First, embedded RP does nothing for the last mile - that is a whole
different problem.

Exactly: it works everywhere where ASM works (which was the point), and
still works where SSM fails (which was also the point).

nope - not without router-code upgrades.

Sure, but those are trivial (IMHO) compared to the other necessary
upgrades.

Oh really? Trivial if you want multicast and have administrative control
over the router. So if everyone whould just set me up with enable/root
access to all the routers in the world I'll turn it on for you.

Sure; but the problem is that there is a set of routers (typically low-end
CPE's for homes etc.) which don't do any multicast at all.
Within those networks that *do* want to support multicast, upgrades like
these do not seem to be a problem at all.
What I want is to fix the *current* multicast deployments. Creating new
ones (like enabling easy multicast to homes) is "just" a secondary goal.

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com

Post by Pekka Savola

Post by s***@shepfarm.com
Second, a few routers? How about all of them??

All of them who want to support those groups; partically everywhere where
interdomain multicast is desirable.

..which is out of the control of the real consumers of multicast.

I'm not sure if I understand what you mean.

Content owners. Assume I'm one - ShepfarmTV and I understand the value of
mcast and have a bizplan around mcast distribution I can simply go to
Sprint or Verio to get it, right? Wrong. What I get is an mcast transit
cicuit into that provider. What I don't get is mcast into every home which
is what my bizplan had expected. As a content owner, my desired footprint
for mcast is earth... and beyond if possible.

You expect multicast to be magically deployed, maybe by the help of SSM;
I don't. It would be nice if it did, but that's a different thing. I
want my IPv6 interdomain multicast to work where it's for IPv4 right now.
ShepfarmConference is currently using IPv4 multicast + vic to take part in
the video/teleconferences about raising pigs to save phone bills and to
enable better co-operation (I wonder if anyone really does that).
ShepfarmConference wants to start using IPv6 and multicast. Suddenly, the
only option would be to wait for all the problems relating to apps, hosts,
switches, etc. to resolve if a change to SSM would be required. An
alternative method would be embedded RP which would require a new software
in the IPv6 multicast transit sites and the routers participating in the
IPv6 conference. All IPv6 host systems deployed at the moment already
support MLDv_1_, so multicast works just fine out of the box.

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Pekka,

I think I'm convinced that embedded-RP is worth pursuing for inter-domain
ASM in IPv6.

Do you have an opinion on whether to use PIM-SM or PIM-bidir? Embedded-RP
would make it possible to use either one in the Internet.

Personally, I think I would prefer PIM-bidir because of its relative
simplicity (no tree switching).

It seems that deploying both would be unnecessarily complex.


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Pekka Savola]

Post by Bill Nickless
Do you have an opinion on whether to use PIM-SM or PIM-bidir? Embedded-RP
would make it possible to use either one in the Internet.
Personally, I think I would prefer PIM-bidir because of its relative
simplicity (no tree switching).
It seems that deploying both would be unnecessarily complex.

I must admit that I don't know enough of the specifics of bidir-PIM to say
anything for or against.

I have only three arguments about the decision we'd make:
- it should work (see e.g. Toerless's arguments on bidir-PIM only)
- it should not unduly limit the number (current or future) of IPv6
multicast router vendors; ie. e.g.
* is bidir-PIM more difficult to implement?
* is it stable enough so there won't be any new holes discovered in it?
* has it been implemented by all (or close to all) v6 multicast
vendors (AFAIK, not by KAME pim6sd I think)
- we *must* be able to proceed quick enough; debating whether PIM-SM or
bidir-pim is the right choice for 6 months would seem the wrong approach:
there is a "market" window for something like this, and it's closing
soon..

[Toerless Eckert]

Post by Pekka Savola
But that does *NOT*, in general, help you with the equipment you have
today -- the equipment you may have to live with for _even_ 3-5+ _years_,
or where upgrades are difficult at best.

Right. But even let's say 3 years ago there would have been enough
experience in customer spaces to understand what type of protucts to
buy when feature updates during the lifetime of the product are
important for you. Only that this argument often does not make the cut.

Low end L2 switches are about as bad as it can get for feature upgrades
because of the high percentage of cost that goes into highly optimized
hardware for exactly the predefined set of features available at FCS.
Even if an additional feature later on could be implemented in software,
likelyhood is that it will not be because the lifetime of these L2
products on the shelves of the vendors is so short too, eg: it will be
replaced by an updated HW version quickly, and then the vendor will have
rather arguments to NOT support newer features on the older hardware.

Post by Pekka Savola
Which is one of my reasons why I *pragmatically* am resigned to a much
slower SSM adoption rate. ASM+fixes is a relatively simple mechanism and
it *works* (as far as ASM can work) *today* with equipment in use *today*.

Well, yes and no: Yes, SSM adoption will be slow. Yes, ASM+fixes is a relative
simple mechanism. NO: Nothing IPv6 can be taken for granted to work on
products. be very careful what you expect and don't necessarily assume
that yust because it works in IPv4 means that you'll easily get products
to support today the same in IPv6.

Post by Pekka Savola
Upgrading a few router softwares for something like embedded RP is a much
simpler task than driving the app developers, ensuring the last mile works
etc.

Well, i hope we can persuade people that embedRP is a more generic long
term solution than just being a short-term ASM fix.

Cheers
Toerless

[Bill Nickless]

Post by Toerless Eckert
Has somebody found the forum where application developers gather ?
That's where we need to preach SSM to. Right now we're mostly enjoying
to preach it to the quire (us networking folks).

<Bill raises his hand>

May I point you to my May 2003 posting to the PIM mailing list?

http://netweb.usc.edu/pipermail/pim/2003-May/000511.html

Summary: we can trace the SSM vs. ASM argument back to a 1985 Deering &
Cheriton decision to make host groups "open". Quoting RFC 966:

The sender need not be a member of the destination group. We refer
to such a group as open, in contrast to a closed group where only
members are allowed to send to the group. We chose to provide open
groups because they are more flexible and more consistent as an
extension of conventional unicast models (even though they may harder
to implement).

Making host groups "open" pretty much means you're stuck with some sort of
flooding distribution scheme. Witness DVMRP, PIM-DM, PIM-SM (shared tree),
MSDP, and even PIM bi-dir to some extent.

SSM partially reverses this 1985 decision: each (S,G) distribution tree is
a "closed" group by the RFC 966 definition. It's even more closed than RFC
966 suggests--only S can transmit to the group.

Post by Toerless Eckert

Post by Pekka Savola
- there are a number of "last-mile" deployment problems, like with
snooping switches

I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Is this a somewhat backward approach?

One of the more dominant applications on the Internet today is the World
Wide Web, using the HTTP and HTML protocols. When HTTP was defined and
servers written, it would run over unmodified Internet infrastructure. A
student at the University of Illinois wrote Mosaic, and users who ran it it
didn't need any special Internet infrastructure.

I think it would have been harder for Tim Berners-Lee and Marc Andreessen
to achieve widespread adoption of the WWW and Mosaic, if potential users
had to forklift-upgrade all their existing IEEE 802.1 bridges first.

Post by Toerless Eckert

Post by Pekka Savola
- host support is still new or missing (also for those systems which
weren't shipped yesterday!)
- application API is in progress (though near to finalized), not widely
implemented, and the changes needed in the apps to transition them to SSM
are not not always trivial

Yes, everything on the host side is something much harder to fix
quickly *sigh*

And you know what's harder than host side changes?

IEEE 802.1 switch changes.

Post by Toerless Eckert
IMO, the main benefit of SSM is simplicity. All the other stuff-
addressing, security, etc- is just icing on the cake. What we have seen
the last 5 years is that if you have something horribly complex, people
won't turn it on.

I can upgrade router software. I can upgrade host software. But there are
a *HUGE* number of IEEE 802.1 bridges out there that would have to be
forklift upgraded to make today's IGMPv3/MLDv2-snooping deployment strategy
work.

That's why wide-area network operators/suppliers just love the idea of
SSM--because it's trivial for them to support on their SONET-, ATM-, or
MPLS-based backbones. None of that messy RP or MSDP ugliness to worry about.

But deploy it to the end-user over an existing IEEE 802 network
infrastructure? That's a completely other story.

Post by Toerless Eckert
Or something along the lines of - 'Protocols that implement the ASM
model for IPv6 MUST NOT require flooding & maintaining state for active
sources in all parts of the network for source discovery'.

In that spirit, how about something along the lines of 'IPv6 multicast
forwarding MUST NOT require any changes to the underlying network
technologies (including IEEE 802 networks that include IEEE 802.1 bridges)
in order to operate efficiently.' ?

Post by Toerless Eckert
I've been pushing SSM as much as i can and will continue to do so,
but i have to say that embedded-RP may come pretty close giving you

If you can solve the IEEE 802.1 IGMPv3/MLSD snooping deployment problem,
more power to you. I'm not convinced that's possible.

Perhaps some want to stick with the Deering/Cheriton "open group"
model. Embedded RP addresses in IPv6 group addresses would permit PIM
bi-dir to be deployed inter-domain. Finding the RP is the major impediment
to IPv4 inter-domain bi-dir deployment; perhaps we can use embedded RP
addressing to solve that problem in IPv6?


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Toerless Eckert]

Post by Bill Nickless
The sender need not be a member of the destination group. We refer
to such a group as open, in contrast to a closed group where only
members are allowed to send to the group. We chose to provide open
groups because they are more flexible and more consistent as an
extension of conventional unicast models (even though they may harder
to implement).
Making host groups "open" pretty much means you're stuck with some sort of
flooding distribution scheme. Witness DVMRP, PIM-DM, PIM-SM (shared tree),
MSDP, and even PIM bi-dir to some extent.

Requiring a source to be a receiver (closed group) would not necessarily
mean that all members of the group would have to know each other first,
right ? So i think the open/closed differentiation wouldn't help much
for this piece of the equation.

Post by Bill Nickless
SSM partially reverses this 1985 decision: each (S,G) distribution tree is
a "closed" group by the RFC 966 definition. It's even more closed than RFC
966 suggests--only S can transmit to the group.

An SSM "receiver-group" is "open" - the source may or may not want to
receive it's own channel. But all recivers need to know the (one-and-only)
source first. That's what enabled us to avoid source discovery or coordination
in the network.

Post by Bill Nickless

Post by Toerless Eckert
I don't really see those as a mayor process issue. As soon as you
have large paying customers demanding to use SSM and threaten you to
pay money for that feature, it will be implemented by good vendors.
If you are in a big customer environment, you may want to check the
RFP you are sending to vendors and see wether it mentions such SSM
details!

Is this a somewhat backward approach?
One of the more dominant applications on the Internet today is the World
Wide Web, using the HTTP and HTML protocols. When HTTP was defined and
servers written, it would run over unmodified Internet infrastructure. A
student at the University of Illinois wrote Mosaic, and users who ran it it
didn't need any special Internet infrastructure.
I think it would have been harder for Tim Berners-Lee and Marc Andreessen
to achieve widespread adoption of the WWW and Mosaic, if potential users
had to forklift-upgrade all their existing IEEE 802.1 bridges first.

Well, but what you're telling here is my argument about the "clueless
commercial Internet" (TM) after 1995 all along: HTTP became quickly a
commercial success because there was a viable user base that could leverage
it - maybe more than 4 million people by then - and HTTP itself had not to
be the killer application to drive deployment of the network for these
4 million people first. From there on, it was down hill. Almost every
IP multicast application on the other hand is faced with an almost 0
initial population it could reach ("not deploed first, need to enable first,
show me the money"), and it has to be the killer application to justify
enabling IP multicast for the required population of users first, and that's
what has inhibited ubiquitous deployment for more than 10 years now. So it
was the initial DoD and public funding that created to the largest degree the
Internet up to 1995. IP Multicast never had this dedicated funding of a
viable large first user base for the _any_ application (even today, and
even in universities it's just deployed in pockets if you really look at
the eyeballs/PCs it can reach).

Why is there no special problem on IGMPv3 snooping ? Well, because either
you have today an _any_ application, which has so little bandwidth
requirement vs. what's available, that you can really forego snooping
and go for flooding at L2 for a while (heck, people are even using IP
multicast in 802.11[abg], where's the snooping switch there ?), and
then you can make noise about an RFE afterwards and get IGMPv3 snooping
hopefully some time later. OR: You really want to deliver 100th of TV
channels over fiber to the home, and in this case you can pretty much
expect to get SSM capable snooping if you simply put this requirement on the
top portion of your RFP.

Post by Bill Nickless
And you know what's harder than host side changes?
IEEE 802.1 switch changes.

[...]

Post by Bill Nickless
I can upgrade router software. I can upgrade host software. But there are
a *HUGE* number of IEEE 802.1 bridges out there that would have to be
forklift upgraded to make today's IGMPv3/MLDv2-snooping deployment strategy
work.

Well, one possible solution is listed above (simply flood).
But really: If IGMPv3 snooping would be required more by customers,
it would happen more.

Sure, the general problem with L2 switches is that their typical
deployment cycle, especially in cost sensitive environments (academic,
research) is often far exceeding feature-upgrade lifetimes. But again,
it is really up to the customers to make that choice. Most customer feel
that it is great to go for the cheapest switch with already a limited
feature set, knowing that they'll likely never get any useful upgrade,
but they want to maximize the number of ports at maximum speed only.

And yes, i think we agree that any new functionality that potentially
requires new forwarding hardware instead of just new control plane work
is a mayor problem. IGMP snooping certainly is a mayor one, but again,
the current market situation is so that there's little alternative.
Yes, we discussed possible protocol solutions in the IETF, but we know
how long it would take to get _those_ supported. Where's GMRP on host
stacks by the way ? Same argument.

Post by Bill Nickless
In that spirit, how about something along the lines of 'IPv6 multicast
forwarding MUST NOT require any changes to the underlying network
technologies (including IEEE 802 networks that include IEEE 802.1 bridges)
in order to operate efficiently.' ?

Well, why didn't you say so 6 years ago, when IPv6 was designed. Now
we have a new MAC address range for IPv6 multicast packets, and we have
IPv6 ICMP packets instead of IPv4 IGMP packets for signalling. Too late...
These are market lessons: Even if we did or would have known the right
answers earlier, IP multicast is just a small piece of the overall puzzle
and the right answers for IP multicast always have to fight for their
right in the market place.

Post by Bill Nickless
Perhaps some want to stick with the Deering/Cheriton "open group"
model. Embedded RP addresses in IPv6 group addresses would permit PIM
bi-dir to be deployed inter-domain. Finding the RP is the major impediment
to IPv4 inter-domain bi-dir deployment; perhaps we can use embedded RP
addressing to solve that problem in IPv6?

Let me take the issue to a new mailing thread..

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Bill Nickless
I think it would have been harder for Tim Berners-Lee and Marc Andreessen
to achieve widespread adoption of the WWW and Mosaic, if potential users
had to forklift-upgrade all their existing IEEE 802.1 bridges first.
Well, but what you're telling here is my argument about the "clueless
commercial Internet" (TM) after 1995 all along: HTTP became quickly a
commercial success because there was a viable user base that could leverage
it - maybe more than 4 million people by then - and HTTP itself had not to
be the killer application to drive deployment of the network for these
4 million people first. From there on, it was down hill.

I agree--HTTP and Mosaic found a ready-built infrastructure that they could
leverage without any change whatsoever.

That's a good thing.

Post by Bill Nickless
Almost every IP multicast application on the other hand is faced with an
almost 0 initial population it could reach ("not deployed first, need to
enable first, show me the money"), and it has to be the killer application
to justify enabling IP multicast for the required population of users
first, and that's what has inhibited ubiquitous deployment for more than
10 years now.

Is this necessarily the case? Is there anything inherent in what IP
multicast can provide to user applications that requires fundamental
changes to how the Internet works?

Post by Bill Nickless
So it was the initial DoD and public funding that created to the largest
degree the Internet up to 1995. IP Multicast never had this dedicated
funding of a viable large first user base for the _any_ application (even
today, and even in universities it's just deployed in pockets if you
really look at the eyeballs/PCs it can reach).

One could say the same thing about IPv6.

But there's a major difference between IPv6 and IP Multicast: One can get
access to the IPv6 core through host software updates (and the freely
available tunnel servers) alone. IPv6 doesn't have to be turned on in the
intervening routers. Turning on IPv6 doesn't impact the IEEE 802 edge
networks (either by unwanted flooding or requiring forklift upgrades).

===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Bill Nickless
Making host groups "open" pretty much means you're stuck with some sort of
flooding distribution scheme. Witness DVMRP, PIM-DM, PIM-SM (shared tree),
MSDP, and even PIM bi-dir to some extent.
Requiring a source to be a receiver (closed group) would not necessarily
mean that all members of the group would have to know each other first,
right ? So i think the open/closed differentiation wouldn't help much
for this piece of the equation.

Good point. Let me try again--

In the context of open groups, any Internet host is eligible to send to any
host group (set of receivers). The network is expected to forward traffic
from any possible sender to all group members.

In the context of closed groups, only the group members are eligible to
send to the host group. In other words, the network is expected to only
forward traffic from senders that have joined the group.

In the context of SSM, the network is expected to only forward traffic from
senders that have one or more explicitly joined receivers.

My point?

Supporting open groups requires some sort of flooding, either direct (via
DVMRP, PIM-DM) or indirect (via PIM-SM shared tree, MSDP, or PIM bi-dir).

Why?

Because the knowledge of the active source cannot be spread in advance of
the first data packet the source emits.

Bottom line:

Supporting closed groups gives the network an opportunity to spread the
knowledge of potentially active senders (the group members) and to
establish any necessary forwarding state.

The "bursty source" problem goes away, because the group membership (for
receiving) can be leveraged to keep active the knowledge of potentially
active senders.


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Bill Nickless
In that spirit, how about something along the lines of 'IPv6 multicast
forwarding MUST NOT require any changes to the underlying network
technologies (including IEEE 802 networks that include IEEE 802.1 bridges)
in order to operate efficiently.' ?
Well, why didn't you say so 6 years ago, when IPv6 was designed. Now
we have a new MAC address range for IPv6 multicast packets, and we have
IPv6 ICMP packets instead of IPv4 IGMP packets for signalling. Too late...
These are market lessons: Even if we did or would have known the right
answers earlier, IP multicast is just a small piece of the overall puzzle
and the right answers for IP multicast always have to fight for their
right in the market place.

It's never too late to get the answer right.

Consider the history of "Trailer encapsulation" for IPv4 on
Ethernet. According to RFC 893, Bill Joy designed an encapsulation for
IPv4 datagrams on Ethernet that was optimized to reduce or eliminate copy
operations on VAX architecture computers.

But RFC 894 documents what became the standard--what we use today.

RFC 792 documents ICMP type 4, Source Quench. The assumption behind Source
Quench seems to be that hosts clock out their packets at an adjustable
rate. But as we know, TCP is externally clocked (hopefully by the gateway
interface outbound to the slowest link in the path). In other words, TCP
deals with congestion without adjusting some sort of clock on the
transmitter side. Thus, ICMP type 4 messages are vanishingly rare in
today's Internet.

In both of these examples, the original designers (Bill Joy, J. Postel, et
al) made engineering decisions that were eventually superceded--in light of
operational experience, protocol development, new ideas, or other
factors. This doesn't take anything away from the original design, or the
competence of the designers themselves.


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Toerless Eckert]

Dave,

For a mechanism like embedded-RP, the argument that specifying another
detail of operations and mabe express a way to select it is an overload
of signalling is a bit beside the point: The whole idea of embedded
RP addresses already is to replace a huge chunk of protocol/signalling
operations.

I also have to say that i am much less interested in fundemantal
beauty of protocol or design arguments as long as they can not provide
me a comparable simple, effective and reliable mode of large scale deployments,
aka: If i have to violate design principles whose only defense is
"i am a design principle, don't violate me" to get all those deployment
benefits, then i rather choose the deployment benefits. Sure: as soon
as someone tells me "there is an architecturally better way and it is
comparable simple, effective and reliable", then i of course vote for
the architecturally better solution.

Fact is that the amount of state in the Internet for IP multicast is
an important factor to consider. Fact also is that you may want to
have either SPT or RPT based forwarding if you could choose from. I do
not see any comparable simple, effecte and reliable mode of relaying
that information to the DR in a group then to make it part of the address
encoding. Fix the protocol ? Heck, if i could fix PIM-SM to give me less
pain finding an RP, we wouldn't need embedded-RP in the first place, right ?

So, the argument goes: Embedding semantics into a multicast address isn't
as bad as embedding it into a unicast address! Why ? - well, because
there are leass zeleats trying to defined the unencumbered beauty for
multicast addresses as there are for unicast addresses ? Anyhow,
embedded-RP by itself is allowed by the gods of architecture beauty (*pheef*,
what a revief). So now we're discussing wether taking the 4 bits of
address piece we have available (RPaddr) and assigning semantics to each
value of it consistutes a violation of principle in the supreme IETF court
based on the claim that it invading the rights of the RP-unicast-addres.

But that's just a matter of interpretation. My interpretation is that
these 4 bits are not really an RP address but constitute an index into
a table that determines parameters for the mode of operations of PIM
for the IP multicast group itself:

Parameter 1 Parameter2 Parameter3 ...
Index RP-address SPT threshold Protocol
Interface-ID
-------------------------------------------------------------------------
1 1 0 PIM-SM
2 2 infinity PIM-SM
further values to be allocated

Now we already agree that the Embedded-RP group address conveys the
information that this is a group to be run in PIM-SM and we also agree
that the Index field itself will determine a value for the Interface-ID.
I personally do not see any architectural difference in declaring this
Index to also determine other elements of operation, like the SPT threshold.
I would rather argue that if this argument that you could not encode
the SPT threshold setting parameter that we then shold also not be
allowed to do the embedded-RP mechanism at all on the matter of principle,
because we already try to express other parameters like the Protocol and
the Interface-ID.

I am totally open to an actual requirements discussion wether or not
being able to select the SPT threshold (or for that matter Bidir-PIM vs.
Sparse-Mode) is operationally/deployment-wise required / a good thing
or not, but this matter of principle for protocol design arguments - sorry -
strike me just as bogus.

Cheers
Toerless

Post by David Meyer
[bunch of stuff deleted...]

Post by Pekka Savola
Well, to be clear, SPT switchover is always allowed AFAIK; what you really
want is to give a strong hint (or even, an *order*) whether the routers
processing the multicast address should use it or not.

Post by Toerless Eckert
eg: by either using
one of the 4 bits of the RP address to encode this or by simply
enumerating the RP 0..15 for specific functions and simply start
allocating and using only the first few to be open to further extensions
1 = PIM-SM RP with SPT-threshold 0
2 = PIM-SM RP with SPT-threshold infinity

If we had an unlimited number of bits, why not ;-)

I would ask you (ed) to consider the effect of spreading
(overloading, really) what is essentially signaling
information all over Internet architecture. IMO this is a
recipe for disaster down the road.

Post by Pekka Savola

Post by Toerless Eckert
Yes, i remember some strange arguments why such hard operational
considerations could not become part of this spec, but none of them
sounded persuasive to me (the biggest one was something in the order of
"this is against foo-architecture guidelines"). I just can't see this,
and clearly PIM-SM is operationally two quite different protocols
depending on wether or not you have SPT-threshold infinity. Not even
discussing which mode of operations should be used - even if not
configurable - is i think not an appropriate way of bringing forward
a protocol in the mboned working group (aka: i can understand when
"protocol designers" ignore reality in the PIM working group, but mboned
was specifically meant to take care of such elements too, right ?)

There are several arguments for and against. You've rather well summed
- there is this philosophical argument that glueing any interpretation
about "magic numbers" in addresses is a bad idea. IMO, it's roughly OK as
long as you put them only in the multicast address. But if you want to
make a mapping like "RP address looks like it is using RP threshold
infinity, so perform checks A, B and C", we're venturing into a very
dangerous territory.

Same argument. Putting what comes down to signaling
semantics into addresses of any kind is going to lead
to problems.

Post by Pekka Savola
3) split off 1 bit from current 4-bit RPad field to signal this; ie.,
shrink RPad to enable 8 RPs which all could function in either mode.
b) split off 2 bits where the second would be "0=indeterminate,
1=Bidir")
4) glue different meanings to the RP addresses, like RPad=1 ==>
SPT-infinity, RPad=2 ==> SPT=0, etc. (like you propose) (so that if you
want certain functionality, you would have to use the specific
interface-ID/RP address)

Again, same argument. Instead of hacking around this
problem, why don't we just fix it (like in the protocol)?
Dave

[David Meyer]

Toerless,

Post by Toerless Eckert
For a mechanism like embedded-RP, the argument that specifying another
detail of operations and mabe express a way to select it is an overload
of signalling is a bit beside the point: The whole idea of embedded
RP addresses already is to replace a huge chunk of protocol/signalling
operations.

I understand what you are saying. I just disagree that
replacing one bad idea with another (possibly
unarchitected) one is something we might want to think a
little about.

Dave

[Kevin C. Almeroth]

Post by Pekka Savola
SSM is taking a good step in the right direction, but it doesn't really
appear to be widely available in the short term;
- there are a number of "last-mile" deployment problems, like with
snooping switches
- host support is still new or missing (also for those systems which
weren't shipped yesterday!)
- application API is in progress (though near to finalized), not widely
implemented, and the changes needed in the apps to transition them to SSM
are not not always trivial
- (routers seem to be in a pretty good state, though!)

I'd disagree that SSM isn't widely available.

Also, not to take a stab at IPv6, but some of those issues you listed
above are equally applicable to both SSM and IPv6.

Post by Pekka Savola
But that's why I've been begging for input. I heartily admit that e.g.
SSM is a better mechanism, but I'm worried about deployment and what can
be made easily available, not theory. It seems to me that a small
modification in the router software is the simplest way to deploy IPv6
multicast...

My personal opinion is that only SSM be supported in IPv6. The particular
small modifications you mention are, in my mind, a repeat of past mistakes.

While not everyone will have immediately access to IPv6 multicast, sending
a clear and simple message about what needs to be supported is going to
better encourage future support.

-Kevin

[Toerless Eckert]

Post by Kevin C. Almeroth
My personal opinion is that only SSM be supported in IPv6. The particular
small modifications you mention are, in my mind, a repeat of past mistakes.
While not everyone will have immediately access to IPv6 multicast, sending
a clear and simple message about what needs to be supported is going to
better encourage future support.

So are you saying that you are objecting to make ASM for IPv6 more
flexible and easy on the grounds that it could challenge the
acceptance of SSM in IPv6 ? Or did i miss some other argument ?

Cheers
Toerless

[Leonard Giuliano]

On Fri, 13 Jun 2003, Kevin C. Almeroth wrote:

-) >>SSM is taking a good step in the right direction, but it doesn't really
-) >>appear to be widely available in the short term;
-) >> - there are a number of "last-mile" deployment problems, like with
-) >>snooping switches
-) >> - host support is still new or missing (also for those systems which
-) >>weren't shipped yesterday!)
-) >> - application API is in progress (though near to finalized), not widely
-) >>implemented, and the changes needed in the apps to transition them to SSM
-) >>are not not always trivial
-) >> - (routers seem to be in a pretty good state, though!)
-)
-) I'd disagree that SSM isn't widely available.
-)
-) Also, not to take a stab at IPv6, but some of those issues you listed
-) above are equally applicable to both SSM and IPv6.
-)

Agree here, but I'll go a step further. These issues seem only applicable
to IPv4, and not at all to IPv6.

To paraphrase, in IPv4 the 2 biggest issues with SSM are 1) legacy
apps/kernels and 2) lack of igmpv3 snooping implementations. Well, with
IPv6, "legacy IPv6" (apps, kernels or anything) is an oxymoron. And as
for snooping- are there any MLDv1 snooping implementations/deployments out
there? Assuming the answer is no, then SSM and ASM are in the same boat
here.


-) >>But that's why I've been begging for input. I heartily admit that e.g.
-) >>SSM is a better mechanism, but I'm worried about deployment and what can
-) >>be made easily available, not theory. It seems to me that a small
-) >>modification in the router software is the simplest way to deploy IPv6
-) >>multicast...
-)
-) My personal opinion is that only SSM be supported in IPv6. The particular
-) small modifications you mention are, in my mind, a repeat of past mistakes.
-)
-) While not everyone will have immediately access to IPv6 multicast, sending
-) a clear and simple message about what needs to be supported is going to
-) better encourage future support.
-)

Wholeheartedly agree. That is why we have proposed deprecating ASM in
IPv6
(http://www.ietf.org/internet-drafts/draft-giuliano-mboned-v6mcast-framework-00.txt).
Simply put, you just don't need ASM in IPv6, so let's not bother wasting
our time on it. Instead, let's focus on a solution that solves most cases
so people will actually deploy it.

Do we really want to repeat the mistakes of the past be wondering 5 years
from now why people don't deploy mcast in v6?


-Lenny

[Stig Venaas]

Post by Leonard Giuliano
Simply put, you just don't need ASM in IPv6, so let's not bother wasting
our time on it. Instead, let's focus on a solution that solves most cases
so people will actually deploy it.

Is there any reason why ASM is less useful for IPv6 than it is for IPv4?
Are you saying that you need it for IPv4 just because SSM is hard to
deploy? Or is it just because of legacy applications?

Post by Leonard Giuliano
Do we really want to repeat the mistakes of the past be wondering 5 years
from now why people don't deploy mcast in v6?

I fail to see why the existence of ASM should stop people from deploying
SSM. I can see why some may want to deploy ASM, and why some only will
deploy SSM. I don't see any reason to deprecate ASM, although I agree
that parts of it could be improved...

I would also say that you have legacy applications for IPv6. There are
already a number of ASM applications supporting IPv6. And it's much
easier to port an IPv4 ASM application to IPv6, than it is to change it
to use SSM. Unless of course it's a simple streaming application.

I've been thinking a bit of how to modify ASM applications, so that they
can work with SSM and do the necessary source discovery on their own. It
is doable, but adds a lot of complexity at the application layer. This
in itself may not be too bad though. Someone should really try to analyze
what the possible effects are.

Stig

[Leonard Giuliano]

On Sat, 14 Jun 2003, Stig Venaas wrote:

-) On Fri, Jun 13, 2003 at 09:57:05PM -0700, Leonard Giuliano wrote:
-) > Simply put, you just don't need ASM in IPv6, so let's not bother wasting
-) > our time on it. Instead, let's focus on a solution that solves most cases
-) > so people will actually deploy it.
-)
-) Is there any reason why ASM is less useful for IPv6 than it is for IPv4?
-) Are you saying that you need it for IPv4 just because SSM is hard to
-) deploy? Or is it just because of legacy applications?
-)

Well, I think deprecating ASM in IPv4 would be a great thing as well.
Unfortunately, for these 2 reasons (legacy apps/OSs and snooping
availability), it may be a bit too late to get rid of ASM in IPv4. But
it's not too late to do things right in IPv6.

-) > Do we really want to repeat the mistakes of the past be wondering 5 years
-) > from now why people don't deploy mcast in v6?
-)
-) I fail to see why the existence of ASM should stop people from deploying
-) SSM. I can see why some may want to deploy ASM, and why some only will
-) deploy SSM. I don't see any reason to deprecate ASM, although I agree
-) that parts of it could be improved...
-)

Unfortunately, the presence of ASM still DOES affect the deployment of
SSM. Look at any mcast wg meeting at IETF- 90% of the work and discussion
is about addressing ASM limitations. Get rid of ASM, and you send a clear
message to app writers to make sure their apps are SSM-aware. And we
focus more attention to a model that will have a much better chance of
deployment, scales better, is more secure, etc. Do the interdomain
unicast routing WGs spend time on RIPs limitations?


-) I would also say that you have legacy applications for IPv6. There are
-) already a number of ASM applications supporting IPv6. And it's much
-) easier to port an IPv4 ASM application to IPv6, than it is to change it
-) to use SSM. Unless of course it's a simple streaming application.
-)

Which is easier, creating/extending/bastardizing network protocols,
getting them implemented by vendors and deployed by ISPs -or- fixing apps?
By virtue of the fact that in IPv6, interdomain ASM mcast is currently
impossible, and intradomain Anycast RP is impossible, the existence of a
few v6 ASM apps today is moot- deployments are impossible. So let's
define what the network does now, before it's too late.

Are we willing to mortgage the future of IPv6 mcast routing just so we can
enable a few v6 apps work right now?

Do we want to continue designing protocols just so that SDR works?

-) I've been thinking a bit of how to modify ASM applications, so that they
-) can work with SSM and do the necessary source discovery on their own. It
-) is doable, but adds a lot of complexity at the application layer. This
-) in itself may not be too bad though. Someone should really try to analyze
-) what the possible effects are.
-)

This is what needs to be done. Spending more time figuring out how apps
can handle source discovery, instead of making the network do it. It's
certainly possible- if routers can do it, apps can do it, and do it much
better. Complexity has to go somewhere- either the apps or the network.
I believe the network should not provide this function.

-) Stig
-)

[s***@shepfarm.com]

Post by Leonard Giuliano
-) > Simply put, you just don't need ASM in IPv6, so let's not bother wasting
-) > our time on it. Instead, let's focus on a solution that solves most cases
-) > so people will actually deploy it.
-)
-) Is there any reason why ASM is less useful for IPv6 than it is for IPv4?
-) Are you saying that you need it for IPv4 just because SSM is hard to
-) deploy? Or is it just because of legacy applications?
-)
Well, I think deprecating ASM in IPv4 would be a great thing as well.
Unfortunately, for these 2 reasons (legacy apps/OSs and snooping
availability), it may be a bit too late to get rid of ASM in IPv4. But
it's not too late to do things right in IPv6.
-) > Do we really want to repeat the mistakes of the past be wondering 5 years
-) > from now why people don't deploy mcast in v6?
-)
-) I fail to see why the existence of ASM should stop people from deploying
-) SSM. I can see why some may want to deploy ASM, and why some only will
-) deploy SSM. I don't see any reason to deprecate ASM, although I agree
-) that parts of it could be improved...
-)
Unfortunately, the presence of ASM still DOES affect the deployment of
SSM. Look at any mcast wg meeting at IETF- 90% of the work and discussion
is about addressing ASM limitations. Get rid of ASM, and you send a clear
message to app writers to make sure their apps are SSM-aware. And we
focus more attention to a model that will have a much better chance of
deployment, scales better, is more secure, etc. Do the interdomain
unicast routing WGs spend time on RIPs limitations?

Lenny, I completely agree - BUT in holding with Nidhi's questions, I'd
have to say the 90% (and that's WAY conservative) of the effort is spent
dealing with network-based source discovery issue; ie, finding RPs,
communicating between RPs, ensureing data packets arrive interdomain for
SDR so the SPT can be built, etc..

Post by Leonard Giuliano
-) I would also say that you have legacy applications for IPv6. There are
-) already a number of ASM applications supporting IPv6. And it's much
-) easier to port an IPv4 ASM application to IPv6, than it is to change it
-) to use SSM. Unless of course it's a simple streaming application.
-)
Which is easier, creating/extending/bastardizing network protocols,
getting them implemented by vendors and deployed by ISPs -or- fixing apps?
By virtue of the fact that in IPv6, interdomain ASM mcast is currently
impossible, and intradomain Anycast RP is impossible, the existence of a
few v6 ASM apps today is moot- deployments are impossible. So let's
define what the network does now, before it's too late.

Exactly!! And that was the very point of our intent. Put a stake in the
ground before v6 mcast gets way out of control and becomes unusable - or
painfully usable as interdomain v4 mcast is today.

Post by Leonard Giuliano
Are we willing to mortgage the future of IPv6 mcast routing just so we can
enable a few v6 apps work right now?
Do we want to continue designing protocols just so that SDR works?
-) I've been thinking a bit of how to modify ASM applications, so that they
-) can work with SSM and do the necessary source discovery on their own. It
-) is doable, but adds a lot of complexity at the application layer. This
-) in itself may not be too bad though. Someone should really try to analyze
-) what the possible effects are.
-)
This is what needs to be done. Spending more time figuring out how apps
can handle source discovery, instead of making the network do it. It's
certainly possible- if routers can do it, apps can do it, and do it much
better. Complexity has to go somewhere- either the apps or the network.
I believe the network should not provide this function.
-) Stig
-)

[s***@shepfarm.com]

Well said.

Greg

Post by Leonard Giuliano
-) >>SSM is taking a good step in the right direction, but it doesn't really
-) >>appear to be widely available in the short term;
-) >> - there are a number of "last-mile" deployment problems, like with
-) >>snooping switches
-) >> - host support is still new or missing (also for those systems which
-) >>weren't shipped yesterday!)
-) >> - application API is in progress (though near to finalized), not widely
-) >>implemented, and the changes needed in the apps to transition them to SSM
-) >>are not not always trivial
-) >> - (routers seem to be in a pretty good state, though!)
-)
-) I'd disagree that SSM isn't widely available.
-)
-) Also, not to take a stab at IPv6, but some of those issues you listed
-) above are equally applicable to both SSM and IPv6.
-)
Agree here, but I'll go a step further. These issues seem only applicable
to IPv4, and not at all to IPv6.
To paraphrase, in IPv4 the 2 biggest issues with SSM are 1) legacy
apps/kernels and 2) lack of igmpv3 snooping implementations. Well, with
IPv6, "legacy IPv6" (apps, kernels or anything) is an oxymoron. And as
for snooping- are there any MLDv1 snooping implementations/deployments out
there? Assuming the answer is no, then SSM and ASM are in the same boat
here.
-) >>But that's why I've been begging for input. I heartily admit that e.g.
-) >>SSM is a better mechanism, but I'm worried about deployment and what can
-) >>be made easily available, not theory. It seems to me that a small
-) >>modification in the router software is the simplest way to deploy IPv6
-) >>multicast...
-)
-) My personal opinion is that only SSM be supported in IPv6. The particular
-) small modifications you mention are, in my mind, a repeat of past mistakes.
-)
-) While not everyone will have immediately access to IPv6 multicast, sending
-) a clear and simple message about what needs to be supported is going to
-) better encourage future support.
-)
Wholeheartedly agree. That is why we have proposed deprecating ASM in
IPv6
(http://www.ietf.org/internet-drafts/draft-giuliano-mboned-v6mcast-framework-00.txt).
Simply put, you just don't need ASM in IPv6, so let's not bother wasting
our time on it. Instead, let's focus on a solution that solves most cases
so people will actually deploy it.
Do we really want to repeat the mistakes of the past be wondering 5 years
from now why people don't deploy mcast in v6?
-Lenny

[Nidhi Bhaskar]

Hi,

Post by s***@shepfarm.com
Well said.
Greg

<snip>

Post by s***@shepfarm.com

Post by Leonard Giuliano
Wholeheartedly agree. That is why we have proposed deprecating ASM in
IPv6
(http://www.ietf.org/internet-drafts/draft-giuliano-mboned-v6mcast-framework-00.txt).

I think the draft could do with some clarification.

Post by s***@shepfarm.com

Post by Leonard Giuliano
Simply put, you just don't need ASM in IPv6, so let's not bother wasting
our time on it. Instead, let's focus on a solution that solves most cases
so people will actually deploy it.

While you say above that the proposal is to deprecate ASM for IPv6, it
reads more like the proposal is to deprecate PIM-SM spt switchover +
MSDP. I'm not sure they are the same thing.

Section 2.1 states:

Since network-based source-discovery unnecessarily contributes to
the cost and complexity of the network infrastructure in a
significant way, this document proposes to deprecate network-based
multicast source discovery in IPv6. With source discovery provided
by the application layer, SSM and Bidirectional-PIM (BiDir-PIM) are
the only service models necessary for deploying IPv6 multicast.


But Bidir-PIM does rely on network-based-source-discovery. The
receiver only joins a group, not a source & group. The last hop DR
relies on the RP shared tree (network) to forward active sources to
receivers. The application does not tell the DR who the sources are.
Why don't you consider Bidir PIM an ASM protocol? How do you classify
it ?

Also, I think no matter what you propose in this draft, it all boils
down to OS/app support for MLDv2. And possibly to some open source
reference implementations of v4/v6 apps that do 'source discovery at
the application layer'. Neither of which are availble to users
deploying IPv6 multicast today.



Thanks,
Nidhi.

[s***@shepfarm.com]

Post by Nidhi Bhaskar
Hi,

Post by s***@shepfarm.com
Well said.
Greg

<snip>

Post by s***@shepfarm.com

Post by Leonard Giuliano
Wholeheartedly agree. That is why we have proposed deprecating ASM in
IPv6
(http://www.ietf.org/internet-drafts/draft-giuliano-mboned-v6mcast-framework-00.txt).

I think the draft could do with some clarification.

Post by s***@shepfarm.com

Post by Leonard Giuliano
Simply put, you just don't need ASM in IPv6, so let's not bother wasting
our time on it. Instead, let's focus on a solution that solves most cases
so people will actually deploy it.

While you say above that the proposal is to deprecate ASM for IPv6, it
reads more like the proposal is to deprecate PIM-SM spt switchover +
MSDP. I'm not sure they are the same thing.
Since network-based source-discovery unnecessarily contributes to
the cost and complexity of the network infrastructure in a
significant way, this document proposes to deprecate network-based
multicast source discovery in IPv6. With source discovery provided
by the application layer, SSM and Bidirectional-PIM (BiDir-PIM) are
the only service models necessary for deploying IPv6 multicast.
But Bidir-PIM does rely on network-based-source-discovery. The
receiver only joins a group, not a source & group. The last hop DR
relies on the RP shared tree (network) to forward active sources to
receivers. The application does not tell the DR who the sources are.
Why don't you consider Bidir PIM an ASM protocol? How do you classify
it ?

Well, I'd have to classify BiDir as an ALL Source Multicast protocol. The
source info is ignored. So I think we're picking symantics here, but we
should try to settle on common terms. So I'll have to agree that this
boils down to depricating spt and MSDP - how do you suggest it be
described?

Post by Nidhi Bhaskar
Also, I think no matter what you propose in this draft, it all boils
down to OS/app support for MLDv2. And possibly to some open source
reference implementations of v4/v6 apps that do 'source discovery at
the application layer'. Neither of which are availble to users
deploying IPv6 multicast today.

Yes - OS/app for MLDv2. Reference apps is also a good suggestion. The lack
of availability I believe is primarily due to the fact the most (all) v6
apps are just v4 ports and bring along with them network based source
discovery. I wanted to include depricating MLDv1, but MLDv2 already does
that. =)

Greg

Post by Nidhi Bhaskar
Thanks,
Nidhi.

[Nidhi Bhaskar]

Post by s***@shepfarm.com

Post by Nidhi Bhaskar
But Bidir-PIM does rely on network-based-source-discovery. The
receiver only joins a group, not a source & group. The last hop DR
relies on the RP shared tree (network) to forward active sources to
receivers. The application does not tell the DR who the sources are.
Why don't you consider Bidir PIM an ASM protocol? How do you classify
it ?

Well, I'd have to classify BiDir as an ALL Source Multicast protocol.

I see, that is a new term for me :-)

Post by s***@shepfarm.com
The source info is ignored. So I think we're picking symantics here,
but we should try to settle on common terms. So I'll have to agree
that this

Right. 'Deprecating ASM' was a bit alarming, until I read the
draft.

Post by s***@shepfarm.com
boils down to depricating spt and MSDP - how do you suggest it be
described?

Lets see, how about - 'Deprecate the use of MSDP for interdomain
multicast in IPv6'. It suggests depracating exactly what your draft
describes as complex & a deployment hurdle. I think its too early to
suggest depracating PIM-SM for v6 - people use it, works within a PIM
domain etc. could be revisited later, perhaps...

Or something along the lines of - 'Protocols that implement the ASM
model for IPv6 MUST NOT require flooding & maintaining state for active
sources in all parts of the network for source discovery'.

Post by s***@shepfarm.com

Post by Nidhi Bhaskar
Also, I think no matter what you propose in this draft, it all boils
down to OS/app support for MLDv2. And possibly to some open source
reference implementations of v4/v6 apps that do 'source discovery at
the application layer'. Neither of which are availble to users
deploying IPv6 multicast today.

Yes - OS/app for MLDv2. Reference apps is also a good suggestion. The lack
of availability I believe is primarily due to the fact the most (all) v6
apps are just v4 ports and bring along with them network based source
discovery. I wanted to include depricating MLDv1, but MLDv2 already does
that. =)

Right. It might also be interesting to learn why ipv4 applications
haven't moved in the last few years that SSM has been available - I
fear things are going to be even slower for v6!


Thanks,
Nidhi.

Post by s***@shepfarm.com
Greg

Post by Nidhi Bhaskar
Thanks,
Nidhi.

[Toerless Eckert]

Post by Leonard Giuliano
Agree here, but I'll go a step further. These issues seem only applicable
to IPv4, and not at all to IPv6.
To paraphrase, in IPv4 the 2 biggest issues with SSM are 1) legacy
apps/kernels and 2) lack of igmpv3 snooping implementations. Well, with
IPv6, "legacy IPv6" (apps, kernels or anything) is an oxymoron. And as
for snooping- are there any MLDv1 snooping implementations/deployments out
there? Assuming the answer is no, then SSM and ASM are in the same boat
here.

All right. So, which IPv6 applications and host stacks do you know ?
If you were trying to make an exhaustive list, then ist would show
that the situation of SSM support is not much different than in IPv4.

Post by Leonard Giuliano
Wholeheartedly agree. That is why we have proposed deprecating ASM in
IPv6
(http://www.ietf.org/internet-drafts/draft-giuliano-mboned-v6mcast-framework-00.txt).
Simply put, you just don't need ASM in IPv6, so let's not bother wasting
our time on it. Instead, let's focus on a solution that solves most cases
so people will actually deploy it.

That's a noble attempt in support of SSM, and you might even get it
through as an informational RFC, and that might help some customers to
consider more strongly to mive to SSM in IPv6, but that's about as much
as it will achieve. - Which is fine, but which certainly does not
deprecate ASM.

Post by Leonard Giuliano
Do we really want to repeat the mistakes of the past be wondering 5 years
from now why people don't deploy mcast in v6?

What ? ASM was a mistake ? I don't think so. Sure, we had problems for
which we found no good nor simple enough solutions (like address allocation,
interdomain ASM with MSDP, or worse BGMP), and for those applications that
were hit hardest by these problems, SSM definitely was and is the best
solution in IPv4.

But please don't just switch off your brain and say "in IPv6 everything is
the same" - it is not. IPv6 is not only a different ball park, it is
a completely new game !

- We do not have address allocation issues due to rfc3306
(address management - mayor reason for global SSM in IPv4, remember ?)

- We do not have the interdomain MSDP problem because of embedRP
(simplicity - mayor reason for SSM in IPv4, remember ?)

- We as far as the third argument in favor of SSM in IPv4 goes:
we can even have DoS attack reduced very similar to SSM with
ebedRP (see my other email on that thread).

So, instead of repeating our IPv4 SSM prayer into IPv6 unchanged, could
we please stick to the facts and acknowledge that those are different
in IPv6 over IPv4 ?

Cheers
Toerless

[Leonard Giuliano]

On Sat, 14 Jun 2003, Toerless Eckert wrote:

-) On Fri, Jun 13, 2003 at 09:57:05PM -0700, Leonard Giuliano wrote:
-) > Agree here, but I'll go a step further. These issues seem only applicable
-) > to IPv4, and not at all to IPv6.
-) >
-) > To paraphrase, in IPv4 the 2 biggest issues with SSM are 1) legacy
-) > apps/kernels and 2) lack of igmpv3 snooping implementations. Well, with
-) > IPv6, "legacy IPv6" (apps, kernels or anything) is an oxymoron. And as
-) > for snooping- are there any MLDv1 snooping implementations/deployments out
-) > there? Assuming the answer is no, then SSM and ASM are in the same boat
-) > here.
-)
-) All right. So, which IPv6 applications and host stacks do you know ?
-) If you were trying to make an exhaustive list, then ist would show
-) that the situation of SSM support is not much different than in IPv4.
-)
-) > Wholeheartedly agree. That is why we have proposed deprecating ASM in
-) > IPv6
-) > (http://www.ietf.org/internet-drafts/draft-giuliano-mboned-v6mcast-framework-00.txt).
-) > Simply put, you just don't need ASM in IPv6, so let's not bother wasting
-) > our time on it. Instead, let's focus on a solution that solves most cases
-) > so people will actually deploy it.
-)
-) That's a noble attempt in support of SSM, and you might even get it
-) through as an informational RFC, and that might help some customers to
-) consider more strongly to mive to SSM in IPv6, but that's about as much
-) as it will achieve. - Which is fine, but which certainly does not
-) deprecate ASM.
-)

The goal is not to publish a document, but rather to get people to turn
mcast on. In the words of John Z, "I want my MTV!"

-) > Do we really want to repeat the mistakes of the past be wondering 5 years
-) > from now why people don't deploy mcast in v6?
-)
-) What ? ASM was a mistake ? I don't think so. Sure, we had problems for
-) which we found no good nor simple enough solutions (like address allocation,
-) interdomain ASM with MSDP, or worse BGMP), and for those applications that
-) were hit hardest by these problems, SSM definitely was and is the best
-) solution in IPv4.
-)

Perhaps "mistake" is a bit too revisionist. Replace it with "lessons".
Anyway, the lesson I am refering to is making the network responsible for
source discovery. We don't make routers keep track of all of the
hostnames or websites on the Internet. So why do we make them keep track
of all the mcast sources? Our draft actually proposes to deprecate
network based source discovery. Get rid of that and you don't need ASM.


-) But please don't just switch off your brain and say "in IPv6 everything is
-) the same" - it is not. IPv6 is not only a different ball park, it is
-) a completely new game !
-)
-) - We do not have address allocation issues due to rfc3306
-) (address management - mayor reason for global SSM in IPv4, remember ?)
-)
-) - We do not have the interdomain MSDP problem because of embedRP
-) (simplicity - mayor reason for SSM in IPv4, remember ?)
-)
-) - We as far as the third argument in favor of SSM in IPv4 goes:
-) we can even have DoS attack reduced very similar to SSM with
-) ebedRP (see my other email on that thread).
-)

IMO, the main benefit of SSM is simplicity. All the other stuff-
addressing, security, etc- is just icing on the cake. What we have seen
the last 5 years is that if you have something horribly complex, people
won't turn it on.

EmbedRP may solve one problem, but it still requires a whole new behavior
for PIM- sending joins to an RP in another domain. Analysis of the myriad
of corner cases of PIM will need to be done with this. And you still have
the problem of anycast RP within a domain. Instead of continuing the
search for the best color of lipstick for a pig, let's get rid of the need
for the pig in the first place.

Get rid of network-based source discovery, then you don't need ASM, RPs,
MSDP, BGMP, Embed, pigs, or lipstick. Interdomain v6 mcast? Fixed.
Done. We can all go home early.

You also get rid of 90% of the complexity of mcast. The whitepaper on
deploying mcast is reduced from many pages to one sentence- "Turn PIM on
all your interfaces."



-) So, instead of repeating our IPv4 SSM prayer into IPv6 unchanged, could
-) we please stick to the facts and acknowledge that those are different
-) in IPv6 over IPv4 ?
-)
-) Cheers
-) Toerless
-)

[Toerless Eckert]

Post by Leonard Giuliano
-) All right. So, which IPv6 applications and host stacks do you know ?
-) If you were trying to make an exhaustive list, then ist would show
-) that the situation of SSM support is not much different than in IPv4.

Didn't get an answer on that one...

Post by Leonard Giuliano
-) That's a noble attempt in support of SSM, and you might even get it
-) through as an informational RFC, and that might help some customers to
-) consider more strongly to mive to SSM in IPv6, but that's about as much
-) as it will achieve. - Which is fine, but which certainly does not
-) deprecate ASM.
The goal is not to publish a document, but rather to get people to turn
mcast on. In the words of John Z, "I want my MTV!"

That's why i called it a noble attempt, but the intentions alone (go
for SSM) don't justify slandering of ASM. Real technical arguments would
be much more persuase. Yes, it looks like a duck, but it could quack quite
differently because it's an IPv6 duck !

Post by Leonard Giuliano
Perhaps "mistake" is a bit too revisionist. Replace it with "lessons".
Anyway, the lesson I am refering to is making the network responsible for
source discovery.

Yes, that's a nice gospel, but it's mixing cause and effect to make
a more easy story for the lay person. If we had a simple way to do
source discovery in the network, then it wouldn't be bad right ? We
declared it bad in IPv4 because we couldn't determine a way to make
it simple enough so that the overal solution complexity could well
measure up against the lesser complexity of let's say a web based
application with SSM.

But what's behind it ? Having an RP by itself isn't too bad, it is the
problem of having to have this global topology of MSDP interconnected RPs.
This architecture was born out of IPv4 realities and history, and is
not equivalent to what we could do with IPv6: The solution we have today
with embedRB was and is not possible with IPv4 and likewise were the
view at applications different. All this lead us to arguments resulting
in the MSDP mess:

a) Applications instances were supposed to be primarily anarchic
with no defined ownership - because IPv4 multicast predates the
web by 7 years. Only after the web has become successfull did
many people recognize that while anarchic distribion is nice
(and served us well not only with IP multicast, but with many
prior services, like usenet for example), but that in most
commercial applications this is not only not necessary but also
unwanted to have.

b) Because of a) designers at that time were not really interested
all that much to consider applications just to have a single RP.
Besides: If dynamic protocols would be needed to disseminate
group-to-rp mapping in advance then there would be not much
difference between SA flooding and such group/RP mapping flooding
because in the end - to avoid third party dependency, you would
have to be able to have as many RPs as one per active application,
so that you can always guarantee that whoever is the owner of an
application can also take ownership of the coordination point - the
RP.

Today we can do this with embedRP, and the task of getting a
group-address (and thereby selecting the RP closest to you) is
not much different from finding a web or application server on
which you would like to coordinate the SSM application.

Post by Leonard Giuliano
We don't make routers keep track of all of the
hostnames or websites on the Internet. So why do we make them keep track
of all the mcast sources?

We don't! But much like for example a router will keep track of DHCP
address allocation, he could as well act as an RP for groups opened
by directly connected hosts and do the registering for the remote
sources that are joing these groups.

With the embedRP model, a router does keep as much state as a webserver
would need to have: Only that of applications associated with it as
the control point. The embedRP solution actually allows us to do this
application coordination much easier than we could have it today with SSM:
Where is the middleware specification on how to do ASM emulation over SSM
for group applications ? So each application has to do that on it's own ?
That's not sounding too convincing. We certainly have some work to do on
SSM (session layer, not network lauyer!) to make it a convincing and as easy
to use alternative as ASM is, and that applies to both IPv4 and IPv6.

Post by Leonard Giuliano
IMO, the main benefit of SSM is simplicity. All the other stuff-
addressing, security, etc- is just icing on the cake.

How often have you talked to people in actual customer spaces looking
at solutions ? And i am not talking about the people running the network.
The network folks of course love SSM, but people writing applications
need to be presented with other benefits to be persuaded - guess why it
hasn't been picked up much more ? Because we are waiting for people to
do something who do not have the biggest benefit of SSM (aka: application
developers). If this was the same cooperative Internet that we have before
1995, this wouldn't be a problem, but today everything is very much
business oriented, and you have to be able to show a good bottom line
within 2 quarters. That's difficult to do, unless there is sufficient
technical talent in the customer space.

Post by Leonard Giuliano
What we have seen the last 5 years is that if you have something
horribly complex, people won't turn it on.

Ah, so that's why we have PIM-SM with MSDP deployed all over the world ?
Remind me: What was the horrible complex alternative to this simple
solution ?

Fact is that people turn stuff on when they must. That's why it was
a hard and long sell to convince customers to move to PIM-SM instead
of DVMRP or PIM-DM - heck, even end of last year there was a shootout between
what - 8 ? - vendors and it was based on PIM-DM because the mayority couldn't
run PIM-SM correctly.

Post by Leonard Giuliano
EmbedRP may solve one problem, but it still requires a whole new behavior
for PIM- sending joins to an RP in another domain.

FUD. A PIM domain has no close ties to a routing domain and a routing
domain does not necessarily match 1:1 an administrative domain. Wide scale
PIM domains have been run more than once, they are run today with IPv6,
and they were run in the past before the official policy was to use MSDP.

Post by Leonard Giuliano
Analysis of the myriad of corner cases of PIM will need to be done with this.

FUD. There are no corner cases beyond what has and will still happen
in larger enterprise networks. For the purpose of a remote RP, the
only interesting piece are the register messages and interoperability of
those has and will be faster explored in enterprises than in Interdomain
deployment.

Post by Leonard Giuliano
And you still have > the problem of anycast RP within a domain.

There are pretty simple solutions.

Post by Leonard Giuliano
Instead of continuing the search for the best color of lipstick for a pig
let's get rid of the need for the pig in the first place.

If you can't come up with anything better than i guess you mean to be
slander for ASM, you will not serve SSM. I am as much for SSM as you are,
but i will personally not forego sound and simple technical solutions for
ASM in IPv6 just to drive a political agenda.

And as far as getting rid of pigs is concerned, i think you should have
a serious conversation with Greg on this in the first place. I for once
think pigs are cute or tasty (sometimes both ;-).

Post by Leonard Giuliano
Get rid of network-based source discovery, then you don't need ASM, RPs,
MSDP, BGMP, Embed, pigs, or lipstick. Interdomain v6 mcast? Fixed.
Done. We can all go home early.

... and wait for whatever comes first: our pension or the applications.
Right? No! The network folks have the most benefit of SSM, they need to
drive more than just the network layer for SSM to be successfull.

Post by Leonard Giuliano
You also get rid of 90% of the complexity of mcast. The whitepaper on
deploying mcast is reduced from many pages to one sentence- "Turn PIM on
all your interfaces."

Hey, i am all for it, and i can substantiate all your buzzwords statements
about ASM/SSM in IPv4 quite fine. It just does not apply equally in IPv6.
Does this make SSM any less attractive ? I think not, but it makes ASM
much more attactive. Is that a problem ? Yes, politically it may/will be,
but that should really not influence our technical disuccion in the IETF.
We should try to come up with the best solutions for both (and reminder:
there's need for SSM session layer, don't go home waiting for the pension
right now !).

Cheers
Toerless

[Leonard Giuliano]

On Sat, 14 Jun 2003, Toerless Eckert wrote:

-) On Sat, Jun 14, 2003 at 05:22:31PM -0700, Leonard Giuliano wrote:
-) > -) All right. So, which IPv6 applications and host stacks do you know ?
-) > -) If you were trying to make an exhaustive list, then ist would show
-) > -) that the situation of SSM support is not much different than in IPv4.
-)
-) Didn't get an answer on that one...
-)

As for OSs, actually I don't know. An exhaustive list is unimportant.
Anyone know if any versions of Windows support any versions of MLD?

As for the ASM apps, FIX THEM! App developers sit in bean bags and drink
Mountain Dew. ISPs are run by the phone company. I refuse to buy the
argument that the phone company can innovate faster than Mountain Dew
drinking snowboarders. And remember, it's not just one phone company that
needs to turn it on; ALL of them need to do it. If you don't believe me,
I'll give you the number for my cable modem provider. Ask them when they
will be deploying mcast and let me know what they tell you.

Any app developer should know that if they want people to use their stuff,
apps need to compensate for the limitations/laziness/cluelessness of the
network. Not the other way around.

-)
-) But what's behind it ? Having an RP by itself isn't too bad, it is the

Disagree.

-) Ah, so that's why we have PIM-SM with MSDP deployed all over the world ?
-) Remind me: What was the horrible complex alternative to this simple
-) solution ?
-)

So you are pleased with how deployment is going? I am not, and I presume
I am not alone.

Folks at Sprint, Verio, I2, etc will probably deploy whatever is there,
regardless of complexity. They are not the problem. It's the
non-pioneering rest of the world we have to worry about. The operators
who aren't on this mailing list and could care less about mcast. They
will only deploy it if it's real simple. As long as it's got RPs in it,
the architecture is too complex. Too complex = not deployed. So for
widespread deployment, it's not ASM vs SSM, it's SSM vs nothing.

The main question is do we need ASM? For IPv4, I think it's debateable.
For IPv6, IMO there's no debate. We need to decide if we need it. If we
don't, let's get rid of it, because it's not helping.

-) > And you still have > the problem of anycast RP within a domain.
-)
-) There are pretty simple solutions.
-)

Care to share any? Keep in mind there's a reason why no one uses BSR.

-)
-) And as far as getting rid of pigs is concerned, i think you should have
-) a serious conversation with Greg on this in the first place. I for once
-) think pigs are cute or tasty (sometimes both ;-).
-)

I love bacon, ham and pork chops (mmm, pork chops). I think there's a
place for pigs- on a plate or in Greg's barn. I just don't think IPv6 is
one of them.

[Toerless Eckert]

Post by Leonard Giuliano
As for OSs, actually I don't know. An exhaustive list is unimportant.
Anyone know if any versions of Windows support any versions of MLD?
As for the ASM apps, FIX THEM! App developers sit in bean bags and drink

Yes, but this developer is shielded by triple layers of product
marketing, management and economy analysis, and all those folks want
to know why the developer should raise his finger for this task - show them
the money, and it has to be at least 10th of millions.

Post by Leonard Giuliano
Mountain Dew.

*yuck*.

Post by Leonard Giuliano
ISPs are run by the phone company. I refuse to buy the
argument that the phone company can innovate faster than Mountain Dew
drinking snowboarders.

[private ranting mode on - don't consider this to be Ciscos opinion]
Just one example:
How comes that a company that completey hangs out their image as mountain -
cool - dew drinking even cooler snowboarders - ultracool guys like
Nullsoft haven't even implement freaking IP - well known v4 - multicast
for years now even though you can find more than just one interview
with these folks about how cool IP multicast would be. Is it because cool
people in the end want to make up only their own cool stuff to support
their egos or because ip multicast isn't cool, but just useful or even
necessary ? Or is it because named cool people in the end report to yet
another replacement for TPC and nobody has manged to show the triple layer
shielding 10th of millions of dollars success guarantee ? I guess in the
end, the ecxuse is the same stupid chicken&egg salat that we have heard
for 10 years now by application: "why should i support IP multicast, if
the network doesn't support it". Yeah, right. By making sure that the
market leading applications don't support multicast you also make sure that
the network has no incentive to support it either. Great job.
[ranting mode off]

Post by Leonard Giuliano
And remember, it's not just one phone company that
needs to turn it on; ALL of them need to do it. If you don't believe me,
I'll give you the number for my cable modem provider. Ask them when they
will be deploying mcast and let me know what they tell you.

Wait a second, we're in this together right ? I can give you names of
people in TPC to whom i've complained 5 years ago that they should do
IP multicast. Now show me your complaints ;-))

And by the way: I actually think that it's good enough to initially have
just ONE last-mile provider enable IP multicast within any competitive market
ubiquitously, eg: not all. Unfortunately, in many markets there only is
ONE actual usable provider (and if he's intelligent he's got 20 resellers
to hide that fact).

Post by Leonard Giuliano
Any app developer should know that if they want people to use their stuff,
apps need to compensate for the limitations/laziness/cluelessness of the
network. Not the other way around.

Well, that's what i try to preach to application developers to, but
it's hard: Just look at application written to leverage whatever
is there - IP unicast. Don't even start counting the stupid workarounds
applications have to do to cope with that services inadequacies.

In IP multicast, many networks supporting it are bought and
built together with an application, only that many customers think that
the application can be arbitrarily stupid and the network has to jump
through arbitrary hoops to best support that application: 1 packet loss
withing 48 hours in a nation wide network and no packet reordering please.
Yeah sure, that's exactly the IP service model.

But wait! what are our marketing folks doing (yours as much as ours) -
they're selling exactly this as QoS! And there's a whole solution
architecture called VoIP that relies on exactly this ! And it even works.

So, effectively, the network has jumped through hoops to provide new
services, and with IP multicast still being considered by most to be
a technology for new services, the same expectations are raised against it
as well - persistent initial packet loss with MSDP ? Well, what's the
worse workaround here ?

Post by Leonard Giuliano
-) But what's behind it ? Having an RP by itself isn't too bad, it is the
Disagree.

I think it is very hard to honestly judge a solution on it's
architectural benefits and shortcoming but keeping actual products
limitations out of the picture. If you think you can do this, more
power to you. I for once have come to see that typically solutions/
technologies that can _not_ be supported by one's product are likely
tried to be argued as inferior. My recommendation is to overcompensate,
that's what i have been doing with respect to IGMPv3 snooping.
Maybe you should consider this for embedRP ?

;-)))

[ Did you see my other email ? If you consider the first-hop RP does
embedRP with MADCAP, you pretty much have SSM! ]

Post by Leonard Giuliano
The operators who aren't on this mailing list and could care less about
mcast. They will only deploy it if it's real simple. As long as it's got
RPs in it, the architecture is too complex.

That's the same as saying: "As long as it's got TCP in it, the architecture
is too complex" - the transit ISP doesn't have to participate in any RP
operations at all. The RP is in a customer network or some ASP. So,
what's the deal here ?:

SSM-join: a) receive (S,G) join
b) RPFinterface = RPF_lookup(S)
c) send (S,G) join to RPFinterface

embedRPjoin: a) receive (*,G) join
b) RPFinterface = RPF_loookup(embedRP_map(G))
c) send (*,G) join to RPFinterface

c'mon !

Post by Leonard Giuliano
Too complex = not deployed. So for
widespread deployment, it's not ASM vs SSM, it's SSM vs nothing.

Is that an official J position ?

Post by Leonard Giuliano
The main question is do we need ASM? For IPv4, I think it's debateable.
For IPv6, IMO there's no debate. We need to decide if we need it. If we
don't, let's get rid of it, because it's not helping.

Well, to repeat my opinions on this:
- It's unfair to the market / application developers to remove ASM
before a comparable solutions architecture with SSM is defined ->
aka: let's define an ASM session-layer for SSM, and then talk
about the need for network layer ASM
b) IETF process wise:
- We MUST judge network ASM/SSM in face of their actual technical merits
and complexity. With embedRP, the evaluation of this is quite different
from IPv4.
- We MUST assume, ASM is needed. Wether it's session level or
network level ASM is a different issue, but we can only declare
network level ASM to be deprecated if we know that a session level
ASM is actually technical easier and more widely accepted.

Cheers
Toerless

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Toerless Eckert
- It's unfair to the market / application developers to remove ASM
before a comparable solutions architecture with SSM is defined ->
aka: let's define an ASM session-layer for SSM, and then talk
about the need for network layer ASM

Agree.

Options include doing the session layer in host kernels, in application
libraries, or elsewhere. We should look at the existing applications to
find common factors. There is also a body of literature in the
distributed-memory message-passing supercomputing research community that
may be relevant.

Post by Toerless Eckert
- We MUST judge network ASM/SSM in face of their actual technical merits
and complexity. With embedRP, the evaluation of this is quite different
from IPv4.

Agree.

Post by Toerless Eckert
- We MUST assume, ASM is needed. Wether it's session level or
network level ASM is a different issue, but we can only declare
network level ASM to be deprecated if we know that a session level
ASM is actually technical easier and more widely accepted.

Agree.

Amazing--I'm actually in agreement with Toerless. Who would have ever
thought that possible? :-)



===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Leonard Giuliano
As for the ASM apps, FIX THEM! App developers sit in bean bags and drink
Mountain Dew. ISPs are run by the phone company. I refuse to buy the
argument that the phone company can innovate faster than Mountain Dew
drinking snowboarders. And remember, it's not just one phone company that
needs to turn it on; ALL of them need to do it. If you don't believe me,
I'll give you the number for my cable modem provider. Ask them when they
will be deploying mcast and let me know what they tell you.

I have bad news for you.

First of all, getting an ASM application converted to use SSM is a
nontrivial exercise. The application has to be more complex, if for no
other reason than to internally discover and manage the set of sources.

But even if the application is designed with that requirement in mind, it's
still not enough. Take my favorite application--Access Grid--as an example.

As I said on the PIM mailing list a few weeks ago, the Access Grid
developers are releasing version 2.0 of their collaboration tool kit. Go to

http://www.mcs.anl.gov/fl/research/accessgrid/software/releases/2.0/index.html

and install it on your RedHat Linux 7.3 or Windows 2000/XP host. As the
Open Source folks like to say, it's free (as in beer). There are something
like 200 Access Grid nodes deployed across the world today, primarily using
research and education networks that are solidly multicast enabled.

Access Grid nodes use a software mechanism that keeps track of all "nodes"
in a "venue". Architecturally, Access Grid is perfectly positioned to use
SSM, as the venue server already knows about all of the nodes participating
in the venue.

Where possible, Access Grid nodes use ASM-style IPv4 multicast. SSM/IGMPv3
is not in currently in the AG developers plans, because it would require
them to depend on local sites to implement IGMPv3 and SSM.

Post by Leonard Giuliano
Any app developer should know that if they want people to use their stuff,
apps need to compensate for the limitations/laziness/cluelessness of the
network. Not the other way around.

Exactly right. But the way the AG developers are compensating is NOT to
wait for end-to-end SSM deployment. Rather, they're working on purely
host-software-based multicast services. (They want to do more than just
data forwarding--they're talking about things like trans-coding video
formats as well.)

Based on the AG experience with how hard it is to get IPv4 ASM working, the
AG developers are making a rational decision to implement their own data
distribution mechanisms--rather than wait for or depend on SSM/IGMPv3.

In the commercial H.323 world, Multipoint Control Units (MCUs) often handle
the data replication. (see http://www.h323forum.org/products/ ) Some of
them can leverage IP multicast when available, of course.

VRVS (another collaboration toolkit like Access Grid) uses application
unicast replication. See http://www.vrvs.org/Documentation/VAG/ for how
VRVS and AG interoperate, plus pointers to how VRVS works around broken
network-level IP multicast.

There's a window of opportunity for the IP Multicast community to build
protocols that can (1) work correctly on today's infrastructure but still
(2) work better when the infrastructure gets smarter.

Be careful what you ask for--you might not like it when you get it!

===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Kevin C. Almeroth]

Post by Toerless Eckert

Post by Leonard Giuliano
-) All right. So, which IPv6 applications and host stacks do you know ?
-) If you were trying to make an exhaustive list, then ist would show
-) that the situation of SSM support is not much different than in IPv4.

Didn't get an answer on that one...

What's your point?

Post by Toerless Eckert

Post by Leonard Giuliano
Perhaps "mistake" is a bit too revisionist. Replace it with "lessons".
Anyway, the lesson I am refering to is making the network responsible for
source discovery.

Yes, that's a nice gospel, but it's mixing cause and effect to make
a more easy story for the lay person. If we had a simple way to do
source discovery in the network, then it wouldn't be bad right ? We
declared it bad in IPv4 because we couldn't determine a way to make
it simple enough so that the overal solution complexity could well
measure up against the lesser complexity of let's say a web based
application with SSM.

Toerless, you've worked too long for a router vendor. Putting source
discovery in the network was the worst mistake that could have
happened to multicast. It isn't even a "lesson learned" (after all,
people are still advocating putting ASM in v6). Why?

Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)

This chased away more network admins, users, application writers,
than I think most of us are willing to admit.

Throw in the scalability arguments and the DoS arguments and
MSDP was a mistake.

To perpetuate that same mistake in IPv6 would be, uh... pick
something suitably evil.

Trying to argue that MSDP was the only viable option at the
time is a weak argument. Further weakened by the fact that
the "right way" has never been developed.

Post by Toerless Eckert
Ah, so that's why we have PIM-SM with MSDP deployed all over the world ?
Remind me: What was the horrible complex alternative to this simple
solution ?

Uh, Dave, are you still listening? Can I do a presentation at
MBONED in Vienna on the current state of multicast routing?
It was something Prashant wanted to do in SF, but there wasn't
time on the agenda.

The right solution was to figure out we were driving at a high
rate of speed into a brick wall. The solution: turn. Hindsight
is 20/20 but why wasn't SSM an option instead of MSDP?

-Kevin

[Pekka Savola]

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)
This chased away more network admins, users, application writers,
than I think most of us are willing to admit.
Throw in the scalability arguments and the DoS arguments and
MSDP was a mistake.
To perpetuate that same mistake in IPv6 would be, uh... pick
something suitably evil.
Trying to argue that MSDP was the only viable option at the
time is a weak argument. Further weakened by the fact that
the "right way" has never been developed.

Please re-read what you wrote. Everything you say could be ended up with
", but embedded RP ASM does this better" :-)

What it's actually doing is eliminating the worst "evilness" of MSDP and
network-based source discovery: the sharing of state. Who cares if only
one RP (the one in charge of the group) has to handle it? I think that
would be a *vast* improvement.

And remember, SSM would still be better than embedded-RP ASM; once SSM
works fine and apps support it properly, embedded-RP could be a nice way
to make the architecture much nicer.

[s***@shepfarm.com]

Post by Pekka Savola

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)
This chased away more network admins, users, application writers,
than I think most of us are willing to admit.
Throw in the scalability arguments and the DoS arguments and
MSDP was a mistake.
To perpetuate that same mistake in IPv6 would be, uh... pick
something suitably evil.
Trying to argue that MSDP was the only viable option at the
time is a weak argument. Further weakened by the fact that
the "right way" has never been developed.

Please re-read what you wrote. Everything you say could be ended up with
", but embedded RP ASM does this better" :-)
What it's actually doing is eliminating the worst "evilness" of MSDP and
network-based source discovery: the sharing of state. Who cares if only
one RP (the one in charge of the group) has to handle it? I think that
would be a *vast* improvement.

but only a partial improvement. MSDP is only a part of the evils of
network-based source discovery. Why are we trying to only simplify an
unwanted mechanism? Let's just get rid of it.

Post by Pekka Savola
And remember, SSM would still be better than embedded-RP ASM; once SSM
works fine and apps support it properly, embedded-RP could be a nice way
to make the architecture much nicer.

..and since you aknowledged in your previous post that the current IPv6
mcast deployments are small and should be simple to upgrade, then why
bother with this ASM step at all? Go straight to interdomain SSM in V6

Greg

[Pekka Savola]

[...]

Post by s***@shepfarm.com

Post by Pekka Savola
What it's actually doing is eliminating the worst "evilness" of MSDP and
network-based source discovery: the sharing of state. Who cares if only
one RP (the one in charge of the group) has to handle it? I think that
would be a *vast* improvement.

but only a partial improvement. MSDP is only a part of the evils of
network-based source discovery. Why are we trying to only simplify an
unwanted mechanism? Let's just get rid of it.

In a perfect world, it might be best to kill it. But we don't live in a
perfect world. In that light, it would seem to me that the best tradeoffs
could be gained from embedded RP (a short-mid range tool) and from SSM
(mid-long range term).

I really don't think we could jump straight to SSM *in every scenario*
(for some, it's certainly possible, and more power to those!). From
routers' perspective, it's a trivial thing, but there's the whole picture
to consider.

Post by s***@shepfarm.com

Post by Pekka Savola
And remember, SSM would still be better than embedded-RP ASM; once SSM
works fine and apps support it properly, embedded-RP could be a nice way
to make the architecture much nicer.

..and since you aknowledged in your previous post that the current IPv6
mcast deployments are small and should be simple to upgrade, then why
bother with this ASM step at all? Go straight to interdomain SSM in V6

It boils down on what you have to upgrade.

Router software? Easy.

Host OS? Maybe more difficult (more OS's out there, upgrades are
more difficult, more users, different administrative domains)

Host applications? Porting a multicast app from IPv4 to IPv6 is rather
easy. But also change it to use SSM at the same time, especially if it
actually *is* a multi-party app (like vic)? Not feasible in the short
term.

Switch firmwares? Some are non-upgradeable and implement some
bastardization of multicast snooping. A long lifespan, making the
introduction of IGMPv3 and MLDv2 a bit more difficult.

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by s***@shepfarm.com
but only a partial improvement. MSDP is only a part of the evils of
network-based source discovery. Why are we trying to only simplify an
unwanted mechanism? Let's just get rid of it.

PIM Bi-Dir with embedded RP addressing (in the IPv6 context) doesn't
require network-based source discovery, or explicit state for each
source. Are there other "evils" that I'm missing?


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Toerless Eckert]

Post by Bill Nickless

Post by s***@shepfarm.com
but only a partial improvement. MSDP is only a part of the evils of
network-based source discovery. Why are we trying to only simplify an
unwanted mechanism? Let's just get rid of it.

PIM Bi-Dir with embedded RP addressing (in the IPv6 context) doesn't
require network-based source discovery, or explicit state for each
source. Are there other "evils" that I'm missing?

First of all (*mumble* *mumble* ;-P ):
Unless i get some support that we need to encode things like protocol
mode and other details somewhere in the 128 bit embedRP group addresses
(aka: There is enough space, it's just politics) - we will never be
able to do anything but just exactly one fixed protocol (PIM-SM) with
embedRP.

Bidir-PIM today can not be used with embedRP because it requires
protocol operation (DF-election) before a single PIM/IGMP message
or data packet for a group is received. And it's a per-RP protocol
operations, so you don't want to do this for 2^64 different RPs.

Fixing this isn't difficult, but we have to break the religious belief
of the Bidir-PIM protocol believers in the first place:

The religion states that the mayor benefit of Bidir-PIM is that it's
totally free of data-triggered events, so it is the nicest multicast
protocol a router will ever see. This is achieved by having done the DF
election first, so when you receive a packet for a yet unknown group and
you're the elected DF for the RP of the group, then you will have G/M
(group/mask) forwarding state already established to send the traffic
towards the RP. If we wanted to support embedRP, we would need to
change this. Effectively, upstream traffic on a branch of the tree
without receivers would need to be a data-triggered event resulting
in some form of extended DF-election (probably not based on actual
RP-address but on the RIB prefix covering the RP to allow for more
scalability). The problem with this is of course the need to buffer
these first packets until the DF election has finnished and sending them
out thereafter without misordering.

So, unless we can establish the workaround "closed group" (source
must be receiver first to avoid this problem), we will have a
very similar behavior to MSDP on the first packets of a flow.

That, or we go even further and demand in-advance extended DF
calculation of all prefixes in the RIB, but that sounds like a killer
thing for a core-router, so it's likely impractical.

Unless there are better ideas on how to solve this (and i wouldn't
conclude that there are none), you're probably better off in the
interdomain embedRP case with a PIM-SM that is forced to have no (S,G)
state and where the sources continuously send traffic to the RP via
the register tunnel. (Lenny: wouldn't this be an argument for you to
vote for embedRP ? *grin* ;-)

Cheers
Toerless

[Dino Farinacci]

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)

I just want to ask eweryone one question. And let's be real honest with
ourselves.

Do you think multicast would be farther along without MSDP?

Dino

[Toerless Eckert]

Post by Dino Farinacci
I just want to ask eweryone one question. And let's be real honest with
ourselves.
Do you think multicast would be farther along without MSDP?

You mean if we would have thought of SSM in 1994 and defined & implemented it
with a simpler version of IGMP for SSM than *yuck* IGMPv3 ? I think it likely
would have been better because at that time there was still sufficient work
on the application and research side that would supported the end-to-end
aspects of it.

Unfortunately that type of development would never have happened in 1994
unless we had time travel to show all the dead bodies that PIM-SM with
MSDP has left on the battle field, because architecture wise everybody
was so persuaded that the ASM model is the best thing since the wheel.

Don't tell me time travel will never be possible, i still want to go
back and fix things ! ;-))

Cheers
Toerless

[Dino Farinacci]

Post by Toerless Eckert
You mean if we would have thought of SSM in 1994 and defined & implemented it
with a simpler version of IGMP for SSM than *yuck* IGMPv3 ? I think it likely
would have been better because at that time there was still sufficient work
on the application and research side that would supported the end-to-end
aspects of it.

But we didn't. There were strong requirements then to support the Deering
model so we designed within those constraints.

Dino

[Toerless Eckert]

Post by Dino Farinacci
But we didn't. There were strong requirements then to support the Deering
model so we designed within those constraints.

requirements ? There was a lot of good ideas about architectures
and little understanding of market processes.

[Dino Farinacci]

Post by Toerless Eckert
requirements ? There was a lot of good ideas about architectures
and little understanding of market processes.

Well, there was no market for multicast. It all started out of research.

Dino

[Toerless Eckert]

Post by Dino Farinacci

Post by Toerless Eckert
requirements ? There was a lot of good ideas about architectures
and little understanding of market processes.

Well, there was no market for multicast. It all started out of research.

Well, i was referring to the recognition that in a network moving torwards
commercial justifications, architectures that require consistent end-to-end
deployment live and fall withe the added complexity.

Cheers
Toerless

[Dino Farinacci]

Post by Toerless Eckert
Well, i was referring to the recognition that in a network moving torwards
commercial justifications, architectures that require consistent end-to-end
deployment live and fall withe the added complexity.

We didn't know that then. At that time, people were dealing with new link
state protocols.

Dino

[Jared Mauch]

Post by Dino Farinacci

Post by Toerless Eckert
requirements ? There was a lot of good ideas about architectures
and little understanding of market processes.

Well, there was no market for multicast. It all started out of research.

I've had customers approach us while they're in the process of
purchasing their connections and ask us about our multicast support, sla,
and how they can reach the internet with their streaming media services.

problem is i usually rain on their parade/business plan when i
explain that yes, part of the internet is multicast enabled but a large
set of it is not. This makes them change their model slightly as they
realize that they're going to need to unicast stream all that data
instead of sending it via multicast. that's where the people at akamai
(and other similar companies) come in and offer local streaming to
people who colo their boxes for a lower cost.

I know that broadcast.com (now part of y!) was trying to get the
edge providers to multicast enable their dial, dsl, etc.. ports but
with limited success.

SSM/IGMPv3 is really the way things need to go, but there are
a number of reasons why the growth of this will be stunted for
some time. 1) microsoft licensing keeping people from getting ssm/igmpv3
stacks as they don't want to be locked into forced upgrade cycle. 2)
lack of consumer space multicast enabled/capable devices (including
ssm, igmpv3, etc..) for wireless, 4 port firewall + nat + cablemodem
type units.. 3) edge providers fearing instablity due to enabling
new features, 4) lack of market because of #1-3

It's quite a challenge. all us operators can do is continue
to make sure the ssm/asm multicast models continue to work for our
nasa-tv and places all over the world things and wait for the numerous
upgrade cycles to happen. we can do ssm/igmpv3, it's just the edge
is missing that functionality and will be for some time until there is
the next killer-application. perhaps it'll take the riaa offering
multicast streaming radio stations for $12/yr or something like that
for people to consider not just firing up their p2p and downloading
the media to adopt multicast..

- jared

[Toerless Eckert]

Post by Jared Mauch
I know that broadcast.com (now part of y!) was trying to get the
edge providers to multicast enable their dial, dsl, etc.. ports but
with limited success.

Well, IP multicast is actually used by some of the media distribution
services available today, but unfortunately - and due to the lack of
IP multicast to the home - not end-to-end but just in between actual
unicast distribution hubs.

As Lenni said - go and complain with your edge-ISP *sigh*.

Post by Jared Mauch
SSM/IGMPv3 is really the way things need to go, but there are
a number of reasons why the growth of this will be stunted for
some time.

Well, short term, the effect is rather that SSM gives people another
excuse why not to do multicast (aka: i've ignored doing multicast
for so long, now i have to wait another few years until some other

Post by Jared Mauch
1) microsoft licensing keeping people from getting ssm/igmpv3
stacks as they don't want to be locked into forced upgrade cycle.

Without being specific to microsoft:
You can't blame a vendor for not putting the newest features into
the oldest products. If at all, you can blame customers who are not
forcing the vendor to change it's strategy. But that all depends on how
much pressure customers can exercise on a vendor. In a competitive situation
this is of course much easier.

Post by Jared Mauch
2) lack of consumer space multicast enabled/capable devices (including
ssm, igmpv3, etc..) for wireless, 4 port firewall + nat + cablemodem
type units.. 3) edge providers fearing instablity due to enabling
new features, 4) lack of market because of #1-3

I thought i summed it up with: "Lack of customer RFPs with SSM as one
of the top items on the list". If you had those, and if they would have
an influence on actual product selection, all of the above would happen
by itself.

Post by Jared Mauch
It's quite a challenge. all us operators can do is continue
to make sure the ssm/asm multicast models continue to work for our
nasa-tv and places all over the world things and wait for the numerous
upgrade cycles to happen.

Not true. If you have any influence on people who know people who write
RFPs, then talk to them ;-))

Post by Jared Mauch
we can do ssm/igmpv3, it's just the edge
is missing that functionality and will be for some time until there is
the next killer-application.

The killer app in the web was effectively the opennness of the web,
allowing small startups to easily offer services. Not the big players,
whose solutions typically tend to have completely different primary
requirements.

Post by Jared Mauch
perhaps it'll take the riaa offering
multicast streaming radio stations for $12/yr or something like that
for people to consider not just firing up their p2p and downloading
the media to adopt multicast..

Check out http://www.joltid.com/index.php/peerenabler/
they're certainly on the way of trying to be the next wave of
commercial content distribution for smaller startups.

Cheers
Toerless

[Jared Mauch]

Post by Toerless Eckert
As Lenni said - go and complain with your edge-ISP *sigh*.

Yeah, the problem is they're feeling the same crunch others
are and quite a number are still mom-and-pop operations so have trouble
obtaining people with clue sufficent to configure multicast, or when
they do, they are shot down as it's not something that customers have
asked for.

Post by Toerless Eckert

Post by Jared Mauch
SSM/IGMPv3 is really the way things need to go, but there are
a number of reasons why the growth of this will be stunted for
some time.

Well, short term, the effect is rather that SSM gives people another
excuse why not to do multicast (aka: i've ignored doing multicast
for so long, now i have to wait another few years until some other

This is true. I think that we'll see native IPv6 with most
providers sooner than we'll see them being SSM/ASM enabled.

Post by Toerless Eckert

Post by Jared Mauch
1) microsoft licensing keeping people from getting ssm/igmpv3
stacks as they don't want to be locked into forced upgrade cycle.

You can't blame a vendor for not putting the newest features into
the oldest products. If at all, you can blame customers who are not
forcing the vendor to change it's strategy. But that all depends on how
much pressure customers can exercise on a vendor. In a competitive situation
this is of course much easier.

For once the intention wasn't to point out the Pure Evil(tm) of
microsoft. What i'm trying to say is that people are not upgrading their
software at the same rate as in the past. While microsoft will continue
to see their new product shipments in the consumer space through
dell, gateway, and others, there are a significant number of people
that will not be upgrading to anything that can support SSM/ASM in the
near future until there is some new technological breakthrough that
forces them to.

Due to their hardware profiling and the way I manage my hardware
if I were to upgrade to any of their recent software I would not have any
luck keeping my system working with my existing software license system.
I'm just using myself as a reference point, and I know full well i'm not
the norm, but the people who spend lots of cash on computer upgrades
(or have historically) have been very put off by this change that will
make their system stop to work if they keep the same hard drive yet
upgrade processor, etc..

I see people slowly getting the featureset over the next 5 years
but just not anywhere near the rate it was from 1994-2000.

Post by Toerless Eckert

Post by Jared Mauch
2) lack of consumer space multicast enabled/capable devices (including
ssm, igmpv3, etc..) for wireless, 4 port firewall + nat + cablemodem
type units.. 3) edge providers fearing instablity due to enabling
new features, 4) lack of market because of #1-3

I thought i summed it up with: "Lack of customer RFPs with SSM as one
of the top items on the list". If you had those, and if they would have
an influence on actual product selection, all of the above would happen
by itself.

Yeah, we need some hosting giant to come out and do this.
Real Networks/Broadcast.com(y!) or even Microsoft could to this.

Post by Toerless Eckert

Post by Jared Mauch
It's quite a challenge. all us operators can do is continue
to make sure the ssm/asm multicast models continue to work for our
nasa-tv and places all over the world things and wait for the numerous
upgrade cycles to happen.

Not true. If you have any influence on people who know people who write
RFPs, then talk to them ;-))

Post by Jared Mauch
we can do ssm/igmpv3, it's just the edge
is missing that functionality and will be for some time until there is
the next killer-application.

The killer app in the web was effectively the opennness of the web,
allowing small startups to easily offer services. Not the big players,
whose solutions typically tend to have completely different primary
requirements.

Post by Jared Mauch
perhaps it'll take the riaa offering
multicast streaming radio stations for $12/yr or something like that
for people to consider not just firing up their p2p and downloading
the media to adopt multicast..

Check out http://www.joltid.com/index.php/peerenabler/
they're certainly on the way of trying to be the next wave of
commercial content distribution for smaller startups.

This stuff just reminds me of squid caches, but more of an
autodiscovery of adjacent caches and perhaps even archie type searches
with the p2p (http with ranges) for download instead of ftp.

Just a slightly different approach to what we've seen in
the past.

- Jared

[Toerless Eckert]

Post by Jared Mauch
Yeah, the problem is they're feeling the same crunch others
are and quite a number are still mom-and-pop operations so have trouble
obtaining people with clue sufficent to configure multicast, or when
they do, they are shot down as it's not something that customers have
asked for.

Right, make SSM enabled by default whereever IP is enabled.
So then we could have the nicely running router for mom&pops network even
without their knowledge (and any enterprise network for that matter).
Problem only is that the mayority of customers don't want this either
because of FUD.

Post by Jared Mauch
For once the intention wasn't to point out the Pure Evil(tm) of
microsoft. What i'm trying to say is that people are not upgrading their
software at the same rate as in the past. While microsoft will continue
to see their new product shipments in the consumer space through
dell, gateway, and others, there are a significant number of people
that will not be upgrading to anything that can support SSM/ASM in the
near future until there is some new technological breakthrough that
forces them to.

I would argue that the update rate is subject to the perceived maturity
of the solutions offered. Certainly IGMPv3 and IPv6 are explicitly NOT
put into older microsoft versions because Microsoft hopes to leverage
these new technologies to have people upgrade (and make Microsoft money
in the process).

As far as "pure evil" is concerned - i don't think you could attach this
attribute to Microsoft with repect to IP multicast. Show me a single other
host vendor or OS that has done as much in support as IP Multicast as Microsoft
in the past 3..4 years. There is none. Microsoft leads the pack. Just look
at MacOS / Quicktime or Linux!

Post by Jared Mauch
Due to their hardware profiling and the way I manage my hardware
if I were to upgrade to any of their recent software I would not have any
luck keeping my system working with my existing software license system.
I'm just using myself as a reference point, and I know full well i'm not
the norm, but the people who spend lots of cash on computer upgrades
(or have historically) have been very put off by this change that will
make their system stop to work if they keep the same hard drive yet
upgrade processor, etc..

No use in blaming a tiger for being a tiger. Rather check out
whom the zoo director is reporting to.

Post by Jared Mauch
I see people slowly getting the featureset over the next 5 years
but just not anywhere near the rate it was from 1994-2000.

On the other hand, there are other host devices like mobile phones or
PDAs which will pick up newer technologies much faster, so it's maybe
just a question which market to target first.

Post by Jared Mauch

Post by Toerless Eckert
I thought i summed it up with: "Lack of customer RFPs with SSM as one
of the top items on the list". If you had those, and if they would have
an influence on actual product selection, all of the above would happen
by itself.

Yeah, we need some hosting giant to come out and do this.
Real Networks/Broadcast.com(y!) or even Microsoft could to this.

I don't think the ball is on the side of the content or middleware
producers. Except of course for supporting SSM, but not for driving
ASM/SSM deployment.

Post by Jared Mauch
This stuff just reminds me of squid caches, but more of an
autodiscovery of adjacent caches and perhaps even archie type searches
with the p2p (http with ranges) for download instead of ftp.
Just a slightly different approach to what we've seen in
the past.

Well, the mayor change would be if it allows for small startups to
put up their content and have it reliably distributed (with payment)
to a large receiver basis - without the need for paying through your
nose for hosting a server host for downloads of the content.

Cheers
Toerless

[Marshall Eubanks]

Some thoughts;

1.) IP Multicast, complete with PIM and IGMPv2, is used by satellite
media distribution and is built into UDLR. Just
as DVMRP is still the basis for multicast financial distribution, these
applications will be legacy for a long time to come.

2.) My feeling is that the most interest in multicast as a business is
in "cable" video distribution as it moves to IP. These
applications _could_ be SSM, but are likely to be IGMPv2/ASM.
Incidentally, the "cable" operators I have talked to see
the Internet (as opposed to IP equipment) as a threat and are not
interested (yet) in getting any video over the Internet -
and, typically, do not have the bandwidth to support this. Of course,
with no interdomain

3.) I think that it is reasonable, as technology matures, for the speed
of upgrades and new technology to slow down.
Given that the most used OS according to our web logs is now Windows NT
5.0 (recently overtaking Windows 98).
it will be years before anything requiring host changes to get adopted.

4.) I think that everyone agrees that in network _source discovery_ is
BAD. I think that the real argument here is
about doing in network or session layer _RP discovery_, and I am not
convinced that embedding this in group addresses
is the way to go. Of course, if all ASM does is RP discovery it is much
easier to protect it against the DOS attacks that will
eventually kill it if nothing is done.

Oh, and BTW, at present I do not believe that you could _give away_
multicast only radio stations. Believe me, we tried.

Regards
Marshall

Post by Toerless Eckert

Post by Jared Mauch
I know that broadcast.com (now part of y!) was trying to get the
edge providers to multicast enable their dial, dsl, etc.. ports but
with limited success.

Well, IP multicast is actually used by some of the media distribution
services available today, but unfortunately - and due to the lack of
IP multicast to the home - not end-to-end but just in between actual
unicast distribution hubs.
As Lenni said - go and complain with your edge-ISP *sigh*.

Post by Jared Mauch
SSM/IGMPv3 is really the way things need to go, but there are
a number of reasons why the growth of this will be stunted for
some time.

Well, short term, the effect is rather that SSM gives people another
excuse why not to do multicast (aka: i've ignored doing multicast
for so long, now i have to wait another few years until some other

Post by Jared Mauch
1) microsoft licensing keeping people from getting ssm/igmpv3
stacks as they don't want to be locked into forced upgrade cycle.

You can't blame a vendor for not putting the newest features into
the oldest products. If at all, you can blame customers who are not
forcing the vendor to change it's strategy. But that all depends on how
much pressure customers can exercise on a vendor. In a competitive situation
this is of course much easier.

Post by Jared Mauch
2) lack of consumer space multicast enabled/capable devices (including
ssm, igmpv3, etc..) for wireless, 4 port firewall + nat + cablemodem
type units.. 3) edge providers fearing instablity due to enabling
new features, 4) lack of market because of #1-3

I thought i summed it up with: "Lack of customer RFPs with SSM as one
of the top items on the list". If you had those, and if they would have
an influence on actual product selection, all of the above would happen
by itself.

Post by Jared Mauch
It's quite a challenge. all us operators can do is continue
to make sure the ssm/asm multicast models continue to work for our
nasa-tv and places all over the world things and wait for the numerous
upgrade cycles to happen.

Not true. If you have any influence on people who know people who write
RFPs, then talk to them ;-))

Post by Jared Mauch
we can do ssm/igmpv3, it's just the edge
is missing that functionality and will be for some time until there is
the next killer-application.

The killer app in the web was effectively the opennness of the web,
allowing small startups to easily offer services. Not the big players,
whose solutions typically tend to have completely different primary
requirements.

Post by Jared Mauch
perhaps it'll take the riaa offering
multicast streaming radio stations for $12/yr or something like that
for people to consider not just firing up their p2p and downloading
the media to adopt multicast..

Check out http://www.joltid.com/index.php/peerenabler/
they're certainly on the way of trying to be the next wave of
commercial content distribution for smaller startups.
Cheers
Toerless

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Leonard Giuliano]

Marshall- are these thoughts pertinent to IPv6, or just IPv4. I think we
may all be in agreement that we are stuck with ASM for IPv4. The question
is what about IPv6.

-Lenny

On Mon, 16 Jun 2003, Marshall Eubanks wrote:

-) Some thoughts;
-)
-) 1.) IP Multicast, complete with PIM and IGMPv2, is used by satellite
-) media distribution and is built into UDLR. Just
-) as DVMRP is still the basis for multicast financial distribution, these
-) applications will be legacy for a long time to come.
-)
-) 2.) My feeling is that the most interest in multicast as a business is
-) in "cable" video distribution as it moves to IP. These
-) applications _could_ be SSM, but are likely to be IGMPv2/ASM.
-) Incidentally, the "cable" operators I have talked to see
-) the Internet (as opposed to IP equipment) as a threat and are not
-) interested (yet) in getting any video over the Internet -
-) and, typically, do not have the bandwidth to support this. Of course,
-) with no interdomain
-)
-) 3.) I think that it is reasonable, as technology matures, for the speed
-) of upgrades and new technology to slow down.
-) Given that the most used OS according to our web logs is now Windows NT
-) 5.0 (recently overtaking Windows 98).
-) it will be years before anything requiring host changes to get adopted.
-)
-) 4.) I think that everyone agrees that in network _source discovery_ is
-) BAD. I think that the real argument here is
-) about doing in network or session layer _RP discovery_, and I am not
-) convinced that embedding this in group addresses
-) is the way to go. Of course, if all ASM does is RP discovery it is much
-) easier to protect it against the DOS attacks that will
-) eventually kill it if nothing is done.
-)
-) Oh, and BTW, at present I do not believe that you could _give away_
-) multicast only radio stations. Believe me, we tried.
-)
-) Regards
-) Marshall
-)
-)
-)
-) On Monday, June 16, 2003, at 03:51 PM, Toerless Eckert wrote:
-)
-) > On Mon, Jun 16, 2003 at 03:30:53PM -0400, Jared Mauch wrote:
-) >> I know that broadcast.com (now part of y!) was trying to get the
-) >> edge providers to multicast enable their dial, dsl, etc.. ports but
-) >> with limited success.
-) >
-) > Well, IP multicast is actually used by some of the media distribution
-) > services available today, but unfortunately - and due to the lack of
-) > IP multicast to the home - not end-to-end but just in between actual
-) > unicast distribution hubs.
-) >
-) > As Lenni said - go and complain with your edge-ISP *sigh*.
-) >
-) >> SSM/IGMPv3 is really the way things need to go, but there are
-) >> a number of reasons why the growth of this will be stunted for
-) >> some time.
-) >
-) > Well, short term, the effect is rather that SSM gives people another
-) > excuse why not to do multicast (aka: i've ignored doing multicast
-) > for so long, now i have to wait another few years until some other
-) > chicken&egg salad get's solved):
-) >
-) >> 1) microsoft licensing keeping people from getting ssm/igmpv3
-) >> stacks as they don't want to be locked into forced upgrade cycle.
-) >
-) > Without being specific to microsoft:
-) > You can't blame a vendor for not putting the newest features into
-) > the oldest products. If at all, you can blame customers who are not
-) > forcing the vendor to change it's strategy. But that all depends on how
-) > much pressure customers can exercise on a vendor. In a competitive
-) > situation
-) > this is of course much easier.
-) >
-) >> 2) lack of consumer space multicast enabled/capable devices (including
-) >> ssm, igmpv3, etc..) for wireless, 4 port firewall + nat + cablemodem
-) >> type units.. 3) edge providers fearing instablity due to enabling
-) >> new features, 4) lack of market because of #1-3
-) >
-) > I thought i summed it up with: "Lack of customer RFPs with SSM as one
-) > of the top items on the list". If you had those, and if they would have
-) > an influence on actual product selection, all of the above would happen
-) > by itself.
-) >
-) >> It's quite a challenge. all us operators can do is continue
-) >> to make sure the ssm/asm multicast models continue to work for our
-) >> nasa-tv and places all over the world things and wait for the numerous
-) >> upgrade cycles to happen.
-) >
-) > Not true. If you have any influence on people who know people who write
-) > RFPs, then talk to them ;-))
-) >
-) >> we can do ssm/igmpv3, it's just the edge
-) >> is missing that functionality and will be for some time until there is
-) >> the next killer-application.
-) >
-) > The killer app in the web was effectively the opennness of the web,
-) > allowing small startups to easily offer services. Not the big players,
-) > whose solutions typically tend to have completely different primary
-) > requirements.
-) >
-) >> perhaps it'll take the riaa offering
-) >> multicast streaming radio stations for $12/yr or something like that
-) >> for people to consider not just firing up their p2p and downloading
-) >> the media to adopt multicast..
-) >
-) > Check out http://www.joltid.com/index.php/peerenabler/
-) > they're certainly on the way of trying to be the next wave of
-) > commercial content distribution for smaller startups.
-) >
-) > Cheers
-) > Toerless
-) >
-)
-) T.M. Eubanks
-) e-mail : ***@multicasttech.com
-) http://www.multicasttech.com
-)
-) Test your network for multicast :
-) http://www.multicasttech.com/mt/
-)
-) Our New Video Service is in Beta testing
-) http://www.americafree.tv
-)

[Toerless Eckert]

4.) I think that everyone agrees that in network _source discovery_ is BAD.

As said in before: This was and is my tune in IPv4, but with IPv6 i think
that this is making too broad a statement: It is bad when it is more complex
than an alternative solution. Once it is similarily or even less complex than
this alternative .... tell me again: why should it still be called bad under
those circumstances ? - then we're really getting into more interesting
details, like: Should network operations have control over end-to-end
applications, and if so to what level ? As the TCP bigot you'd say of course
NO, but then again, we wouldn't have access-lists, firewall, or any other
protective measures in the network, right ? If we had the right
people in that discussion, then that would be a wonderful flame war.

Oh, and BTW, at present I do not believe that you could _give away_
multicast only radio stations. Believe me, we tried.

No disagreement, but: what does that prove that we didn't know in before ?
Want to have another round of this excellent chicken&egg salad ? We've
been feeding on it since 6 year now.

(And thanks a lot for the effort anyhow. I still think that even if it
is without short term success, it still keeps awareness of potential
benefits alive and will turn tables at some point in time. We've seen
enough customers in the last three years moving to multicast. Most of
this has little outside visibility because even though it is often
worldwide deployment, it is always single administration).

Cheers
Toerless

[Marshall Eubanks]

Hi Toerless;

Post by Toerless Eckert

4.) I think that everyone agrees that in network _source discovery_ is BAD.

As said in before: This was and is my tune in IPv4, but with IPv6 i think
that this is making too broad a statement: It is bad when it is more complex
than an alternative solution. Once it is similarily or even less complex than
this alternative .... tell me again: why should it still be called bad under
those circumstances ? - then we're really getting into more interesting
details, like: Should network operations have control over end-to-end
applications, and if so to what level ? As the TCP bigot you'd say of course
NO, but then again, we wouldn't have access-lists, firewall, or any other
protective measures in the network, right ? If we had the right
people in that discussion, then that would be a wonderful flame war.

I said that Source discovery is bad, not RP discovery. If you are going
to have source discovery in the network, then there
has to be authentication / authorization of some sort to keep the dogs
of DOS at bay.
Suppose that my RP always knew how to find "the" RP
for a group - this could be made much harder than MSDP (as RP's are not
end host boxes) against DOS, etc., etc.

Now, I think that the shortest path to this might
be to (put on your peril sensitive sunglasses!) modify MSDP.
MSDP actually does serve as means for RP discovery, and restricting it
to RP discovery only would remove the SA DOS amplification that will
eventually kill interdomain SSM if it is not fixed (I might be
be able to take down MY RP by bomdarding it with new sources, but this
info would not be flooded out.)

Also, in this paradigm, the only software/hardware that has to be
changed is at the RP's, and there are only a few thousand of those at
present - and, if you did it right, it might be able to make it
interoperate with the legacy system, even at the MSDP level,
and it would interoperate from birth at the application level.

Just an idea.

(BTW, I am a UDP bigot. I also happen to believe that IPv6 really
changes very little except the size of the address space; it is
IMHO an error to assume that anything that can be fixed in v6 cannot be
fixed in v4.)

Post by Toerless Eckert

Oh, and BTW, at present I do not believe that you could _give away_
multicast only radio stations. Believe me, we tried.

No disagreement, but: what does that prove that we didn't know in before ?
Want to have another round of this excellent chicken&egg salad ? We've
been feeding on it since 6 year now.
(And thanks a lot for the effort anyhow. I still think that even if it
is without short term success, it still keeps awareness of potential
benefits alive and will turn tables at some point in time. We've seen
enough customers in the last three years moving to multicast. Most of
this has little outside visibility because even though it is often
worldwide deployment, it is always single administration).

That's cool. How do I get a check ?

Post by Toerless Eckert
Cheers
Toerless

Regards
Marshall

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Toerless Eckert]

Post by Marshall Eubanks
I said that Source discovery is bad, not RP discovery. If you are going
to have source discovery in the network, then there
has to be authentication / authorization of some sort to keep the dogs
of DOS at bay.

Which of course is much simpler if you just have a single RP because
then you can have the "owner" of a group ascert policies on the RP.

Post by Marshall Eubanks
Suppose that my RP always knew how to find "the" RP
for a group - this could be made much harder than MSDP (as RP's are not
end host boxes) against DOS, etc., etc.
Now, I think that the shortest path to this might
be to (put on your peril sensitive sunglasses!) modify MSDP.

There's a gag reflex associated with that word though ;-)

Post by Marshall Eubanks
MSDP actually does serve as means for RP discovery, and restricting it
to RP discovery only would remove the SA DOS amplification that will
eventually kill interdomain SSM if it is not fixed (I might be
be able to take down MY RP by bomdarding it with new sources, but this
info would not be flooded out.)

I'm not clear i'm following (understand) what you say. In embedRP
i also only have one RP for a group, so if that's attacked, it would
also not propagate, right ?

What's the attack that will kill interdomain SSM ?

Post by Marshall Eubanks
Also, in this paradigm, the only software/hardware that has to be
changed is at the RP's, and there are only a few thousand of those at
present - and, if you did it right, it might be able to make it
interoperate with the legacy system, even at the MSDP level,
and it would interoperate from birth at the application level.

IPv4 ? Now i'm totally confused. Maybe you could elaborate a bit more ?

Cheers
Toerless

[Beau Williamson]

Whoa! I don't pick up email for a day and look at the debate that ensues. :)

Post by Toerless Eckert

Post by Marshall Eubanks
Now, I think that the shortest path to this might
be to (put on your peril sensitive sunglasses!) modify MSDP.

There's a gag reflex associated with that word though ;-)

I think this has to little to do with actual *recent* (heavy emphasis on
recent) real-world issues with MSDP (see some of the emails from Phrashant)
and more to do with all the pain we subjected ourselves to trying to
standardize MSDP and then finally giving up on the "process", not the
protocol. I for one still have an open mind to the possibility of some form
of MSDP in IPv6. (Ok, so I'm a heretic. What else is new. I just feel that
we've become so hysterical over MSDP in our search for the "perfect"
multicast solution that we may be throwing the baby out with the bath water.)

Post by Toerless Eckert
What's the attack that will kill interdomain SSM ?

Ah, thank you for asking.

SSM is (IMHO) just as evil as MSDP in terms of potential DoS attacks,
possibly even more so. MSDP SA's are originated only from RP's and are
constrained to the set of routers that have MSDP interconnections. This
means that you have *some* possibility of applying some limitations to the
amount of SA state that gets created in the Internet and hence the extent
and impact of a DoS Attack.

Now consider SSM. Every host in the network now has the ability to kill
every SSM multicast router in the Internet by sending IGMPv3 joins to every
possible (S,G) combination. This causes every multicast router in the
Internet to create so much bogus (S,G) state that it croaks. "On, but we
are going to eventually get around to building special code in the routers
to somehow limit the total amount of SSM (S,G) state that it can
instantiate in order to fix this." Ok, so now the DoS attack doesn't
completely take down the router, it only takes down legitimate SSM
multicast. Sorry, that's not much better IMHO.

Frankly, I think a lot of the hype for SSM is blown way out of proportion
when it comes to 1) application adoption, 2)L2 switch support, 3) immunity
to DoS attack, 4)applicability to all Multicast applications. Therefore, I
too believe that some *immediate* form of ASM support in IPv6 is a MUST.
I'm not sure what that needs to look like; embedRP, MSDPv6, Inter-domain
bidir or what.

Don't get me wrong, I want to see SSM move forward. However, in my own
personal crusade for the "perfect" multicast solution, I'm skeptical that
SSM is the "second-coming" of multicast.

Beau Williamson
PS: I agree with Marshall. Very interesting discussion.

[Marshall Eubanks]

Hello;

Post by Beau Williamson
Whoa! I don't pick up email for a day and look at the debate that ensues. :)

Post by Toerless Eckert

Post by Marshall Eubanks
Now, I think that the shortest path to this might
be to (put on your peril sensitive sunglasses!) modify MSDP.

There's a gag reflex associated with that word though ;-)

I think this has to little to do with actual *recent* (heavy emphasis
on recent) real-world issues with MSDP (see some of the emails from
Phrashant) and more to do with all the pain we subjected ourselves to
trying to standardize MSDP and then finally giving up on the
"process", not the protocol. I for one still have an open mind to the
possibility of some form of MSDP in IPv6. (Ok, so I'm a heretic. What
else is new. I just feel that we've become so hysterical over MSDP in
our search for the "perfect" multicast solution that we may be
throwing the baby out with the bath water.)

The thing I worry about MSDP really is the limited dynamic range in the
protocol. We have right now about 5000 SA's.
Experience has shown that things start to break at about the 100,000 SA
area. This is not a huge margin of safety for
a dynamic protocol.

I might point out that people have a lot of trouble implementing
multicast without MSDP. If the network is
complicated (NBMA, say) it can be tricky, and there is no good cookbook
for the uninitiated. Now, if we could just
create a software version of Beau, we would be a lot further along.

Post by Beau Williamson

Post by Toerless Eckert
What's the attack that will kill interdomain SSM ?

Ah, thank you for asking.
SSM is (IMHO) just as evil as MSDP in terms of potential DoS attacks,
possibly even more so. MSDP SA's are originated only from RP's and
are constrained to the set of routers that have MSDP interconnections.
This means that you have *some* possibility of applying some
limitations to the amount of SA state that gets created in the
Internet and hence the extent and impact of a DoS Attack.

The difference is, in ASM you have a chance to kill the multicast
_infrastructure_. In SSM you have the chance to
kill any multicast enabled _router_ for any purpose _including
unicast_. The damage is more localized but could be more
severe.

Post by Beau Williamson
Now consider SSM. Every host in the network now has the ability to
kill every SSM multicast router in the Internet by sending IGMPv3
joins to every possible (S,G) combination. This causes every multicast
router in the Internet to create so much bogus (S,G) state that it
croaks. "On, but we are going to eventually get around to building
special code in the routers to somehow limit

This seems too diffuse an attack to me. There are at present about 4 x
10^15 such (S,G) for SSM.
At its peak the Sapphire attacks were sending
10^8 (100 million) packets per second - it would have taken Sapphire
over 1 year to try and join all (S,G) - enough time to do something
about it. But, clearly, you could take out _selected_ routers, and
there might be ways to do the scanning to make the
wide area damage mount up faster.

Post by Beau Williamson
the total amount of SSM (S,G) state that it can instantiate in order
to fix this." Ok, so now the DoS attack doesn't completely take down
the router, it only takes down legitimate SSM multicast. Sorry,
that's not much better IMHO.
Frankly, I think a lot of the hype for SSM is blown way out of
proportion when it comes to 1) application adoption, 2)L2 switch
support, 3) immunity to DoS attack, 4)applicability to all Multicast
applications. Therefore, I too believe that some *immediate* form of
ASM support in IPv6 is a MUST. I'm not sure what that needs to look
like; embedRP, MSDPv6, Inter-domain bidir or what.

I frankly agree. I think that it will take until 2006 until SSM is
where ASM is now, and who knows when IPv6 will gain
serious traction (look at NANOG for the last few days for a lot of
speculation on this).

Post by Beau Williamson
Don't get me wrong, I want to see SSM move forward. However, in my own
personal crusade for the "perfect" multicast solution, I'm skeptical
that SSM is the "second-coming" of multicast.
Beau Williamson
PS: I agree with Marshall. Very interesting discussion.

Regards
Marshall Eubanks

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Marshall Eubanks]

Hello;

Post by Beau Williamson
Whoa! I don't pick up email for a day and look at the debate that ensues. :)

Post by Toerless Eckert

Post by Marshall Eubanks
Now, I think that the shortest path to this might
be to (put on your peril sensitive sunglasses!) modify MSDP.

There's a gag reflex associated with that word though ;-)

I think this has to little to do with actual *recent* (heavy emphasis
on recent) real-world issues with MSDP (see some of the emails from
Phrashant) and more to do with all the pain we subjected ourselves to
trying to standardize MSDP and then finally giving up on the
"process", not the protocol. I for one still have an open mind to the
possibility of some form of MSDP in IPv6. (Ok, so I'm a heretic. What
else is new. I just feel that we've become so hysterical over MSDP in
our search for the "perfect" multicast solution that we may be
throwing the baby out with the bath water.)

The thing I worry about MSDP really is the limited dynamic range in the
protocol. We have right now about 5000 SA's.
Experience has shown that things start to break at about the 100,000 SA
area. This is not a huge margin of safety for
a dynamic protocol.

I might point out that people have a lot of trouble implementing
multicast without MSDP. If the network is
complicated (NBMA, say) it can be tricky, and there is no good cookbook
for the uninitiated. Now, if we could just
create a software version of Beau, we would be a lot further along.

Post by Beau Williamson

Post by Toerless Eckert
What's the attack that will kill interdomain SSM ?

Ah, thank you for asking.
SSM is (IMHO) just as evil as MSDP in terms of potential DoS attacks,
possibly even more so. MSDP SA's are originated only from RP's and
are constrained to the set of routers that have MSDP interconnections.
This means that you have *some* possibility of applying some
limitations to the amount of SA state that gets created in the
Internet and hence the extent and impact of a DoS Attack.

The difference is, in ASM you have a chance to kill the multicast
_infrastructure_. In SSM you have the chance to
kill any multicast enabled _router_ for any purpose _including
unicast_. The damage is more localized but could be more
severe.

Post by Beau Williamson
Now consider SSM. Every host in the network now has the ability to
kill every SSM multicast router in the Internet by sending IGMPv3
joins to every possible (S,G) combination. This causes every multicast
router in the Internet to create so much bogus (S,G) state that it
croaks. "On, but we are going to eventually get around to building
special code in the routers to somehow limit

This seems too diffuse an attack to me. There are at present about 4 x
10^15 such (S,G) for SSM.
At its peak the Sapphire attacks were sending
10^8 (100 million) packets per second - it would have taken Sapphire
over 1 year to try and join all (S,G) - enough time to do something
about it. But, clearly, you could take out _selected_ routers, and
there might be ways to do the scanning to make the
wide area damage mount up faster.

Post by Beau Williamson
the total amount of SSM (S,G) state that it can instantiate in order
to fix this." Ok, so now the DoS attack doesn't completely take down
the router, it only takes down legitimate SSM multicast. Sorry,
that's not much better IMHO.
Frankly, I think a lot of the hype for SSM is blown way out of
proportion when it comes to 1) application adoption, 2)L2 switch
support, 3) immunity to DoS attack, 4)applicability to all Multicast
applications. Therefore, I too believe that some *immediate* form of
ASM support in IPv6 is a MUST. I'm not sure what that needs to look
like; embedRP, MSDPv6, Inter-domain bidir or what.

I frankly agree. I think that it will take until 2006 until SSM is
where ASM is now, and who knows when IPv6 will gain
serious traction (look at NANOG for the last few days for a lot of
speculation on this).

Post by Beau Williamson
Don't get me wrong, I want to see SSM move forward. However, in my own
personal crusade for the "perfect" multicast solution, I'm skeptical
that SSM is the "second-coming" of multicast.
Beau Williamson
PS: I agree with Marshall. Very interesting discussion.

Regards
Marshall Eubanks

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv


Regards
Marshall Eubanks

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Leonard Giuliano]

On Tue, 17 Jun 2003, Beau Williamson wrote:
-)
-) SSM is (IMHO) just as evil as MSDP in terms of potential DoS attacks,
-) possibly even more so. MSDP SA's are originated only from RP's and are
-) constrained to the set of routers that have MSDP interconnections. This
-) means that you have *some* possibility of applying some limitations to the
-) amount of SA state that gets created in the Internet and hence the extent
-) and impact of a DoS Attack.
-)
-) Now consider SSM. Every host in the network now has the ability to kill
-) every SSM multicast router in the Internet by sending IGMPv3 joins to every
-) possible (S,G) combination. This causes every multicast router in the
-) Internet to create so much bogus (S,G) state that it croaks. "On, but we

How is this any worse than sending IGMPv2 joins for every possible G? I
supposed they only go toward the RP, but they still consume memory on
every router along the way. Or I could create the same attack by running
pimd on a host and flooding a bunch of (S,G) pim joins. My point is that
all the vulnerabilities of SSM are present in ASM. The converse is not
true; ASM has far more vulnerabilities attributed to network based source
discovery.

The amazing thing we have seen so far is that all the attacks that have
hurt the mcast infrastructure have all been BY ACCIDENT. Ramen and
Slammer broke mcast without even trying to do so.

Mcast is inherantly insecure bc hosts create state in the network. But
ASM magnifies the vulnerabilities. At least with SSM, you have to know
what you are doing to launch an attack. If we can get rid of the attacks
created by people who aren't even trying, that would be a huge step.

[Jay Ford]

Post by Marshall Eubanks
Now, I think that the shortest path to this might
be to (put on your peril sensitive sunglasses!) modify MSDP.
MSDP actually does serve as means for RP discovery, and restricting it
to RP discovery only would remove the SA DOS amplification that will
eventually kill interdomain SSM if it is not fixed (I might be
be able to take down MY RP by bomdarding it with new sources, but this
info would not be flooded out.)
Also, in this paradigm, the only software/hardware that has to be
changed is at the RP's, and there are only a few thousand of those at
present - and, if you did it right, it might be able to make it
interoperate with the legacy system, even at the MSDP level,
and it would interoperate from birth at the application level.
Just an idea.

Another useful thing currently in MSDP is the mesh-group mode for state
sharing among RPs within a domain. Assuming that some form of ASM continues
to exist, I want the option of having multiple RPs within my domain, &
anycast with mesh-group MSDP for source state sharing is a fairly slick way
to do that. Are there are alternatives to mesh-group MSDP for intradomain RP
state sharing?

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-***@uiowa.edu, phone: [phone], fax: [phone]

[s***@shepfarm.com]

Post by Dino Farinacci

Post by Toerless Eckert
You mean if we would have thought of SSM in 1994 and defined & implemented it
with a simpler version of IGMP for SSM than *yuck* IGMPv3 ? I think it likely
would have been better because at that time there was still sufficient work
on the application and research side that would supported the end-to-end
aspects of it.

But we didn't. There were strong requirements then to support the Deering
model so we designed within those constraints.

..and so now we are asking to remove those constraints for v6 and move
right to what we now know to be more simple, reliable, secure, and what
fills the needs of current interdomain content owners - SSM

Greg

Post by Dino Farinacci
Dino

[Toerless Eckert]

Post by s***@shepfarm.com
..and so now we are asking to remove those constraints for v6 and move
right to what we now know to be more simple, reliable, secure, and what
fills the needs of current interdomain content owners - SSM

Greg: It's simply not true that ASM is not needed. There are sufficiently
many ideas that rely on network based ASM, at least intradomain. They
all leverage source discovery for some form of ressource discovery.
Why don't you stat out explaining how to do SRVLOC with SSM for example ?
(yes, of course it could be done, but unless it is done, we need ASM).

Cheers
Toerless

[Leonard Giuliano]

-) Greg: It's simply not true that ASM is not needed. There are sufficiently
-) many ideas that rely on network based ASM, at least intradomain. They

Toerless- are you then implying that intERdomain ASM is not needed?

[Toerless Eckert]

Post by Leonard Giuliano
-) Greg: It's simply not true that ASM is not needed. There are sufficiently
-) many ideas that rely on network based ASM, at least intradomain. They
Toerless- are you then implying that intERdomain ASM is not needed?

I am quite positive that interdomain ASM is a _MUST_. Wether or not
this would best be served by network level ASM or session level ASM
(via network level SSM) is a decision that has to be based on the merits
of the technical alternatives, and i have neither seen any IETF documents
on session level ASM over network level SSM, nor do i think anybody has
tried to compare the benefits/downsides of either approaches. My gut feeling
is just that the overall complexity of session level ASM with network
level SSM is in the same order as network level ASM via embedRP with
specific parameters, so at this point in time i would like to drive
both solution alternatives forward - in the end it might not even
necessarily be an either-or decision.

And as far as shorrt/mid/long-term is concerned:

- Short term, embedRP has a lot of process benefits
- Short term, we need to also work on session level ASM via SSM if you ask me.

- Mid term success of either solution will determine long term
recommendations:

- embedRP must be finalized appropriately to allow
for a few important and selectable operational modes. This
may still be inhibited with "architectural BS" reasons by
the religious opposition.

- Session level SSM must find some solutions

With both of these uncertainties, i can today only say that both
alternatives have the potential to be recommended long-term solutions,
and it is completely unclear wether or not we can count out one of
these solutions long-term.

- Long-term:

The only thing we probably all agree on for the long term is that
SSM is the technically most simple solution for static-single-source
type media broadcast, and that it is extremely likely that this will
ever change. Does this cover the mayority of Interdomain applications ?

It would cover those applications that today would have the highest
chance of actually triggering IP multicast deployment, but not necessarily
all the application that could make use of IP multicast Interdomain.

Cheers
Toerless

[s***@shepfarm.com]

Post by Toerless Eckert
The only thing we probably all agree on for the long term is that
SSM is the technically most simple solution for static-single-source
type media broadcast, and that it is extremely likely that this will
ever change. Does this cover the mayority of Interdomain applications ?
It would cover those applications that today would have the highest
chance of actually triggering IP multicast deployment, but not necessarily
all the application that could make use of IP multicast Interdomain.

..and those apps that have more than one dynamic source can then leverage
the success of SSM by building source discovery into the application.

Greg

Post by Toerless Eckert
Cheers
Toerless

[Toerless Eckert]

Post by s***@shepfarm.com

Post by Toerless Eckert
It would cover those applications that today would have the highest
chance of actually triggering IP multicast deployment, but not
necessarily all the application that could make use of IP multicast
Interdomain.

..and those apps that have more than one dynamic source can then leverage
the success of SSM by building source discovery into the application.

Sure, but that was never the point, was it ?

Am i just being to picky or is my impression right that you folks are
not really interested to talk about any technical details comparing the
merits of SSM vs. embedRP, but that this is simply about protocol fascism ?

Wanting to promote SSM by inhibiting any viable technical alternatives
in fear that it might reduce the potential success of SSM ? - "We don't
need a second alternative, one is good enough, besides, these other options
might confuse users" ?

If so, can someone please explain to me why _i_ have to make the argument
for the freedom of choice and proliferation by competition to a couple of
americans ?

;-)))

Cheers
Toerless

P.S.: Recommended: Highlander on HDTV - "there can be only one" ! ;-))

[s***@shepfarm.com]

Post by Toerless Eckert

Post by s***@shepfarm.com

Post by Toerless Eckert
It would cover those applications that today would have the highest
chance of actually triggering IP multicast deployment, but not
necessarily all the application that could make use of IP multicast
Interdomain.

..and those apps that have more than one dynamic source can then leverage
the success of SSM by building source discovery into the application.

Sure, but that was never the point, was it ?
Am i just being to picky or is my impression right that you folks are
not really interested to talk about any technical details comparing the
merits of SSM vs. embedRP, but that this is simply about protocol fascism ?

Hey, don't start name-calling or I'll make fun of your white-on-white
convertable VW Rabbit.

Post by Toerless Eckert
Wanting to promote SSM by inhibiting any viable technical alternatives
in fear that it might reduce the potential success of SSM ? - "We don't
need a second alternative, one is good enough, besides, these other options
might confuse users" ?

Personally, I'm tired of spinning so many cycles try to solve technical
details of solutions now will ever deploy.

Post by Toerless Eckert
If so, can someone please explain to me why _i_ have to make the argument
for the freedom of choice and proliferation by competition to a couple of
americans ?
;-)))

You're more than welcome to source Deutsche Welle by any means you
like. BUT if we don't draw a line on the v6 mcast roadmap - soon - the
infinite supply of undeployable ideas will continue to roll-in, and the
mud will only get thicker.

Greg

Post by Toerless Eckert
Cheers
Toerless
P.S.: Recommended: Highlander on HDTV - "there can be only one" ! ;-))

[Leonard Giuliano]

On Mon, 16 Jun 2003, Toerless Eckert wrote:

-)
-) If so, can someone please explain to me why _i_ have to make the argument
-) for the freedom of choice and proliferation by competition to a couple of
-) americans ?
-)

Toerless- As a matter of fact, in the US, we have an organization (I
believe it is NIST) whose job is, among other things, to define the specs
for a 1/4 inch screw. They come up with one standard so manufacturers are
given clear direction on how to make these screws. The standard does not
include multiple models based on the limitations of screw manufacturers
from 1904.

This allows the consumers to walk into a hardware store and select with
confidence a 1/4 inch screw that they know will do the job. They can
select from multiple manufacturers knowing they all use the same standard.
In this way, by restricting choice on the design specs of a screw,
consumers are given more freedom and choices and enjoy more competition.

As long as the ASM crutch exists, app designers will use it. Let's ween
them from the teet now before it's too late. Separate is not equal. The
existence of ASM DOES prevent SSM deployment.

What is also interesting is that SDR has been pointed out as the only app
that requires interdomain ASM, and you are pointing out that EmbedRP
doesn't even support SDR.

The path of ASM IPv6 inevitably leads us to MSDP for IPv6. Even this
thread has gone in that direction.

-Lenny

[David Meyer]

Not that I really want to get involved in this, but...

Post by Leonard Giuliano
The path of ASM IPv6 inevitably leads us to MSDP for IPv6.

I don't think this is supportable. It would seem at least
possible that someone (or some group), if incented,
could come up with something other than MSDP .

Dave

[Toerless Eckert]

Post by David Meyer
Not that I really want to get involved in this, but...

Post by Leonard Giuliano
The path of ASM IPv6 inevitably leads us to MSDP for IPv6.

I don't think this is supportable.

== not agreeable in the IETF ?

Post by David Meyer
It would seem at least
possible that someone (or some group), if incented,
could come up with something other than MSDP .

Right: If we concede that equivalent functionality to MSDP is required
in IPv6, then i for once would be torn apart between:

a) If my customers MUST have it now, what can i do except just implement
it as fast as possible

and

b) This is IPv6, we're here to come up with good architectural long
term solutions if possible. We had 5 years time to learn a lot
about the shortcomings of MSDP, and if we squeeze our memory cells
we will also remember a lot of good ideas on how we could improve it.

I _definitely_ do not see the need for a) (as long as we can establish
Embedded RP) and so i argue the need for b).

But if at all we see that we would long term need something like MSDP,
then lets to some high level brainstorming on b) first. Although i wouldn't
like to spend cycles on it given that i rather think other mechanisms
are more worthy to invest time into.

Cheers
Toerless

[Pekka Savola]

Post by Leonard Giuliano
The path of ASM IPv6 inevitably leads us to MSDP for IPv6. Even this
thread has gone in that direction.

I don't think this follows. Please elaborate why you think we'd
eventually have MSDP for IPv6.

(Some folks using anycast-RP might actually want it for intra-domain case,
but I'm not sure if you were referring to that, or that it's a valid
argument for interdomain case)

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Toerless Eckert
I am quite positive that interdomain ASM is a _MUST_.

I think I agree, but what *kind* of ASM? Open or closed groups?

So far as I can tell, the following ASM applications will work just fine
with closed groups:

SDR (Session Directory Tool)

RTP/RTCP (Real Time Protocol / Real Time Control Protocol)
- Access Grid
- VRVS
- H.323 conferencing systems
- etc.

Reliable Multicast Transport protocols
(see http://www.ietf.org/html.charters/rmt-charter.html )

Are there other ASM applications that require open groups?

Why is this a relevant question?

If we're going to stick with the Cheriton/Deering decision of RFC 966, and
require open groups for IPv6 ASM, then we will necessarily be stuck with a
data-driven architecture. Those of us building routers that expect to
handle gigabit multicast flows should be uncomfortable with that prospect. :-)

On the other hand, if closed groups are sufficient, then PIM bi-dir and
Embedded RP will be sufficient for IPv6. ASM (closed) is not necessarily
data driven, because all the necessary state is created when the potential
sender joins the group.

(Bill valiantly tries to bring the thread back towards Embedded RP!)


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Toerless Eckert]

Post by Bill Nickless
I think I agree, but what *kind* of ASM? Open or closed groups?
So far as I can tell, the following ASM applications will work just fine
SDR (Session Directory Tool)
RTP/RTCP (Real Time Protocol / Real Time Control Protocol)
- Access Grid
- VRVS
- H.323 conferencing systems
- etc.
Reliable Multicast Transport protocols
(see http://www.ietf.org/html.charters/rmt-charter.html )
Are there other ASM applications that require open groups?

Well, most of these application actually have a strong differentiation
between sources and receivers of a group. Neither one of these applications
requires the receivers to know who the sources are (SSM) nor do the sources
need to be receivers (closed group).

Could you do them with a closed group model ? Yes, certainly, but
in general, the "closed group" paradigm doesn't buy us all that much.

Post by Bill Nickless
Why is this a relevant question?
On the other hand, if closed groups are sufficient, then PIM bi-dir and
Embedded RP will be sufficient for IPv6. ASM (closed) is not necessarily
data driven, because all the necessary state is created when the potential
sender joins the group.

Well, Bidir-PIM still has the problem that a lot of hardware can't do it
correctly, and even that hardware that can may not necessarily support
a lot of different RPs. Yes, i think Bidir-PIM is technically an excellent
long-term option and for scoped deployments in which you can select the
routers for the requirement it is even today an excellent solution.
I want embedRP to support it, because i think that typical applications that
would prefer Bidir-PIM (multi-party), are actually closed group applications
(participants are sources and receivers) and such having Bidir-PIM work
perfectly for initially sent packets can well be bound to requiring being a
receiver in the first place.

But all of this interaction with embedRP will require further development
work on Bidir-PIM beyond embedRP, and it also doesn't take away the need
i think for PIM-SM based ASM.

Yes, i would love to make just one single protocol offering and declare
it to be the hailbringer for all solutions. I just don't think that
we have any such protocol. If you ask me, it could also only be an
amalgamation of what we have today, so let's rather start out identifying
the minimum set of protocols needed to solve all applications with
a split so that each individual deployment requires minimum complexity.

Cheers
Toerless

Post by Bill Nickless
(Bill valiantly tries to bring the thread back towards Embedded RP!)
===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2
iQCVAwUBPu4oCawgm7ipJDXBAQELXQP/VpPeKwOvRG6VQtQsgrAjtsefwazoZwBO
puZxczRGzGZudq4bxRUp1SZREHAOuQe/9yGraIbbIu8vEYnTY30B9D//ud5t3Y0l
OQb4pdHCsQSdJ7zGmksmMlRFkWU5sd6A8RHlk0XolO/bpPeRDkG0qFhng1lElfCj
uO3czDovc7o=
=Njzs
-----END PGP SIGNATURE-----

[Bill Nickless]

-----BEGIN PGP SIGNED MESSAGE-----

Post by Toerless Eckert

Post by Bill Nickless
So far as I can tell, the following ASM applications will work just fine
SDR (Session Directory Tool)
RTP/RTCP (Real Time Protocol / Real Time Control Protocol)
- Access Grid
- VRVS
- H.323 conferencing systems
- etc.
Reliable Multicast Transport protocols
(see http://www.ietf.org/html.charters/rmt-charter.html )
Are there other ASM applications that require open groups?

Well, most of these application actually have a strong differentiation
between sources and receivers of a group. Neither one of these applications
requires the receivers to know who the sources are (SSM) nor do the sources
need to be receivers (closed group).
Could you do them with a closed group model ? Yes, certainly, but
in general, the "closed group" paradigm doesn't buy us all that much.

Oh good--the universe is in balance again--I'm back to disagreeing with
Toerless!

Taking them one at a time--

SDR is the poster child for ASM. It has no central server host address.

RTP/RTCP, especially RTCP, assumes ASM. Every RTP/RTCP participant is both
a source and a receiver, because RTCP receivers also transmit reception
reports. RTCP reception reports are transmitted based on a *total*
bandwidth ceiling for all reports, which requires all RTCP receivers to
hear each other.

At least some Reliable / Secure Multicast Transport protocols assume ASM to
discover new group members. http://www-itg.lbl.gov/CIF/GroupComm/ has some
pointers to such protocols.


===
Bill Nickless http://www.mcs.anl.gov/people/nickless [phone]
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 ***@mcs.anl.gov

[Toerless Eckert]

Post by Bill Nickless
Taking them one at a time--
SDR is the poster child for ASM. It has no central server host address.

Funny that you should mention this, i was just refuting the same
statement from an application developer within Cisco ;-) - SDR doesn't
care about IP Multicast. SAP does. SAP has so far only been defined for
ASM, true. But likewise is it true that SAP is not used in many of the
production uses that rely on SDR today because of the lack of control
it provides.

[ I would also make the argument, that one could replace ASM/SAP with SSM/SAP
via a (replicated) ASM SAP server that announcer send announcements to,
and the anycast SAP server SSM multicasts them. That gives you control,
as to it's benefits/shortcomings - that's a longer discussion which would
need to be preceeded by the discussion wether or not to use SAP in the
first place.]

Post by Bill Nickless
RTP/RTCP, especially RTCP, assumes ASM.

Multicast RTCP is only useful in uncontrolled multi-party applications.
We already determined that it's a very bad ida for the mayority of
applications (broadcast style) we're seeing to be actually in demand.

But yes, RTCP is actually a good reason for closed group ASM. RTP itself
for broadcast applications is neither an argument for ASM nor for closed
groups (source server is not receiver).

Post by Bill Nickless
At least some Reliable / Secure Multicast Transport protocols assume ASM to
discover new group members. http://www-itg.lbl.gov/CIF/GroupComm/ has some
pointers to such protocols.

Ok, i only care about PGM or tornado-codec style FEC broadcasts unless
someone shows me good arguments why other protocols that demand more of
the network are actually needed in deployment!

So, where does this leaves us ? You bring up a range of perceived requirements
for ASM, and i am trying to show you to what degree you could adopt them
to SSM - to me nothing has changed: I want to promote SSM, but i know
customers will need ASM, wether or not the actual use is something that
they could better (or worse) do with SSM - or not. Aka: One has to do both
of them as good as possible if you're trying to make paying customers happy.

I think the interesting question is rather wether embedRP will be able
to provide ASM services for all the applications you listed. I for once
think that it will SHOULD not be used to provide ASM for example for
"The global SAP group" because that one has a completely unpredictable
membership size and no known ownership. But my answer to this is that
global SAP was a bad idea in the first place, and just because we don't
have a good web pased directory of multicast events only shows that there's
not much commercial interest in it, but it doesn't prove that SAP is a good
solution.

Cheers
Toerless

[s***@shepfarm.com]

Post by Toerless Eckert

Post by s***@shepfarm.com
..and so now we are asking to remove those constraints for v6 and move
right to what we now know to be more simple, reliable, secure, and what
fills the needs of current interdomain content owners - SSM

Greg: It's simply not true that ASM is not needed. There are sufficiently
many ideas that rely on network based ASM, at least intradomain. They
all leverage source discovery for some form of ressource discovery.
Why don't you stat out explaining how to do SRVLOC with SSM for example ?
(yes, of course it could be done, but unless it is done, we need ASM).

What you do inside your domain is your bis. What you do with MY pig in MY
barn is MY buisiness. BTW, I told Wilbur you said 'hello' - he just wink
and chuckled.. Hmm, that the last time I let you go to the barn alone with
plate of watermelon. ;-)

Find me one app other than SDR that truely NEEDS ASM interdomain?

Greg

Post by Toerless Eckert
Cheers
Toerless

[Toerless Eckert]

Post by s***@shepfarm.com

Post by Toerless Eckert
Greg: It's simply not true that ASM is not needed. There are sufficiently
many ideas that rely on network based ASM, at least intradomain. They
all leverage source discovery for some form of ressource discovery.
Why don't you stat out explaining how to do SRVLOC with SSM for example ?
(yes, of course it could be done, but unless it is done, we need ASM).

What you do inside your domain is your bis. What you do with MY pig in MY
barn is MY buisiness. BTW, I told Wilbur you said 'hello' - he just wink
and chuckled..

Exactly, and with embedRP it is you as the owner of the pig, uhm, RP, who
makes that choice. In PIM-SM/MSDP it's a totally uncontrollable globally
distributed decision.

Post by s***@shepfarm.com
Hmm, that the last time I let you go to the barn alone with
plate of watermelon. ;-)

You just need to configure accept-register on your pig !

Post by s***@shepfarm.com
Find me one app other than SDR that truely NEEDS ASM interdomain?

Well, as said in another mail on this thread: SDR wouldn't be applicable
to embedRP in my opinion anyhow. But the typical multi-party conference
would be applicable to ASM. Could you do it with session-level ASM via
network level SSM ? Sure. Would it be easier ? IPv4: Sure. IPv6: With
embedRP that's an open question. I think complexity-wise they will be
very similar, and it's about their functional differences where it becomes
interesting.

Another example is simply the broadcast of programs with redundant sources.
If i could have embedRP ranges with a definition of allowed sources, then
i can easily use embedRP to have redundant servers without additional
application signalling, something which in SSM would require anycast.

Cheers
Toerless

[Prashant Rajvaidya]

Post by Dino Farinacci
I just want to ask eweryone one question. And let's be real honest with
ourselves.
Do you think multicast would be farther along without MSDP?

Simple answer: "no". A more quantitative answer: "68% probability that
multicast would not be farther along, with or without MSDP".

Without denying the evils/bads/limitations/cons/holes of MSDP, I do want
to mention that in good part of 2000-2001 MBGP routing was extremely
flaky. During this period, more than 68% of addresses were not visible to
several core routers 20%-60% of each day. Therefore, MSDP or no MSDP,
frustrations level was for folks was rising any ways because of severe
reachability and data delivery problems. As kevin said: "Basically we were
under the illusion that multicast was working fine when it wasn't."

--prashant

Post by Dino Farinacci

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)

Dino

[Marshall Eubanks]

What would you say is the current number for this ? (I.e., the
inconsistency in multicast
reachability.) And, why was it so much worse than unicast BGP, when
it's the same
interdomain protocol ?

Very interesting discussion, BTW.

Post by Prashant Rajvaidya

Post by Dino Farinacci
I just want to ask eweryone one question. And let's be real honest with
ourselves.
Do you think multicast would be farther along without MSDP?

Simple answer: "no". A more quantitative answer: "68% probability that
multicast would not be farther along, with or without MSDP".
Without denying the evils/bads/limitations/cons/holes of MSDP, I do want
to mention that in good part of 2000-2001 MBGP routing was extremely
flaky. During this period, more than 68% of addresses were not visible to
several core routers 20%-60% of each day. Therefore, MSDP or no MSDP,
frustrations level was for folks was rising any ways because of severe
reachability and data delivery problems. As kevin said: "Basically we were
under the illusion that multicast was working fine when it wasn't."
--prashant

Post by Dino Farinacci

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)

Dino

Regards
Marshall Eubanks

T.M. Eubanks
e-mail : ***@multicasttech.com
http://www.multicasttech.com

Test your network for multicast :
http://www.multicasttech.com/mt/

Our New Video Service is in Beta testing
http://www.americafree.tv

[Prashant Rajvaidya]

Post by Marshall Eubanks
What would you say is the current number for this ? (I.e., the
inconsistency in multicast
reachability.)

In terms of "route stability", "consistency in reachability", and
"increase in deployment", things have been good lately (last one year).
Have not done deeeeeep-detailed analysis for recent data sets. However, I
can pretty confidently guess the following for the last one year:
- Only about 10%-15% addresses have had instable connectivity
- As for inconsistency in reachability of different routers is concerned,
things have been fairly good as well. If the 10-15% unstable
addresses are kept out of consideration, reachability is *almost*
consistent across routers.
- *almost* because some addresses are continually seen only in a few
routers. I fail to understand why because I believe policy is not much
in use. Any insights in this regard will be great.

Post by Marshall Eubanks
And, why was it so much worse than unicast BGP, when it's the same
interdomain protocol ?

Great question, have been digging into it for quite some time myself.
Unfortunately, have not found anything so far :(. Any one has any ideas?

Post by Marshall Eubanks
Very interesting discussion, BTW.

Coming back to MSDP and brokenness of multicast, I wanted to ask three
simple questions:
"When MSDP eats away SA(s), is it not true that instabilities in MBGP
might have been the prime culprit (Instable MBGP => increased
chances of RPF failing for MSDP)?"

"How frequent are complaints about sources not being reachable, at
all?"

"How frequent are complaints about audio/video/data delivery being not
stable/reliable?"

I ask these questions because probably things are not as bad as they used
to be. Regardless of how much room there is for improvements/fixes in the
current protocols, it will be sad if we fail to acknowledge improvements
in stability in recent years, if there have been any.

--prashant

Post by Marshall Eubanks

Post by Prashant Rajvaidya

Post by Dino Farinacci
I just want to ask eweryone one question. And let's be real honest with
ourselves.
Do you think multicast would be farther along without MSDP?

Simple answer: "no". A more quantitative answer: "68% probability that
multicast would not be farther along, with or without MSDP".
Without denying the evils/bads/limitations/cons/holes of MSDP, I do want
to mention that in good part of 2000-2001 MBGP routing was extremely
flaky. During this period, more than 68% of addresses were not visible to
several core routers 20%-60% of each day. Therefore, MSDP or no MSDP,
frustrations level was for folks was rising any ways because of severe
reachability and data delivery problems. As kevin said: "Basically we were
under the illusion that multicast was working fine when it wasn't."
--prashant

Post by Dino Farinacci

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See sdr-monitor
and Mantra work for data.)

Dino

Regards
Marshall Eubanks
T.M. Eubanks
http://www.multicasttech.com
http://www.multicasttech.com/mt/
Our New Video Service is in Beta testing
http://www.americafree.tv

[Marshall Eubanks]

These are just my personal observations.

Post by Prashant Rajvaidya

Post by Marshall Eubanks
What would you say is the current number for this ? (I.e., the
inconsistency in multicast
reachability.)

In terms of "route stability", "consistency in reachability", and
"increase in deployment", things have been good lately (last one year).
Have not done deeeeeep-detailed analysis for recent data sets.
However, I
- Only about 10%-15% addresses have had instable connectivity
- As for inconsistency in reachability of different routers is concerned,
things have been fairly good as well. If the 10-15% unstable
addresses are kept out of consideration, reachability is *almost*
consistent across routers.
- *almost* because some addresses are continually seen only in a few
routers. I fail to understand why because I believe policy is not much
in use. Any insights in this regard will be great.

Policy can seep through at many levels.

For example, consider the effects of route aggregation
Many people announce smaller address blocks for multicast than for
unicast.
There was a time when Verio would aggregate out many blocks longer than
a /22, and they did this in MBGP as well. This hurts more than it seems
it should
because there is no guarantee that the provider who provided you with
your
address block is the provider you get multicast from. Greg and Jared
cleaned up this little mess, but I am sure that there are others like
it out there.

I put a lot
of store on temporal stability as a proxy for reliability and that
seems to be roughly as good as in unicast. (Notice that GE
announces and withdraws a BGP /8 pretty much daily recently - wonder
what that does for unicast
reachability?)

Post by Prashant Rajvaidya

Post by Marshall Eubanks
And, why was it so much worse than unicast BGP, when it's the same
interdomain protocol ?

Great question, have been digging into it for quite some time myself.
Unfortunately, have not found anything so far :(. Any one has any ideas?

Post by Marshall Eubanks
Very interesting discussion, BTW.

Coming back to MSDP and brokenness of multicast, I wanted to ask three
"When MSDP eats away SA(s), is it not true that instabilities in MBGP
might have been the prime culprit (Instable MBGP => increased
chances of RPF failing for MSDP)?"
"How frequent are complaints about sources not being reachable, at
all?"
"How frequent are complaints about audio/video/data delivery being not
stable/reliable?"

To be honest, I see few signs of these problems now. Even the "65
second"
problem doesn't seem to be as bad as it was. It's more binary - if it
works, it
seems to work OK.

Post by Prashant Rajvaidya
I ask these questions because probably things are not as bad as they used
to be. Regardless of how much room there is for improvements/fixes in the
current protocols, it will be sad if we fail to acknowledge
improvements
in stability in recent years, if there have been any.
--prashant

Marshall

Post by Prashant Rajvaidya

Post by Marshall Eubanks

Post by Prashant Rajvaidya

Post by Dino Farinacci
I just want to ask eweryone one question. And let's be real honest with
ourselves.
Do you think multicast would be farther along without MSDP?

Simple answer: "no". A more quantitative answer: "68% probability that
multicast would not be farther along, with or without MSDP".
Without denying the evils/bads/limitations/cons/holes of MSDP, I do want
to mention that in good part of 2000-2001 MBGP routing was extremely
flaky. During this period, more than 68% of addresses were not
visible
to
several core routers 20%-60% of each day. Therefore, MSDP or no MSDP,
frustrations level was for folks was rising any ways because of severe
reachability and data delivery problems. As kevin said: "Basically we were
under the illusion that multicast was working fine when it wasn't."
--prashant

Post by Dino Farinacci

Post by Kevin C. Almeroth
Look at the history of MSDP state in the network. For several
years, from about 1998 to 2001 the MSDP was horribly inconsistent
among the core Internet routers. What this meant was that more
than half the time you'd join a group, you would not see all the
sources for that group. Basically we were under the illusion that
multicast was working fine when it wasn't. Just because I could
click on a group in IPTV and see a source did not mean all groups
were working or I saw all sources for that group. (See
sdr-monitor
and Mantra work for data.)

Dino

Regards
Marshall Eubanks
T.M. Eubanks
http://www.multicasttech.com
http://www.multicasttech.com/mt/
Our New Video Service is in Beta testing
http://www.americafree.tv

[Kevin C. Almeroth]

Post by Pekka Savola
Yes, that is the point, but please keep in mind that the the number of
routers is much, much smaller than that of hosts, there are a lot, lot
fewer generally deployed router implementations.

Myth #1: Just because there are fewer routers, it takes less time to
upgrade them all.

Post by Pekka Savola
Greg: It's simply not true that ASM is not needed. There are sufficiently
many ideas that rely on network based ASM, at least intradomain. They
all leverage source discovery for some form of ressource discovery.
Why don't you stat out explaining how to do SRVLOC with SSM for example ?
(yes, of course it could be done, but unless it is done, we need ASM).

Myth #2: Having a complex solution that accounts for every problem is
going to make people happier and want to deploy a whole series
of protocols and services.

We've tried the new-protocol-per-new-problem idea (and are still
trying it)... and it doesn't work.

I would encourage SSM-only in IPv6 as the way to go. If someone wants to
then propose protocol XYZ to create some advance functionality (source discovery)
in the network, be my guest.

But throwing every service into the cart before hooking it to the horse
is going to leave us with a horse tied to a cart that can't be moved.

-Kevin

[Toerless Eckert]

Post by Kevin C. Almeroth

Post by Toerless Eckert
Greg: It's simply not true that ASM is not needed. There are sufficiently
many ideas that rely on network based ASM, at least intradomain. They
all leverage source discovery for some form of ressource discovery.
Why don't you stat out explaining how to do SRVLOC with SSM for example ?
(yes, of course it could be done, but unless it is done, we need ASM).

Myth #2: Having a complex solution that accounts for every problem is
going to make people happier and want to deploy a whole series
of protocols and services.

Agreed that that's a myth, but that's not really related to the embedRP
discussion. embedRP is rather about finding one alternative that could be
a very simple solution for a given problem, and the given problem is ASM.

You're not really debating the need for ASM, right ? But you leave out
providing any details that measure up the solutions complexity of
session layer ASM/network layer SSM vs. purely network layer ASM with
embedRP.

Post by Kevin C. Almeroth
We've tried the new-protocol-per-new-problem idea (and are still
trying it)... and it doesn't work.

It has worked, and it's not a new problem. Of course: improving on the
technical solution alone is not sufficient to improve deployment, but
it can certainly help.

Post by Kevin C. Almeroth
I would encourage SSM-only in IPv6 as the way to go.

If you're saying this from the perspective of someone just working at
the network layer, then that's an evading argument: You just shifted
whatever you couldn't manage to solve into somebody else's responsibility.
How's that going to drive the overall solution requirements.

C'mon on, let's try to be fair and honest to the process here !
ASM is a required service model, and there are solutions at different
levels. Unless you have a better grip of it's replacements outside of
the network layer, don't even start to measure up the perceived complexity
of something like embedRP which definitely is very close to minimum
complexity as you can get on any layer !

Post by Kevin C. Almeroth
If someone wants to
then propose protocol XYZ to create some advance functionality (source
discovery) in the network, be my guest.

embedRP.

Post by Kevin C. Almeroth
But throwing every service into the cart before hooking it to the horse
is going to leave us with a horse tied to a cart that can't be moved.

Quite the opposite. The poor horse you describe was PIM-SM with MSDP.
We now have a couple of different cars/horse-carriages, and most customers
will only need one type. Does it mean we can prohibit any particular
vehicle type use on the highway ? Yes, for the IPv6 highway we may
want to inhibit horse-carriages, but embedRP is certainly not one, it's
rather a retro-style sports car if you ask me.

Cheers
Toerless

[Kevin C. Almeroth]

Post by s***@shepfarm.com
Find me one app other than SDR that truely NEEDS ASM interdomain?

Why do you need ASM for sdr? Set up a few source/group IDs that
basically broadcast sdr-style info. Applications join one of
the well-known source/group IDs. Starts to look like a streaming
version of DNS.

All this assuming there is even a reason to have sdr.

-Kevin

[s***@shepfarm.com]

Post by Kevin C. Almeroth

Post by s***@shepfarm.com
Find me one app other than SDR that truely NEEDS ASM interdomain?

Why do you need ASM for sdr? Set up a few source/group IDs that
basically broadcast sdr-style info. Applications join one of
the well-known source/group IDs. Starts to look like a streaming
version of DNS.
All this assuming there is even a reason to have sdr.

No argument from me. Mcast today is like ham radio.. I hope you all enjoy
seeing my purple dragon.. :P

Greg

Post by Kevin C. Almeroth
-Kevin

[Kevin C. Almeroth]

Post by Toerless Eckert
Am i just being to picky or is my impression right that you folks are
not really interested to talk about any technical details comparing the
merits of SSM vs. embedRP, but that this is simply about protocol fascism ?

You might actually be right on the first point... as Greg mentioned
the key is to have a roadmap for IPv6 first and foremost with deployability
in mind.

I'm not adverse to discussing embedRP, but the concern I have is that
cute network solutions have and will continue to miss the fundamental
problem.

Post by Toerless Eckert
Wanting to promote SSM by inhibiting any viable technical alternatives
in fear that it might reduce the potential success of SSM ? - "We don't
need a second alternative, one is good enough, besides, these other options
might confuse users" ?

As a first phase of deployment, absolutely.

Given that we don't know a good enough solution for ASM, I would not
recommend to the IPv6 community to start making it an integral part
of IPv6.

-Kevin

[John Zwiebel]

Guys, it seems to me we have to refocus. Everyone has made
some good points (as well as some stupid ones -- but what would
fun would this discussion be without being able to think we're
all smarter than each other. ;-)

Let me try to outline the dimensions of the problem so we can
break things down and stop using the fact that "you used to
date my sister and dumped her so I won't talk to you any longer"
from interfering with our overall goal of deploying something
that "works".

One dimension of the problem (which I will call "vendor responsibility)
is:
Applications/Hosts, Network (IP/Routers), Layer 2 (switches and/or
"last mile").

Other (perhaps interdependent) dimension are:
ease of deployment and use
scalability
reliability
functionality

I believe we can gain insight into restrictions that have to be dealt
with
in each of the second group of dimensions if we recognize the problems
that
will be introduced in the vendor responsibility dimension.

Certain beliefs are held that need to be challenged. Among these:

I believe App writers don't want to have to deal with a new paradigm
when
what they have works "good enough" and if those "network guys"
(routers
and switches) would just "fix there stuff", life would be good.

I believe router guys have been frustrated by the "failure" of the
switch folks (which includes ATM/DSLAM) to recognize the inevitability
of multicast and the myriad of benefits that will be recognized when
multicast is everywhere. (ie, why isn't ATM getting killed faster?)

I believe "most" switch guys, faced with providing something simple
and
cheap (vs a router) and reliable, make the choice to ignore multicast.
After all, the only deployed IGMPv3 is in Windows and there just isn't
enough content out there that they won't be able to sell their
equipment.
(Sorry Jon, the market is a huge player.)

I believe app writers think that if it works in their enterprise lan,
it
should "just work" across the internet while the router guys are faced
with ISPs that don't want to depend on each other so certain
compromises
have to be made (MSDP).

If you take these attitudes and apply them to the second set of problem
dimensions, I think you can see that if we aren't careful, we'll end up
talking "at" each other and the problems we have will continue. Add to
that another dimension...

I also strongly believe there is an enormous financial incentive for
certain content providers to ensure multicast fails, which (perhaps)
results
in this group trying to solve problems that are not solvable.

But, let's leave my paranoia out of the discussion or we'll be looking
for
the WMDs and trying to impeach yet another president -- to no good
effect.

So, let me -- as a router guy -- try to point out the limits of all the
different multicast options and try to highlight the various discussions
I think I've seen in this thread.

BTW, what I hope to encourage out of this is several -separate-
discussions
so we don't have the "so's your mother" arguments (especially Wiber and
watermelon) flowing back and forth.

ASM vs SSM vs Bidir
--------------------
ASM isn't going away soon. DVMRP hung around for years. Dense-mode was
around for years. ASM is going to be around for years. If you are an
app developer depending on ASM, its going to be there for you.

So, what's the big deal? Why are the "router guys" saying ASM must die?

1) the idea of switching to from the RP-tree to the SPT has proven
to be "intractable". The protocol actually has routers "fight"
with each other when trying to determine which router is going to
be the forwarder. If this "fight" were described as a "route flap"
then perhaps folks who haven't watched the protocol might better
understand the seriousness of this conflict. Switching between
trees, joining and pruning trees, conflicts between multiple
forwarders on a LAN: all of these could be thought of as "route
flaps". (Let's not get caught up in how bad a route flap is,
but do recognize that we are talking about cases where these
route flaps are endemic to certain applications and/or topologies
so that just because they don't affect you, doesn't mean they
aren't important to resolve.)

2) Source discovery is is designed into the protocol. Aggh...
This has been a pain since day-one. Every IETF we revisit the
same requirement that there needs to be some kind of a RTS/CTS
protocol that lets routers know that a source intends to send.
Multicast is -NOT- unicast. The idea that unicast UDP just dumps
packets on to the network and so multicast UDP should be able
to do the same is just wrong, wrong, wrong. Bidir (with previously
announced RPs) can meet this requirement because the route is
-previously- established -- just like unicast UDP. But it should
be obvious by now that expecting the network to dynamically create
a route while not losing any packets or creating duplicate packets,
does not work. Especially when you get interdomain multicast
depending on MSDP.

3) Interdomain multicast is outside of the scope of the PIM protocol.
MSDP was designed as a kludge and was only meant to be temporary,
yet from the moment it was proposed, additional requirements were
placed on it to perform functions it was not well suited for.
Specifically the need to encapsulate the first data packet received
by the SA originator so it could be delivered down the shared-path
of whatever domains just might be interested in receiving that
packet.

4) non-RPF traffic is difficult to deal with. This means
asserts as well as packets seen on interfaces that are not in the Olist
and are not the IIF for the mroute. The the separating of the
forwarding machinery from the routing machinery in high-end systems
has made non-RPF traffic difficult to handle without using additional
resources inside the router.

So my view of the big 3 are:
-- dynamic route requiring no packet loss including Interdomain
operations
-- protocol thrashing.
-- non-RPF traffic.

Yes, its much better now than it used to be
and in certain topologies and for certain applications it is
"good enough". But it isn't "good enough" for -all- applications
and -all- topologies. So alternatives must be proposed and developed.

ASM just isn't going to get that much better than it is right now.

Bidir
-----
Bidir greatly simplifies the control plan because nothing's going
anywhere until the route is in place (ie a DF has been elected on
the LAN). This happens -before- the first data packet is sent.

Bidir has a problem in the interdomain environment because you
must figure out where the RP is suppose to reside. This problem
has been around since the beginning of multicast.

Bidir doesn't have to deal with source discovery.

Bidir doesn't require extra machinery to deal with non-RPF traffic.
The OIF is either there or its not. (DF details I won't go into)

SSM
---
Again, the route has to be established -before- any packets
are forwarded off the source lan.

SSM has the problem of source discovery, a new protocol or
procedure has to be established. Who wants to have to deal
with that?

SSM -should- deal with duplicate packets on the LAN and so
probably must implement an assert mechanism, but it doesn't
have to look at every mpacket it sees on every interface
just in case a register needs to be sent to the PIM RP.
And it may be possible to use the DF mechanism to figure out
who the forwarder on a given LAN should be for an SSM group
rather than examine packets on non-RPF interfaces.


So, yes, I've glossed over the application requirements and
ignored the layer2 requirements. I hope though that I've made
it clear that as multicast becomes more widely deployed,
PIM-SM and MSDP are going to become more and more unmanageable
in the interdomain environment. As someone who wants to watch
shep's pig from anywhere in the world, I'm very interested in
simplifying the job that the routers have to perform (There
are a lot of pigs out there and if you have a pig fetish, perhaps
you can't get enough).

Now, I could be accused of being multicast-biased and I am,
since obviously the chances of thousands of folks wanting to
watch Shep's pig at the same time it probably quite limited.
On the other hand, if shep's pig's name was victoria...

But that does bring up another topic for discussion.


So I'd like to see this discussion branch off into:

-- App requirements, please don't say "I have to have ASM".
I equate that to customers saying "I have to have 2547"
"Everyone" except the customer "knows" 2547 isn't going to
scale, yet we do nothing to stop them from jumping off that
cliff. Let's -not- do that with multicast.
o how large are your groups?
o what kind of reliability do you need?
o how many sources? (remember RTCP fails in an ASM environment)
o how many receivers?
o what kind of distribution of sources and receivers?
o BW requirements

-- Layer2 requirements (last-hop/last-mile)
o Why can't you do IGMPv3 snooping?
o Why can't you do point to multipoint?
o Do you have some alternate proposals?

WRT whether or not the embedded RP is a good idea, IHNO
(I have no opinion). I don't know enough about the apps to
decide.

Whether or not interdomain bidir is a good idea -- IHNO

Whether or not ASM is the only way to do source discovery that
scales -- I doubt it. think of it this way. If ASM were good
enough, do you think we'd be pushing for something else? The
routing guys have spent at least as much time trying to fix ASM
as the App guys have spent building the app. If the routing
folks think its necessary to toss out all that work, doesn't
it make sense that there's a reason for it?

Now, as for the argument between the routing guys themselves on
ASM/bidir/SSM: There's no reason not to address all three. The
points that both (all?) sides make are valid. Each vendor has to
make a choice on how to deploy its resources. A vendor that doesn't
currently support ASM isn't going anywhere so that's a moot point.

And the question of Bidir vs SSM can't be determined until we get
a better understanding of the application space. Remember we once
thought Dense-mode was viable for expanding ring searches, but the
ttl-0 problem with asserts should have cured us of that. (Which
shouldn't be interpreted to mean I don't think the bug shouldn't
be fixed.)

In the olden days, sparse or dense eventually evolved to sparse-dense
and now dense has withered away. there are some arguments that
suggest that if we could develop a way of determining where to locate
a bidir RP (remember its virtual so is just a subnet and not a real
box) that SSM won't be required, so -only- bidir should be developed.
That would mean IGMPv3 wouldn't be required.

Perhaps we should be figuring out where to locate the RP and
deny such a thing as a source-only group member. Now the debate
might become even easier. Bidir everywhere.

z

[Dino Farinacci]

Post by John Zwiebel
Whether or not ASM is the only way to do source discovery that
scales -- I doubt it. think of it this way. If ASM were good
enough, do you think we'd be pushing for something else? The
routing guys have spent at least as much time trying to fix ASM
as the App guys have spent building the app. If the routing
folks think its necessary to toss out all that work, doesn't
it make sense that there's a reason for it?

I propose that the next MBONED working group meeting be a joint meeting
with the MMUSIC folks.

Dave, can you make this happen? I cc'ed the MMUSIC chairs as well.

Thanks,
Dino

-------------------------------------------------------------------------------
X-Authentication-Warning: network-services.uoregon.edu: majordomo set sender to owner-***@network-services.uoregon.edu using -f
Date: Tue, 17 Jun 2003 15:31:03 -0700
Subject: Refocus on Multicast choices (was Re: draft-savola-mboned-mcast-rpaddr-03.txt)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Cc: John Zwiebel <***@procket.com>
To: ***@network-services.uoregon.edu
From: John Zwiebel <***@procket.com>
In-Reply-To: <***@cab.cs.ucsb.edu>
X-OriginalArrivalTime: 17 Jun 2003 22:31:05.0650 (UTC) FILETIME=[240C0920:01C33520]
Sender: owner-***@network-services.uoregon.edu
Precedence: bulk
X-Archive: http://darkwing.uoregon.edu/~llynch/mboned/
X-HTTP: http://ns.uoregon.edu/~dmm/MBONED
X-Subscribe: ***@ns.uoregon.edu
X-Unsubscribe: ***@ns.uoregon.edu

Guys, it seems to me we have to refocus. Everyone has made
some good points (as well as some stupid ones -- but what would
fun would this discussion be without being able to think we're
all smarter than each other. ;-)

Let me try to outline the dimensions of the problem so we can
break things down and stop using the fact that "you used to
date my sister and dumped her so I won't talk to you any longer"
from interfering with our overall goal of deploying something
that "works".

One dimension of the problem (which I will call "vendor responsibility)
is:
Applications/Hosts, Network (IP/Routers), Layer 2 (switches and/or
"last mile").

Other (perhaps interdependent) dimension are:
ease of deployment and use
scalability
reliability
functionality

I believe we can gain insight into restrictions that have to be dealt
with
in each of the second group of dimensions if we recognize the problems
that
will be introduced in the vendor responsibility dimension.

Certain beliefs are held that need to be challenged. Among these:

I believe App writers don't want to have to deal with a new paradigm
when
what they have works "good enough" and if those "network guys"
(routers
and switches) would just "fix there stuff", life would be good.

I believe router guys have been frustrated by the "failure" of the
switch folks (which includes ATM/DSLAM) to recognize the inevitability
of multicast and the myriad of benefits that will be recognized when
multicast is everywhere. (ie, why isn't ATM getting killed faster?)

I believe "most" switch guys, faced with providing something simple
and
cheap (vs a router) and reliable, make the choice to ignore multicast.
After all, the only deployed IGMPv3 is in Windows and there just isn't
enough content out there that they won't be able to sell their
equipment.
(Sorry Jon, the market is a huge player.)

I believe app writers think that if it works in their enterprise lan,
it
should "just work" across the internet while the router guys are faced
with ISPs that don't want to depend on each other so certain
compromises
have to be made (MSDP).

If you take these attitudes and apply them to the second set of problem
dimensions, I think you can see that if we aren't careful, we'll end up
talking "at" each other and the problems we have will continue. Add to
that another dimension...

I also strongly believe there is an enormous financial incentive for
certain content providers to ensure multicast fails, which (perhaps)
results
in this group trying to solve problems that are not solvable.

But, let's leave my paranoia out of the discussion or we'll be looking
for
the WMDs and trying to impeach yet another president -- to no good
effect.

So, let me -- as a router guy -- try to point out the limits of all the
different multicast options and try to highlight the various discussions
I think I've seen in this thread.

BTW, what I hope to encourage out of this is several -separate-
discussions
so we don't have the "so's your mother" arguments (especially Wiber and
watermelon) flowing back and forth.

ASM vs SSM vs Bidir
--------------------
ASM isn't going away soon. DVMRP hung around for years. Dense-mode was
around for years. ASM is going to be around for years. If you are an
app developer depending on ASM, its going to be there for you.

So, what's the big deal? Why are the "router guys" saying ASM must die?

1) the idea of switching to from the RP-tree to the SPT has proven
to be "intractable". The protocol actually has routers "fight"
with each other when trying to determine which router is going to
be the forwarder. If this "fight" were described as a "route flap"
then perhaps folks who haven't watched the protocol might better
understand the seriousness of this conflict. Switching between
trees, joining and pruning trees, conflicts between multiple
forwarders on a LAN: all of these could be thought of as "route
flaps". (Let's not get caught up in how bad a route flap is,
but do recognize that we are talking about cases where these
route flaps are endemic to certain applications and/or topologies
so that just because they don't affect you, doesn't mean they
aren't important to resolve.)

2) Source discovery is is designed into the protocol. Aggh...
This has been a pain since day-one. Every IETF we revisit the
same requirement that there needs to be some kind of a RTS/CTS
protocol that lets routers know that a source intends to send.
Multicast is -NOT- unicast. The idea that unicast UDP just dumps
packets on to the network and so multicast UDP should be able
to do the same is just wrong, wrong, wrong. Bidir (with previously
announced RPs) can meet this requirement because the route is
-previously- established -- just like unicast UDP. But it should
be obvious by now that expecting the network to dynamically create
a route while not losing any packets or creating duplicate packets,
does not work. Especially when you get interdomain multicast
depending on MSDP.

3) Interdomain multicast is outside of the scope of the PIM protocol.
MSDP was designed as a kludge and was only meant to be temporary,
yet from the moment it was proposed, additional requirements were
placed on it to perform functions it was not well suited for.
Specifically the need to encapsulate the first data packet received
by the SA originator so it could be delivered down the shared-path
of whatever domains just might be interested in receiving that
packet.

4) non-RPF traffic is difficult to deal with. This means
asserts as well as packets seen on interfaces that are not in the Olist
and are not the IIF for the mroute. The the separating of the
forwarding machinery from the routing machinery in high-end systems
has made non-RPF traffic difficult to handle without using additional
resources inside the router.

So my view of the big 3 are:
-- dynamic route requiring no packet loss including Interdomain
operations
-- protocol thrashing.
-- non-RPF traffic.

Yes, its much better now than it used to be
and in certain topologies and for certain applications it is
"good enough". But it isn't "good enough" for -all- applications
and -all- topologies. So alternatives must be proposed and developed.

ASM just isn't going to get that much better than it is right now.

Bidir
-----
Bidir greatly simplifies the control plan because nothing's going
anywhere until the route is in place (ie a DF has been elected on
the LAN). This happens -before- the first data packet is sent.

Bidir has a problem in the interdomain environment because you
must figure out where the RP is suppose to reside. This problem
has been around since the beginning of multicast.

Bidir doesn't have to deal with source discovery.

Bidir doesn't require extra machinery to deal with non-RPF traffic.
The OIF is either there or its not. (DF details I won't go into)

SSM
---
Again, the route has to be established -before- any packets
are forwarded off the source lan.

SSM has the problem of source discovery, a new protocol or
procedure has to be established. Who wants to have to deal
with that?

SSM -should- deal with duplicate packets on the LAN and so
probably must implement an assert mechanism, but it doesn't
have to look at every mpacket it sees on every interface
just in case a register needs to be sent to the PIM RP.
And it may be possible to use the DF mechanism to figure out
who the forwarder on a given LAN should be for an SSM group
rather than examine packets on non-RPF interfaces.


So, yes, I've glossed over the application requirements and
ignored the layer2 requirements. I hope though that I've made
it clear that as multicast becomes more widely deployed,
PIM-SM and MSDP are going to become more and more unmanageable
in the interdomain environment. As someone who wants to watch
shep's pig from anywhere in the world, I'm very interested in
simplifying the job that the routers have to perform (There
are a lot of pigs out there and if you have a pig fetish, perhaps
you can't get enough).

Now, I could be accused of being multicast-biased and I am,
since obviously the chances of thousands of folks wanting to
watch Shep's pig at the same time it probably quite limited.
On the other hand, if shep's pig's name was victoria...

But that does bring up another topic for discussion.


So I'd like to see this discussion branch off into:

-- App requirements, please don't say "I have to have ASM".
I equate that to customers saying "I have to have 2547"
"Everyone" except the customer "knows" 2547 isn't going to
scale, yet we do nothing to stop them from jumping off that
cliff. Let's -not- do that with multicast.
o how large are your groups?
o what kind of reliability do you need?
o how many sources? (remember RTCP fails in an ASM environment)
o how many receivers?
o what kind of distribution of sources and receivers?
o BW requirements

-- Layer2 requirements (last-hop/last-mile)
o Why can't you do IGMPv3 snooping?
o Why can't you do point to multipoint?
o Do you have some alternate proposals?

WRT whether or not the embedded RP is a good idea, IHNO
(I have no opinion). I don't know enough about the apps to
decide.

Whether or not interdomain bidir is a good idea -- IHNO

Whether or not ASM is the only way to do source discovery that
scales -- I doubt it. think of it this way. If ASM were good
enough, do you think we'd be pushing for something else? The
routing guys have spent at least as much time trying to fix ASM
as the App guys have spent building the app. If the routing
folks think its necessary to toss out all that work, doesn't
it make sense that there's a reason for it?

Now, as for the argument between the routing guys themselves on
ASM/bidir/SSM: There's no reason not to address all three. The
points that both (all?) sides make are valid. Each vendor has to
make a choice on how to deploy its resources. A vendor that doesn't
currently support ASM isn't going anywhere so that's a moot point.

And the question of Bidir vs SSM can't be determined until we get
a better understanding of the application space. Remember we once
thought Dense-mode was viable for expanding ring searches, but the
ttl-0 problem with asserts should have cured us of that. (Which
shouldn't be interpreted to mean I don't think the bug shouldn't
be fixed.)

In the olden days, sparse or dense eventually evolved to sparse-dense
and now dense has withered away. there are some arguments that
suggest that if we could develop a way of determining where to locate
a bidir RP (remember its virtual so is just a subnet and not a real
box) that SSM won't be required, so -only- bidir should be developed.
That would mean IGMPv3 wouldn't be required.

Perhaps we should be figuring out where to locate the RP and
deny such a thing as a source-only group member. Now the debate
might become even easier. Bidir everywhere.

z

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

[Kevin C. Almeroth]

Post by Leonard Giuliano
-) Now consider SSM. Every host in the network now has the ability to kill
-) every SSM multicast router in the Internet by sending IGMPv3 joins to every
-) possible (S,G) combination. This causes every multicast router in the
-) Internet to create so much bogus (S,G) state that it croaks. "On, but we
How is this any worse than sending IGMPv2 joins for every possible G? I
supposed they only go toward the RP, but they still consume memory on
every router along the way. Or I could create the same attack by running
pimd on a host and flooding a bunch of (S,G) pim joins. My point is that
all the vulnerabilities of SSM are present in ASM. The converse is not
true; ASM has far more vulnerabilities attributed to network based source
discovery.

And vendors, in the same way they provide cache control mechanisms for MSDP,
ought to provide control for forwarding state.

A downstream network with an offending user should result in a router
dropping PIM state (and possibly messages from) the offending network.

And not long behind this should be multicast-capable firewalls that not
only punch holes for acceptable UDP traffic but also monitor and possibly
filter control and group traffic... another one of those should-haves from
many moons ago.

-Kevin

[Dino Farinacci]

Post by Kevin C. Almeroth
A downstream network with an offending user should result in a router
dropping PIM state (and possibly messages from) the offending network.

If you can define an offending user (very specifically), I'll be glad to
code it up.

How about drop all multicast traffic that doesn't have ESP as the protocol
number in the IPv6/IPv6 header?

Dino

[Dino Farinacci]

Post by Dino Farinacci
How about drop all multicast traffic that doesn't have ESP as the protocol
number in the IPv6/IPv6 header?

Typo, first occurence replace of IPv6 with IPv4.

Dino