Re: I-D Action:draft-ietf-rtgwg-lf-conv-frmwk-07.txt

[[e-mail]]

 
The whole idea about micro-loop mitigation and all the multipath topics  
including the via-solution that the rtgwg produced lately are based on the 
state  of art knowledge about Dijkstra.
On my website (_www.hummel-research.de_ (http://www.hummel-research.de) )  
an  example demonstrates how to transform any network into an All Links  
Spanning Tree (ALST) rooted at whichever particular destination.  Provided that 
any node knows the network's topology it may compute for each  destination 
node such an ALST, and as a result properly esteem ALL links of the  entire 
network (not just the adjacent links) for the sake of packet forwarding  
towards some specific destination node. Dijkstra would yield only an ALL  Nodes 
Spanning Tree (ANST) rooted at that destination (=the blue subtree in my  
example). However by memorizing the sequence by which each node is assigned 
its  definite predecessor and by transforming - while siffing from node to  
node according to this sequence - all those links into arcs,  which Dijkstra 
didn't transform into its best-hop arcs, you will get an ALL  Links Spanning 
Tree (ALST) which provides even more loop-free multipath  routes than does 
ECMP( the red arcs).   You may even forward a  packet oppositely directed 
than is the used  arc, by adding an  indication bit in the IP-header  to make 
sure that there after 2 hops will  be enforced which both will get the 
packet closer towards the desination.1 Hop  to a more remote neighbor node, 
followed by 2 best hops  without passing the current node would perfectly do.
 
In the end, any node can find out how to esteem    A L  L    its adjacent 
links and can rank them from
1) Dijkstra-best, 2) ECMP, 3) loop-free detouring without getting farer  
away, 4) loop-free detouring while getting farer away, 5) detouring while  
accepting a loop, e.g. some crankback hops 6) recognizing that there is an  
inevitable dead-end so that the packet must be discarded.
 
As a result any (topology-aware) node gets a 100 % orientation with respect 
 to forwarding to which ever destination node.Indeed it may properly esteem 
all  its adjacent links.Also, by properly designed IP-Header bits it may 
guide the  packets via some unusual and even crankbacking detours, 
endless-loop-free. This  however also means: The few bits in the IP-Header must not me 
snatched by  others, e.g. by re-ECN.
 
Instead based on the ALST each node may also look backwards, and detect a  
particular ingress sector subnetwork, i.e. a bunch of nodes which would use 
it  as transit for packet forwarding towards a particular destination node. 
It would  be very easy to design an re-ECN-alternative protocol which 
includes messages,  that are originated by such a congested transit node and are 
forwarded towards  all nodes which are reached by going inverse to the ALST's 
arcs (each hereby  notified node would know by itself wether or not to 
forward the message even  further upstream, and of course towards which nodes 
further up ).
 
This I think is the right way to deal with congestion, as opposed to  
re-ECN, and again: the few bits in the IP-header should be subject to routing of  
THIS packet only !!!. 
There are even more routing topics (e.g. multihoming support by the network 
 rather than to make this an end-user-only topic) which should worry if the 
few  bits of the IP-header were stolen for other purposes than routing THIS 
 packet.
 
Heiner
 
 
 
 
 
---------------------------------------------------------------------------------------------
In einer eMail vom 20.10.2009 15:00:37 Westeuropäische Sommerzeit schreibt  
[e-mail]:

A New  Internet-Draft is available from the on-line Internet-Drafts  
directories.
This draft is a work item of the Routing Area Working Group  Working Group 
of the IETF.


Title       : A Framework for Loop-free Convergence
Author(s)       : M. Shand, S. Bryant
Filename        :  draft-ietf-rtgwg-lf-conv-frmwk-07.txt
Pages     : 23
Date       : 2009-10-20

A micro-loop is a packet forwarding  loop which may occur transiently
among two or more routers in a hop by hop  packet forwarding paradigm.
This framework provides a summary of the causes  and consequences of
micro-loops and enables the reader to form a judgement  on whether
micro-looping is an issue that needs to be addressed in  specific
networks.  It also provides a survey of the currently  proposed
mechanisms that may be used to prevent or to suppress the  formation
of micro-loops when an IP or MPLS network undergoes topology  change
due to failure, repair or management action.  When sufficiently  fast
convergence is not available and the topology is susceptible  to
micro-loops, use of one or more of these mechanisms may be  desirable.

A URL for this Internet-Draft  is:
http://www.ietf.org/internet-drafts/draft-ietf-rtgwg-lf-conv-frmwk-07.txt

Internet-Drafts  are also available by anonymous FTP  at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will  enable a MIME compliant mail reader
implementation to automatically  retrieve the ASCII version of  the
Internet-Draft.


_______________________________________________
rtgwg  mailing  list
[e-mail]
https://www.ietf.org/mailman/listinfo/rtgwg