Re: Reconvergence micro-loops: problem and solutions overview

[Stewart Bryant <[e-mail]>]

Don Fedyk wrote:

>Mike
>
>Tunnels require mechanisms to set them up, and remove them. 
>
For IPFRR we would use multi-point IP tunnels. We propose that when you
configure a router to allow it to be used as an IPFRR repair point it 
multicasts
its tunnel endpoint identity in the IGP. The other routers, when they 
chose their
P nodes, just encapsulate their packets to that tunnel endpoint. Unlike MPLS
IP requires no further setup, maintainance or removal.

>The details are
>out of scope in your current tunnels draft.
>
>One can assume that the
>procedures must be at least analogous to setting CSPF tunnels for MPLS. 
>
Not at all.

>A
>path, complete or partial, must be built and state maintained in some form.
>  
>
Not for IP.

>But regardless they are not pure IP forwarding based. 
>
In what way impure? The header on the front of a tunnelled packet is an 
IP header
so it's pure IP forwarding from the encap to the decap. The repairing router
has to encap, but logically this is just using an alternative next-hop. The
decapsulating router (at the chosen tunnel endpoint)  is doing IP tunnel
removal which is a well known IP packet operation.

- Stewart

>Regards,
>Don 
>
>  
>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] 
>>On Behalf Of mike shand
>>Sent: Thursday, September 23, 2004 3:05 PM
>>
>>
>>At 14:39 23/09/2004 -0400, Alia Atlas wrote:
>>    
>>
>>>At 01:17 PM 9/23/2004, mike shand wrote:
>>>      
>>>
>>>>At 12:20 23/09/2004 -0400, Alia Atlas wrote:
>>>>The advantage of the other two mechanisms is they actually 
>>>>        
>>>>
>>work when a
>>    
>>
>>>>link is added or the cost of a link is changed.  If you are 
>>>>        
>>>>
>>arguing that 
>>    
>>
>>>>micro-loop prevention is vital to support SLAs and avoid 
>>>>        
>>>>
>>traffic loss, 
>>    
>>
>>>>those same arguments seem to me to apply for when a link is added.
>>>>        
>>>>
>>>>>Both the incremental cost advertisement and the ordered SPF 
>>>>>approaches
>>>>>solve the problem for the new link case as well as the 
>>>>>          
>>>>>
>>failed link case.
>>    
>>
>>>>And so do tunnels!
>>>>        
>>>>
>>>How so?  I can infer what one might do, but it is not 
>>>      
>>>
>>described at all 
>>    
>>
>>>in
>>>your draft, and I'm not certain what this would do to the 
>>>      
>>>
>>traffic load on 
>>    
>>
>>>the links.
>>>      
>>>
>>In draft-bryant 6.2 (for example), globally replace "failure" by "new 
>>adjacency" and that is pretty much it.
>>
>>
>>
>>
>>    
>>
>>>How and when does the use of the tunnels get terminated?
>>>      
>>>
>>When everyone has converged (as for link down). e.g. on a timer
>>
>>    
>>
>>>What happens if there is a second change?  How is a new node handled,
>>>where multiple new links may be learned of simultaneously, 
>>>      
>>>
>>or similarly a 
>>    
>>
>>>failed node?
>>>      
>>>
>>Unrelated second changes are generally a problem (even with 
>>ordered SPFs), 
>>but the related set of changes caused by node down/up turn 
>>out to be OK.
>>
>>         Mike
>>
>>
>>
>>    
>>
>>>Alia
>>>
>>>      
>>>
>>_______________________________________________
>>Rtgwg mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/rtgwg
>>
>>
>>    
>>
>
>_______________________________________________
>Rtgwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/rtgwg
>
>
>  
>


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