Subject: Re: Adopting draft-francois-ordered-fib-00.txt as a WG document

From: Alex Zinin <[email-masked]>
Date: Thu, 16 Feb 2006 22:39:59 -0800

Folks-

 Sorry for the delay on this. Couple of things:

  1. I'd like to clearly understand whether this is proposed as a
     replacement for PLSN or as a next-step mechanism. This is related
     to the discussion about WG next steps that we'll need to hold in
     Dallas.

  2. I'd like us to give Olivier et al an opportunity to present their
     simulation results in Dallas, and have a serious face-to-face
     discussion about this doc there.

-- 
Alex
http://www.psg.com/~zinin

Friday, November 25, 2005, 1:08:23 AM, stefano previdi wrote:

> On Nov 22, 2005, at 2:29 PM, Don Fedyk wrote:

>> Stewart
>>
>>>
>>>
>>>
>>> Don Fedyk wrote:
>>>
>>>> Oliver
>>>>
>>>> A couple of questions for the group. So far the work accepted by the
>>>> group mainly been focused around routers immediately adjacent to a
>>>> failure or neighbors of routers adjacent to a failure.  This work
>>>> extends the ordering to all routers in an area.
>>>>
>>>>
>>> Don
>>>
>>> That is incorrect.
>>
>> Please elaborate.
>> Given a failure with a network with all nodes with PLSN and all nodes
>> with oFIB. Do PLSN and ordered FIB actions extend to the SAME routers?
>> Reading the document it is my understanding is that oFIB is different.
>> We have to accurately compare oFIB against the alternatives.  The work
>> group and design team were working on scheme to get the maximum benefit
>> with the minimum of changes. oFIB gives complete coverage with more
>> change. The question at hand is how much coverage and how much change.
>>
>>>
>>> With PLSN ALL routers that have a path affected by the change
>>> may have their convergence delayed as a result of the change.
>>> This may extend to many hops from the failure.
>>>
>>> Even thought you are protecting only a single link with basic
>>> repair, PLSN needs to be deployed throughout the network.
>>
>> I never said you don't require PLSN everywhere, just that effect is
>> less.
>> There is less code with PLSN. There are only three types of classes and
>> 2 timers.
>> oFIB is perhaps more ideal but it comes with more code and more 
>> effects.

> oFIB is indeed better from a coverage point of view and
> this justifies (to me) the overhead in the amount of code
> to be written (if any).

> Having said that, I did implement oFIB a little while
> ago and didn't find the complexity of the algorithm such
> that it couldn't be smoothly integrated into a well
> known routing protocol implementation.

> To me, it's not really the number of timers that matter,
> it is more the number of SPT/rSPT you have to compute
> (knowing that cases like PLSN or oFIB you can't use
> i-SPF).

> s.

>>>> The law of diminishing returns is that most of the benefit
>>> is for the
>>>> neighboring routers and the extra effort is for a small amount of
>>>> traffic.  So I think we need to make sure that operators
>>> feel this type
>>>> of extension is important. I believe you need to know that
>>> all routers
>>>> within the area have the capability to ensure orderly operation.
>>>>
>>>> Other questions:
>>>> If one router in the area does not support the feature what is the
>>>> action?
>>>>
>>>>
>>> With PLSN and oFIB all routers in the area MUST support the
>>> mechanism. In both cases the consequence of a router using
>>> traditional convergence may be a sustained loop. With both
>>> mechanisms it is possible to detect the presence of a non
>>> conforming router and inhibit the loop protection mechanism.
>> None of this is in the document.
>>
>>>
>>>
>>> The tunneling mechanism that we proposed is much more
>>> tolerant to non-conforming routers.
>> The thread was headed down decoupling the oFIB from the protection
>> mechanisms.
>>
>>>
>>>> Also if an unplanned event occurs during ordering would you
>>> immediately
>>>> shut of the fib ordering?
>>>>
>>>>
>>> Yes
>>>
>>>> This draft would replace the micro loop analysis and Path
>>> locking via
>>>> safe neighbors draft? While it is not perfect it also reduces the
>>>> effect of changes (planned or unplanned) when used in
>>> conjunction with
>>>> loop free alternates.
>>>
>>> It is by no means as simple as that.
>>
>> And what does that mean? None of this is simple I will agree. So how 
>> are
>> people to make an educated assessment of the situation? What worries me
>> is that there is no cost/complexity benefit analysis for ordered FIB.
>> PLSN in not perfect so we introduce oFIB.  I'm not at all convinced we
>> have the mandate to work on more complex schemes.  So far only the
>> member of the original design teams are discussing this.
>>
>> At any rate I think the document needs to address these issue before
>> being considered as a working group document.
>>
>> Don
>>
>>
>>>
>>> - Stewart
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Rtgwg mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/rtgwg
>>

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