[email protected]
[Top] [All Lists]

Re: ops reqs on IP FRR

Subject: Re: ops reqs on IP FRR
From: mike shand
Date: Mon, 14 Nov 2005 16:44:11 +0000
At 16:30 14/11/2005, Alia Atlas wrote:

On 11/14/05, mike shand <[email protected]> wrote:
> At 03:52 12/11/2005, Alia Atlas wrote:
> >  Second,
> >that by default, DELAY_TYPEC should be 0 - and then then knowledgable
> >operator could adjust it.  This would impact the effectiveness, but
> >give the original behavior (modulo the small % extra delay to collect
> >advertisements).
> >
>          Maybe I'm misunderstanding what you are proposing here, but
> doesn't that just reduce to no loop prevention?

No,  I don't think so.  DELAY_TYPEB is still non-zero.
Oh I see. I sort of assumed you were leaving out type B's as well.

It means type
A and type C change to their new next-hops immediately.  Type As (of
course) and type B are still protected.  What wouldn't be protected
would be the type C to anything loops.  That would definitely reduce
the coverage of PLSN, which is quite unfortunate & not the normal
recommendation.  On the other hand, it's the only way I see of
ensuring that the use doesn't cause additional traffic losage when S
doesn't have an alternate.

If you have the time, could you take a look at your simulation results
& see what this does to the coverage?  (% of potential micro-loops)
OK. I'll have a go. So we treat type As and type Bs as normal, but change
type Cs at the same time as type As. Is that right?
i.e. as you said originally, just change the type C delay timer to zero.


Rtgwg mailing list
[email protected]

<Prev in Thread] Current Thread [Next in Thread>