Re: [magma] WG Last Call: draft-ietf-magma-msnip-02.txt
Pekka Savola <pekkas@netcore.fi> Mon, 10 March 2003 22:14 UTC
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16837; Mon, 10 Mar 2003 17:14:06 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMRWO24964; Mon, 10 Mar 2003 17:27:32 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h2AMJ3O24544 for <magma@optimus.ietf.org>; Mon, 10 Mar 2003 17:19:03 -0500
Received: from netcore.fi (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16498 for <magma@ietf.org>; Mon, 10 Mar 2003 17:05:20 -0500 (EST)
Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h2AM7Je29840; Tue, 11 Mar 2003 00:07:20 +0200
Date: Tue, 11 Mar 2003 00:07:19 +0200
From: Pekka Savola <pekkas@netcore.fi>
To: Brian Haberman <bkhabs@nc.rr.com>
cc: MAGMA Mailing List <magma@ietf.org>
Subject: Re: [magma] WG Last Call: draft-ietf-magma-msnip-02.txt
In-Reply-To: <3E67EFFC.3060102@nc.rr.com>
Message-ID: <Pine.LNX.4.44.0303102133590.28795-100000@netcore.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: magma-admin@ietf.org
Errors-To: magma-admin@ietf.org
X-BeenThere: magma@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=unsubscribe>
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>
List-Post: <mailto:magma@ietf.org>
List-Help: <mailto:magma-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/magma>, <mailto:magma-request@ietf.org?subject=subscribe>
On Thu, 6 Mar 2003, Brian Haberman wrote: > This is the start of a working group last call on > draft-ietf-magma-msnip-02.txt as a Proposed Standard. This > last call will be three (3) weeks long and end on 03/28/2003. > Substantive comments should be directed to the mailing list. > Editorial issues should be directed to the authors. Comments below. There are some big issues in the spec still to be sorted out, definitely not IESG material yet. I didn't have time to read the latter part of the spec properly. Beware of quite raw comments, first time reading the spec. 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.) 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 | Length=0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ==> this is invalid for IPv6; RFC2461 sect 4.6 disallows this: Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. The value 0 is invalid. Nodes MUST silently discard an ND packet that contains an option with length zero. ==> so, the minimum length for IPv6 ND is 8 octets (6 octets of empty padding unless you figure something nice to put in there :-). 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. ==> Note: you've forgotten to add GenID in the diagram above. ==> 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. ... ==> authors' addresses are typically after the references; more importantly, IPR notice and the copyright notice trailers are completely missing -- the draft will bounce back from the AD if these are do not exist (ID-nits) 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. ==> It should also be mentioned in the abstract (which seems way too abstract to me). IPMulticastsSourceRegister (socket, source-address, multicast-address) IPMulticastsSourceDeregister (socket, source-address, multicast-address) ==> should these be s/Multicasts/Multicast/ ? These are inconsistent across the doc. ==> I hope this is not the function name you propose -- rather, an obfuscated version -- and a real API specification will follow. 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. capable and have a consistent configuration for the SSM address range. ==> I think the "consistent config ..." needs to be clarified -- this might mean a lot of things. Link without multicast routing: To ensure backwards compatibility with existing receivers, MSNIP does not try to control traffic on a router-less link. It does so by defining the MSNIP managed range to be empty. Although it would be possible to control multicast transmission on a shared link not connected to a multicast routed infrastructure, MSNIP operation would require that receivers were capable of actively participating in the protocol. Source control would work by defining an address range within which sources would not transmit until directly contacted by a receiver (for example the default IPv4 SSM range of 232/8 [6]). The drawback would be that a non MSNIP capable receiver joining a group through IGMP would have no way of getting the source to transmit. Relying on triggered IGMP messages from legacy receivers to control transmission would not be robust either. ==> this section is too long and should be split up; a good border would be where you start to talk about non-solutions. 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. routing protocol changes for a specific source and multicast destination. Such reports are only sent if the destination address is managed by MSNIP ==> is "the destination address" unambiguous enough (you refer implicitly to the address where the unicast receiver membership status report would be sent, I assume -- but this is rather the address of the managed source IP system. (router address, source address, multicast address, holdtime timer) The router address is obtained from the source address on the IP header of the received message. The source address is obtained from the destination address in the of the IP header. The holdtime timer is set to the value of the holdtime field in the received Receiver Membership Report message. ==> you didn't mention "multicast address". Checksum In IPv4, the Checksum is the 16-bit one's complement of the one's complement sum of the whole IGMP message (the entire IP payload). In IPv6, the Checksum is the standard ICMPv6 checksum, covering the entire MLDv2 message plus a "pseudo-header" of IPv6 header fields .CITE ICMPv6 . For computing the checksum, the Checksum field is set to zero. When receiving packets, the checksum MUST be verified before processing a packet. ==> yes, I agree it's better to cite than rewrite the wheel (your Cite macro seems broken here and elsewhere? :-) 8.2. Receiver Membership Report Packet ==> this section is a bit v4 specific, but the intent seems understandable. MSNIP messages are identified in IPv6 packets by a preceding Next Header value of 58. ==> note that this is a required but not a sufficient condition! 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 [...] ... (IGMPv3 [1] ) and version 2 of the Multicast Listener Discovery Protocol (MLDv2 [2] ). MSNIP operates between multicast sources and their first- ==> s/ )/)/ (note: this is a general problem, also elsewhere in the spec.) Many currently deployed multicast routing protocols, require data ==> s/,// 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,/ multicast routers may be present all multicast routers must be MSNIP ==> s/present/present,/ by a router participating in MSNIP, a miss-configuration SHOULD be ==> s/a miss-/the mis/ o A link with no multicast routers. To be able to differentiate between the three cases and in each ==> remove the extra empty line (also in several other places in the doc!) case discover the MSNIP managed range an MSNIP capable source IP system ==> s/range/range,/ 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.. :-) for each of the TRANSMIT records listed in the message it creates or ==> s/message/message,/ Note that creation and deletion of transmission records in an IP systems state may cause local applications to be notified to start and ==> s/systems/system's/ We received a SSM Range option in an MRD packet on the interface ==> s/a SSM/an SSM/ a preceding Next Header value of 58. All MSNIP messages described in this document are sent with a link-local IPv6 Source Address (or the unspecified address, ==> remove the newline. still be prevented from waisting first-hop link bandwidth by filtering ==> s/waist/wast/ with the HIS message suppression optimisation (see section 10.1). If there is no registered applications in the system and HIS messages are ==> s/there is/there are/ Membership Reports to the system. As a result knowledge of receiver ==> s/result/result,/ offering a large number of potential sessions. Although unlikely it is ==> s/unlikely/unlikely,/ described in [1] IPSEC AH can be used to authenticate IGMP messages if ==> s/[1]/[1],/ (as you note I like commas -- they add readability to the text, and make it more easier to distinguish different parts of long sentences!) We consider the ramifications of a forged message of each type. As described in [1] IPSEC AH can be used to authenticate IGMP messages if desired. ==> s/IGMP/MLD/IGMP/ [3] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In Progress, <draft-ietf-idmr-igmp-mrdisc-08.txt>, 2001. ==> some refs like this, [6], [10], [12], are out of date -- no biggie. -- 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
- [magma] WG Last Call: draft-ietf-magma-msnip-02.t… Brian Haberman
- Re: [magma] WG Last Call: draft-ietf-magma-msnip-… Pekka Savola