Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document?

[Robert Raszuk <[e-mail]>]

James,

 > First of I do not anticipate having to send more than two paths for
 > almost all cases.

Great that you said this. As tier 1 I have 25 paths for each b_net. I 
have a path for each of my peering point with other tier1s or tier2s

How do I figure which ones are optimal for the client or group of 
clients located in the same POP from the route reflector pov ?

With add-paths or without add-paths the problem to be solved remains 
exactly the same.

Problem goes away only in the following cases:

- if you have only 1 path for all prefixes,
- if you have only 2 paths max for all prefixes,
- if you decide to send _all_ my domain external paths to all clients .. 
in the above case 25 paths ! Sorry ... bad idea.


 > The AIGP metric is used to carry the "cost" to the NH of the path..

AIGP is completely irrelevant here. In fact it is a pretty poor design 
choise to choose a path for all clients based on AIGP metric or IGP 
metric from the point of view of control plane route reflector in a 
given AS.

Keep in mind that AIGP is relevant only when number of ASes are under 
the same administration. Not that common case in the Internet :)Usually 
folks do know how to run single AS globally without any issues.

The problem which needs to be solved is to provide information to the RR 
in order for RR client to be able to receive optimal paths - optimal for 
example to follow hot potato routing requirements in a given AS.

If one would follow AIGP metric some control plane RR clients may 
clearly get not optimal exit paths from the AS they reside point of view.

Best,
R.


> Ilya,
>
> Apologies for not responding sooner.. I do have some questions in re
> the draft..
>
>
> 1. Motivation
>
> "ADDPATH solves this problem by letting route-reflector to advertise
> multiple paths for given prefix.  If number of advertised paths
> sufficiently big, route-reflector clients can choose same route as
> they would in case of full-mesh.  This approach however places
> additional burden on the control plane."
>
> First of I do not anticipate having to send more than two paths for
> almost all cases. Secondly this is applied on a per prefix basis so
> there is not a doubling of routing state.. So I do not think this
> concern is warranted.. There are tools and guidelines for setting the
> number of paths see
> http://tools.ietf.org/html/draft-ietf-idr-add-paths-guidelines-02 for
> a complete description which examines a number of use cases..
>
> "For example, if next-hop information itself has been learned via BGP
> then simple SPF run on link-state database won't be sufficient to
> obtain cost information."
>
> The AIGP metric is used to carry the "cost" to the NH of the path..
> This draft was developed to address the exact issue of carrying NH
> info in bgp and losing the notion of an accumulated cost.. Why is
> that not sufficient?
>
> I also do not see how you del with this except for the creation of a
> table of NHs and associated costs.. But how is that created? Does the
> new AFI/SAFI accumulate costs across multiple IPG domains?
>
> I would like to understand what scenarios require this solution above
> and beyond a correct addpaths setting and/or AIGP..
>
> 2. Next-Hop Information Base
>
> "  NHIB can be populated from various sources both static and
> dynamic. This document focuses on populating NHIB using BGP.  However
> it is possible that protocols other than BGP could be also used to
> populate NHIB."
>
> This is a bit vague.. if you are learning NHs in BGP without the
> accumulated cost then the only way to populate is to statically
> define costs to NHs.. this seems burdensome and is not easily change
> to reflect the dynamic of cost due to maintenance or failure..
> putting aside the difficulty in creating and maintaining this NHIB it
> seems that it cannot respond to changes in the topology..
>
> 3. BGP BEST PATH SELECTION MODIFICATION
>
> Lots of chatter about the sanctity of the BGP Best path selection..
> Have you spoken to folks who seem to be vehemently opposed?
>
> 4.
>
> A general note about introducing AFI/SAFIs.. This is always not
> trivial as it introduces scale, control plane complexity and
> vulnerability.. What happens if the AFI/SAFI becomes compromised? It
> would be good if you could describe that here.. My assumption would
> be that you would fall back to igp cost?
>
> In summary, I do not understand how addpaths and AIGP do not solve
> this problem.
>
>
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Anton Elita Sent:
> Wednesday, November 23, 2011 11:05 AM To: [e-mail] List Subject:
> Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG
> document?
>
> Support
>