[MBONED] SSM migration mechanisms (was: Re: deprecating MSDP)

[Toerless Eckert <[e-mail]>]

[Let me change subject here]

Hitoshi, *:

There is a wide range of mappings to enable SSM forwarding in networks,
implemented by various vendors. IGMP/MLD EXCLUDE G mappings to IGMPv3/MLDv2
INCLUDE (S,G) via manual config or via DNS learned mappings. Likewise
the same thing for PIM (*,G) joins translated to (S,G) joins. Starting
as early as 2004? if i remember correctly.

The reason why i never opted to document any of these mechanisms in the
IETF (beside "there is something more important to do") was always
two fold:

a) These transition solutions do not give you SSM. Calling them SSM
   is a lie in disguise. Oops: great marketing. !!!!!

   You still need to do ASM style multicast group addess management:
   You can not have two uncordinated application receivers randomnly
   choose group addresses and get away with it!!! With SSM, there
   is no need for any multicast group address management/allocation
   to application instances!!!

b) With a) taken into accoun, I thought and still think that these
   are transition mechanisms.  Documentating them would give them
   more credit than i think they should have. Aka: Especially today,
   there is IMHO no reason why any applications should not be able to 
   generate (S,G) memberships.
   
   If someone thinks there is a good reason, let me know!

Now, there are transition mechanisms that do not suffer from a),
namely IGMPv3 lite and URD. These are a class better, but never
catched on as much as the IGMP/PIM SSM mapping mechanisms - because
they did require application developers to do something - as opposed
to hos IGMP/PIM SSM mapping mechanisms, IGMPv3lite and URD where
only meant to get around the limitation of the OS not supporting
IGMPv3/MLDv2. But guess what: the whole reason why SSM has not catched
on as much as it should is LAZY APPLICATION DEVELOPERS and 
LAZY API STANDARDISERS (eg: IGMPv3 support in Java, websockets etc. pp).
And all OSs today support IGMPv3/MLDv2.

So, i would opt against documenting these mechanisms in a way that
would promote them. Besides, there are patents with my name
or other Cisco inventors on these, and given how i do not work for
Cisco anymore, i can not help in getting IPR disclosures from
Cisco.

I would be happy to write up an extended version of above text
for informational purposes describing the mechanisms, and doing
my best to stay factual and not let my opinions trickle in too much
(which i took the freedom to do above). If this is something the WG
would like to see. And maybe get some co-author...

Cheers
    Toerless

On Thu, Jul 27, 2017 at 02:55:35PM +0900, Hitoshi Asaeda wrote:
> Basic question.
> Why we should not have a function/mechanism to translate (*,G) join/leave to (S,G) join/leave?
> All (*,G) join/leave requests with global scope multicast address should be translated to appropriate (S,G) join/leave requests based on ???something???.
> This ???something??? may be a multicast database, a directory system, or some network protocol. If no ???S??? information on this ???something???, routers receiving join/leave just discards the request.
> 
> In fact, one big issue would be the deployment of SSM-aware applications. Recently, IGMPv3/MLDv2 are implemented on major OSes. (It took long years!) How about iOS and Android OS? (Maybe not?)
> Now???s the time to consider SSM-aware applications? (Wait for long years again?)
> 
> Long years ago, I tackled the issue and published a paper, whose title is ???Multicast routers cooperating with channel announcement system???.
> (http://ieeexplore.ieee.org/document/1266120/)
> It is an old paper. And the work was in progress at that moment but I stopped the work as my task was done; however this idea may be still interesting. It introduces various benefits, not only (*,G) to (S,G) translation.
> 
> I???m interested in hearing thoughts about (*,G) to (S,G) translation.
> (Sorry for changing the discussion about ???deprecating MDSP???.)
> 
> Regards,
> 
> Hitoshi