[email protected]
[Top] [All Lists]

Re: Updated: draft-zinin-microloop-analysis-01.txt

Subject: Re: Updated: draft-zinin-microloop-analysis-01.txt
From: Alex Zinin
Date: Fri, 3 Jun 2005 16:48:55 -0700

>> >> >     For situation 2 (an A/B or an A/C combination), the implementation:
>> >>
>> >> >       1)   SHALL update the route with the new next-hops that 
>> satisfy the
>> >> >            safety condition without an additional delay
>> >>
>> >> >       2)   SHALL add the remaining new next-hops after DELAY_TYPEB.
>> >>
>> >>SB>> maybe clarify type B is NOT used, although, there seems to
>> >>SB>> be no protocol reason why use type B cannot be used.
>> >>
>> >>I'm not sure I understand what you mean here.
>> > Safe but not new primary neighbors (type B) could be used during the
>> > transition period.
>>That's what the text says, right?

> Well, it's a bit unclear.  It says "with the new next-hops", so that 
> implies, to me at least, that those are safe new primary next-hops.

> Also, the fact that in step 2 the remaining new next-hops are added and the
> type B next-hops aren't removed indicates that the type B next-hops aren't
> used.

>> > This is expressing a policy that they will not be; it
>> > would be safe to use them.
>>Sorry, still not clear enough to me--are you guys suggesting the text is
>>changed, if so how?

> Do you want the policy of using type B or not? If not using them, then the
> text is ok - but needs a clarifying statement that this means that the type
> B next-hops are not used due to policy.

OK, understood. Personally, I'd rather avoid extra next-hop flip-flop (and
hence traffic rerouting) and not use the temporary safe nbrs unless I have
to (as in the type-B case), but if you think we should explicitly allow
them, I'll add a MAY in step 1 and words on removal in 2.

Let me know.


Rtgwg mailing list
[email protected]

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