Re: [Idr] draft-uttaro-idr-bgp-persistence

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Tue, 30 July 2019 20:38 UTC

Return-Path: <jheitz@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 2BA28120089 for <idr@ietfa.amsl.com>; Tue, 30 Jul 2019 13:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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, 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 header.b=LnUShs3U; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JrDwBc9h
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 PcA53d2_-QSf for <idr@ietfa.amsl.com>; Tue, 30 Jul 2019 13:38:09 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7016C120024 for <idr@ietf.org>; Tue, 30 Jul 2019 13:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25124; q=dns/txt; s=iport; t=1564519089; x=1565728689; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jgQWWgfyaxWoX/f696znAACrCTYWiGOo3wJ+9XlqvhU=; b=LnUShs3UeSruI0v2S3lsae8rh3/an1rznDbRbyP93apEAFStO/RxCvpi R7CG8/0w5rT7WQS8nqaSDh+MborG+3LEu+JwVId+xdt1qt8c9H6do0OtP NZ2tL4gyFJMH+ph9QQY2dJVvWztGdrGTcCRQUZkVYMFPtrlgc7YS/MpYR o=;
IronPort-PHdr: 9a23:5pq+2xwlO7rCUnLXCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuHCUD6MOzCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AOAADJqUBd/49dJa1lGQEBAQECAQEBAQEIAQEBAQGBVgIBAQEBDAGBFC8kBScDbVUgBAsqhB6DRwONBoJbl1SBLhSBEANUCQEBAQwBAR8OAgEBhEACF4IrIzYHDgEDAQEEAQECAQZthR4MhUoBAQEBAxIRChMBATcBDwIBCBEEAQEoAwICAjAUCQgCBAENBQgMDoI1TIEdTQMdAQIMoVYCgTiIYHGBMoJ6AQEFhQwYghMDBoE0AYtfF4FAP4ERRoJMPoJhAQEDgSsBDAYBCBkVFgmCVTKCJowNgnGFAIhxjhIJAoIahluFIog0gi6HJY4+jT2HS5APAgQCBAUCDgEBBYFXDiMqPXFwFYEVghKDaAECgkiFFIU/coEpinwOF4IsAQE
X-IronPort-AV: E=Sophos;i="5.64,327,1559520000"; d="scan'208,217";a="605997409"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2019 20:38:08 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x6UKc8DM003683 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 30 Jul 2019 20:38:08 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 15:38:07 -0500
Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 30 Jul 2019 15:38:07 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 30 Jul 2019 15:38:07 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QQJUZAzE2hN343BfH314Y6aUR57329OiKA31KdFMo35eH4yHya+H9Qjm7HUG7yg+U8cKWxbJKI5zSanhu0GKEJaHJclHZkFleQJhQRiK8INv5aEnpXLXs7gaeZcgezaxmKwvMPwk0xvBwPC2lbDboDjL/KuS4t1Z8bTGI4s9GsWc6NhhBw6c9ENdzyARbXRK7vznScbtRt4W1LB68vFXwoIqVA9El1UEUmOpWZN0l9VpsYuGTdy2ng2LKLHFZUBd94bhrGSBJ3v2O/APt9din5C4bXvJi50FuRSF8m6dn/+bJ/UbBAZI4a2O6lUpNMeFOGk0iE+IPky58nV70pS0jQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jgQWWgfyaxWoX/f696znAACrCTYWiGOo3wJ+9XlqvhU=; b=I4w/fUAKk0tcbb7qta/FhlM+C3oxGp1ggO+yk7fhIxhguTptITP8SFdVZrTR+w8dIJO2aVCc7MYMsXTPPEgQKQFyQLnu7v+K8z9YQ1MpkbsmR4hRKJaB9s4oeO+HY3pVsG6uigtM/f3Olot1/8Jg4dHzGaMfofRIJOVWMfjfT4i1q8rLZyrDJpCWN5YWhv1R5dVz1kjhZMNLno4m4OpDEMx1f/ljeQval4dA83EFRAf/Mq/qLSZCXvChmcN+aAH/YMT2VOjCEDA8WAN4dt9+xGB7v8dX7xQq46VUQGMa7Uxz9ipS89mwmucFmSY6Tvz1J1S59HdaDojDEH7dxNU1+Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jgQWWgfyaxWoX/f696znAACrCTYWiGOo3wJ+9XlqvhU=; b=JrDwBc9hV4mht4RAXLavtZiil1aHS/ZxYoxtTCgsDb39Gu+MWbVQJiBuUP4/9laTsmgDlkA7R2LoDwAm6kKbgGw6mNWC9mU07LXmx85i8GC2KU7pF9qNYj9+JwsB8WYzG4S3b0sSAZngYXagdw17Y2sZY6svW/SCAesS7fEZoTY=
Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB3126.namprd11.prod.outlook.com (20.177.227.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Tue, 30 Jul 2019 20:38:05 +0000
Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::a894:a92:ad6e:ee2a%7]) with mapi id 15.20.2115.005; Tue, 30 Jul 2019 20:38:05 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "bruno.decraene@orange.com" <bruno.decraene@orange.com>, Robert Raszuk <robert@raszuk.net>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] draft-uttaro-idr-bgp-persistence
Thread-Index: AQHVReTJgAVyKlMy50utPHV9GFO/pabjN0KAgABptAA=
Date: Tue, 30 Jul 2019 20:38:05 +0000
Message-ID: <BYAPR11MB3751FB92FC2F17BCFDC3421DC0DC0@BYAPR11MB3751.namprd11.prod.outlook.com>
References: <CAOj+MME=scL9h7d9Jbh_3vYch6dTruTpseGLXx=peLwexEwH0Q@mail.gmail.com> <25379_1564496252_5D40517C_25379_366_1_53C29892C857584299CBF5D05346208A48BC0422@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
In-Reply-To: <25379_1564496252_5D40517C_25379_366_1_53C29892C857584299CBF5D05346208A48BC0422@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com;
x-originating-ip: [2001:420:30d:1254:68ee:ac2e:9d42:aa6f]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 80c4cdee-4e73-405a-dd2a-08d7152dd32d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3126;
x-ms-traffictypediagnostic: BYAPR11MB3126:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BYAPR11MB3126FBFD05EAA1AB09C86FECC0DC0@BYAPR11MB3126.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0114FF88F6
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(39860400002)(346002)(396003)(189003)(199004)(81156014)(478600001)(46003)(256004)(790700001)(6506007)(5024004)(446003)(76116006)(11346002)(476003)(102836004)(53546011)(76176011)(229853002)(9686003)(14444005)(55016002)(54896002)(606006)(66446008)(6246003)(486006)(66556008)(14454004)(66476007)(186003)(236005)(6436002)(33656002)(5660300002)(25786009)(561944003)(52536014)(6306002)(6116002)(86362001)(2906002)(316002)(4326008)(71200400001)(2501003)(71190400001)(64756008)(66946007)(68736007)(99286004)(8936002)(7696005)(53936002)(8676002)(74316002)(110136005)(7736002)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3126; H:BYAPR11MB3751.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: QUzy+U8yzJLrcWvPxZ81r+L0Eg0pydT1k+CrEyEOZX6Xmw6E3+lRmGiRCFon3ZwBz3Ty7T0PkkdhrtnkJ47MXefuf9ygybcpLv7eHZ6qgBxXhBpwwziDjvwjnVR2iLnc9y3JQbbD6SEUWWiPkOKzPOyneUnTtM9GShJqL60P3WTs1vw9uV7lf8LI2JVeOap207Zl9K8aC0QsENFl2CqGfS+727VUmJIKTMaHsA9/m4Z0lvHPeHiVyrVj9KYSi5ZKn1aavbT3jtRUDZDxdkYCB3u6jSKsPeaRqZZXnGEcRU0MoUci0Ky0q2QCJNXqCM3s7lCnfQHtATjVeVfXfIH5NR3nhDZNkMc9GhgrUQl+4KlCFq4SWmji1ub73SlJv62YK+RIdhtShIs20qP2WYzLZfITzAZr7FxWZ1W3bP1s7ME=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3751FB92FC2F17BCFDC3421DC0DC0BYAPR11MB3751namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 80c4cdee-4e73-405a-dd2a-08d7152dd32d
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2019 20:38:05.5445 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: jheitz@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3126
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.22, xch-rcd-012.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Esao5o36alQQo7QOiBBu1W2b1sw>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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, 30 Jul 2019 20:38:13 -0000

Robert,

You can cause your neighbor to delete your routes immediately by bringing up a new BGP
session, and send the LLGR capability with the F bit clear and then bring
it right back down again. If you don't want your neighbor to hold your routes,
then do not advertise the LLGR capability or set the stale time to 0.

Regards,
Jakob.

From: Idr <idr-bounces@ietf.org> On Behalf Of bruno.decraene@orange.com
Sent: Tuesday, July 30, 2019 7:18 AM
To: Robert Raszuk <robert@raszuk.net>
Cc: idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] draft-uttaro-idr-bgp-persistence

Hi Robert,

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, July 29, 2019 10:08 AM
To: idr@ietf. org
Subject: [Idr] draft-uttaro-idr-bgp-persistence

Hi,

Assume LLGR has been negotiated and routes have been exchanged with LLGR community. The retention timer is looong.
‘Long’ or ‘simple’ is a matter of opinion. I’m pretty sure that some, possibly you, will consider that an hour is long. While that is in scope the Graceful Restart. Compared to GR, persistence minimize the preference of the stale routes hence live routes will be preferred. Personally, this seems safer than GR (but indeed, this creates additional control plane processing)


While I am happy to see that suggestions to follow GR procedures have been used the draft is pretty silent on one very important aspect - clearing persistent routes. GR procedures which rely on using GR time for it do not apply.

Imagine I want to bring such session down and I do want to remove all routes including those marked as LLGR. How do I do that ?

From current draft the only way seems to be to reestablish a session with LLGR capability and readvertise subject routes with NO-LLGR community hoping it will clear the former routes. But even here we are at the mercy of local policy as per section 3.2 & 3.3

 For your case, the BGP session seems to be up or able of been up. Why do you think the use of a hard reset would not work? This seems to be specifically referred to by the specification:

“   In the presence of the "Long-lived Graceful Restart Capability", the

   procedures specified in [RFC4724<https://tools.ietf.org/html/rfc4724>] and [RFC8538<https://tools.ietf.org/html/rfc8538>] continue to apply

   unless explicitly revised by this document.”



For the case where the BGP session is down, clearly a protocol message/behavior is not applicable. I would assume that a local CLI would do this. (E.g. clear ip bgp session). In all cases, this is not specific to BGP persistence and equally applies to GR.



King regards,

--Bruno


In any case that is pretty awkward method.

Then we just had a little thread regarding max prefix in GROW WG. New draft there actually relies on BGP NOTIFICATION MSG with CEASE error code to remove all routes making on purpose crossing a max prefix limit a drastic event (of course unless warning only is set).

Bottom line BGP here is used again as configuration tool not as dynamic routing protocol. I do not think this type of use of BGP which should be endorsed.

If this proposal moves fwd it should clearly spell how not only to retain the LLGR eligible prefixes but also how to cleanly remove them when needed - way before they expire.

Kind regards,
R.

_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.