IETF Logo Mail Archive

Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

"Ketan Talaulikar (ketant)" <ketant@cisco.com> Sun, 18 February 2018 12:16 UTC

Return-Path: <ketant@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 CCCBE1242F7 for <idr@ietfa.amsl.com>; Sun, 18 Feb 2018 04:16:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level:
X-Spam-Status: No, score=-14.53 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 Q1LCBAq7ifKI for <idr@ietfa.amsl.com>; Sun, 18 Feb 2018 04:16:21 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE286120724 for <idr@ietf.org>; Sun, 18 Feb 2018 04:16:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20374; q=dns/txt; s=iport; t=1518956180; x=1520165780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GJS7GtlnVib5cXfW6PsIPVHwvd4zWCb7XrNQOwPADtU=; b=SOTYVOme3b22DtSOiEVW4aQeCs5J8fm7zvkqQxO5WHb4HvqCiW7UxbgB DOb0jLg8ZqSvbls8nVb6P+dzTQBj9YcOUnJz4o8oKqt80JrDhiRhDVX34 iYaPWPcmF8QMzDxsev0vkrIgV+LIU5X9VvMeYNtmhnDblw3LQrNfk41oB E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DpAABsbYla/5pdJa1cGQEBAQEBAQEBAQEBAQcBAQEBAYJaRDFmcCgKg1yKJY4DggKBF5BthVyCFgqFOwIagixUGAECAQEBAQEBAmsohSMBAQEEIwpFBxACAQgRBAEBKAMCAgIwFAkIAgQBDQUIiTZkrD2CJ4h0ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhQuCKIFXgWcBgy6FSRCCYYJlBZosigkJApV/lFCXcgIRGQGBOwEfOYFRcBWCfYJUHIIGeI1IgRkBAQE
X-IronPort-AV: E=Sophos;i="5.46,529,1511827200"; d="scan'208,217";a="355596849"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Feb 2018 12:16:19 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1ICGJfE029824 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 18 Feb 2018 12:16:19 GMT
Received: from xch-aln-008.cisco.com (173.36.7.18) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 18 Feb 2018 06:16:17 -0600
Received: from xch-aln-008.cisco.com ([173.36.7.18]) by XCH-ALN-008.cisco.com ([173.36.7.18]) with mapi id 15.00.1320.000; Sun, 18 Feb 2018 06:16:18 -0600
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, "Acee Lindem (acee)" <acee@cisco.com>
CC: "idr@ietf.org" <idr@ietf.org>
Thread-Topic: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
Thread-Index: AQHTqC+ofggdie7eIUGcZsQgc0HRx6Opf1iAgAADuoCAAAJXAIAABEkAgADY+wD//6/n0A==
Date: Sun, 18 Feb 2018 12:16:18 +0000
Message-ID: <0662380165004d7ab970ded0d5b00c8f@XCH-ALN-008.cisco.com>
References: <CAMMESszyqjqm+m3J00GWG1Dw0OjYdo-GGXePxcWvyBp4sgtm6Q@mail.gmail.com> <C46BE9FB-AA2E-49BC-8942-579020733FF9@cisco.com> <CA+wi2hNOnGPXv2rp7i4=gBet=nxii2kDgqfVv-yHTC6f8AK8Jg@mail.gmail.com> <790D778D-19CF-4A2E-81DD-547C69E2E7BF@cisco.com> <CA+b+ERmtDnL2h19=T7F+hhNgxmEWuf=xSTSQbuuqy4RSUHPCsQ@mail.gmail.com> <637F72B8-914C-4EC4-AB96-5949E1F1FFA6@cisco.com> <CA+b+ERmWxbdsKFFESB_10Z2j4OjaZi45XbBFXjZwKFjf=X1GiQ@mail.gmail.com>
In-Reply-To: <CA+b+ERmWxbdsKFFESB_10Z2j4OjaZi45XbBFXjZwKFjf=X1GiQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.75.146]
Content-Type: multipart/alternative; boundary="_000_0662380165004d7ab970ded0d5b00c8fXCHALN008ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/q7DirQ8YC2F7WG7ijVYhnfdf9TY>
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 18 Feb 2018 12:16:23 -0000

Hi Robert,

I do hope this is not an open surgery of the draft ☺

Regarding Anycast prefixes, my understanding was that this, by definition, means the same prefix being multi-home and originated by more than one routers. I did not follow anycast with different prefixes.

Also, the handling of anycast involves either of the following:

1)     Pointing to the “closest” (best on whatever the decision process of the protocol involved) originator of the prefix, OR

2)     Doing load-balancing between the multiple originators (when this is possibled/desired).

So I am not sure I understood the relationship of anycast to the conflict.

Thanks,
Ketan

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: 18 February 2018 16:27
To: Acee Lindem (acee) <acee@cisco.com>
Cc: idr@ietf.org
Subject: Re: [Idr] Review Updates to draft-ietf-idr-bgp-prefix-sid

Hi Acee,

Since we are at the open surgery of this draft there is one more point which did not got resolved during our offline discussion. Feedback from WG is welcome here.

The draft RECOMMENDS the following procedure in case of a conflict:


... it is RECOMMENDED that the first prefix using the label index is selected.

In BGP there is no guarantee about ordered delivery of BGP prefixes.  It may work such in some specific topologies but not in any arbitrary one. So if we recommend to pick one prefix on R1 and different prefix on R2 and install in forwarding the same SID for those I am afraid the data plane will get quite severely messed up and even finding it during troubleshooting will be quite hard.

Also as pointed out already MPLS anycast SID may on purpose use the same label across nodes according to draft-ietf-spring-mpls-anycast-segments-02. Now if we want to accomplish the same in BGP we would need to advertise different prefixes with the same SID (in MPLS-SR index). the above paragraph does prevents that. Note that adding and advertising the _same_ prefix from different nodes will not work as BGP speakers may pick only one (best path) and use it for forwarding. IBGP or EBGP multipath may not always be enabled/use same set.

The crux of the issue when advertising SIDs in BGP is not so much about prefixes, but their next hops which unfortunately the draft does not even mention once.

Kind regards,
Robert.

v2.23.0 | Report a Bug | By Email