Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

"Jakob Heitz (jheitz)" <jheitz@cisco.com> Thu, 01 August 2019 05:46 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 34AE6120059; Wed, 31 Jul 2019 22:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=l8fOXKPp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JWgAGXFv
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 vH08L-XasUSr; Wed, 31 Jul 2019 22:45:59 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DBFA12000F; Wed, 31 Jul 2019 22:45:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6364; q=dns/txt; s=iport; t=1564638359; x=1565847959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=hsu/7vRPxgCLM0mqJ9ZNII+PW5cqYj0NQB+HyABmKd0=; b=l8fOXKPpgnMUfacw+BZfKY9A84hYIpLKrdy8A63FOi5ulwZ77eRqTXTK gPkM/KD5HFBkFCAPxwCcewEOOg0DJCI3BPaI9VVcxaUR7tDIsvbExy7ws 3YBrotNLR5DSAWe3vzA48ohmLNbroRbdJWhWWUhcBvg/rxLc1riXjUXQU 4=;
IronPort-PHdr: 9a23:oEbmpBzlag9Cgw/XCy+N+z0EezQntrPoPwUc9psgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1kAgMQSkRYnBZuHCUD6MOzCZC0hF8MEX1hgrDm2
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AJAADZe0Jd/4MNJK1lGQEBAQEBAQEBAQEBAQcBAQEBAQGBVAMBAQEBAQsBgUQkLANtVSAECyqEHoNHA4snglt+lleBLoEkA1QJAQEBDAEBGAsKAgEBhEACF4I4IzUIDgEDAQEEAQECAQZthR4MhUoBAQEBAwEBEBERDAEBLAsBCwQCAQgRAwEBAQECAiYCAgIlCxUICAIEAQkEBQgagwGBagMdAQIMoEUCgTiIYHGBMoJ6AQEFhQMYghMDBoEMKAGLXxeBQD+BEUaCFzU+gmEBAYFjFYJ0MoImjwSbI20JAoIai0+IZoIugjKTN41BgTKSYoNRAgQCBAUCDgEBBYFSATWBWHAVO4JsgkKDcYUUhT4BcoEpijgGAYJLAQE
X-IronPort-AV: E=Sophos;i="5.64,333,1559520000"; d="scan'208";a="303060007"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Aug 2019 05:45:57 +0000
Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x715jvnI020361 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 1 Aug 2019 05:45:57 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Aug 2019 00:45:56 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 1 Aug 2019 01:45:55 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 1 Aug 2019 00:45:54 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kko8yubSPEKU73HT9LJwAE5RtfzHla7qX0Y/kbvxNqlz51vSjhWvuoXyzLtr3gYtCVzsGihjBvtMeTLkihT4hTi9TiAv/Vv3s/IqvwaDoPLtsRNk9aNV54dfDLhJyXtKYPdLaSeHw98uWPG9Hi+fAK7DLqw//WmsGhbNxoW9M4lts6HkDY3WUytIhDomsB/kflhJJM3hDN0EsO7V3NhD1hsLBVWIwokSctcCYW5A1LlWXjMhPNTT5sKB5M+9r1ZEg+P9ED0f7P0RhVEPK2ORUjYibr7o+jIGG90HexxdwvS1e7sdQKT2yyCF3OXvKZQERVBtt6SjR6Zph3OG/HGa1g==
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=hsu/7vRPxgCLM0mqJ9ZNII+PW5cqYj0NQB+HyABmKd0=; b=fyj3VeDAfaWU3UZ76fuwZ25iM31dzhltx5QRMnYSq6RuMEyq1EiITGkbrl66efvrLX5LauhrRvmV81zKf7BppWbGIGSxdywknyEUsfED13MNACm8NmJRZJDFRZNwV5tC1dzbe0AR3xI1kiGSurPlGZjC1Uskk0VKWsljNip2xb1dK6Bx60zDVCaabMK6FcJKYlryIrXkzZPYoRJM6SuWntsDBdeoYHfIuLpZaeEsXNmA4bX1K/V3pWSbJzVGXqtPfy9fjUMiHo3RHGfN1tNJwN51SNLYW6FJkTv0pmrY0YV+TdSU9UMOU5Psr74D3uKJp+SdW9gqsnIM2h1+wVRwuw==
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=hsu/7vRPxgCLM0mqJ9ZNII+PW5cqYj0NQB+HyABmKd0=; b=JWgAGXFvoxDDkJDqtoDgcDMBPMyZkUA2fGWva44xrCP70/DknPvwxoNFcQdtKdE/d/JrbffKpkVYvq6qu3Rxwj6j2AOlNWiK2Y6tSAx6qmWhxkdzFj5fuhnEn7kGaYop8SW0rpk2KJIXZIpJDK5qw4JceSBlxexmlzCCYXeYWuw=
Received: from BYAPR11MB3751.namprd11.prod.outlook.com (20.178.238.144) by BYAPR11MB2744.namprd11.prod.outlook.com (52.135.228.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Thu, 1 Aug 2019 05:45:54 +0000
Received: from BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::f19b:a29c:2227:69e4]) by BYAPR11MB3751.namprd11.prod.outlook.com ([fe80::f19b:a29c:2227:69e4%5]) with mapi id 15.20.2136.010; Thu, 1 Aug 2019 05:45:53 +0000
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
To: "Enke Chen (enkechen)" <enkechen@cisco.com>, Jeffrey Haas <jhaas@pfrc.org>
CC: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-extended-messages@ietf.org" <draft-ietf-idr-bgp-extended-messages@ietf.org>, Susan Hares <shares@ndzh.com>
Thread-Topic: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
Thread-Index: AQHVR9vBQjRvIAbX5keDAJxM/9Uil6blOpgAgAAJhwCAACxwgIAARlPwgAAQgYCAAABe4A==
Date: Thu, 01 Aug 2019 05:45:53 +0000
Message-ID: <BYAPR11MB37512B5A0C56F50F02F50A08C0DE0@BYAPR11MB3751.namprd11.prod.outlook.com>
References: <CAMMESsyvuU8_dBOeoOXPBt=-HwoF0eHvYgm5d8CgF-4o_oiP=g@mail.gmail.com> <20190731211602.GA31271@pfrc.org> <119404A5-8384-456B-9677-0445899B008F@cisco.com> <20190801002911.GB31271@pfrc.org> <BYAPR11MB3751B2E90D5CBD559EBE319CC0DE0@BYAPR11MB3751.namprd11.prod.outlook.com> <6A947BF0-FC05-4423-9EAA-A56F507ED451@cisco.com>
In-Reply-To: <6A947BF0-FC05-4423-9EAA-A56F507ED451@cisco.com>
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:c0c8:1007::ea]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d9bc431d-60ed-460d-03a1-08d71643849d
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2744;
x-ms-traffictypediagnostic: BYAPR11MB2744:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <BYAPR11MB27445AF87E1E56EBFB033405C0DE0@BYAPR11MB2744.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01165471DB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(396003)(346002)(39860400002)(189003)(199004)(13464003)(110136005)(11346002)(8676002)(486006)(68736007)(6116002)(15650500001)(4326008)(476003)(81156014)(2906002)(305945005)(446003)(7696005)(46003)(7736002)(25786009)(33656002)(74316002)(6246003)(8936002)(6436002)(64756008)(6306002)(6506007)(9686003)(55016002)(5660300002)(186003)(76116006)(256004)(53936002)(229853002)(86362001)(14444005)(316002)(66946007)(66476007)(71200400001)(76176011)(99286004)(54906003)(53546011)(14454004)(66446008)(66556008)(102836004)(52536014)(478600001)(81166006)(966005)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2744; 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: i22+tiVvGPU9QsAVO9KY3Pbq6pSkElgyBbFL5umU3pVINzY2zSFaY/X+lbkrWEu+w9UB6h8zqhdqm9L+9qdPwAKsxcQd2kqSF5uHbwg3EH/PPXCjtDSHDB3gTW3ybtZqYyw/DyNdrEVl6/mLVaVGIf4CObpVF7+rPZVYJE5jLw/qFvIBlj/5D6R/VMsl9IiqO1+GTNK2dVwL0EBXFkF0EP/n2qA2UzJessRq7I5QJ4B17fr6Cz3VXJECcIUBW1cmLeKmtCbjLAYG7WDfIdsYSRiocAWlyaQ/sblrg/WbEtlb4nLjRiD6fPLuJF7zLFNb/fUuKQlGhoudfY2DA4raWMm5bR5t4bh8B5t/uuvguLD/tT0yQwSgL0qM7cD55Op8ucI1MnvCnp6Avt8sRpLSSIdBqQKbMKw/7nzzGiVAK7k=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d9bc431d-60ed-460d-03a1-08d71643849d
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2019 05:45:53.7568 (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: BYAPR11MB2744
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com
X-Outbound-Node: alln-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Naq7PKMWjjPabH7R7Sx8D7DkV_w>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
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: Thu, 01 Aug 2019 05:46:02 -0000

MCAS made the MAX non-deployable, but at least crashes are avoided.
I prefer stable over deployable.

You could split this by non-interfering address families.
For example, if BGP-LS needs extended messages, but IPv4
does not, then allow extended messages only in the BGP-LS
address family. Interfering address families might be
EVPN and L3VPN, because IP routes can be transferred
between them.

Regards,
Jakob.

-----Original Message-----
From: Enke Chen (enkechen) 
Sent: Wednesday, July 31, 2019 10:40 PM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Jeffrey Haas <jhaas@pfrc.org>
Cc: idr-chairs@ietf.org; idr@ietf. org <idr@ietf.org>; draft-ietf-idr-bgp-extended-messages@ietf.org; Susan Hares <shares@ndzh.com>; Enke Chen (enkechen) <enkechen@cisco.com>
Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

Hi, Jakob:

I am afraid what you just proposed would make the feature non-deployable ☹

1) I suspect that for *a long time* there will some EBGP neighbors that don't have the capability
enabled. Thus the speaker will not be able to send the large messages to any neighbors...

2) Also just imagine when one of the neighbors decide disables the capability ...

Requiring "simultaneous configs" over a session always make it hard for the deployment of a feature,
let alone synchronizing  across many neighbors.

Thanks.  -- Enke  

-----Original Message-----
From: "Jakob Heitz (jheitz)" <jheitz@cisco.com>
Date: Wednesday, July 31, 2019 at 10:04 PM
To: Jeffrey Haas <jhaas@pfrc.org>, "Enke Chen (enkechen)" <enkechen@cisco.com>
Cc: "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, "draft-ietf-idr-bgp-extended-messages@ietf.org" <draft-ietf-idr-bgp-extended-messages@ietf.org>, Susan Hares <shares@ndzh.com>
Subject: RE: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages

    I'll raise you one.
    A single speaker in a network that is not capable of receiving extended
    messages will lead to a mess of (non-edge) cases. 
    
    How about:
    
    A BGP speaker MUST NOT send the extended messages capability in
    an OPEN message to any BGP speaker if it has received an OPEN message
    without the extended message capability from any
    BGP speaker. A BGP speaker MUST delay sending an OPEN message to
    any BGP speaker by one keepalive interval if that OPEN message will
    contain the extended message capability and it has not yet received
    an OPEN message from every configured BGP speaker. The stated OPEN
    messages are understood to be of current or future BGP sessions,
    not of old sessions that have been taken down.
    
    This will reduce, but not completely eliminate the mess cases.
    
    Regards,
    Jakob.
    
    -----Original Message-----
    From: Idr <idr-bounces@ietf.org> On Behalf Of Jeffrey Haas
    Sent: Wednesday, July 31, 2019 5:29 PM
    To: Enke Chen (enkechen) <enkechen@cisco.com>
    Cc: idr-chairs@ietf.org; idr@ietf. org <idr@ietf.org>; draft-ietf-idr-bgp-extended-messages@ietf.org; Susan Hares <shares@ndzh.com>
    Subject: Re: [Idr] Capability Advertisement in draft-ietf-idr-bgp-extended-messages
    
    Enke,
    
    On Wed, Jul 31, 2019 at 09:50:08PM +0000, Enke Chen (enkechen) wrote:
    > >>  Note that RFC 6793 (4-byte ASes) require bi-directional advertisement.
    > 
    > No, this statement is not correct. It is fundamental (in transition) for a BGP  speaker
    > to be able to talk to both NEW speakers (that have advertised the capability), and OLD
    > speakers (that have not advertised the capability).  Different encodings are used in the
    > UPDATE message depending on whether the 4-byte AS capability is received from a
    > neighbor.
    
    I should have known I wasn't pedantic enough in this comment. :-)
    
    The point here is that in order to exercise the procedures between NEW BGP
    speakers, (RFC 6793, §4.1), both sides must advertise and use the
    capability.  If you have a mix, each speaks 4271 to each other with the new
    speaker running the transitional procedures.
    
    With regard to the extended messaging, my preference is that both sides
    advertise the capability in order to use the large messages.  A mis-match
    falling back to 4271 4k PDUs is fine - symmetrically.  Asymmetrically
    sending extended messages leads to a mess of edge cases.
    
    -- Jeff
    
    _______________________________________________
    Idr mailing list
    Idr@ietf.org
    https://www.ietf.org/mailman/listinfo/idr