[email protected]
[Top] [All Lists]

Re: ops reqs on IP FRR

Subject: Re: ops reqs on IP FRR
From: Alia Atlas
Date: Mon, 14 Nov 2005 08:54:57 -0800
On 11/14/05, mike shand <[email protected]> wrote:
> At 16:30 14/11/2005, Alia Atlas wrote:
> >Mike,
> >
> >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.

Ah, well, that would reduce it to meaningless with no loopprevention :-)
>
> >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.

Exactly.

Thanks!

Alia

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

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