Subject: Re: [MBONED] WGLC for <draft-ietf-mboned-ipv4-uni-based-mcast-04.txt>

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2008 07:57:06 +0200 (EET)

On Wed, 12 Dec 2007, Toerless Eckert wrote:
> 1. Use SSM
>
>   When applied to the global internet, it proliferates the choice of ASM multicast
>   that in my understanding has been recognized to be no long term IETF preferred
>   choice (based on the status of MSDP necessary to support it). All the applications
>   for global address space that i have seen would better be served with SSM too
>   anyhow, so i i will claim that i have not seen sufficient justification
>   (requirements) for what the draft claims to provide a solution for.

The proof is in the pudding, they say.  If SSM provides better and 
easier mechanisms to deploy some applications, it's going to be used. 
Preventing those that don't see SSM as an option at this point from 
using this approach does not seem very productive to me.

> 2. Do not allocate global addresses for private scoped address use.
>
>   The overwhelming mayority of addressing AFAIK is requested for content distribution
>   in private peerings, never to be handed to the global Internet. Like all the
>   market data or TV providers that i had the unpleasant experience trying to keep
>   as happy customers while still explaining why i hate the allocation of of more
>   Internet scope ASM addresses ;-)
>
>   I would thus propose to redesignate this draft not for allocation of
>   addresses for the global I, but for an IP multicast version of ULAs like
>   existng for IPv6 in unicast (Unique Local Address, rfc4193), aka: define
>   that this additional ASM address space is an extension of administrative
>   scoped multicast addresses that just are globally unique, but that will not
>   be routed across the bit I.

I don't see this suggestion being productive.

However, I don't see that there is anything stopping from creating yet 
another, similar address space that's meant to be used for the purpose 
you suggest (e.g., under the lower bits of 239/8).  But that should be 
a separate proposal (can you write a draft about it?), not requirement 
to change an existing one.

> 3. Consider hard coding of address issue
>
>   Unless we come up with a better way for lame application developers, we
>   will see these addresses hardcoded into applications purely for ease of service
>   discovery. I would like to avoid that as much as possible, because within
>   the context of this draft that constitutes an extreme abuse (you never own
>   unicast adress space forever, so you can't hardcode anything derived from it
>   into applications).

I don't see these addresses being hardcoded (that much) into 
applications, because the app developers don't know which IP addresses 
they end up being used at (but rather being used by enterprises to 
assign addresses to the apps they use).

In this manner I see this as a potentially decreasing the amount of 
applications that use hard-coded addresses, not the opposite.

The app developer could of course use its own organization's IP prefix 
(if it has a sufficiently large IP assignment and expects it to be 
stable) to deploy the hardcoded application to other domains, but this 
is (AFAICS) just fine.  The same is already available with GLOP 
addresses in any case.

>   In any case, it might be useful to consider an actual IANA policy to
>   specifically assign such to-be-hard-burned addresses, also from this ULA
>   space (as none of these resource discovery mechanisms will or should run
>   across the global internet). One cOuld easily use some subrange of
>   <ULAbyte>.[224...255].X.Y. As we obviously can only assign [1...223]
>   with a unicast allocation derived scheme. And by making an IANA
>   assignment with somemandatory informational RFC to specify what application/protocol
>   is used there we will at least get documentation for such hard coded addresses,
>   and by mean of being ULA, we can relax the architectural constraints

An interesting suggestion, please write it up and let's consider it on 
its own merits.. instead of tying it to the fate of this allocation 
mechanism.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
MBONED mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mboned

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2008 07:57:06 +0200 (EET)

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 21 Jan 2008 22:20:46 -0800

Thanks for replying.

Inline.

> using this approach does not seem very productive to me.

Drafting RFCs to help users easier repeat mistakes of the past easier does
not seem to be helpfull to me either. If successfull across the internet,
this draft/RFC would proliferate theuse of MSDP and thus cause exactly
what i thought we concluded in the IETF not to be of benefit.

And if not targeted for the internet, as i think some other folks on this
working group agreed to also, then there is no need to delegate this
scheme to global scope, internet routed addresses, right ?
> I don't see this suggestion being productive.

Please explain.

> to change an existing one.

I disagree. It has been obvious from the adoption of technology in the
indusry, that if given the choice, the path of initial least resistance
is choosen, easilyleading into dead-ends.

> applications that use hard-coded addresses, not the opposite.

If a particular application/solution developer (including a financial
service provider) can get hold of globally unique addresses, why again
would the individual user/receiver of such product/services wantor need
to reassign addresses ? I can't follow that logic. These addresses
explicitly do provide for product/service poviders to hard-code
addresses and not ave thier customers worry about those because they
ae globally unique. 

> is (AFAICS) just fine.  The same is already available with GLOP 

Sure. see above about global Internet interdomain ASM/MSDP.

> its own merits.. instead of tying it to the fate of this allocation 

Again, the problem is foremost to avoid creating an RFC/IANA assignment
that proliferates and eases a use ofinterdomain PIM-SM/MSDP,and is
draft right now can easily cvause this unless a change in wording
of intended use and semantic of these adresses makes it clear that
they are notmeant to be used across the globalinternet, but at best only
across closed-user-group setups.

Seriously: How can the IETF release as likely standards-track an
addressing method to ease the use of an address space (global scope ASM),
for which the IETF has so far concluded there is no viable scalable
protocol model ???

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 21 Jan 2008 22:20:46 -0800

Thanks for replying.

Inline.

Please explain.

Cheers
    Toerless

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jan 2008 11:00:30 +0000

Hi,

When I read this discussion, I'm reminded of similar ones between IPv4
and IPv6.   To many people, IPv6 is the future, and inevitable, and working 
on things to keep IPv4 propped up seems time better spent elsewhere.
Yet of course IPv4 is here for a long time.

While SSM may be the better solution in many people's eyes, the reality
is that not all vendors are interested in supporting it, and deployment
obstacles remain.   In the meantime there are sites that would like to
offer global scope multicast content that are having difficulty doing so
due to the existing lack of alternatives to GLOP.

It's all very well to try to block this draft on a point of principle, 
but the reality is that there are issues deploying SSM today, and in getting
globally scoped group addresses for ASM.

I would in fact probably argue that in order to give multicast a foot up
in general, getting initial services running with ASM, until SSM is ready,
could potentially be very useful.

In my own context, UK universities are one such community who would 
benefit from this proposal.   You have several hundred sites for whom 
address space is available from only one ASN.    Dave's proposal puts the
address alolcation and managementin the hands of the end site (just as IPv6
multicast does).

And I would echo Pekka's request to extend the 'experiment' to 3 or 5 years 
initially.

Tim

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jan 2008 11:00:30 +0000

Hi,

Tim

-- 
Tim

---

From: Dave Price <[email-masked]>
Date: Tue, 22 Jan 2008 11:20:36 +0000

Dear Tim and All,

[email-masked] said:
>  but the reality is that there are issues deploying SSM today, and in
> getting globally scoped group addresses for ASM.

> I would in fact probably argue that in order to give multicast a foot
> up in general, getting initial services running with ASM, until SSM is
> ready, could potentially be very useful.

I've been quietly reading all the emails going
past on this issue.   I too can see the "point of principle",
but I, like Tim and others, really do think we need
something that will work in the short to medium
term for ASM.

I have been in several situations where either "users" or
"students" have asked about the "choice of address" issue
and its really hard to offer answers that work in reality today.

Tim notes...

[email-masked] said:
> address space is available from only one ASN.    Dave's proposal puts
> the address alolcation and managementin the hands of the end site
> (just as IPv6 multicast does).

I too am part of this community and have authored some
guides for users/managers on multicast and the "choosing an address"
issue has been hardest thing to write about when
people actually want a hard pragmatic answer that works...

I think we need to go with the proposal.

Dave Price
-- 
Dave Price, 
Email: [email-masked] PHONE: +44 1970 622428 FAX: +44 1970 628536
Post: Computer Science, Aberystwyth University,
      Penglais, Aberystwyth, WALES, UK, SY23 3DB.

---

From: Dave Price <[email-masked]>
Date: Tue, 22 Jan 2008 11:20:36 +0000

Dear Tim and All,

Tim notes...

Dave Price

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2008 13:35:37 +0200 (EET)

> scheme to global scope, internet routed addresses, right ?

I suspect that the majority of uses for this address space is likely 
going to be in inter-domain scenarios where "inter-domain" does not 
include the whole Internet (e.g., it could be from a national 
broadcaster to all the multicast-enabled ISPs in the country).  So 
it's going to be propagated in MSDP, though not necessarily in "whole 
Internet" MSDP.

I don't see this making the current status quo significantly worse but 
it still makes addressing and multicast deployment easier especially 
in inter-domain scopes that don't necessarily require "whole Internet" 
propagation.  So it's a win-win approach.

[...]
>> I don't see this suggestion being productive.

I understood that you believe 1) this approach is actively harmful and 
thought that 2) an alternative approach, with tight local scoping, 
should be done instead.

Your suggestion was to morph the proposal significantly so that it 
could no longer be used except under some form of local scoping.

I would like to separate issues 1) and 2) so the WG can get rough 
consensus on them separately.  A rough consensus can be obtained 
without any new draft for 1) but a draft is needed if 2) is to be 
progress.

> for which the IETF has so far concluded there is no viable scalable

The addressing model takes no stance on whether the addresses are used 
inside an enterprise, in inter-domain MSDP setups between consenting 
enterprises, or in global Internet MSDP.

Even if the draft could rule out the last item, any prohibition would 
be unimplementable and unenforceable -- I don't see how an 
implementation could make a difference between a "consenting 
enterprises" and "global internet" MSDP policies.  So it's easier to 
not try to tackle this at all.

So at most we the draft could have an applicability statement stating 
that its use in Internet-wide setting is possibly not scalable, or to 
include some text about this in draft-ietf-mboned-addrarch 
(suggestions welcome).

---

From: Pekka Savola <[email-masked]>
Date: Tue, 22 Jan 2008 13:35:37 +0200 (EET)

[...]

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 04:51:39 -0800

> something that will work in the short to medium

Can you two be a little more specific. Are you saying the network  
layer or multicast protocols need to do more (or less) and if so, what  
do you think they need to do.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 04:51:39 -0800

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Jan 2008 06:42:42 -0800

> globally scoped group addresses for ASM.

I by the way was not intending to "block" this draft but rather propose
a change in wording and semantic of the address assignment. Aka: Let's
just define for multicast group adresses that space to be "ULA". Meaning
you can do everything with them that should factually work well,
like using them within your enterprise or across well managed
private peerings or scoped deployments such as a typical (financial)
service provider and their customers, but just not "across the global
internet", because as soon as we claim these adresses to be usable across
the global Internet, we immediately cause an increase in the MSDP 
problem, which we can not solve.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Jan 2008 06:42:42 -0800

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Jan 2008 06:59:39 -0800

> something that will work in the short to medium

When we did SSM in 2000, even the pessimists like Dave thought
it might take 5 years for SSM to get adopted. 

Improving now the ease to load up the global Internet with more ASM
state and it's MSDP management issues and unresolvable group security
issues, is just fully giving up on using the IETF as a corrective instrument 
to set future proof directions, and has us fall back to just leverage the
IETF to do what serves our short term business interests best.
Like drilling for oil in in the arctic wildlife refuge. 

I mean business wise i love it. The more people will use ASM across
the Internet, the more we can sell of our multicast access control
features in our routers and multicast with IPsec, yada yada, just
to get around the intrinsic security issue of ASM. And the job
security in explaining to folks how to use all that stuff ;-P

Heck, let's just distribute ASM multicast access control policies
(permitted sources) for the new group-ranges across the Internet via new
BGP extensions. We could for example by default have the group
prefixes only have valid sources from the AS owning the prefix, and
then override this with new BGP announcements that define additional
or fewer allowed sources for the group range. And utilize again the
implied asociation of owner-AS of BGP announcer with authorizing the
announcement.

All the fun of layering even ore complexity on top of this to
start making it secure. Not to speak of the redesigning MSDP to scale
to all this perceived need. Isn't that great job security ? I just
wonder who has the cycles to do all this  but was not capable to
kick some folks to simply have their host stacks and apps use SSM.

I quite frankly don't think that all this is needed, because i think
ultimatly the primary users will not go across the Internet but rather more
acces contstrained peerings/etc as well as hard-burned into applications
that are instantiated within enterprises. That's why i am saying let's
really designate the address space to that purpose so we can fully avoid
even to tap into the Internet scope related security and scalabilty
issues.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 22 Jan 2008 06:59:39 -0800

Cheers
    Toerless

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jan 2008 15:05:10 +0000

> do you think they need to do.

I can't speak for Dave, but in my view its 

a) global scope group addresses for end sites to use.   This is problematic
   today for certain scenarios.   But obviously I can only speak with the
   knowledge of the community I'm in (from various BoFs etc we have had).

b) tools to allow applications to determine available addresses within
   the site.   This arises from researchers and students writing (often 
   but not always IPv6) multicast applications.    There's madcap but...

I think the draft answers a) sufficently well for the short to medium
term (beyond which SSM will maybe get more uptake), while b) is a topic
I raised at IETF69(?) and on which I think there was a new draft posted 
quite recently.

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jan 2008 15:05:10 +0000

-- 
Tim

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 07:39:19 -0800

>   knowledge of the community I'm in (from various BoFs etc we have  

Why isn't GLOP address allocation sufficient?

>   but not always IPv6) multicast applications.    There's madcap  

This draft solves that, no?

> I raised at IETF69(?) and on which I think there was a new draft  

So when we get past this, there should be no issues? That is, will the  
excuses for deploying  multicast go away?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 07:39:19 -0800

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 22 Jan 2008 10:57:05 -0500

On Jan 22, 2008, at 10:39 AM, Dino Farinacci wrote:

>>>>> up in general, getting initial services running with ASM, until  
>>>>> SSM
>>>>> is

A decent proportion of the Multicast address assignment requests IANA  
gets is from organizations that have used
up their GLOP space.

Regards
Marshall

> So when we get past this, there should be no issues? That is, will  
> the excuses for deploying  multicast go away?
>
> Dino
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 22 Jan 2008 10:57:05 -0500

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 08:03:11 -0800

> A decent proportion of the Multicast address assignment requests  
> IANA gets is from organizations that have used
> up their GLOP space.

Then they can get another AS to get more multicast address space.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 08:03:11 -0800

Dino

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jan 2008 16:15:15 +0000

> Why isn't GLOP address allocation sufficient?

In the scenario we're in (which may or may not be common in national
research and education networks) the provider (NREN) has an ASN but the
regional networks and end sites invariably do not.   So we can only get
a GLOP allocation from the NREN.   Between a few hundred universities
and thousands of colleges connected to that NREN, a GLOP block doesn't
go far, especially when the NREN itself may wish to 'reserve' addresses
for its own future use (quite reasonably).

In reality there's maybe 100 sites in that NREN's scope that have an
old style Class B allocation for whom the proposal would give up to 256
global scope group addresses.

But the proposal also allows the site to manage it's allocations.  It
doesn't have to go back to the NREN to acquire more, or to perhaps annually
justify what it has been allocated and what it's actually using.

> This draft solves that, no?

Sorry, what I meant was ways for applications to get a group address for
short or long term usage, if one isn't administratively allocated and
manually configured.    We're seeing some interest in this on the IPv6
side (e.g. for p2p file sharing applications).
 
> excuses for deploying  multicast go away?

Well no, but as Dave Price said address allocation issues are perhaps the
thorniest ones in writing HowTo's for our community.    My own view is
(as an enterprise person) the enterprise one.    

I agree that using SSM would be preferred, but we see practical issues today,
since as firewall and host OS support issues, that make that challenging
(both for IPv4 and IPv6 SSM).

I certainly appreciate the concerns over MSDP.   I would be interested to
hear more precise concerns on scalability issues, wrt number of peerings and
volumes of groups, but one could say that today in theory 10,000 ASNs are
out there and that could be a LOT of global scope groups.    While this 
proposal increases the potential number of groups in use, it's not clear
how much bigger the 'risk' gets.   

But yes SSM ought to be the end game :)

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Tue, 22 Jan 2008 16:15:15 +0000

-- 
Tim

---

From: Stig Venaas <[email-masked]>
Date: Tue, 22 Jan 2008 21:00:30 +0100

[...]

As I see it the people using ASM today would prefer to use SSM if they
could, but there are several obstacles. Perhaps we should rather focus
on those? Even with the unicast based addresses there are still many
advantages with SSM, I don't see that as a reason not to move to SSM.

As I see it, the unicast based addresses simply means that they have a
better and more structured way to choose what addresses to use and ease
management a bit. I can see why you would not do any significant
protocol effort to improve ASM, but this is a simple mechanism requiring
no code changes to make life easier while waiting for SSM.

The main obstacles for deploying SSM are application support, MacOS X
support and IGMPv3 snooping support. Things are slowly getting better...

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 22 Jan 2008 21:00:30 +0100

[...]

Stig

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 22 Jan 2008 16:46:30 -0500

> -----Original Message-----
> From: Stig Venaas [mailto:[email-masked]] 

> on those?

I've seen this said many times, but I'm not sure how to interpret it.

Do you mean, those now implementing ASM would prefer to use
IGMPv3/MLDv2, filtering on (*,G), or do you mean that everyone wants to
be filtering on the source address too?

My experience is that ASM is what serves some purposes best, and that's
why customers often prefer to specify IGMPv1/v2 or MLDv1. It's simpler,
it's deployed (at least the IGMP versions of ASM), and it does exactly
what is needed.

> Even with the unicast based addresses there are still many

I don't have a case for global scope ASM, so maybe my comments are "who
cares." In general, I would hate to see ASM disappear, because no one
spoke up for it.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 22 Jan 2008 16:46:30 -0500

Bert

---

From: John Zwiebel <[email-masked]>
Date: Tue, 22 Jan 2008 14:35:26 -0800

> cares." In general, I would hate to see ASM disappear, because no one

It has been my experience that the reason to ASM is to discover the  
source.
Source discovery should be moved out of the PIM protocol.
With just SSM and bidir, there is a huge win in getting rid of data  
driven
events.  No PIM registers, no asserts, no worries on the last-hop about
switching to the shortest-path.

But all these wins are in the network itself.  If you don't have a  
topology
that has asserts or you don't have high volumes of multicast, you  
probably
wouldn't notice.

I see you're from boeing, just don't put any ASM into your instrument  
controls.
;-)

---

From: John Zwiebel <[email-masked]>
Date: Tue, 22 Jan 2008 14:35:26 -0800

---

From: Stig Venaas <[email-masked]>
Date: Tue, 22 Jan 2008 23:53:51 +0100

> it's deployed (at least the IGMP versions of ASM), and it does exactly

The one unique thing where ASM is needed IMO is service discovery,
autoconfiguration etc. Cases where you need some multicast address or
perhaps anycast for bootstrapping... But this isn't something you would
do on the Internet, just inside a site or an organisation.

In other cases I think you can do source discovery at the application
layer and use SSM. Of course there is lots of complexity in doing it
in the application as well, but I think that is a better approach.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Tue, 22 Jan 2008 23:53:51 +0100

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 16:41:25 -0800

> for its own future use (quite reasonably).

But you can go get an ASN and not use it for BGP purpose but do use it  
for GLOP addressing. Then you decouple yourself from your upstream  
provider.

> justify what it has been allocated and what it's actually using.

Right, so does GLOP if you just go apply for an ASN.

> (both for IPv4 and IPv6 SSM).

How about this as a proposal to solve all your problems:

1) Go get an ASN and use GLOP group addresses.
2) Each GLOP group address maps to a (S,G) pair where G is the GLOP  
address.
3) Put SSM translation on the last-hop routers directly connected to all
    potential receivers so when an IGMPv2 report comes to them with a  
GLOP
    address, the router does a (S,G) PIM join.

So you run SSM in your site which extends to inter-domain SSM usage.  
This code is most likely in your routers today. You can do this with  
uni-based-mcast addresses as well.

So any other issues? Can we now move forward? Can we document this in  
the HowTo guide and move on?

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 22 Jan 2008 16:41:25 -0800

Dino

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 22 Jan 2008 20:58:56 -0500

Dino;

On Jan 22, 2008, at 7:41 PM, Dino Farinacci wrote:

> But you can go get an ASN and not use it for BGP purpose but do use  
> it for GLOP addressing. Then you decouple yourself from your  
> upstream provider.
>

I think that there is a big problem with this suggestion :

Soon, 16 bit ASN will become unavailable. (January, 2009, the RIRs  
will only give them out by request,
January 2010, they will not distinguish between the 16 and 32 bit  
pools, which means in practice you
will get a 32 bit one.)

There is no GLOP space for 32 bit ASN. We are working on a I-D to  
address this, but it is not there yet.

(There are other problems, but this is a big one.)

Marshall

>    potential receivers so when an IGMPv2 report comes to them with  
> a GLOP
> So you run SSM in your site which extends to inter-domain SSM  
> usage. This code is most likely in your routers today. You can do  
> this with uni-based-mcast addresses as well.
>
> So any other issues? Can we now move forward? Can we document this  
> in the HowTo guide and move on?
>
> Dino
>
>
>

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 22 Jan 2008 20:58:56 -0500

Dino;

Marshall

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jan 2008 00:56:25 -0800

> do on the Internet, just inside a site or an organisation.

Hmm.. for service discovery/autoconfiguration ASM is convenient to the
application if then available in the netork, but not necessarily the
best solution or only solution. anycast or dns or lots of other mechanisms can
be used for service discovery etc. as well.

I think the ultimate issue with ASM is still the security from unwanted
sources. Nobody has clearly answered me yet how it can be within the
security requirements of the IETF to do something like ASM across 
a completely untrustworthy scope like the Internet (without creatng
a mandatory spec dependency against a security layer - and just
saying IPsec is not sufficient, because it would only allow
discarding of unwanted traffic due to missing authentication _AFTER_
that traffic has wasted bandwidth to a potentially large number of
receivers).

I guess we never faced this challenge from the IETF, because rfc1112
was never updated ? Like to include a specification that the ASM service
model also applies to IPv6 ? I guess i digress...

I think that most common ASM applications do have a client/server
structure and they should be using a unicast to server, SSM back from
server transmission scheme to allow for better security (as in: server
can easily control sources).

Obviously, ASM is very convenient to applications, so as soon as
the scope is sufficiently well controllable, there's nothing bad
about using ASM. Those scopes are usually structured such that
one can also more easily move to Bidir. Let's call them enterprises.

> in the application as well, but I think that is a better approach.

Somehow i remember a time, let's call it the 80th and early 90th where
most of the protocols and networked applications running on the
Internet where based on reuse of research developed libraries and application
code, freely available. I wonder where that model went for the simple
object of an application layer multicast library that under the hoods
would appropriately choose ASM, SSM, SSM+hub/spoke distribution,
AMT or worst case unicast replication. Strangely enough nobody from
any university ever stepped forward and said they'd be willing to implement
this and put it into some reference app like vlc or the mbone tools.
Shouldn't be a problem to get such a work funded.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 23 Jan 2008 00:56:25 -0800

Cheers
    Toerless

---

From: John Zwiebel <[email-masked]>
Date: Wed, 23 Jan 2008 07:55:39 -0800

On Jan 23, 2008, at 12:56 AM, Toerless Eckert wrote:

>  I wonder where that model went for the simple
> AMT or worst case unicast replication.

There definitely is a PD available AMT, and a VLC that works with it.

http://www.utdallas.edu/~ksarac/amt/vlc/vlc-0.9.0-svn-01-22-08.zip

---

From: John Zwiebel <[email-masked]>
Date: Wed, 23 Jan 2008 07:55:39 -0800

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 23 Jan 2008 11:09:22 -0500

> From: Toerless Eckert [mailto:[email-masked]] 

> Nobody has clearly answered me yet how it can be within the

Probably not across the Internet, I agree.

> one can also more easily move to Bidir. Let's call them enterprises.

Yup. In these cases, it can be more convenient to have the network
filter the allowable source devices, and keep the clients as simple as
possible. It may well be easier to maintain security this way, over
time, as source devices are added or changed, or as mpt-mpt networks of
multifunction consoles (for example) are upgraded.

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 23 Jan 2008 11:09:22 -0500

Bert

---

From: Stig Venaas <[email-masked]>
Date: Wed, 23 Jan 2008 19:26:16 +0100

[...]
> AMT or worst case unicast replication. Strangely enough nobody from

I would really like to see this as well. Isn't that partly what the IRTF
samrg is looking into? Or at least I've been hoping.

> Shouldn't be a problem to get such a work funded.

Someone has implemented something a bit like this, making an ASM
application work with only SSM. On Linux with LD_PRELOAD this could be
done without modifying the binary.

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 23 Jan 2008 19:26:16 +0100

[...]

Stig

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jan 2008 04:55:50 -0800

> address this, but it is not there yet.

Use eGLOP and/or draft-ietf-mboned-ipv6-uni-based_mcast-04.txt.

> (There are other problems, but this is a big one.)

I want to start solving the problems so there are no excuses. But my  
interpretation of all this is that we have solved the problems so why  
are there still obstacles.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jan 2008 04:55:50 -0800

Dino

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Jan 2008 13:43:25 +0000

On Thu, Jan 24, 2008 at 04:55:50AM -0800, Dino Farinacci wrote:
> Use eGLOP ...

So where do I get my eGLOP allocation today?

eGLOP just seems complicated.  Lots of paperwork (initially and presumably 
recurrent), coordination between RIRs (or management by IANA), etc.

This proposal however is simple, comparatively 'elegant', minimises
paperwork, and allows a reasonable allocation size to an enterprise that
has a /16 for unicast.   

> ... and/or draft-ietf-mboned-ipv6-uni-based_mcast-04.txt.

We use that today, for IPv6.   Though in practice embedded-RP is more 
popular on more global scope IPv6 networks because the (now RFC) you 
mention only really works with one pre-configured RP (like in m6bone), 
whereas embedded RP allows any content provider to implictly define the 
RP for the group (usually but not always locally).   So we tend to use
embedded RP group addresses a lot at present, whether scoped locally 
or wider.  (Most of that currently is organisation scope IPv6 IPTV,
but we have services offered externally as well, and we expect external
services to grow as universities become more competitive in offering
material globally.)
 
Having said that, I appreciate multicast is many things to many people,
and demands and requirements will vary.   We're probably not typical.

> are there still obstacles.

We'd like to use SSM.   Vendor shortcomings currently make that somewhat
impractical, for IPv4 and IPv6, at least from the enterprise perspective
we're looking from :(   

Tim

---

From: Tim Chown <[email-masked]>
Date: Thu, 24 Jan 2008 13:43:25 +0000

Tim

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 24 Jan 2008 08:45:24 -0500

> recurrent), coordination between RIRs (or management by IANA), etc.

We expect to have an I-D out in this very shortly. Stay tuned...

Regards
Marshall

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 24 Jan 2008 08:45:24 -0500

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jan 2008 18:21:33 -0800

> recurrent), coordination between RIRs (or management by IANA), etc.

You either get complicated with paperwork or with protocol mechanism.  
We don't need the later or else we go with MASC, MADCAP, or other.

>> ... and/or draft-ietf-mboned-ipv6-uni-based_mcast-04.txt.

Sure, so go with it. My point is there shouldn't be anymore obstacles.

> services to grow as universities become more competitive in offering

Sure, but if you ever want to use Bidir with embedded-RP groups, there  
are going to be major issues. Sender-only branches just don't work  
well, that is, will cause a lot of packet loss.

> impractical, for IPv4 and IPv6, at least from the enterprise  

It would be good to identify them so vendors have specific data to go  
resolve the issues.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 24 Jan 2008 18:21:33 -0800

Dino

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2008 11:57:12 +0000

> We don't need the later or else we go with MASC, MADCAP, or other.

Unless I'm missing something, this proposal has no paperwork, it just
enables group address 'allocations' automatically.
 
> Sure, so go with it. My point is there shouldn't be anymore obstacles.

It would be nice, yes :)
 
> well, that is, will cause a lot of packet loss.

I'd be interested in any references on this.   At the moment we're only
using embedded-rp to source content that ideally could be done with ssm.
 
> It would be good to identify them so vendors have specific data to go  

I thought that naming vendors wasn't 'good form' here.   I think people
using multicast on campus-style networks will know the issues, but
of course everyone's scenarios will differ a bit...

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2008 11:57:12 +0000

It would be nice, yes :)

 

-- 
Tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2008 12:00:04 +0000

> in the application as well, but I think that is a better approach.

I agree that would be nice.   One could look at applications like vic/rat
that are used within AccessGrid to see how the system could use SSM (or
has this already been done?).   

I agree for service discovery you're likely to be working on site or
organisational scope, so the problem is generally constrained.

tim

---

From: Tim Chown <[email-masked]>
Date: Mon, 28 Jan 2008 12:00:04 +0000

tim