Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-06.txt

Jeffrey Haas <> Fri, 14 June 2019 15:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DB3C81202B7 for <>; Fri, 14 Jun 2019 08:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZbfmIGX0hRtT for <>; Fri, 14 Jun 2019 08:50:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 731F6120257 for <>; Fri, 14 Jun 2019 08:50:34 -0700 (PDT)
Received: by (Postfix, from userid 1001) id B9F121E2F1; Fri, 14 Jun 2019 11:51:38 -0400 (EDT)
Date: Fri, 14 Jun 2019 11:51:38 -0400
From: Jeffrey Haas <>
Cc: "" <>
Message-ID: <>
References: <> <5057_1560520581_5D03A785_5057_221_1_9E32478DFA9976438E7A22F69B08FF924C254D21@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5057_1560520581_5D03A785_5057_221_1_9E32478DFA9976438E7A22F69B08FF924C254D21@OPEXCAUBMA3.corporate.adroot.infra.ftgroup>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-06.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Jun 2019 15:50:36 -0000

[Not speaking for the authors, but I've done a recent initial review.
Definitely needs more work.]


On Fri, Jun 14, 2019 at 01:56:20PM +0000, wrote:
> - LLGR is missing while useful and deployed

LLGR isn't even an IDR draft right now.  It's not really appropriate to have
in the base yang module for BGP.

This rather goes back to a conversation I had some years ago: IDR must
decide what the "base" features of BGP are.  Things like route reflection,
confederations, damping, aigp, etc. are included in the module in spite of
the fact that they are completely *optional* extensions to 4271.

This is thus not the RFC 4271 yang module.  How much beyond that we should
go is an interesting question.

But for things that haven't even hit RFC, we should certainly keep them out
as extensions until then.

> - what's the difference between hold-time and hold-time-configured (same for keepalive) as both are configurable leaves ? Do you have a min-holdtime option which is deployed and very useful ?

Generally a negotiated value vs. the configured value.  Similar issue in BGP

-- Jeff