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

Robert Raszuk <robert@raszuk.net> Mon, 21 November 2011 08:32 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 2970821F84DA for <idr@ietfa.amsl.com>; Mon, 21 Nov 2011 00:32:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
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 zINiSnrPB2pA for <idr@ietfa.amsl.com>; Mon, 21 Nov 2011 00:32:50 -0800 (PST)
Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 152B021F8447 for <idr@ietf.org>; Mon, 21 Nov 2011 00:32:49 -0800 (PST)
Received: (qmail 11112 invoked by uid 399); 21 Nov 2011 08:32:48 -0000
Received: from unknown (HELO ?192.168.1.57?) (178.42.173.212) by mail1310.opentransfer.com with ESMTP; 21 Nov 2011 08:32:48 -0000
X-Originating-IP: 178.42.173.212
Message-ID: <4ECA0CAF.1080701@raszuk.net>
Date: Mon, 21 Nov 2011 09:32:47 +0100
From: Robert Raszuk <robert@raszuk.net>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Shane Amante <shane@castlepoint.net>
References: <7B61DC70-08D9-46C7-8C15-5DD339C61C2D@juniper.net> <E8A8092A-6352-4A12-954A-B0D5E946BE6B@castlepoint.net>
In-Reply-To: <E8A8092A-6352-4A12-954A-B0D5E946BE6B@castlepoint.net>
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: Mon, 21 Nov 2011 08:32:51 -0000

Hi Shane,

> If this draft is adopted as a WG doc, I would like to see some
> refinements wrt the following: 1)  IIUC, the draft alludes to a
> situation where one can either send regular IGP Cost in the NH_SAFI
> attribute -or- "(not necessarily IGP cost, but whatever has been
> chosen to be carried in NH SAFI)".  See also Appendix A.2.  Although
> I see the "simplicity" of wanting to go with this latter direction
> (non-IGP cost in NH_SAFI), I think it has the potential to create
> some significant operational (and/or, implementation) hazards and
> thus should be considered for removal.  Unless, someone can convince
> us that it is, after all, "safe".

The addition of any arbitrary metric dates back to the discussion on the 
list where some folks expressed the need to have ability for manually 
configured "provider's policy exit selection" from any possible PE/ASBR.

With tunneled networks (which are prerequisite for such policy) and 
minimum operational carefulness I see that much harm in allowing the 
next hop "metric" from a given PE to be derived by other then IGP metric 
means. One could be static configuration, the other could be RTT to the 
next hop, one could be geographic distances etc ...

> More specifically, I think: a)  If
> a node -- let's say it's another RR client in the same cluster --
> does not understand (hasn't implemented) NH_SAFI, then how is it
> supposed to receive the NH value + "special cost", which presumably
> is needed at a bare minimum for routes to pass BGP's NEXT_HOP
> reachability check?

I would envision this SAFI to be used between RR and the client and be 
rather applicable to inter-cluster routes.

> i)  At the very least, this makes an assumption
> and puts a burden on the RR client to have, at the very least, a less
> specific route for the NH in it's IGP (or traditional BGP) for that
> purpose, which should get documented in a Operational Considerations
> section.

I don't think this is required.

> ii) What's potentially more concerning is that if RR clients
> in the same cluster are configured to be fully iBGP meshed, (not
> using client-to-client reflection on their RR), then if one of those
> RR clients can't see the NH_SAFI, then it could fall back on the IGP
> metric and make an inconsistent path selection and lead to forwarding
> loops.

Again this tool is not so much applicable to client to client. It is RR 
to client as optimal best path selection is a feature one would enable 
on RRs only.

>  b)  Can an operator stick any value he/she wants for NEXT_HOP
> in that field of the NH_SAFI?  Or, must the implementation only send
> a NEXT_HOP in NH_SAFI, when it has a valid match (IPv4 /32 or IPv6
> /128?) for that NEXT_HOP in their IGP routing table?

The next hop must be reachable. I do not see why /32 or /128 would be 
required. While with MPLS encap those may already be there anyway with 
IP encap this is not required.

> c)  Is the
> NH_SAFI + "special cost" only supposed to be configured on the RR or
> on the RR-clients and sent to the RR?  (I think it's the latter).

Yes.

> Regardless, it should be recommended that the RR-client must always
> send a consistent NH_SAFI + "special cost" to it's redundant set of
> (upstream) RR's -- or, the RR's must be configured identically with
> the same NH_SAFI + "special cost" -- in order to ensure consistent
> path selection at the redundant set of RR's.

I agree.

> 2)  I think the document could benefit from an "Applicability
> Statement" section, which: a)  More clearly articulates that this
> solution is primarily intended to be used in networks whose RR's
> don't have full visibility to IGP costs from the perspective of each
> of its clients due to well-known issues with lack of IGP visibility
> due to Inter-Area or Inter-Level summarization.

If you consider the pure metric propagation them I would agree. However 
some may argue that even in such cases we would like to send pure metric 
with NH_SAFI as only PEs/ASBRs are in position to determine if such NHs 
are for example labels switch paths really reachable from their location 
of the network.

> b)  I don't think
> this draft is aimed at Inter-AS use, since presumably MED's are still
> sufficient in that case?  Either way, that should get clarified.

I agree.


> 3)  I also think the document could benefit from an "Operational
> Considerations" section, which: a)  Discusses whether changes to
> "Administrative Distance" are needed at the RR's, specifically for
> the NH_SAFI addresses.  Are these going to be required (manually) by
> Operators or automatically through the implementators of NH_SAFI so
> that NH_SAFI are consistently selected for NH resolution compared to
> traditional IGP metric costs.

The assumption was (perhaps too implicit) that NH_SAFI replaces the 
value which nh_metric RIB check would return for a given NH.

>  For example, on Cisco iBGP AD is 200
> vs. IGP's such as OSPF or ISIS that are at 110 and 115, respectively.
> (There is a very brief discussion already in Section 3 that talks
> about using NH_SAFI instead of IGP cost, but it's not clear if this
> is enforced through the implementation of NH_SAFI or if it will be
> required of the operator to manually tune AD's to get this 'right').

IMHO it should be automated.

> b)  Recommendations that it would probably be advisable for operators
> to enable and tune SPF throttling in their networks and, more
> importantly, that implementations of NH_SAFI only flood "new" NH_SAFI
> information _after_ an SPF has occurred.  This would hopefully
> mitigate a vicious feedback loop from the IGP cranking through lots
> of SPF's and shoving that info into BGP toward an, already very busy,
> RR.

True. NH_SAFI would flood only new information as well as it would flood 
them only on "significant" threshold change.

Many thx for your review,
R.

> On Nov 16, 2011, at 2:06 AM, John Scudder wrote:
>> Folks,
>>
>> We have received a request from the authors to adopt
>> draft-varlashkin-bgp-nh-cost-02 as an IDR WG document.  Please send
>> your comments to the list.  The deadline for comments is December
>> 5, 2011 at noon EST.
>>
>> Thanks,
>>
>> --John _______________________________________________ Idr mailing
>> list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
>
> _______________________________________________ Idr mailing list
> Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr
>
>