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

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 17 Jun 2003 17:01:45 -0700

Pekka,

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.

thanks
Isidor

Pekka Savola writes:
>On Tue, 8 Apr 2003, Brian Haberman wrote:
>> All,
>>       This is the start of a one week working group last call on:
>> 
>>          Title     : Multicast Source Notification of Interest Protocol
>>                            (MSNIP)
>> 	Author(s) : B. Fenner et al.
>> 	Filename  : draft-ietf-magma-msnip-03.txt,.ps
>> 	Pages     : 26
>> 	Date      : 2003-4-3
>> 
>> This short last call is to ensure consensus on the changes made
>> during the previous last call.  Substantive comments should be
>> sent to the mailing list.  Editorial comments can be sent to the
>> authors.
>
>The changes seem ok to me.
>
>In my comments earlier, there were some issues I raised for which I have 
>not seen a clear answer to.  I don't think all need to covered in the 
>draft, but at least some reasoning why not to do so might be nice -- so 
>the wg would know.
>
>Below, I've removed those comments which seemed to be clearly addressed in 
>the revision.
>
>====
>Substantial:
>------------
>==> considering the big picture, it seems to me that the SSM range options 
>for v4 causes quite bit of special casing.  If so, one could consider 
>removing it to a separate spec and sticking to 232/8 + IPv6 only here.

The definition of the SSM range has been moved to a separate document
a while back (draft-ietf-magma-mrdssm). What remains in the MSNIP spec
has been significantly simplified by the decision to revert to
flooding in the absence of routers. I think that the current text is
fairly well contained.

>==> also, as a lot of stuff in the MSNIP protocol seem to look like
>MLDv2/IGMPv3 messages (robustness, holdtimes, similar messaging, etc.) I
>kept wondering whether this could/should be specifying as an IGMPv3/MLDv2 
>extension, not as a separate protocol.

Well as stated in the abstract it is an IGMP / MLD extension :-)

>==> as a general note, somehow I kept missing the "processing of X" 
>descriptions (beginning from validation of messages), like with RFC2461.  
>The information seemed to scattered over the spec at the moment.

Will add validation text in the packet format section.

>                                                               An
>     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)?

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

>     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 is desirable for applications within an IP system that supports
>MSNIP to have a consistent service interface for multicast transmission
>that does require the application to be aware of the SSM address range.
>MSNIP supports this by allowing applications to use the service   
>interface described in section 3 for multicast destination addresses  
>that are outside its operating range. When an application registers for
>notifications for a destination address that is not managed by MSNIP it
>is immediately notified to start transmitting.
>
>==> the first sentence seems to be out of sync with the rest of I'm
>misunderstanding.  I took the first sentence to mean that apps must be
>aware of the SSM address range (IMO, seems like a bad design choice if
>so!), but the rest would seem to imply that it is not the case -- quite 
>the opposite: the implementation would provide an "emulation layer".

This has already been fixed in the current ID.

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

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

>If even one multicast router on a link does not have MSNIP capability
>then ALL routers on that link MUST be configured to not provide MSNIP
>services and to not advertise the MSNIP Operation option.
>
>==> Ok, is it ok to put it like this or should there be some automatic 
>fallback?  If manual config is necessary, I believe there will have to be 
>some "Operational Considerations" section summarizing these issues.

This behaviour is similar to that of IGMP where configuring all
routers on a link to operate the same version of the protocol is the
job of the administrator.

>4.2.  Communicating Range to Source Systems
>
>==> One should maybe clarify that this whole section (and subsequent 
>complexity) only seems to affect IPv4 MSNIP, but some text seems to be 
>like applicable to both.  What's the deal?

It has been clarified in current ID.

>     All MSNIP capable routers that receive an Interest Solicitation
>message from an IP system, maintain a system interest record of the
>form:
>
>     (IP system address, holdtime timer)
>
>==> this could get real tricky if IP system address is a limited scope 
>IPv6 address :-).  Yet again something for the scoped address architecture 
>:-)
>
> 0                   1                   2                   3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|     Type      |   Reserved    |           Checksum            |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>|           Holdtime            |
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>Type The type field is set to XX (to be assigned by IANA as an IGMP type
>     for IPv4 and an ICMPv6 type for IPv6).
>
>
>Reserved
>     Transmitted as zero. Ignored upon receipt.
>
==> why not just specify "Code" rather than Reserved, with code being
>zero?  To do otherwise might be out of sync with RFC2463 which states
>e.g.:
>
>--8<--
>   The ICMPv6 messages have the following general format:
>
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Type      |     Code      |          Checksum             |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                                                               |
>      +                         Message Body                          +
>--8<--
>
>==> this issue is even worse in Receiver Membership Report messages!

MLDv2 Report packets already use "reserved". In any case the field is
specific to the message type.

>11.  Inter-operation with IGMP / MLD Proxying
>
>==> this section needs to be much more clear on whether the text is 
>proposing modifications to IGMP/MLD proxying to cope with MSNIP, or giving 
>some informational guidance.  In addition, it would be good to specify, 
>*up front* what happens if you deploy MSNIP host and a router in a network 
>where there is an IGMP/MLD proxy between them (with *no* MSNIP support).  
>This is bound to happen, and often! --> this is stuff for the operational 
>considerations section.

Has been addressed.

>Semi/Editorial:
>---------------
>
>IP system wishing to source multicast data can register to be notified
>when receivers join and leave the session. This enables multicast
>sources to avoid the work of transmitting packets onto their first-hop
>
>==> to be more specific, MSNIP provides a notification of two events:
>1) the first receiver has joined the session
>2) the last receiver has left the session
>
>Right?  The language above is not unambiguous; what's at the start of
>section 5 seems better.
>
>     Information on which multicast destination addresses have receivers
>for a particular sender is typically available to the multicast routing
>protocol on the first hop router for a source. MSNIP uses this
>information to notify the application in the sending system of when it
>should start or stop transmitting. This is achieved without any
>destination address specific state on the first-hop router for potential
>sources without receivers.
>
>==> You should mention "SSM-only" earlier, around this paragraph at the
>latest.  Otherwise, people start wondering (like I did), "hey, this is 
>never going to work, DR's don't know enough about the multicast routing 
>system".  No long explanations are needed just, just a short pointer like 
>that. 
>
>destination. The IPMulticastsSourceDeregister call should be implicit in
>
>==> s/should/should also/ (underline the fact) -- note, I believe in over 
>95% of cases apps don't do Deregister, just tear down the session.
>
>     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.

>8.2.  Receiver Membership Report Packet
>
>==> this section is a bit v4 specific, but the intent seems 
>understandable.
>
> cause them to transmit Receiver Membership Reports messages for any
>  multicast destination addresses with receivers for the target host.
>
>==> s/addresses/address/
>==> perhaps not updated for SSM-only?
>
>o The new MSNIP Operation option for the Neighbour Discovery / ICMPv6
>  protocol. This option requires a new NDP / ICMPv6 type value to be
>  assigned by IANA.
>
>==> An informational value, to be exact, of course.
>
>Editorial:
>----------
>                                Abstract
>
>
>     This document discusses the Multicast Source Interest
>     Notification Protocol (MSNIP).  MSNIP is an extension to
>
>==> abstract indentation etc. is not in line with typical policies; the 
>same goes with the text indentation:
>
>     The Multicast Source Notification of Interest Protocol (MSNIP) is
>an extension to version 3 of the Internet Group Membership Protocol
>[...]
>
>subset of the address space that is used by source-specific multicast
>(SSM) [10]. As described in section 2 MSNIP only tries to control 
>
>==> move/add the reference to the first mention of SSM, currently in 
>section 2.
>==> s/section 2/section 2,/
>
>address equal to the source address. If the source destination pair
>satisfy these conditions then [Robustness Variable] Receiver Membership
>
>==> s|source dest|source/dest| (or something.. :-)
>
>-- 
>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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/magma
>

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

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 17 Jun 2003 17:01:45 -0700

Pekka,

thanks
Isidor

Has been addressed.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jun 2003 09:21:54 +0300 (EEST)

Hi,

> remaining comments inline.

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

Thanks.

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

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

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

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jun 2003 09:21:54 +0300 (EEST)

Hi,

Thanks.

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 17 Jun 2003 23:55:48 -0700

>I think the API work is critical if MSNIP is to be of any use.  MSNIP is 

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

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

>address is SSM or ASM -- and thus automatic response for ASM seems a bit 

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.

---

From: Isidor Kouvelas <[email-masked]>
Date: Tue, 17 Jun 2003 23:55:48 -0700

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jun 2003 10:38:18 +0300 (EEST)

> acknoledgement? What is positive and what is negative?

Sorry, I was confused about the model.

The model seems to be, put another way:

"If MSNIP Operation has been detected (e.g. by IPv6 router 
advertisements), the hosts know that MSNIP is supported.  If no MSNIP 
Operation has been detected, the hosts know that MSNIP is not supported 
and can notify the apps to start transmitting"

.. ie. when there is no sign of MSNIP support, the hosts don't try to 
"probe" the support from routers explicitly (which might be causing 
timeouts and delays I was referring to).

> know anything about MSNIP for this to happen.

Yep.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jun 2003 10:38:18 +0300 (EEST)

Yep.