Re: [magma] WG Last Call: draft-ietf-magma-msnip-03.txt

[Pekka Savola <[e-mail]>]

Hi,

On Tue, 17 Jun 2003, Isidor Kouvelas wrote:
> Thanks for the comments and sorry for the delay. I am working on a
> hopefully final version of the draft. I am including answers to your
> remaining comments inline.

I'll include the comments which seemed a bit controversial/unclear yet in 
the reply.

Thanks.

> >     implementation may allow a special "unspecified" value to be passed
> >     as the source-address parameter, in which case the request would
> >     apply to the "primary" IP address of the "primary" or "default"
> >     interface of the system (perhaps established by system
> >     configuration).
> >
> >==> I think this needs to be either taken off from here as an appendix, a
> >paragraph with disclaimers, or pursued further (e.g. by specifying the
> >actual special value etc.) -- so that is actually usable for people who
> >try to create cross-platform applications!
> 
> Just like the IGMPv3 specification, the MSNIP draft does not define
> the API. Maybe we need a companion document (like msfapi for IGMPv3)?

I think the API work is critical if MSNIP is to be of any use.  MSNIP is 
useless without it.

> >3.1.  Application Operation
> >
> >     Applications wishing to use MSNIP to control their multicast data
> >transmission to destination G from source address S operate as follows.
> >
> >     Initially the application contacts the IP system to obtain the
> >socket handle for use on all subsequent interactions. The application
> >invokes IPMulticastSourceRegister for the desired S and G and then waits
> >without transmitting any packets for the IP system to notify that
> >receivers for the session exist.
> >
> >==> UH-OH!  Seems like a potential issue here: what if MSNIP-enabled hosts 
> >are deployed in a network where MSNIP routers aren't present -- at least 
> >with v6, you're in deep trouble, it seems.
> 
> As is explained in the draft, in the absence of routers an MSNIP
> capable application is immediately notified by the host IP stack to
> transmit thus preserving backward compatibility.

But do they get a _negative_ acknowledgements quickly, also?  Positive 
acks are of course OK, but I fear negative acks could be practically 
blackholed, leading to a very delayed transmit..

> >     If and when the IP system notifies the application that receivers
> >exist using the IPMulticastSourceStart call
> >
> >==> I'm having a lot of difficulties imagining how IP system would _in 
> >practise_ notify the application with such a call.  Please elaborate?
> >(In hindsight, when reviewing the comments after the read-through, it 
> >seems the intention of the calls is to say that it creates some loop 
> >through which the app receives the specific MSNIP packets -- but this is 
> >not properly defined.)
> 
> Again concerte API is not specified in the draft.

It really, really needs to be specified: whether here or elsewhere, but I
see very little use in it otherwise (same argument might go for one reason
why IGMPv3 hasn't taken off)

> >==> the SSM thing is an important design decision, IMO.  The critical 
> >point is, have we abstracted the multicast API enough so that applications 
> >will not need special support or use of different API to send SSM 
> >multicast.  If there is a difference, and that is the intended goal, MSNIP 
> >model should really be that it only accepts SSM destinations.
> 
> The point is that the mechanism requires the host to be aware of the
> SSM range but not the application. Applications registering for
> notification for a non-SSM address are simply notified to transmit.

I see the point: but my point is that SSM from app perspective seems like 
a completely different jungle than ASM.  You may not be able to code the 
app which just uses multicast through an interface, and depending on which 
group address is used, uses either ASM or SSM.  There are some fundamental 
differences in these models.

Ie. I think any app must know *before even trying to transmit* that the 
address is SSM or ASM -- and thus automatic response for ASM seems a bit 
redundant..
 
> >==> so, this requires host operating systems implementing MSNIP to be 
> >aware of SSM range.  Is that OK, or should the requirement be pushed back 
> >to the first-hop router?  (IMO, it's OK at least if we assume the SSM 
> >range will be *very* consistent and won't change (e.g. add new blocks) in 
> >a 3-5 year timespan.)
> 
> The configuration of the SSM range does take place on the routers.
> Communication of the range from the routers to the hosts is achieved
> using the multicast router discovery SSM range option (see
> draft-ietf-magma-mrdssm).

A questionable choice (should be some static values if we need those;  
dynamic range signalling is way too complex for the gain it gives you),
but that's a different topic.
 
> >     Receiver Membership Report messages are used by routers to
> >communicate the receiver membership status of particular multicast
> >destination addresses to a specific IP system. Each message contains a
> >list of transmission control records of either TRANSMIT or HOLD type
> >that instruct a system to respectively start or stop sending traffic on
> >this link to the specified multicast destination address.
> >
> >==> this section was not updated for SSM-only operation, it seems.
> 
> Not sure what this means.

Sorry, there was typo in above.  I meant "updated from".  My point seemed 
to be that the paragraph was SSM-specific.

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



_______________________________________________
magma mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/magma