Subject: [Roll] new Industrial routing reqs draft

From: Kris Pister <[email-masked]>
Date: Thu, 30 Oct 2008 18:15:50 -0700

Pascal and I tried to incorporate all of the comments that we got.  I 
still have two open issues with JP's comments (surprise! :) )

I've excerpted them here:
------------------- 
Issue #1 

"The routing protocol MUST route on paths that are changed to
   appropriately provision the application requirements."  
 
JP> This should translate into "The routing protocol MUST dynamically 
recompute path if the underlying topology changes.
 
No, I think that you're missing the point.  Say I currently have a route 
from A->B->Z that is provisioned to handle 1 packet every 5 seconds. 
 There are other routes, e.g. A->C->Z that are known to exist, but are 
not used.  Then A requests 100 times more bandwidth, and B announces 
that it can handle twice the bandwidth, but anything more would violate 
it's energy-scavenging-limited power restrictions.  This triggers both a 
need to generate new routes, and to update a bunch of L2 provisioning. 
 You could try to auto-detect-and-provision on L2, but if the service 
request is based on latency instead of BW, then there is no way for L2 
to figure that out by itself.  Solving the routing problem without some 
information exchange with L2 is not possible.

JP> Back to our long and interesting discussion the subject matter but 
as worded it was not that obvious that you were referring to that issue. 
As you know we are organized in layers ;-) I'm not saying that the 
dynamic provisioning a new links according to real time traffic analysis 
is a bad thing. As a matter of fact we did work on such architectures at 
the IETF (MPLS with VNT, ...) but this is not strictly speaking a 
routing requirements. The routing engine computes paths based on 
physical or logical topologies. If there is a need to dynamically adapt 
such topologies according to upper layer requirements, this is not 
really a routing issue. I am not saying that we will not work on this at 
some point, but let's this leave out of the scope of this ID.

KP: I don't believe that this can be left out.  It may be that if I 
still need to get the language right so that you understand what I'm 
talking about, but the concept is critical to routing.  So I didn't 
change this part from the last draft.
-------------  Issue #2

"Hop-by-hop path diversity is used to improve latency-bounded
   reliability."
 
JP> Path diversity does not help with latency-bounded reliability ... It 
does help to increase packet delivery if you use a 1+1 technique, or to 
find an alternate path or limit the proportion of flows impacted by a 
single failure but not for latency. What did you mean ?
 
Path diversity *does* help with latency-bounded reliability, and I have 
volumes of data to prove it.  In LLNs the PDR on individual links can 
very rapidly change by many tens of percent, up to and including a 
sudden transition from near 100% to 0%.  If I have a 1s latency target 
for 99.9% of my packets, a substantial change in PDR needs to initiate 
new path computation, but I can't afford to wait around for the results 
of that effort - I need another path right now.  And that other path 
can't be something that I created as a backup yesterday and haven't used 
recently.  It needs to be exercised regularly so that I know that I can 
trust it.

JP> Here is the disconnect: we usually use path diversity for network 
recovery. By computing diverse path (link/node/SRLG) you can make sure 
that a single failure will not impact both paths; thus with 1+1 you 
guarantee data delivery and with 1:1 you are sure that you always have 
an available path upon network failure detection. Here your argument is 
that by having diverse path, if one path suddenly has a low PDR, by 
having a diverse path handy you can immediately use the second diverse 
path without waiting until a second path is computed. This is the same 
notion of path availability, not latency along the data path. As worded, 
the text says that because the path are diverse one can guarantee 
bounded latency. I think that we're on the same page, just a question of 
terminology. Can you use the notion of "path availability" and add a few 
words to avoid confusion ? Thanks.
KP: I added a sentence to try to address what you're looking for, but 
I'm not sure
if we can agree on what we're talking about.
----------
---------
Issue #3

"Therefore,
   the routing protocol MUST support auto-provisioning of field devices."
 
JP> To which extent ? Does that mean a true 0-configuration routing 
protocol ?
 
If by "true 0-configuration" you mean that someone who knows nothing 
about networking can bolt 10 pressure sensors onto an oil well head and 
not have to do anything else to get them to work, then yes.

JP> ;-) Here is my point. 0 config is always a great objective and then 
when you design the protocol, people usually requires the support of 
many features, options, ... That do require configuration. Thus we just 
need to be prudent when we say 0 configuration.

KP: I think that we really do mean 0-configuration.  that's what's 
happening in the field today with wireless HART.  If we can't come up 
with a protocol that at least has this mode as an option, I don't think 
that we'll make any friends in industrial.
---------
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll