>> >> > 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
>> > 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