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

Robert Raszuk <robert@raszuk.net> Sun, 27 November 2011 15:57 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FFB21F8B62 for <idr@ietfa.amsl.com>; Sun, 27 Nov 2011 07:57:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.006
X-Spam-Level:
X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, GB_PAYLESS=0.5, J_CHICKENPOX_41=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HZJjur7MJT8 for <idr@ietfa.amsl.com>; Sun, 27 Nov 2011 07:57:13 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id E27A821F8B2D for <idr@ietf.org>; Sun, 27 Nov 2011 07:57:12 -0800 (PST)
Received: (qmail 25951 invoked by uid 399); 27 Nov 2011 15:57:12 -0000
Received: from unknown (HELO ?192.168.1.91?) (83.31.148.193) by mail1310.opentransfer.com with ESMTP; 27 Nov 2011 15:57:12 -0000
X-Originating-IP: 83.31.148.193
Message-ID: <4ED25DD9.8050209@raszuk.net>
Date: Sun, 27 Nov 2011 16:57:13 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: "UTTARO, JAMES" <ju1738@att.com>
References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> <CAKP9Kx_k+RWqDdrh+64-G8jtyOOYJsefv_5481u_MA8_P42eOg@mail.gmail.com> <B17A6910EEDD1F45980687268941550FA34B06@MISOUT7MSGUSR9I.ITServices.sbc.com> <4ED12015.6060002@raszuk.net> <B17A6910EEDD1F45980687268941550FA34B6A@MISOUT7MSGUSR9I.ITServices.sbc.com>
In-Reply-To: <B17A6910EEDD1F45980687268941550FA34B6A@MISOUT7MSGUSR9I.ITServices.sbc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "idr@ietf.org List" <idr@ietf.org>
Subject: Re: [Idr] Adoption of draft-varlashkin-bgp-nh-cost-02 as IDR WG document?
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: robert@raszuk.net
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Nov 2011 15:57:14 -0000

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

> [Jim U>] I believe that there should be some determination made as to
> what to flood.. I wasn't actually thinking of it from a topology
> sense but from a perspective of which prefixes should get the
> enhanced service definition above and beyond a traditional internet
> definition..

Since we are talking about Internet routing what is your definition of 
"enhanced service definition" vs "traditional internet definition" ? Are 
you trying to say that those who pay less do not deserve closest exit ? 
In other words if I am a customer and I did not pay premium my packets 
will end up traveling around ATT's autonomous system miles before they 
exit towards the destination ?

I think most providers today do value sending customer packets to their 
closest exit point from the point of view of PE which is receiving those 
packets rather then from the point of view of some control plane RR 
sitting somewhere in the middle or maybe on the other side of their AS. 
That's why for Internet routing RRs are still in the data path most 
often at the core to pop boundaries and POPs are fully meshed.


> [Jim U>] Hmm I guess I am not understanding this. I am
> under the impression that path P1 is learned from let's say 25
> different peering points.. first let's examine let's examine P1 from
> Peer A and Peer B where these two peers are close together.. The RR
> serving these two POPs would forward either P1:NH=A and P1:NH=B to
> RR1 based on its local BGP Table that has been statically configured
> (Ouch) ..

Ouch x 2 :)

1. If you read the IDR WG draft RRs are fully meshed and RRs exchange 
all externals paths.

2. The draft which is the subject of this thread or just IGP itself 
avoid to have any static configuration on RRs.


> If RR1 also learns P1:NH=C then you want the RR1 to
> evaluate the BGP "Cost" and select the NH with the best IGP cost.. is
> that right? Ok So RR1 has statically accumulated the cost from itself
> to RR and to the egress peer?  Is it really your intention to create
> unique tables at every point in the network which would essentially
> be an IGP graph of the topology using the local node as the root..
> That is an operational nightmare and probably a catastrophe..

LOL ... therefor I guess you will never deploy LFA as this would be a 
catastrophe too.

> Again
> as I stated before there is no way to adapt to a changing topology
> due to failure or maintenance.. can you address that..

There is no static configuration involved at all so adjusting to 
topology changes is automatic and build in. For both auto IGP 
calculation as well as for NH-SAFI there are thresholds of information 
distribution.


> It is not clear how sub-optimal the selection of P1 with addpaths=2
> would be. Certainly there are other metrics i.e AS-PATH length which
> will immediately paths Again to our ex.. with addpaths=2 in the RR
> topology you would always send the two best IGP paths based on cost..

That would be the cost from the point of view of RR. That is the 
problem. If you distribute RRs to be in each POP .. there is no problem. 
However more and more operators are moving towards control plane RRs .. 
even control plane RR in the virtual environments.

> If you do this at every point how sub-optimal could it be?  Have you
> done an analysis of this... That would be a good addition to the
> draft as it would clear up any confusion in terms of addpaths
> applicability and the need for this draft..

See above. Analysis is obvious.

> view. [Jim U>] I thought you wanted an RR-client ( PE ) to select the
> best egress NH for a given path..Assuming a BGP 3107 design with AIGP
> ( pseudo IGP )

AIGP can still be used but applied as additive metric from the point of 
view of the client not the RR.

Best,
R.