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

[Isidor Kouvelas <[e-mail]>]

Pekka Savola writes:
>> >     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.

Agreed that an API spec is an obvious next step. BTW I have heard of
at least one prototype linux implementation (will try to track this
down).

>> >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..

I do not understand your question. What do you refer to as an
acknoledgement? What is positive and what is negative?

>> >     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..

The automatic response is necessary to preserve compatibility for SSM
apps on non MSNIP-capable links. Coupling it with the definition of an
MSNIP-managed address (i.e. an address known to operate in SSM mode +
a router doing MSNIP) seems reasonable. This then provides the above
notification for free.
I guess your comment above means that an app that wants to use ASM
will not even bother to register using MSNIP calls. There is nothing
to prevent such an app to simply start transmitting using the existing
multicast API. If the host is MSNIP capable and the destination
address that the app pics happens to be SSM (MSNIP managed) and there
are no receivers then the IP stack in the host MAY choose to filter
the packets and not send them on the link but the app does not need to
know anything about MSNIP for this to happen.

>> >==> 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