IETF Logo Mail Archive

Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Tue, 05 June 2018 22:43 UTC

Return-Path: <rajiva@cisco.com>
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 482031311BE; Tue, 5 Jun 2018 15:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level:
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jalP18YklVUE; Tue, 5 Jun 2018 15:43:05 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C22130E04; Tue, 5 Jun 2018 15:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22018; q=dns/txt; s=iport; t=1528238585; x=1529448185; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bskGMrenyHJy115OCa5EDVPsH5VUkZ309H6YvOl6+3I=; b=MeGZx1GocmqeqoRWKaeFgPNnL+HK8dWIaxa0OTztbhsEqgOYdTeigg6P fLLW49VXjLqK/sxM7LA0h8c9cS+zhI4bb5kfYjgoo03jpfA1n4FdP6Z/p sZHz8tOeq/+7AXf4n3HIUFfLQ5/r3I5PS+bNdrtq6KFzRKEZZgEMOYOtM k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DDAAAqERdb/5BdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYJOdWJ/KAqDbogEjG+BWCGUTRSBZAsYAQqESQIXggkhNBgBAgEBAQEBAQJsHAyFKAEBAQQBASEKQQsQAgEIEQMBAigDAgICJQsUCQgCBAENBRuDBwKBG2QPp2qCHIhDgWMFiEKBVD+BMwyCJzWDEQEBgSgiLQkWgkowgiQCh3BFiHeHSAkCiESGIoE9g3iHa5B/AhETAYEkHTiBUnAVOyoBghgJiweFPm+OMIEZAQE
X-IronPort-AV: E=Sophos;i="5.49,479,1520899200"; d="scan'208,217";a="124974395"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2018 22:43:04 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w55Mh45U009033 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2018 22:43:04 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 5 Jun 2018 17:43:04 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1320.000; Tue, 5 Jun 2018 17:43:04 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Nick Hilliard <nick@foobar.org>, Robert Raszuk <robert@raszuk.net>
CC: "idr@ietf. org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>, "draft-ietf-idr-rs-bfd@ietf.org" <draft-ietf-idr-rs-bfd@ietf.org>
Thread-Topic: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27
Thread-Index: AQHT+uDiZNsDrJrYkkGJbRHUEf1KEqRQHOeAgAJjTwD//9fxAA==
Date: Tue, 05 Jun 2018 22:43:03 +0000
Message-ID: <4F08B1BA-AECB-4768-9707-A1B361838D65@cisco.com>
References: <013401d3d338$f7c74f60$e755ee20$@ndzh.com> <CACWOCC_fb1NcUC6qGrNFAA0CTBJkDOhecV4J-NgvTP7_wzWV5g@mail.gmail.com> <89466EFB-7F8F-4C5A-AB36-7E510FA3F3C6@juniper.net> <4f6267d4-6759-4ed6-2869-ccbe16d9a817@foobar.org> <m2r2loipj0.wl-randy@psg.com> <CA+b+ERkVoM4Z64BYp3MDd6GihBJBUbLmVMMHTHrd3UKrz+KTYA@mail.gmail.com> <1b996f48-9d17-436c-3709-28fc8a93ef42@foobar.org>
In-Reply-To: <1b996f48-9d17-436c-3709-28fc8a93ef42@foobar.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.c.0.180410
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.45.53]
Content-Type: multipart/alternative; boundary="_000_4F08B1BAAECB47689707A1B361838D65ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/BXakghX2FGmXCqhBxrFvePIKtI8>
Subject: Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 05 Jun 2018 22:43:10 -0000

Dear Authors,

I was suggested to refresh ietf-idr-bgp-bestpath-selection-criteria draft, which should be a normative reference in this draft. Could you please confirm that next version would reflect that correctly?

--
Cheers,
Rajiv Asati
Distinguished Engineer, Cisco

From: Idr <idr-bounces@ietf.org> on behalf of Nick Hilliard <nick@foobar.org>
Date: Tuesday, June 5, 2018 at 5:07 PM
To: "robert@raszuk.net" <robert@raszuk.net>
Cc: "idr@ietf.org" <idr@ietf.org>, Hares Susan <shares@ndzh.com>, "draft-ietf-idr-rs-bfd@ietf.org" <draft-ietf-idr-rs-bfd@ietf.org>
Subject: Re: [Idr] draft-ietf-idr-rs-bfd-05 - 2 Week WG LC from 4/13 to 4/27

Robert,

Robert Raszuk wrote on 04/06/2018 09:38:
* It has been demonstrated with real RS data that vast majority of RS
carry single path for given prefix. This draft will not help in such cases.

the bfd brokerage aspect of draft-ietf-idr-rs-bfd will help enormously
in this case.

* If there is second path available for a given prefix the simple
solution is to observe that most IXes offer two Route Servers. Therefor
it is trivial to make such secondary RS to distribute second best path
ahead of any failure (knob for this does exist already in number of
shipping implementations) - so this would be one line config change on
RS and no upgrade(s) to the IX clients needed.

offering inconsistent views from a route server cluster is difficult.
The best thing for an ixp to do is to provide a consistent and
predictable service.

* It has also been pointed out that distributing 2 or even 3 or more
paths with add-paths will not cause any customer CE meltdown. So simply
configure "add-paths 2" on those clients who need two paths from single
RS and be done.

In theory, yes.  In practice, there are very few ebgp add-path
implementations.  Also in practice, if you want fail failover, you need bfd.

* Let's not forget the bigger picture here. IX peering is an
optimization. To provide redundancy across IX with failing fabric
connectivity, different IX peering can be used or destinations can be
reached over native Internet path.

yes, but in order to use that alternative path, the client network needs
to detect the failure at the IXP, which is what this draft is trying to
achieve.

* Last getting different path does not guarantee any level  success if
IX fabric failure location is close to the client.

this point is out of scope for this discussion, which deals with
arbitrary failures of the ixp fabric.

Nick

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

v2.23.0 | Report a Bug | By Email