Re: I-D Action:draft-ietf-rtgwg-lf-conv-frmwk-07.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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)  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 Internet-Drafts at ietf.org:
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
rtgwg at ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg
 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.