[Mobopts] Re: Review of Draft draft-schmidt-mobopts-mmcastv6-ps-00.txt

Dear Christophe,

many thanks for your review - please find comments inline:

Christophe Jelger wrote:

> I quickly read your draft and here are a few comments. First since I 
> don't know what the "purpose" of the draft is, I would say it's a fair 
> introduction of the problem.
> 
This is the purpose of a problem statement - it is meant to exhaustively
sketch the problem space and give clues on common approaches to solution.

> To be very honest, the content is pretty close to the quite old but 
> still valid "Xylomenos" paper (IEEE Mag, Jan 1997) which basically well 
> summarized the issues of mobility with multicast communications. 

Mhmm - the Xylomenos paper could neither know of MIPv6 nor account for
SSM. But you're right, we will add it to the reference list.

> Thus I 
> would also try to extend the current document with a more in-depth 
> discussion of technical and deployment-related issues.
> 

I'm not sure what you mean by technical ... but there are of course
deployment related issues:

> For example, I personaly think that multicast routing protocols should 
> not be changed (i.e. should remain mobility agnostic) and mobility 
> should be handled at the "edges" (as for Mobile IP). The point here is 
> that current multicast deployment is already quite limited and complex 
> (inter-domain) so injecting more complexity is probably not a good idea 
> (TMHO) and might increase "human resistance" against large-scale 
> deployment of multicast. 

This is definitely true and supposedly there is an unspoken demand for
ease & simplicity in IETF work anyway ...

... however, the trouble with mobile SSM seems the lack of any such
simple, mobility agnostic scheme. At least it is our believe that
mobility awareness of routers is a core issue of the SSM problem.

> Some details:
> - page 4 (top), "multicast communication is asymmetric ..." -> usually 
> assymetry in multicast rather refers to the router/node different 
> behaviors (as in MLD) than the sender/receiver roles

OK - this is a language fix.

> - same page bottom: I haven't followed this recently, but MSNIP can be 
> used by a source to know whether they are receivers or not
> 

MSNIP was intended to inquire on receivers of designated routers, which
is only limited information. However, MSNIP has been terminated a while
ago and people didn't want to revitalise it recently.

Best regards

thomas

_______________________________________________
Mobopts mailing list
Mobopts@irtf.org
https://www1.ietf.org/mailman/listinfo/mobopts