Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification

Job Snijders <job@ntt.net> Sat, 18 March 2017 10:54 UTC

Return-Path: <job@ntt.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 69AEC124BFA for <idr@ietfa.amsl.com>; Sat, 18 Mar 2017 03:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 z7bLCZKXQw-j for <idr@ietfa.amsl.com>; Sat, 18 Mar 2017 03:54:30 -0700 (PDT)
Received: from mail3.mlpsca01.us.to.gin.ntt.net (mail3.mlpsca01.us.to.gin.ntt.net [IPv6:2001:418:3ff:3::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34991120727 for <idr@ietf.org>; Sat, 18 Mar 2017 03:54:30 -0700 (PDT)
Received: by mail3.mlpsca01.us.to.gin.ntt.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88) (envelope-from <job@ntt.net>) id 1cpBzq-0000oI-Jn (job@us.ntt.net) for idr@ietf.org; Sat, 18 Mar 2017 10:54:30 +0000
Received: by mail-wm0-f45.google.com with SMTP id n11so32065677wma.1 for <idr@ietf.org>; Sat, 18 Mar 2017 03:54:06 -0700 (PDT)
X-Gm-Message-State: AFeK/H21TgkmY4lBxySmRsObm7pSOHX9mfjNaw+RPkW+8nRAmtqa6nowJx4WciT2A7gcJdeyfk/bVmMFpyBtLQ==
X-Received: by 10.28.15.12 with SMTP id 12mr2196918wmp.22.1489834444795; Sat, 18 Mar 2017 03:54:04 -0700 (PDT)
MIME-Version: 1.0
References: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com>
In-Reply-To: <4eedda5c2db74539bd0f949e38cb8b26@XCH-ALN-014.cisco.com>
From: Job Snijders <job@ntt.net>
Date: Sat, 18 Mar 2017 10:53:53 +0000
X-Gmail-Original-Message-ID: <CACWOCC_JVt_=5mmD5c=D5MWRUsk8TdZOhJ6=F4DG-of-w36U6g@mail.gmail.com>
Message-ID: <CACWOCC_JVt_=5mmD5c=D5MWRUsk8TdZOhJ6=F4DG-of-w36U6g@mail.gmail.com>
To: "Jakob Heitz (jheitz)" <jheitz@cisco.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a11469342db6402054aff1c33
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6uVK2N8rYZp4GMttiOZmjFIC388>
Subject: Re: [Idr] Early allocation for draft-ietf-idr-bgp-gr-notification
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: Sat, 18 Mar 2017 10:54:32 -0000

Hi everyone,

Given the 50+ years of combined IETF experience the authors of this draft
possess, I'm somewhat surprised to see a suggested value in the IANA
considerations instead of "TBD". See the last major bullet point here:
https://trac.ietf.org/trac/idr/wiki/Checklist%20for%20writing%20a%20BGP-related%20draft

Jakob, thanks for kicking of the process to rectify this situation.

Furthermore, shouldn't the "Hard Reset" be called "Really Really Really
Reset"? I am skeptical whether the principles of graceful restart should be
applied to the notification mechanism. In
https://tools.ietf.org/html/draft-iops-grow-bgp-session-culling-00 we are
describing a procedure that strongly relies on the currently understood
semantics of expiration of BGP Hold Timers and the Administrative Shutdown:
"STOP sending traffic".

I find it hard to reconcile how we can have both "My control-plane
temporarily going away, but keep sending traffic" and "data-plane is
broken, bgp subsequently dies, don't send traffic". The exact failure
scenario which triggers the expiration of the BGP Hold Timers cannot be
known at OPEN when the capabilities are exchanged. The GR NOTIFICATION
seems to distort the congruency between data-plane and control-plane.

Perhaps there should be an implementation guideline which encourages
vendors to by default, disable this mechanism on non-RFC3021/RFC6164 links?

Has draft-idr-bgp-gr-notification been vetted in the wild? What were the
results and under which circumstances is the mechanism useful? Am I missing
something?

Kind regards,

Job


On Sat, 18 Mar 2017 at 02:50, Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

Hi chairs,



We are implementing

https://tools.ietf.org/html/draft-ietf-idr-bgp-gr-notification-09

and would like IANA to allocate the code 9 for the Hard Reset subcode in the

BGP Cease NOTIFICATION message subcodes registry.



Thanks,

Jakob.


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