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

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.

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

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

                                                               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!

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.

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

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

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

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

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.

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?

     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!

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.

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.

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
magma@ietf.org
https://www1.ietf.org/mailman/listinfo/magma