[Idr] Re: New Liaison Statement, "oLS to IETF on BGP data model"

Ketan Talaulikar <ketant.ietf@gmail.com> Wed, 03 December 2025 13:33 UTC

Return-Path: <ketant.ietf@gmail.com>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 922629484BE8 for <idr@mail2.ietf.org>; Wed, 3 Dec 2025 05:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1loFqxBBp83 for <idr@mail2.ietf.org>; Wed, 3 Dec 2025 05:33:19 -0800 (PST)
Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 1B4089484BE1 for <idr@ietf.org>; Wed, 3 Dec 2025 05:33:19 -0800 (PST)
Received: by mail-pl1-x631.google.com with SMTP id d9443c01a7336-298250d7769so48615855ad.0 for <idr@ietf.org>; Wed, 03 Dec 2025 05:33:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764768798; x=1765373598; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dFHFR8nMP2eB6U5uBcQIU6ie22Rvsa3kCj05OkynxZw=; b=CDkgJopJZcGyeE3sczy2T9Rodp8saYku6vtlMQkobryuvmhYmyyhaqWa1fviiapqsi bg5NdWczQeZvonji6sdhxiOzvjURBE128e1YNPkiQhRYOo5gTjHem6epI/pwfSziINfT xGkwafYFwyX2T6E5nYpk4XRa7VSlQPNa2KzCGegRzsMz67EYsk4o2wrFQ0fJfJsvfn3O ox1nW1NrRv5i9UYwHhyQbdgJB547oqyC7eMN5UIWazKc1tTh4Gc4h3pXnR9I4oBQ3kmH oBuU4NVUgkQC4D8x6/QHlFhE128SxWs/yXZusjpZvt3oEZpnGRJMtLsks/MOsPiJtWig diyw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764768798; x=1765373598; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dFHFR8nMP2eB6U5uBcQIU6ie22Rvsa3kCj05OkynxZw=; b=OBum+tZbKv786oDTIG+p1Rlo/niikg1eEXB/X4BlRXMzVfEkgS54FdCx8AVb49g5dd f2rNcl2gDZ2SQl78+tE8eowt0znACoMUpjTgV5VBkP4XxmyKhTpx0Vi/1gpt121uObEH enDA9ztTIyo8gPJqr2KRrjhVA/LwUPHAzt+DkIOdRE32j9rGuoRwqBz4HHlCp8c1eX1C axlfqRzCYZxbh1vMZj6H0IPCAKjyJOEanLVMGCY+2Lwgk7PoWA3xC2YjyCMaZ6OaSbIT iywyp9wfPhhuILSF0NyMtGKNxqAbIlO29qL94l1Oc0uvImPtY7KO7YjPp96C1LCNoURF rDJQ==
X-Gm-Message-State: AOJu0YwT/aJ2b0qnQtJ3m2j2nnZmJTMTyUeAq5WOF/n5ing+glft2Hvq dLqPfk0o5I6rU0KnDqya41JV6WbYygeZGLgYxNhxgsMChEDa/xseq7Px5Lgc9AJ9r6uhwNCAX6v 1OLPNSxQ93VGWVzzMZ55bJ5Now12b3OpmAQ==
X-Gm-Gg: ASbGncvfk+uxGYAkHYgBnuvKVvnoPkdV42DzPuY9CKRq63DFYTkytla1Gh4hePKxmLo 0nQSnjRYqGa1y/yC4Tf0Wh6426mDfsNtm9pF0LUHEkoSYDj2ZrIHD7whnXIBt3bBt2OQHLp91RZ ZSa+09WOc/Wm+gMGpPFqEBW5KqK4sXptF82L7TDS6k4q/EeqSbPi0+2SvOspLllGpM1PJMNAuKU 0ZGL4//OF9CCIEcz9oO8F6YwMHJN1C3BCYoKLsBcncAo6LC43kkkLdALyJIC38Fi0xcK9s=
X-Google-Smtp-Source: AGHT+IFqmzkBC+GAJrWu+8yUaFPMBjKB4xa4vEq8Cd3QUdH4HMI7LOmO6m08DDSdpjBF3Zl+MoMBKTwqHgk6f/beej0=
X-Received: by 2002:a17:902:fc84:b0:29a:2d0:c1b5 with SMTP id d9443c01a7336-29d683790a2mr28816175ad.22.1764768797780; Wed, 03 Dec 2025 05:33:17 -0800 (PST)
MIME-Version: 1.0
References: <176377917609.1807088.18231834189018308158@dt-datatracker-5bd94c585b-wk4l4> <CAH6gdPwpL59w6tPxvTqbExUExRYotSETQFt3sFJwGdNEr47y2w@mail.gmail.com> <F5F747F2-F53F-4C18-809A-F8647157D73E@pfrc.org>
In-Reply-To: <F5F747F2-F53F-4C18-809A-F8647157D73E@pfrc.org>
From: Ketan Talaulikar <ketant.ietf@gmail.com>
Date: Wed, 03 Dec 2025 19:03:06 +0530
X-Gm-Features: AWmQ_bnbTULpCAdbnrmF7ussx-z4W_Df-2J_nJRoq0zhBhJneUfa_bPWbjESi-E
Message-ID: <CAH6gdPwvtHSWvOPFE_YTbEWf-nbm7RPwVeFGzOZoi+0c1tzhvQ@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Content-Type: multipart/alternative; boundary="0000000000004d6ecf06450c413b"
Message-ID-Hash: L7HFRNHE4DMHJTLEIXZJTN6WUSOB7HBO
X-Message-ID-Hash: L7HFRNHE4DMHJTLEIXZJTN6WUSOB7HBO
X-MailFrom: ketant.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Inter-Domain Routing Discussion List <idr@ietf.org>, Mohamed Boucadair <mohamed.boucadair@orange.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: New Liaison Statement, "oLS to IETF on BGP data model"
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/rocBEY6F4NNXmyD-Uo5pEd-nasw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

+ Med and Mahesh

Hi Jeff,

You have brought up some very good points and I am adding Med and Mahesh
for their guidance.

Please check inline below.


On Wed, Dec 3, 2025 at 1:29 AM Jeffrey Haas <jhaas@pfrc.org> wrote:

> Ketan,
>
>
> > On Nov 22, 2025, at 2:25 AM, Ketan Talaulikar <ketant.ietf@gmail.com>
> wrote:
> >
> > The BGP-4 YANG model document has gone through WGLC and has been waiting
> for implementations for more than 2 years now. I am not sure of its current
> status - I do see warnings and errors being reported on the YANG.
>
> This isn't hugely surprising.  The underlying landscape of YANG is a nest
> of dependencies.  A refresh and cleanup is needed.
>
> >
> > All 3 IDR chairs are authors on it and the IDR Secretary is the document
> shepherd. I recognize this odd situation.
>
> Indeed.  After my experience with the BGP MIB v2 effort, I tried to avoid
> entanglement.  I failed.
>
> > However, a decision on the future of this document is now overdue. This
> Liaison is a good trigger for the WG to make a decision (and within a
> timeframe so the Liaison can be responded to).
> >
> > As AD, I've already expressed my view that an exception to the 2
> implementation rule be sought from the WG for this document so it can be
> published as an RFC. I believe it was in Madrid where I had expressed that
> view, but perhaps even before that. If there is consensus to proceed with
> that exception, this can be progressed - else it just stays waiting for
> implementation and the WG will need to give a suitable response to BBF.
> >
> > Sue, Jeff, Keyur, and Jie, could you please take this topic up as a
> priority request from me for discussion at your next meeting? Please let
> the WG know your thoughts and if there is anything that you would like me
> to do, please let me know.
>
> Our next meeting should be this Friday 5 Dec.  We did not meet the prior
> week due to the US Thanksgiving holiday.  We can certainly discuss the path
> to publication without implementation if that's what's desired.
>

KT> Thanks. Just to be clear the WG needs to be polled for their desire to
proceed in this manner - i.e., this is just my suggestion.


>
> Even without the sanity check of implementation, I do urge you in your AD
> role to consider the burden for review for the document in its current
> form.


KT> Yes, this would be a biggie but not a blocker if it were a one-time
"large commit". See further for my real concern.


> As you've seen from other work from Mahesh (author, and AD), there's been
> a lot of discussion about how do we move things forward faster.  This has
> been done under the OPSAWG VELOCE discussions.
>
> Since it almost entirely certain that publication without implementation
> will require updates at a later time, it'd be useful to know what the
> strategy is for updates to the contents of the draft.  In its current form,
> each -bis would be 225+ pages of refresh.
>

KT> This is a real concern and a blocking one from my perspective. I've
seen this happen recently in other WGs and it is a problem that needs an
urgent solution - ideally as part of VELOCE but if not at least a more
immediate solution to enable patching of YANG models. We cannot be doing
200+ pages of bis. I am prepared to HOLD this work until that problem is
solved if the IDR chairs and WG agree.


>
> While the BGP YANG document will almost certainly benefit and serve as
> good use case for "do YANG faster in IETF", the authors aren't currently
> signed up to define and drive such methodology. :-)  It might be
> appropriate to set the BGP YANG publication timeline according to
> resolution of what such practices might be.
>

KT> +1 - I am with you and we seek help from Med & Mahesh.

Thanks,
Ketan


>
> -- Jeff
>
>