On 11/14/05, mike shand <[email protected]> wrote:
> 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.
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.
Rtgwg mailing list