Re: [Idr] draft-chen-bgp-avoid-transition-01.txt

[Enke Chen <[e-mail]>]

Hi, Tom:

Thanks for your comments, and sorry that I forgot to reply to your original
message earlier. Please see my comments inline.

> Message-Id: <[e-mail]>
> Cc: [e-mail], [e-mail]
> From: Thomas Barron <[e-mail]>
> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
> To: Enke Chen <[e-mail]>, [e-mail]
> 
> Hi Enke,
> 
>     Attached is an email I sent to IDR that discusses some issues around  
> your draft.  I don't think I have seen a reply.
> 
>    I will add now that since that note I've discussed and thought a bit  
> more about your argument in 5.2, and I think it is quite clear (and is  
> indeed the received opinion nowadays) that the essential ingredient in  
> these route-oscillation problems is the interaction of Route Reflectors  
> and IGP costs.

MED plays a major role as well.

> Using sufficiently high IGP costs between clusters will suffice to stop
> the churn both in your scenario and in other scenarios that don't involve
> router-id.

Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR).

Re-configuring the IGP metric is certainly an option. However, changing the
IGP metric typically has much larger impact on the network traffic matrix,
and may not be desirable or feasible.

> Indeed, in your scenario if by chance  
> the times of arrival correspond in the same order to that determined by  
> the router-ids the churn is not avoided by your algorithm either (the  
> proof is tedious, but intuitively: start the scenario with the same  
> ranking of tie-breakers, just use time-of-arrival instead of router-id;  
> then realize that this order gets preserved as the oscillation proceeds  
> because the repeatedly advertised-and-withdrawn route will always be  
> "newest" and correspond to the largest router id in the original  
> scenario.)

Do you have a specific example?  I would like to understand better whether
the algorithm is applicable to the example.

Unlike the ADD-PATH approach (which is a complete solution), the proposed
algorithm is effective only for a subset of route oscillations.

> 
>    But as I say in the attached, my argument is really with section 5.2,  
> not with your overall proposal.  There are implementations that provide  
> a knob to do just what you are documenting and I agree that the BGP  
> spec should provide for this option.
> 
>     Best regards,
> 
>    Tom Barron
> 
> 
> >From [e-mail] Mon Nov 10 11:51:50 2003
> From: Tom Barron <[e-mail]>
> To: [e-mail]
> Cc: Thomas P Barron <[e-mail]>
> Message-ID: <[e-mail]>
> 
> Enke, Srihari, et. al:
> 
> I have some questions about draft-chen-bgp-avoid-transition-00.txt.
> I'm glad to see this draft since there are implementations out there
> using the route-selection algorithm this draft proposes, and since the
> proposed algorith is not what is documented in RFC1771 or in
> draft-ietf-idr-bgr4-22.txt section 9.1.2.2.
> 
> First, is it the intent of this draft that the proposed algorithm 
> should *replace* the algorithm currently documented, or just that
> it be added as an option?

It is a backward-compatible extension to the base BGP spec.. Whether
it is ON or OFF, that is an implementation decision. (If that is the
intent of your question.)

> 
> Second, while I think the claim in 5.1 that the proposed algorithm
> avoids an unnecessary best path transition is quite straightforward,
> there ought to be some discussion of concerns that have been expressed
> about the consequent lack of determinism in route selection.  See
> for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt
> and appendix A of "Guidelines for Interdomain Traffic Engineering" by
> Feamster, Borkenhagen, and Rexford.  I'm not personally convinced
> that this local indeterminism is a real big deal, but I do think it
> needs some discussion in your draft.

As I recall, the only practical concern raised so far is the impact on
BGP testing script by the proposed algorithm, and the subject (impact
on the testing script) seems to be outside the scope of the document.
Please let me know if I have missed any other practical concerns.

> 
> Third, I found the argument at 5.2 to the effect that the proposed
> algorithm reduces route oscillation a bit unclear.  Maybe just a bit
> more text is needed, but it seems to me that the really essential
> ingredient in your setup in figure 1 and figure 2 is not the router
> ID, but the high intracluster IGP metric.  Indeed, though you cite
> RFC3345, that work focuses on IGP metrics, not router ID, as a
> critical factor for "type 1" oscillation scenarios (yours appears to
> be a type 1 variant.)  If adjusting IGP metrics is sufficient to fix
> both your oscillation scenario and other type 1 scenarios, but
> shifting from Router ID selection to the proposed time-of-arrival
> algorithm is not sufficient for type 1 scenarios in general, then the
> contribution of the proposed algorithm to the route oscillation
> problem does not seem very decisive.  On the other hand, if using the
> proposed time-of-arrival algorithm yields a general solution to
> oscillation problems, then this reader at least did not get that from
> the draft as currently written.
> 

We will work on adding more text to clarify.

> I'm glad you folks wrote this draft.  I hope it's clear that I'm
> not against your proposal, but rather want to address some gaps
> in my own understanding of the issues that surround it.
> 

Some of the gaps are with the text in the document :-)
We will work on improving it in the next version.

Regards,

-- Enke

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr