From nobody Wed Jun 16 15:36:51 2021 Return-Path: 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 598D13A0852 for ; Wed, 16 Jun 2021 15:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 X--cOR0MnxaI for ; Wed, 16 Jun 2021 15:36:45 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78CB83A084E for ; Wed, 16 Jun 2021 15:36:45 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id i13so6881197lfc.7 for ; Wed, 16 Jun 2021 15:36:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kBBztxCvZdh2hoFRQN+05dpMrl6GMCZn4ROY3GlpFxE=; b=FnDUYa2RHAzR9gBv09or/Q7HI+49z/JVu2WNvSktjw3ptx3w+V9IQDSoMqw7kKw9Dq 41LDLFuupOqWNh891hI/p2yuCZL7ENYNoQu7pd8q1qzI7XasWODtFQ4WLDXpFsxEl7DO HXd5JlsMz7wNd3S/IeNT2aMykB21w+OqHFPe9N44N0h4WjDRY+GErKdBf0z7adQxAuWf HFkmI69pitUyJqrON+DuRhewNKb2Aa3f6UPBZmNqa5GDJCWLOukX9j5thUBvdHeCnGbf UYQ5TudrjfQGGsl1qefPOPHb+afcSE2WH5rkWXDDb/EeXsekDVTtRRmuCA6p6SHJQHrG 7AeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kBBztxCvZdh2hoFRQN+05dpMrl6GMCZn4ROY3GlpFxE=; b=G7WwrlMPhHdev5UJkiCIORa31dab4wRc8oltvbP9zYOzpMry9iE1UAvBnHhqJ75Soq m+sl3xV1km0qTj64O/bIq6WCSUqZGZNq5SHdP0KoEt1kPQRJ1JeRNQknK4aMdfOxC4UK COANfBhqH1Gw3ZyWqv48UJd4gsVF6fp8N4twb3kd+RkrWhypxjTX/XEhg/LD+NGacmr+ Entd54jq2h4NeBJHUvY2lQUj9moJ3X/fmdmT4qTN1g4WRuO19iR5DX5qsYdyiECbF+Nd 68tWvPJaKEHo+QLcAyfxnRhpW4R91xjo7GT13SkAT5AdpQFsBVm53oWlTz6gpDg6Z7ws ObUQ== X-Gm-Message-State: AOAM531Co8dimqG6a59WMm4RTxlCQU6LlgAb/0W7f4OIuTi77mhMfHCr fsFyoM6uw2c/ylMqRg4oolwfZ5ebRZgN/Q9WFF+TOw== X-Google-Smtp-Source: ABdhPJx7BNLqcikrFS3XrJX9sK/Lb0zbPv5EIENI7IhPw8PYMWs13TcjVw3pvXyVRPzPjIhucyODygXgkBuIZM7t6FA= X-Received: by 2002:a19:484d:: with SMTP id v74mr1541019lfa.396.1623883002945; Wed, 16 Jun 2021 15:36:42 -0700 (PDT) MIME-Version: 1.0 References: <162387309626.26876.9780257787421823003@ietfa.amsl.com> In-Reply-To: <162387309626.26876.9780257787421823003@ietfa.amsl.com> From: Robert Raszuk Date: Thu, 17 Jun 2021 00:36:32 +0200 Message-ID: To: Robert Wilton Cc: The IESG , draft-ietf-idr-bgp-optimal-route-reflection@ietf.org, idr-chairs , "idr@ietf. org" , John Scudder , Susan Hares , Alvaro Retana Content-Type: multipart/alternative; boundary="0000000000008c329705c4e9b9b6" Archived-At: Subject: Re: [Idr] Robert Wilton's No Objection on draft-ietf-idr-bgp-optimal-route-reflection-25: (with COMMENT) X-BeenThere: idr@ietf.org 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: Wed, 16 Jun 2021 22:36:49 -0000 --0000000000008c329705c4e9b9b6 Content-Type: text/plain; charset="UTF-8" Hi Robert, > May I please check, is there a YANG data model that covers this functionality? The original plan was to add this to the main BGP YANG specification - draft-ietf-idr-bgp-model-10 to keep this part of the main BGP YANG model document. But it seems that this document moved on and now is in IETF LC. We are discussing with co-authors and contributors how to address this at the current point. I am not sure what is IDR WG process in respect to YANG model definition as most if not all documents passing WG LC and becoming RFCs do not contain the YANG section (recent example rfc9012, rfc9003, rfc8956 etc ...). I checked with a few shipping implementations and it seems that vendors have already extended their YANG models with BGP-ORR feature. So it seems that what is defined at this point may cause backwards compatibility issues too. Many thx, Robert On Wed, Jun 16, 2021 at 9:51 PM Robert Wilton via Datatracker < noreply@ietf.org> wrote: > Robert Wilton has entered the following ballot position for > draft-ietf-idr-bgp-optimal-route-reflection-25: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this document - sounds useful! And thanks to Dan for the > Ops-dir review. > > May I please check, is there a YANG data model that covers this > functionality? > > Regards, > Rob > > > > --0000000000008c329705c4e9b9b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,

> May I please check, is = there a YANG data model that covers this functionality?

<= /div>
The original plan was to add this to the main BGP YANG specificat= ion -draft-ietf-idr-bgp-model-10=C2=A0to keep this= part of the main BGP YANG model document.=C2=A0

B= ut it seems that this document moved on and now is in IETF LC.=C2=A0
<= div>
We are discussing with co-authors and contributors how t= o address this at the current point.=C2=A0

I am no= t sure what is IDR WG process in respect to YANG model definition as most i= f not all documents passing WG LC and becoming RFCs do not contain the YANG= section (recent example rfc9012, rfc9003, rfc8956 etc ...).=C2=A0

I checked with a few shipping implementations and it seems= that vendors have already extended their YANG models with=C2=A0BGP-ORR fea= ture. So it seems=C2=A0that what is defined at this point may cause backwar= ds compatibility issues too.=C2=A0

Many thx,
=
Robert


On Wed, Jun 16, 2021 at 9:51 PM Robert Wilt= on via Datatracker <noreply@ietf.org> wrote:
Robert Wilton has entered the following ballot position f= or
draft-ietf-idr-bgp-optimal-route-reflection-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.iet= f.org/doc/draft-ietf-idr-bgp-optimal-route-reflection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this document - sounds useful!=C2=A0 And thanks to Dan for the O= ps-dir review.

May I please check, is there a YANG data model that covers this functionali= ty?

Regards,
Rob



--0000000000008c329705c4e9b9b6--