Re: [Roll] Closure text for ticket #86

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Michael:

I tend to agree that we are somewhat repurposing G... or extending it if
that's a better word.
The clear part of G's meaning is related to floating DAGs which is a
concept that comes with global instances.
Local instances were defined and reserved in RFC 6550 for use in P2P.
RFC 6550 did not push as far as locking meaning for the G bit.
It actually makes sense that the draft that really defines a use of
local instances also defines what G does in that world.
And here we thought is that instead of comparing DODAGs within a DAG
associated to a global instance, G would now be used to compare DODAGs
that are each a DAG associated to a local instance.
The semantic shift is that now, G eventually compares the applicative
value of different apps for a user as opposed to the routing value of
various DODAGs for an application. We went up a level.
That's actually not a bad idea since P2P is getting us deeper in the
world of autonomic networks and thus into higher level abstractions.
I do not see that there is any opposition in doing it. The wish here is
that the text must indicate more clearly that we are doing this shift.
I think that Mukul will provide the additional informative sentence that
we'd like to see. 
In any case, I see no point in keeping that ticket open. Too much ML
bandwidth was used on that discussion. Unless Richard speaks up again
which I doubt, I think we really want the ticket and discussion closed.
 
Cheers,

Pascal


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
Michael Richardson
Sent: jeudi 12 avril 2012 19:40
To: [e-mail]
Subject: Re: [Roll] Closure text for ticket #86


>>>>> "Richard" == Richard Kelsey <[e-mail]> writes:
    >> "The origin sets the G flag to indicate the relative importance
    >> of the route discovery it is initiating. The G flag is set to one
    >> if this particular route discovery is more important from
    >> application's perspective than some other route discovery. In
    >> other words, the origin sets the G flag to one if this particular
    >> route discovery helps meet the application defined goal
    >> \cite{rpl}. Thus, the G flag setting helps an intermediate router
    >> choose which route discoveries to participate in if it cannot
    >> participate in all route discoveries. An intermediate router
    >> SHOULD participate in route discoveries with G flag set to one
    >> (in preference to ones with G flag set to zero)."

    Richard> If you want to repurpose the G flag in this way you need to
    Richard> be clear that the usage in RFC 6550 no longer applies.  I
    Richard> think that the best way to do this would be to say that
    Richard> clause 3 of 8.2.2.2 does not apply to P2P DAGs:

I would like to understand why you feel that in the P2P case, setting
G=1 is somehow repurposing the G flag.

    Richard> Not having floating DODAGs would mean that the original use
    Richard> of the G flag is no longer necessary.

There is no use in floating DODAGs... *for the P2P case*.
I think that floating DODAGs have many uses in the P2MP case, during
DODAG construction and repair.

-- 
]       He who is tired of Weird Al is tired of life!           |
firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [e-mail] http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video
<http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.