Subject: [manet] draft-gerla-manetodmrp-02 review

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 10 Mar 2014 19:43:39 +0100

Dear All,

As the authors requested feedback, I have given the most recent version of this document a review. My comments are below - but do also look at the attached PDF, it's easier to see where each comment applies in there ;)

For those not wanting to read the whole review: I think that this is a well written document, I think it's an interesting idea, and I think it's worth taking further, so I'd encourage further further reviews and work.

There are a few things that need to be addressed, though. Outside the obvious, 'security considerations' and 'the experiment', the main issue is "multiple interfaces and addresses". While the protocol, as I understand it, can work in multiple interfaces/addresses scenarios, I think that the specification is unclear on certain things such as which addresses go in which information sets (such as the Blacklist) and messages.

Either way, see below, and see the file attached to this message - and I look forward to discussing this further with all y'all.

Cheers,

Thomas

File: draft-gerla-manet-odmrp-02 - flattened.pdf

Annotation summary:

--- Page 1 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
General Comments:

I find this specification very well written, well structured, clear and easy to understand. 

Note (yellow), 10 mars 2014 19:24, TClausen:
Executive Summary:
================
I find this specification very well written, well structured, clear, and easy to understand. I believe that there are some clarifications that could be made, though, and a few "formal" things to correct - but also that the protocol specification is fairly straight-forward.

Now, the one point that I think is needing a bit of effort is regarding routers with multiple interfaces and/or multiple addresses, which seems to not be fully specified. At least, it should be made clear which parts of the information base are per interface, and the processing adopted accordingly. The way the "blacklist", for example, is written actually permits an implementation to explicitly "do the wrong thing" when faced with routers with multiple interfaces. I think that it's fairly easy to clear up.

General Comments:
================
I think I understand the general idea, though, of the way the specification is made: you describe, in abstract form, the protocol, signals, etc., and then you provide the mapping to RFC5444-elements in an appendix.

That is not entirely stupid as idea, and the resulting document is actually nice and readable, but.....appendices can't (or, shouldn't) contain normative text. Indeed, there are many MUST/SHOULD/* in Appendix A. 

I suggest promoting Appendix A to a "numbered section" somewhere (perhaps after section 7?) 

While I know that it is early, I think it would be helpful to have some reflections on the security considerations. Recent experiences with the SEC-ADs indicate, that they're considerably more strict than they were even half a decade ago, so understanding "what we're getting ourselves into" if the WG gets involved with this protocol might be helpful.

As was discussed during the MANET wg meeting in London, an EXPERIMENTAL document is supposed to enable an experiment, and that experiment should be documented. See e.g. RFC6971, section 1.2. I'll try to add a couple of my thoughts on what would make for good "experiments":

I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF and other such protocols: whereas these rely on "get a copy of the message to each router, then have the router decide if it delivers those to applications", ODMRP works by only getting copies of messages to routers that actually need it. So, an experiment establishing the boundaries where "efforts to constructing the overlay" are out-weighted by the benefits of not having to deliver a copy of the multicast message to each router.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Mobile Ad hoc Networking (MANET)

Note (yellow), 10 mars 2014 19:24, TClausen:
"Network Working Group" -- see RFC Editor tutorial slides, page 20

Highlight (yellow), 10 mars 2014 19:24, TClausen:
conventional tree-based,

Note (yellow), 10 mars 2014 19:24, TClausen:
Now that I have thought this bit over....

In the end, a tree is constructed, though, is it not? Join Queries flooded, then Join Replies sent back, in a "Tree-construction" fashion?

--- Page 4 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
routing                    techniques to avoid

Note (yellow), 10 mars 2014 19:24, TClausen:
So, it is actually not clear what this means, specifically. The more I think about it, the less do I think of this as "on demand routing techniques" and the more do I think of this as "on-demand tree construction, with proactive maintenance",

Note (yellow), 10 mars 2014 19:24, TClausen:
The more I think about it, the less do I think of this as "on demand routing techniques" and the more do I think of this as "on-demand tree construction, with proactive maintenance",

Note (yellow), 10 mars 2014 19:24, TClausen:
The more I think about it, the less do I think of this as "on demand routing techniques" and the more do I think of this as "on-demand tree construction, with proactive maintenance".

It is clear, that a sensible routing protocol creates and manages forwarding trees/graphs/groups only when there is an actual need for one to exist - so, in that regard, all sensible multicast routing protocols are "reactive".

As I understand it, this protocol is generating the forwarding tree/graph/group from the (expected) source, and then that this is maintained by way of proactive signaling (for as long as there is a need for the forwarding tree/graph/group)

I'd suggest being explicit as to this, both in introduction and in the abstract?

Note (yellow), 10 mars 2014 19:24, TClausen:
I think that you actually also are importing terminology from RFC5444 here, are you not?  At least, section 7 "Packets and Messages" seems to be hinting at - but not calling out explicitly - that you are.

I think I understand why you're not calling it out, with the way that the I-D is written and RFC5444 message mapping being in Appendix, but as I have suggested in "general comments", that organization might not be ideal?

Highlight (yellow), 10 mars 2014 19:24, TClausen:
e.g.

Note (yellow), 10 mars 2014 19:24, TClausen:
Technically, that's probably "i.e., " as there are only those two message types, yes?

Note (yellow), 10 mars 2014 19:24, TClausen:
I would suggest answering the question, which is on everybody's lips, already here: does this integrate with "regular IP Multicasting" or does it require "application level tunneling"? 

In other words, could I expect an mcast-capable application to "just work", and can I implement this "on a commodity OS", or will I have to do kernel-level hacks?

Note (yellow), 10 mars 2014 19:24, TClausen:
I would suggest answering the question, which is on everybody's lips, already here: does this integrate with "regular IP Multicasting" or does it require "application level tunneling"? 

In other words, could I expect an mcast-capable application to "just work", and can I implement this "on a commodity OS", or will I have to do kernel-level hacks to make it work?

Having read through the document, I think that I infer that it's possible to build an user-space implementation manipulating working by simply multicast routing table entries.

Would be good to have it confirmed that my understanding is correct - if it is, that is ;)

--- Page 5 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
addresses

Note (yellow), 10 mars 2014 19:24, TClausen:
I am going to pick out this here, but it applies elsewhere also: "addresses"? 

I believe that you aim at "address length independence", v6/v4/short, and that's a good idea which is, I believe, supported well by RFC5444. Alas, I believe that you probably want to stick in a definition and explanation of that in here. 

Also, I gather that these addresses are "interface identifiers" and not "multicast group addresses", yes? Given that this document talks about multicast, I do recommend perhaps calling this out?

Note (yellow), 10 mars 2014 19:24, TClausen:
I actually would love for you to repeat the example text for "Upstream" here, also. Yeah, it's repetitive, but when reading through a document and looking for a definition, it's nice to not be hunting.

Note (yellow), 10 mars 2014 19:24, TClausen:
I am repeating my comment from the introduction here:

The more I think about it, the less do I think of this as "on demand routing techniques" or a "reactive" protocol, and the more do I think of this as "on-demand tree construction, with proactive maintenance".

It is clear, that a sensible routing protocol creates and manages forwarding trees/graphs/groups only when there is an actual need for one to exist - so, in that regard, all sensible multicast routing protocols are "reactive".

As I understand it, this protocol is generating the forwarding tree/graph/group from the (expected) source, and then that this is maintained by way of proactive signaling (for as long as there is a need for the forwarding tree/graph/group)

I'd suggest being explicit as to this, both in introduction and in the abstract?

Note (yellow), 10 mars 2014 19:24, TClausen:
Just to be clear; am I correct in understanding that:

A Multicast Group Address, is used by applications, and joined (etc) by way of IGMP/MLD.

The ODMRP router hearing these,  maps that to a "Multicast Session".

That ODMRP router then proceeds to construct a Multicast Overlay for that multicast session; the Multicast Overlay of a multicast session is a source-rooted multicast tree?

Also, as I understand it, "Forwarding Group" and "Multicast Overlay" are, respectively, "links" and "routers" for a given Multicast Session?

I think that thats what it is, but the relationship between these terms/concepts  could merit being rendered crystal clear here.

--- Page 6 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest adding "These multicast overlays are, then, proactively maintained for as long as the overlay is needed (as long as there are members in the multicast group AND as long as there is data to be delivered to the multicast group)"

Note (yellow), 10 mars 2014 19:24, TClausen:
IIRC there's a space after and before a "dash"......

Highlight (yellow), 10 mars 2014 19:24, TClausen:
overlay only

Note (yellow), 10 mars 2014 19:24, TClausen:
-> "overlay, only"

Note (yellow), 10 mars 2014 19:24, TClausen:
Correct, but not complete. The overlay is created, trigged by data to deliver to the members - but, no overlay is actually created unless there actually are members of the destination set. 

Highlight (yellow), 10 mars 2014 19:24, TClausen:
overlay for

Note (yellow), 10 mars 2014 19:24, TClausen:
-> "overlay only for...."

Note (yellow), 10 mars 2014 19:24, TClausen:
and until there no longer are members of the multicast group?

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest "if the router belongs to, i.e., has attached hosts which have subscribed to, the multicast group ..." 

Highlight (yellow), 10 mars 2014 19:24, TClausen:
originates

Note (yellow), 10 mars 2014 19:24, TClausen:
This is a really detail-oriented comment, but "originates a Join Reply" here - and "Join Reply Generation" as the section title for section 9.1.2 is a little incoherent ;) 

Note (yellow), 10 mars 2014 19:24, TClausen:
I'd proffer that a lot this perhaps should be going in the "Signaling Overhead" rather than in this section; in part, as you describe messages and sets, before these are defined.

As overview, it's quite too detailed, so perhaps jumping straight to 4.2 and merging 4.1 into 4.3 is the best approach?

Or, perhaps, have 4.2, then 4.3 and finally 4.1 ?

--- Page 7 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
carried

Note (yellow), 10 mars 2014 19:24, TClausen:
This is too "implicit": a "next hop address carried in a packet". You should, at least, in the previous bullet point indicate that a Join Reply carries a "next hop address" (and, possibly, what else it carries - I think that for duplicate JR suppression, that's important?)

Highlight (yellow), 10 mars 2014 19:24, TClausen:
it

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest "If that next hop address is an address of this router..."

Also, what does "is an address of" or "corresponds to" this router mean, precisely? This may sound like a slightly silly question ;) but in NHDP/OLSRv2 we've had to be extremely careful with to what addresses correspond: a router, interfaces on that router, or addresses of hosts reachable by way of this router.

The upshot of this is, that it's really easy to sort out, for example: "Is an address of an interface of this router", or something.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
,

Note (yellow), 10 mars 2014 19:24, TClausen:
For readability, given that this is the overview and functioning:

"If <condition>, <condition>, <condition>, then this ODMRP Router belongs to the forwarding group for the multicast session. Consequently, it installs ..." 

A secondary comment here is, that you have defined "Multicast Session" in the terminology, but you're not using it here (rather, you say "......Forwarding Group, which correspondS [sic] to this multicast group and source..."

Note (yellow), 10 mars 2014 19:24, TClausen:
This is confusing. What is actually discarded here? I.e., what does "it" correspond to"?

--- Page 8 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
flooded periodically

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest adding that/if that can be done by way of an optimized flooding operation, if available on the network.

--- Page 9 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
This probably needs a bit more of explanation. As I indicated in the general comments, the separation of abstract message content, and 5444-encoding is a possible way to go, but it is not clear at this point that that's what's being done.

As a consequence, it is not clear why the section title is "Packets and Messages" - those are (in MANET) 5444-constructs, typically.

One possibility could be to stick Appendix A after section 7. Another, to have appendix A be a subsection to section 7.

--- Page 11 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Multicast Source

Note (yellow), 10 mars 2014 19:24, TClausen:
Somewhat of the same comment as one I have made before: "the address of the Multicast Source"

First, is the "Multicast Source" the router, through which the multicast data messages ingress through, or is it the host on which the application generating data, is? Does it make any difference? "Multicast Source" is not defined.

Second, what about multiple interfaces/addresses? 

I can probably infer how it should be: this is the IP address that one will find in the source-address field of IP multicast datagrams, yes? If so, perhaps just call that out somewhere so there's no doubt.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
address of the neighbor ODMRP Router

Note (yellow), 10 mars 2014 19:24, TClausen:
Jumping on this just once more. "The address of the neighbor ODMRP router..."

The way it is written, one gets the impression that ODMRP is designed for single-interface-single-address routers. 

I do not *think* that this is the case, and it certainly does not have to be made a constraint, so I recommend clearing that up. (Conversely, if it is the case, call that out as a constraint in applicability section). This applies actually through the document, so looking at giving it a pass through with "remove doubts as to multi-if/addr" as objective would be great.

Highlight (yellow), 10 mars 2014 19:24, TClausen:
R_source

Note (yellow), 10 mars 2014 19:24, TClausen:
Why is it P_multicast_source, but this is R_source?

Note (yellow), 10 mars 2014 19:24, TClausen:
From this description, it appears that it all is "per router" and with no "per interface" sets, is that correct?

As I have indicated for the "Blacklist" this may be problematic, or at least necessitate some extra care to specify completely.

--- Page 12 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Multicast Source

Note (yellow), 10 mars 2014 19:24, TClausen:
See previous question regarding Multicast Source

Note (yellow), 10 mars 2014 19:24, TClausen:
Contrary to previous....<something>_source, this is unambiguous ;)

Highlight (yellow), 10 mars 2014 19:24, TClausen:
F_source

Note (yellow), 10 mars 2014 19:24, TClausen:
Why is it P_multicast_source, but this is F_source?

--- Page 13 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
I would probably say "...over which the Join Reply was sent"

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an

Highlight (yellow), 10 mars 2014 19:24, TClausen:
ODMRP Routers

Note (yellow), 10 mars 2014 19:24, TClausen:
What if two routers, A and B, have two interfaces a1, a2, b1, b2?

If A can hear B over a

Note (yellow), 10 mars 2014 19:24, TClausen:
What if two routers, A and B, have two interfaces a1, a2, b1, b2?

If A can hear B over (a1, b1) and B can hear A over (a2, b2), what addresses go into this set?

Also, what if A can hear B over (a1, b1) (and B can hear A over the same pair), and A can hear B over (a1,b2) but B cannot....?

In other words, is this set per interface or per router?

And, what are the addresses you put in there, interface addresses, or "RouterIDs"?

--- Page 14 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Alright, so reading this, it seems that the blacklist must be "per interface", yes?

--- Page 15 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an address

Note (yellow), 10 mars 2014 19:24, TClausen:
Which address? Any? Always the same? Does it matter?

--- Page 16 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
an address

Note (yellow), 10 mars 2014 19:24, TClausen:
Which address? Any? Always the same? Does it matter?

Highlight (yellow), 10 mars 2014 19:24, TClausen:
neighbors

Note (yellow), 10 mars 2014 19:24, TClausen:
I assume that what you want is to forward to all the neighbors on all ODMRP interfaces of this router, yes?

--- Page 19 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
neighbors

Note (yellow), 10 mars 2014 19:24, TClausen:
Over all ODMRP Interfaces?

Note (yellow), 10 mars 2014 19:24, TClausen:
Here, we are gleaning a bit more precisely what the R_source is; so its an interface of an ODMRP router over which the Join Reply was sent, yes?

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Else

Note (yellow), 10 mars 2014 19:24, TClausen:
Else -> "Otherwise, if a tuple exists, ..."

--- Page 20 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
"Otherwise, ..."

--- Page 21 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Else

Note (yellow), 10 mars 2014 19:24, TClausen:
->Otherwise

Note (yellow), 10 mars 2014 19:24, TClausen:
Really nit-picking, but " i.e. " -> " i.e., " is the RFC-Editor style....

Note (yellow), 10 mars 2014 19:24, TClausen:
Suggest: "...run in conjunction with, and benefit from some of the features of, SMF..."

Strikeout (red), 10 mars 2014 19:24, TClausen:
and                benefit from some of its features.

Note (yellow), 10 mars 2014 19:24, TClausen:
I would be hesitant to call this section "SMF Considerations"

While SMF is an important and useful protocol set, I would suggest that this section be generalized: what's at stake is, and I think that I saw that in the slides that were presented in the London IETF, that if there's a "more efficient than classic flooding" network-wider broadcast operation in place, then ODMRP would/should use it - correct?

This might be by way of SMF, or it could be as an extension to OLSRv2's MPR flooding, or it could be (as is seen in for example HNCP) something based off of Trickle - or something entirely different.

So, perhaps "Flooding considerations" as section title, and a bit generalized text would work?

--- Page 22 ---

Highlight (yellow), 10 mars 2014 19:24, TClausen:
Packets

Note (yellow), 10 mars 2014 19:24, TClausen:
Packets -> Packet

Note (yellow), 10 mars 2014 19:24, TClausen:
OK, I think that this document should start by actually requesting the allocations for the two message types. Cf. how it is done in section 18.2 of RFC6130

Then, I *think* that the current 15.1 is the Message-Type-Specific TLV Type Registries" that are being set up, for Join-Query yes? I see "Expert Review" mentioned, but no guidelines/recommendations for the Expert to follow. Do you intend to mirror those from RFC5444, or are there special concerns to take into consideration?

I would actually suggest mirroring the structure of the IANA section from RFC6130  if for no other reasons, than that it's allocating from RFC5444-registries, and has been going through the process and so it may be assumed that something mirroring it will, too. ;)

--- Page 25 ---

Note (yellow), 10 mars 2014 19:24, TClausen:
Just a comment, a cursory review of the mapping to RFC5444 doesn't have anything jump at me screaming "problems", which is good.

I was wondering one thing, though: if running OLSRv2 + ODMRP, then there's an obvious option which could be considered (and could be considered, in order to be disregarded)....

Could one imagine carrying ODMRP signals inside TC messages in any meaningful way, as TLVs and additional addresses included? *technically* it should be possible, does it make sense?

A second thing, is there any reason to request both JR and JQ message type, or is there a way of using just a single code-point, and are there potential benefits in doing so?

A different way of phrasing the above is: given that code-points by definition are limited, I'd like to ask for a bit more of "justification" before they are allocated.

FWIW, I've not had the cycles to review the appendices, other than Appendix A.

(report generated by GoodReader)

Sent from my iPad

---

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 10 Mar 2014 23:01:24 +0100

Hi Thomas,

Thanks a lot for this thorough review. I'll need a moment to go through it and get back to you though :).

Best,

Axel

Le 10 mars 2014 à 19:43, Thomas Heide Clausen <[email-masked]> a écrit :

> <draft-gerla-manet-odmrp-02 - flattened.pdf>
> 
> 
> Sent from my iPad_______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 10 Mar 2014 23:13:21 +0100

> On 10 mars 2014, at 23:01, Axel Colin de Verdière <[email-masked]> wrote:
> 
> Hi Thomas,
> 
> Thanks a lot for this thorough review.

I know, I know. I am a pain in the behind like that ;)

> I'll need a moment to go through it and get back to you though :).
> 

Please do - especially, if there's something that's unclear that needs more explanation.

Cheers,

Thomas

> _______________________________________________
> manet mailing list
> [email-masked]

---

From: Axel Colin de Verdière <[email-masked]>
Date: Tue, 11 Mar 2014 09:37:03 +0100

Hi Thomas,

Thanks again for your review. See inline for the replies point-by-point. A couple points I'd like to copy here:

- Your comments confirm there's a real need to clarify the way this would work with multiple interfaces: describe the router/interface/address relationship, explain which information set is per interface and which is per router (presumably few to none), and clarify which address comes from which interface of which node (host or router).

- You suggest moving appendix A to a section or subsection of section 7. A counter-proposal would be to describe only the message contents in section 7 (with the required and optional fields), and have Appendix A be only an "example encoding using RFC5444" section, that would contain no normative text. Would that be acceptable?

- I think this could be implemented in user-space, but I'm afraid that having to intercept the first data packet in order to build the multicast tree would require a kernel module. I'd appreciate it if someone more knowledgeable than me could infer or refute that.

- There's a need to clarify some of the vocabulary, such as the Multicast Overlay/Forwarding group relationship. Regarding that, I wonder if it wouldn't add more clarity to just drop the "Multicast Overlay" term, and only refer to the Forwarding Group. Thoughts?

Best,

Axel

>>> Note (yellow), 10 mars 2014 19:24, TClausen:

Thank you.

>>> Now, the one point that I think is needing a bit of effort is regarding routers with multiple interfaces and/or multiple addresses, which seems to not be fully specified. At least, it should be m…

That makes sense. I actually had comments in that direction during IETF-week, so that confirms that the next big point to address is this. I hadn't seen the issue with the blacklist though, so thanks.

>>> General Comments:

I have another suggestion, coming from some comments from Justin during IETF-week: section 7 could be written so as to contain only the fields carried by the protocol messages, stating which are required and which are optional (so as to get the MUST and other SHOULDs out of Appendix A), and suggest one possible encoding of these messages with RFC5444 in the appendix, since any correct encoding should be parsed into the right fields. That way the appendix would not contain any normative text, and anyone would be free to use his or her RFC5444 parser/encoder even if it encodes the fields differently. Would that work?

>>> While I know that it is early, I think it would be helpful to have some reflections on the security considerations. Recent experiences with the SEC-ADs indicate, that they're considerably more st…

Ok, I'll take a look at that.

>>> I do believe that, perhaps, a distinguishing point of ODMRP vs. SMF and other such protocols: whereas these rely on "get a copy of the message to each router, then have the router decide if it de…

Yes, I think that would be interesting. It might also be worth it to see if there's a way to adapt to network traffic and switch between the two modes. Another idea would be to try to figure out the possible scopes of deployments of ODMRP, i.e., if ODMRP can be used anywhere where OLSRv2 is deployed.

>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:

Got it (x3).

>>> In the end, a tree is constructed, though, is it not? Join Queries flooded, then Join Replies sent back, in a "Tree-construction" fashion?

Yes, basically it wounds up being a tree. I should probably revise the abstract and applicability statement that way.

>>> I'd suggest being explicit as to this, both in introduction and in the abstract?

You're right, there's a proactive part - I'll amend the intro and applicability statement to reflect this.

>>> I think I understand why you're not calling it out, with the way that the I-D is written and RFC5444 message mapping being in Appendix, but as I have suggested in "general comments", that organiz…

See my previous reply for the organization, but I should probably still call out RFC5444.

>>> Technically, that's probably "i.e., " as there are only those two message types, yes?

Ok.

>>> Would be good to have it confirmed that my understanding is correct - if it is, that is ;)

I think there are two things here. First, since it uses regular IGMP/MLD signaling, there is probably nothing to change on the "host" part of the protocol, and an application should work without any changes. However, although it seems possible to have an user-space implementation that just writes to the multicast routing table, I think there might be an issue with the original tree creation: I'm not sure it's possible to intercept the first data packet(s) to trigger the Join Query process without being in the kernel. But I'm not an expert with this, so somebody might correct me. In the meantime I'll dig a little deeper, see if I can figure something out.

>>> Also, I gather that these addresses are "interface identifiers" and not "multicast group addresses", yes? Given that this document talks about multicast, I do recommend perhaps calling this out?

Ok, will do. I think this will go in the whole "clarifying the router-interface-address relationship" part that goes with handling multiple interfaces.

>>> I actually would love for you to repeat the example text for "Upstream" here, also. Yeah, it's repetitive, but when reading through a document and looking for a definition, it's nice to not be hu…

Alright, no problem.

>>> I'd suggest being explicit as to this, both in introduction and in the abstract?

Ok, that makes sense (same reply :)).

>>> A Multicast Group Address, is used by applications, and joined (etc) by way of IGMP/MLD.

Yes.

>>> The ODMRP router hearing these,  maps that to a "Multicast Session".

Not exactly, since a Multicast Session is Multicast Group Address + Multicast Source Address, hence a router which has an attached host that has joined a Multicast Group Address might have several corresponding Multicast Sessions.

>>> That ODMRP router then proceeds to construct a Multicast Overlay for that multicast session; the Multicast Overlay of a multicast session is a source-rooted multicast tree?

Yes.

>>> Also, as I understand it, "Forwarding Group" and "Multicast Overlay" are, respectively, "links" and "routers" for a given Multicast Session?

I would say the opposite actually, the Forwarding Group is the set of routers that form the Multicast Overlay built by the JQ + JR process, and forward the Multicast data packets for the corresponding multicast session.

>>> I think that thats what it is, but the relationship between these terms/concepts  could merit being rendered crystal clear here.

Agreed. I wonder if it would not be clearer to drop the term "Multicast Overlay" altogether, and only refer to the Forwarding Group, since this is the most concrete construct used by ODMRP, and only call out in the intro and applicability statement that the Forwarding Group forms a source-rooted tree. Would that make more sense?

>>> Suggest adding "These multicast overlays are, then, proactively maintained for as long as the overlay is needed (as long as there are members in the multicast group AND as long as there is data t…

Ok.

>>> Note (yellow), 10 mars 2014 19:24, TClausen:
Got it (x3).

>>> Correct, but not complete. The overlay is created, trigged by data to deliver to the members - but, no overlay is actually created unless there actually are members of the destination set. 

Will clarify.

>>> and until there no longer are members of the multicast group?

Got it, will clarify.

>>> Suggest "if the router belongs to, i.e., has attached hosts which have subscribed to, the multicast group ..." 

Ok

>>> This is a really detail-oriented comment, but "originates a Join Reply" here - and "Join Reply Generation" as the section title for section 9.1.2 is a little incoherent ;) 

Got (x2).

>>> Or, perhaps, have 4.2, then 4.3 and finally 4.1 ?

That makes sense. I think having 4.1 after 4.3 would be good.

>>> This is too "implicit": a "next hop address carried in a packet". You should, at least, in the previous bullet point indicate that a Join Reply carries a "next hop address" (and, possibly, what e…

I think this would be solved by having 4.3 before 4.1 so that the packet contents are known beforehand.

>>> Suggest "If that next hop address is an address of this router..."

Ok.

>>> The upshot of this is, that it's really easy to sort out, for example: "Is an address of an interface of this router", or something.

Got it, will add that to the whole address/interface clarification.

>>> A secondary comment here is, that you have defined "Multicast Session" in the terminology, but you're not using it here (rather, you say "......Forwarding Group, which correspondS [sic] to this multicast group and source..."\

Got it.

>>> This is confusing. What is actually discarded here? I.e., what does "it" correspond to"?

Yeah, I guess there are too many "it"s and possible objects in that paragraph, will rephrase.

>>> Suggest adding that/if that can be done by way of an optimized flooding operation, if available on the network.

Ok.

>>> One possibility could be to stick Appendix A after section 7. Another, to have appendix A be a subsection to section 7.

Agreed, this is not clear enough. See my previous reply for a counter-proposal though (i.e., clarify the separation and keep Appendix A as an "example encoding"). Otherwise promoting appendix A to a section or subsection of sec 7 would work too I guess.

>>> First, is the "Multicast Source" the router, through which the multicast data messages ingress through, or is it the host on which the application generating data, is? Does it make any difference…

I think that provided that the host-to-router relationship is 1-1 and well defined, having the Multicast Source be the actual host sending the data would work. But it's true that there's a need to be explicit there.
>>> I can probably infer how it should be: this is the IP address that one will find in the source-address field of IP multicast datagrams, yes? If so, perhaps just call that out somewhere so there's…

Yup, will do then.

>>> I do not *think* that this is the case, and it certainly does not have to be made a constraint, so I recommend clearing that up. (Conversely, if it is the case, call that out as a constraint in a…

Yup, next big item is "clarify multiple interfaces/addresses and associated".

>>> Why is it P_multicast_source, but this is R_source?

Because I need to make a "consistency pass" through the document I think.

>>> As I have indicated for the "Blacklist" this may be problematic, or at least necessitate some extra care to specify completely.

You're right, I think most of these sets should be "per interface".

>>> Why is it P_multicast_source, but this is F_source?

Got it (x5).

>>> Highlight (yellow), 10 mars 2014 19:24, TClausen:

Got it.

>>> And, what are the addresses you put in there, interface addresses, or "RouterIDs"?

This should be per interface, and described as such. Will do that.

>>> Alright, so reading this, it seems that the blacklist must be "per interface", yes?

Yes

>>> Which address? Any? Always the same? Does it matter?

I think this should actually be the Multicast Source address, so as to map the Join Query to a Multicast Session.

>>> I assume that what you want is to forward to all the neighbors on all ODMRP interfaces of this router, yes?

Yes, although I should probably call out more explicitly that the JQ should be passed to the forwarding mechanism in place in the network (so that if SMF with ECDS - or OLSRv2's MPR - is in place it can be used for example).

>>> Here, we are gleaning a bit more precisely what the R_source is; so its an interface of an ODMRP router over which the Join Reply was sent, yes?

Actually I think I should refactor the document to map this to the multicast source. This should help in mapping various information base tuples to the multicast session, and avoid issues such as choosing which address to put in a newly-generated join query.

>>> Note (yellow), 10 mars 2014 19:24, TClausen:

Got it (x2).

>>> Really nit-picking, but " i.e. " -> " i.e., " is the RFC-Editor style....

Got it.

>>> So, perhaps "Flooding considerations" as section title, and a bit generalized text would work?

Funny enough, this was the original title - I'll put that back in then, and generalize to other possible flooding mechanisms.

>>> I would actually suggest mirroring the structure of the IANA section from RFC6130  if for no other reasons, than that it's allocating from RFC5444-registries, and has been going through the proce…

Alright, will look at that and do so then.

>>> Could one imagine carrying ODMRP signals inside TC messages in any meaningful way, as TLVs and additional addresses included? *technically* it should be possible, does it make sense?

Technically that should work, I guess the advantage would be to have less duplicate information flooded throughout the network, and overall less packets sent, but I'm not sure it would be easy to encode that in any way that would 1) prevent too much duplicate information and 2) be easy to parse (both for the specs reader and the implementation). So I'm worried this would not really be worth it.

>>> A different way of phrasing the above is: given that code-points by definition are limited, I'd like to ask for a bit more of "justification" before they are allocated.

Well first off, in a more "abstract" sense I think it's clearer to keep the JQ vs JR distinction throughout the document. However it could be envisioned to have only a ODMRP-message type with a "flags" TLV that would have one flag determining whether the message is actually treated as a JQ or a JR. After all, the two messages are pretty similar in content. For now the only drawback I see is that it would slightly increase the message size. But I guess the same reasoning could be done with a lot of protocols, no?

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 11 Mar 2014 23:57:45 +0100

Dear Axel,

Below.

> On 11 mars 2014, at 09:37, Axel Colin de Verdière <[email-masked]> wrote:
> 
> Hi Thomas,
> 

OK, that sounds good. Let me know if you need comments on an (intermediary or final) text.

> - You suggest moving appendix A to a section or subsection of section 7. A counter-proposal would be to describe only the message contents in section 7 (with the required and optional fields), and…

I believe that, at some point in the past, we were told to not put normative bits into appendices - and the encoding into 5444-format *is* normative for interoperability, I would think, so I am not really sure how what you propose would actually work - but, perhaps I do not understand it fully? ;)

> - I think this could be implemented in user-space, but I'm afraid that having to intercept the first data packet in order to build the multicast tree would require a kernel module. I'd appreciate i…

OK.

> - There's a need to clarify some of the vocabulary, such as the Multicast Overlay/Forwarding group relationship. Regarding that, I wonder if it wouldn't add more clarity to just drop the "Multicast…

Well, I was thinking that there were quite a bit of terms that might appear not redundant, but perhaps extraneous ;) so looking at simplifying that sounds good.

Further below...snipping out the things that we seem to be in agreement on...

>>> On 10 mars 2014, at 23:01, Axel Colin de Verdière <[email-masked]> wrote:

<SNIP>

> I have another suggestion, coming from some comments from Justin during IETF-week: section 7 could be written so as to contain only the fields carried by the protocol messages, stating which are re…

Ah...

This has nothing to do with one persons encoder/decoder over anothers. The specification must, unequivocally, be such that it is possible to create interoperable implementations, regardless of parser/encoder; that's the whole point of RFC5444 ;)

For example, if you decide to put an address in the "originator field", and I decide to not do that, but stick it in an address block with an "originator TLV" associated, then our implementations just won't interoperate...so the specification definitely has to be specifying normatively so as to avoid such situations.

<SNIP>

> Yes, I think that would be interesting. It might also be worth it to see if there's a way to adapt to network traffic and switch between the two modes. Another idea would be to try to figure out th…

Sounds like this is actually also a good idea.

Something else that I was thinking about just now was the whole notion of the overlays being constructed with or without metrics...is there a clever (i.e., simple) way to use link metrics when constructing the multicast overlays? If such metrics already are available e.g. for an unicast routing protocol already present in the network?

> Yes, basically it wounds up being a tree. I should probably revise the abstract and applicability statement that way.

Actually, I was thinking more in the introduction or in the overview and functioning - not as much in applicability statement.

Given that you are French, let me try with a food-analogy (had you been American, I'd have gone with a car analogy) ;) 

To me, an applicability statement is something like:

	"This protocol is applicable when making puddings. It works for round and square moulds,
	  but has been found to be inapplicable in hexagonal moulds.  For other shapes of moulds,
	  we do not know if this protocol is applicable for pudding-making"

The "Overview and Functioning" is where you write if you use a fork or a whisk for mixing the ingredients.

<SNIP>

> I think there are two things here. First, since it uses regular IGMP/MLD signaling, there is probably nothing to change on the "host" part of the protocol, and an application should work without any changes.

That's excellent.

> However, although it seems possible to have an user-space implementation that just writes to the multicast routing table, I think there might be an issue with the original tree creation: I'm not sure it's possible to intercept the first data packet(s) to trigger the Join Query process without being in the kernel. But I'm not an expert with this, so somebody might correct me. In the meantime I'll dig a little deeper, see if I can figure something out.

That might also be something that could be established as part of the experiment, also, perhaps?

> Ok, will do. I think this will go in the whole "clarifying the router-interface-address relationship" part that goes with handling multiple interfaces.

That sounds about right, yeah.

<SNIP>

> Not exactly, since a Multicast Session is Multicast Group Address + Multicast Source Address, hence a router which has an attached host that has joined a Multicast Group Address might have several…

OK, so the fact that I felt the urge to ask this question might indicate that it could do with a clarification (or, perhaps, that I'm a few cards short of a full deck? ;) )

<SNIP>

> I would say the opposite actually, the Forwarding Group is the set of routers that form the Multicast Overlay built by the JQ + JR process, and forward the Multicast data packets for the correspond…

Ok, same reply as the one above.

> Agreed. I wonder if it would not be clearer to drop the term "Multicast Overlay" altogether, and only refer to the Forwarding Group, since this is the most concrete construct used by ODMRP, and onl…

I'd probably want to see the resulting text before saying yes or no, definitively, but it sounds like it's a very very sensible plan.

<SNIP>

> Agreed, this is not clear enough. See my previous reply for a counter-proposal though (i.e., clarify the separation and keep Appendix A as an "example encoding"). Otherwise promoting appendix A to…

OK, I think that this needs some thought; I've made my comments in the above to this point.

> I think that provided that the host-to-router relationship is 1-1 and well defined, having the Multicast Source be the actual host sending the data would work. But it's true that there's a need to…

Oh, I hope that you mean that the host-to-router relationship is m-1, in that "one router can serve many hosts", yes?

Incidentally, in case that the m-1 applies, that probably deserves to be called out in the applicability statement (i.e., no multihoming permitted?). Even better if you could state what the consequences of multihoming would be (would it work, but be inefficient, or would it break the Internet?)

<SNIP>

> Yes, although I should probably call out more explicitly that the JQ should be passed to the forwarding mechanism in place in the network (so that if SMF with ECDS - or OLSRv2's MPR - is in place i…

That sounds like a good idea, yeah.

> Actually I think I should refactor the document to map this to the multicast source. This should help in mapping various information base tuples to the multicast session, and avoid issues such as c…

That sounds sensible.

<SNIP>

> Funny enough, this was the original title - I'll put that back in then, and generalize to other possible flooding mechanisms.

Hah, first impulses sometimes are the right ones ;)

> Alright, will look at that and do so then.

Note, this is not something I'm dogmatic about, but the approval process of TLV-Extensions has taught me that IANA appreciates getting very very clear instructions (can't blame them ;) ), and that providing such makes things so much easier for authors, ADs and IANA.

> Technically that should work, I guess the advantage would be to have less duplicate information flooded throughout the network, and overall less packets sent, but I'm not sure it would be easy to e…

That's fair enough, this was just something I thought about in an idle moment. 

> Well first off, in a more "abstract" sense I think it's clearer to keep the JQ vs JR distinction throughout the document. However it could be envisioned to have only a ODMRP-message type with a "fl…

OK, fair enough. 

As codepoints (almost always) are at a premium, thinking through these things is just something that I encourage to be done very, very carefully. When we designed OLSRv2, for example, one of the things we did vs. OLSRv1 was to remove 3 message types, and "consume" only one (TC) out of the 5444 message type space.

I've not really made up my mind either way, but I'd encourage that we keep thinking about this?

Sounds, overall, like the coming revision will be reflecting the bulk of the issues that I've brought up, and that we've got a few marked as "to think a bit further about". Overall, that's fabulous!

Thank you for your reply, and I look much forward to reviewing an upcoming iteration of this document.

Best,

Thomas

---

From: Juliusz Chroboczek <[email-masked]>
Date: Mon, 24 Mar 2014 22:10:18 +0100

> - I think this could be implemented in user-space, but I'm afraid that having
> to intercept the first data packet in order to build the multicast tree would
> require a kernel module.

This is exactly the issue that the reactive protocol people have been
struggling with for over a decade now, and that I mentioned in London
during the discussion of AODVv2.

Historically, AODV has been implemented as a kernel module, which
caused no end of problems.  Recently, it has been implemented in
userspace by playing tricks with tun interfaces.

Henning explained the trick to me as follows.  He puts a default route
through a tun interface, which causes all unroutable packets to go to
userspace.  He then buffers the tunnelled packets, and sets a more
specific route whenever a route is established.  Yes, it's a hack, and
one that only works in the absence of bona fide shorter prefix routes
(HNAs in OLSR parlance).  (I also don't see how it handles AODV's
error case, but that's a different issue.)

As you rightly note, and as I mentioned at the London meeting, the
proper approach would be to have a callback to userspace for the first
packets of a new flow (as well as for the error case).  There is some
precedent for that, the "ARP daemon" interface, which allows
implementing the ARP cache (a degenerate reactive protocol) in
userspace.  See CONFIG_ARPD in your kernel configuration docs.

It would be an interesting research project to design and implement
a minimal, stable API that allows implementing both AODVv2 and ODMRP
entirely in userspace.  Actually, it's more than that -- it's the only
way to save AODVv2.

-- Juliusz

---

From: Brian Adamson <[email-masked]>
Date: Mon, 24 Mar 2014 17:53:16 -0400

I recently added a "device" command-line option to our "nrlsmf" user space forwarding code (http://www.nrl.navy.mil/itd/ncs/products/smf) that does the same sort of think you mentioned that Henning described to you with use of a tun/tap virtual interface that is logically bridged (by the nrlsmf code) to a physical interface.  This lets nrlsmf be _in_ the path of all outbound (and inbound) traffic for the virtual interface that is created (and presumably then used by MANET routing code like our OSLR code).   I haven't yet had a chance to describe the "device" option in the User Guide yet, but the code, etc is in our "nightly snapshot" release.  The nlrsmf code works on Linux, MacOSX, Windows, Android, etc since it uses a cross-platform framework we developed for various purposes.

We have some plans to generalize the control interface of our nrlsmf forwarding engine to allow control of a forwarding information based (FIB) for multicast (and possibly unicast) packet forwarding for protocols like the Elastic Multicast draft we recently presented and could be used for the proposed ODMRP as well.  And the concept could allow for support of On Demand unicast routing protocols as well.

The approach would be for the forwarding engine (to have a control port the routing control plane protocol would monitor to be informed of newly detected "flows"  (along the lines of what we described in the Elastic Multicast) presentation and allow the control protocol then specify any changes to how the flow would be handled.  For the case of Elastic Multicast, a default behavior like flooding (perhaps with a token bucket restriction like we described) might be used for newly detected flows until the control protocol made up its mind on what to do.  For something like AODV, I suppose a default behavior of buffering packets could be set …  The idea would be to have some preset default behaviors set for different traffic filters (e.g. multicast vs. unicast or even special handling for certain traffic classes, including perhaps even default flooding of critical unicast flows, etc).  

The purpose of this generalization is to use the nrlsmf framework to prototype the FIB design and determine the control interface requirements looking ahead towards future (hopefully) kernel module implementation, etc.  The nice thing about the interim research & developer user space implementation is cross-platform and development flexibility support until kernel support could be available.   It's a long term path to get there based on the developer time/resources we have available, but this is the direction we're heading.  When we support all this stuff, we may need to change the "smf" in nrlsmf to mean "sophisticated manet forwarding" ;-).

best regards,

Brian

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 Mar 2014 00:39:25 +0100

> I recently added a "device" command-line option to our "nrlsmf" user space
> forwarding code (http://www.nrl.navy.mil/itd/ncs/products/smf)

I see.  The default is to use BPF, right?

> that does the same sort of think you mentioned that Henning
> described to you

Henning claimed that only packets for non-established routes go
through the tun interface -- packets for established routes would
follow the more specific routes.  (I don't see how that can work in
the error case, but Henning usually knows what he's speaking about.)

I assume that your "device" option still pushes all data packets to
userspace, right?

> The approach would be for the forwarding engine (to have a control port the
> routing control plane protocol would monitor to be informed of newly detected
> "flows"

Right.

> For the case of Elastic Multicast, a default behavior...
> For something like AODV, I suppose a default behavior...

Are you putting policy in the kernel?  My choice would be to have just
one behaviour for new flows -- push the packet to userspace, which can
then perform flooding, buffering, dropping, whatever.

> When we support all this stuff, we may need to change the "smf" in
> nrlsmf to mean "sophisticated manet forwarding" ;-).

Heh.  I'm not sure it's specific to MANETs.

-- Juliusz

---

From: Brian Adamson <[email-masked]>
Date: Mon, 24 Mar 2014 21:36:13 -0400

> I see.  The default is to use BPF, right?

Yes - there is an option to use IP Tables queues or BSD ipfw divert sockets but those aren't as flexible with regard to IPv6 support, etc.

> I assume that your "device" option still pushes all data packets to

Henning's approach would have an advantage that packets that already had a route established would stay in the kernel. Yes - the "device" options pushes all data packets to userspace.

> then perform flooding, buffering, dropping, whatever.

The idea would be to explore what makes since for the FIB.  By the time you have the SMF duplicate packet detection (DPD), etc in the kernel, a default 'policy' for new flows wouldn't be much additional complexity (I think!).  We looked at XORP's approach and it pushes packets for new flows up, but I was hoping we avoid that and just signal the existence of  a new flow and just send the flow parameters up (addressing, traffic class, protocol) … but it's definitely open to discuss and we haven't implemented it yet.  There is interest in having the SMF paradigm in a kernel module for performance and to integrate it properly with existing traffic control, queue disciplines, etc.  But it's very exploratory at this point.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 25 Mar 2014 07:36:26 +0100

On 03/24/2014 10:10 PM, Juliusz Chroboczek wrote:
>> - I think this could be implemented in user-space, but I'm afraid
>> that having to intercept the first data packet in order to build
>> the multicast tree would require a kernel module.
> 
> This is exactly the issue that the reactive protocol people have
> been struggling with for over a decade now, and that I mentioned in
> London during the discussion of AODVv2.
> 

Better to play tricks with a stable API to the kernel than having an
"outdated" kernel module after 12 months.

> Henning explained the trick to me as follows.  He puts a default
> route through a tun interface, which causes all unroutable packets to
> go to userspace.  He then buffers the tunnelled packets, and sets a
> more specific route whenever a route is established.  Yes, it's a
> hack, and one that only works in the absence of bona fide shorter
> prefix routes (HNAs in OLSR parlance).

It works for shorter prefix routes if you limit this prefixes to IPs
outside the AODV "main node addresses"... you just need to add a second
route for the whole "AODV node prefix" into the tun interface.

You will still have trouble with overlapping prefixes, but I don't think
there is anything you can do against this with AODV.

> (I also don't see how it handles AODV's error case, but that's a
> different issue.)

It does not.

To handle the error cases you should have a regular look at the IP
neighbor tables. If you loose a "next hop" of a route from the neighbor
table, you can mark the route as "timed out" and create a RERR.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Thomas Clausen <[email-masked]>
Date: Thu, 27 Mar 2014 20:11:51 +0100

> entirely in userspace.  Actually, it's more than that -- it's the only

I am not disagreeing with you here, the ability to make user-space implementations (without tun/tap hacks - which do not solve everything, as you point out) is hugely beneficial. You've seen how OLSR(v2) is designed for exactly that, so we definitely are on the same page on this. Implementability should be a key consideration for any protocol designer and specification writer.

I would suggest, though, that we be careful not to mix up reactive routing protocol issues with what concerns ODMRP, as I believe that they are very different in nature (technically, procedurally, and politically).

The technical difference:
	1) 	There's something inherently "on demand" in the "subscribe to a multicast group, 
		have an overlay constructed which includes you". You get IGMP/MLD signals sent on the
		segment between a host and a router, which the router "does something with", including
		getting multicast routing tables set up. I believe that ODMRP tries to tap into this, and 
		then that the overlay is constructed (and maintained) proactively. I do not think that there's 
		anything (in an implementation of) ODMRP that would necessitate data traffic transiting 
		user-space: contrary to a reactive unicast routing protocol, joining of a group is not data
		triggered, but triggered by an explicit application action (API call).

The procedural difference:
	2)	ODMRP Is very explicit about being exactly an experiment, by way of aiming for publication
		as an experimental RFC. I believe that what we're in the process of discussing here is
		exactly the experiments that we would like to have happen -- which include "is there a
		way in which this can be implemented without resorting to "hacks" and without requiring
		kernel-space coding? (My inkling is "yes, possibly with some constraints, once a stable
		spec is out there, I might set forth coding stuff to figure it out")
		
		(The reactive unicast routing protocol, on the other hand, aims for publication on std. track
		  -- for which the bar of "running code" and "known implementability" should be much higher,
		  and such issues expected to be uncovered, documented and addressed by way of 
		  also documented solutions -- themselves with documented limitations, validated by way of 
		  running interoperable code.)

I'd like to ask the ODMRP authors if this sort of stuff is part of what they're writing up as part of "The Experiment" section for this document? It would seem to me that it should be, and that an "implementabiity experiment" is a quite viable sub-reason for an experimental RFC to be published?

Cheers,

Thomas

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 27 Mar 2014 21:15:31 +0100

> Implementability should be a key consideration for any protocol
> designer and specification writer.

Nicely put.

> I would suggest, though, that we be careful not to mix up reactive
> routing protocol issues with what concerns ODMRP, as I believe that
> they are very different in nature (technically, procedurally, and
> politically).

From the technical point of view, I'd really like to see an API emerge
that solves both problems.  Perhaps that's wishful thinking.

> ODMRP Is very explicit about being exactly an experiment, by way of
> aiming for publication as an experimental RFC. [...] The reactive
> unicast routing protocol, on the other hand, aims for publication on
> std. track -- for which the bar of "running code" and "known
> implementability" should be much higher,

Fully agree.

-- Juliusz

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 27 Mar 2014 21:41:18 +0100

Thank you.

> that solves both problems.  Perhaps that's wishful thinking.

Everything is possible in an API. I would like to see an approach emerge that does not require me to go lobby Apple and MS to change their systems.....'cus they probably won't. 

>> implementability" should be much higher,

Seems that we are in violent agreement here, this will be a really short fight.....

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Fri, 28 Mar 2014 07:32:55 +0100

> that solves both problems.  Perhaps that's wishful thinking.

We have yet to see a kernel API for multicast forwarding in MANET...
or maybe it is there, but nearly undocumented.

Henning Rogge