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

[[e-mail]]

Re-,

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani <[e-mail]>
Envoyé : mercredi 3 décembre 2025 17:06
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Ketan Talaulikar <[e-mail]>; Jeffrey Haas <[e-mail]>; Inter-Domain Routing Discussion List <[e-mail]>
Objet : Re: New Liaison Statement, "oLS to IETF on BGP data model"



Hi Med,

See inline with [mj]


On Dec 3, 2025, at 7:39 AM, [e-mail]<mailto:[e-mail]> wrote:

Hi Ketan, Jeff, all,

Putting aside VELOCE for a moment, I think that the maintenance of BGP models can be simplified and avoid +200 bis doc by considering the following:

•         You can offload all the IANA-maintained modules from the current spec and seek for their publication (iana-bgp-community-types, iana-bgp-notification, iana-bgp-types, iana-bgp-rib-types).

[mj] The plan was always to offload the IANA based modules to IANA for further maintenance. The process of how that happens might be different, but that is the intent.
[Med] The point is that you can decorrelate their publication from the main BGP models and move those in the publication process independently. Bundling all the pieces in one single document is not justified for this part, IMO.


·         Publishing these modules is orthogonal to the implementation policy the IDR WG has, as this is about providing a representation of IANA registries.

o    These types can be used/leveraged by other BGP-related modules as these values are important for interop

o    Note also that, per 8407bis, final RFC do not need to include the initial version of such modules as IANA is the authoritative source for those.

·         You may consider one further doc split: common types/grouping vs main data structures. This doc split is what was followed for VPN data models, attachment circuits, etc.

o    Similar to IANA types, common types are likely to be leveraged outside the IETF.

[mj] I am opposed to further split of the document at this stage. It will only further delay the publication of the module. There are common types/groupings that can be referenced/used by other modules in and outside of IETF by including the right set of modules.
[Med] I’m not sure there is extra delay that will be induced, but I think that this approach is worth to be considered by the WG to ease maintenance, usability, etc. I’m not expressing a preference, though.

Thanks.



o

Now, if we suppose that VELOCE is in place, the current provision (no consensus yet) is that bis will be scoped to describe updates only:

   *  Bis versions of the initial RFC MAY be considered to document
      major changes and their rationale.  Such a decision is left to the
      WG.  The RFC update is scoped to the narrative part describing the
      updates.  WGs may decide to maintain an adopted YANG module in the
      IETF repository but never seek for an RFC publication of major
      module revisions.

Hope this helps.

Cheers,
Med

De : Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>
Envoyé : mercredi 3 décembre 2025 14:33
À : Jeffrey Haas <[e-mail]<mailto:[e-mail]>>
Cc : Inter-Domain Routing Discussion List <[e-mail]<mailto:[e-mail]>>; Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>; BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Objet : Re: New Liaison Statement, "oLS to IETF on BGP data model"


+ 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 <[e-mail]<mailto:[e-mail]>> wrote:
Ketan,


> On Nov 22, 2025, at 2:25 AM, Ketan Talaulikar <[e-mail]<mailto:[e-mail]>> 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

____________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.


Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>





____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.