[Idr] Re: Fwd: I-D Action: draft-montrose-idr-gpu-capability-00.txt

[Robert Raszuk <[e-mail]>]

Well, creating new attributes in BGP codebase these days is a cookie cutter
:)

However I can easily imagine requirements to drop such an attribute while
letting NHC to pass - even on ingress of some BGP speakers.

See what strikes the most here is this sentence in the abstract:

This optional, transitive attribute enables schedulers,
   orchestration systems, and control-plane applications to discover GPU
   resources directly through BGP,


And since when schedulers and orchestration systems talk BGP ? On the
other hand such information is pretty much useless for spine,
leafs/TORs or even most of the compute nodes. So how does it fit to be
carried in BGP ?


I would rather prefer such info to be distributed in real time via one
of the pub-sub message busses or even exported as telemetry from GPU
nodes directly to schedulers and orchestration systems.


Cheers,

Robert



On Mon, Jan 26, 2026 at 10:24 AM Donatas Abraitis <
[e-mail]> wrote:

> >IMO separating this into a new attribute is cleaner and safer.
>
> Yes and no :) NHC is already defined and implemented by some of the
> well-known implementations, and adding something on top is easier (much
> faster too).
>
> Regarding the new various types as you said, I agree, it will be a mess,
> eventually.
>
> On Mon, Jan 26, 2026 at 11:19 AM Robert Raszuk <[e-mail]> wrote:
>
>> Hi Donatas,
>>
>> IMO separating this into a new attribute is cleaner and safer. I would
>> even consider new SAFI if we (majority of the WG would consider this as a
>> useful addition to BGP).
>>
>> But irrespective into which envelope we stuff it I believe my questions
>> and comment still stands.
>>
>> Thx,
>> R.
>>
>> On Mon, Jan 26, 2026 at 9:16 AM Donatas Abraitis <
>> [e-mail]> wrote:
>>
>>> Hi,
>>>
>>> wouldn't it be just easier to implement this as a next-hop dependent
>>> characteristic?
>>>
>>> On Mon, Jan 26, 2026 at 2:16 AM Robert Raszuk <[e-mail]> wrote:
>>>
>>>> Hi Alexander,
>>>>
>>>> I have read your proposal with interest.
>>>>
>>>> I have two questions and one concern about it ...
>>>>
>>>> Question 1: Assume a compute node with GPU is reachable over IPv4 and
>>>> IPv6. So in which AFI 1 or 2 would this new attribute be sent ?
>>>>
>>>> Question 2: Are you assuming that there is no aggregation of the
>>>> information and as you said in overlay only /32 and /128 host routes are
>>>> carried across a given DC fabric ?
>>>>
>>>> Concern: A lot of proposed TLVs may change in sub second time scale.
>>>> After that the data becomes irrelevant. For example the amount of free GPUs
>>>> or the amount of Free RAM. How do you justify such information to be
>>>> stuffed into BGP Routing Protocol and how are you going to assure that it
>>>> will not impact actual routing itself ? Note that today most if not all BGP
>>>> implementations use a single session for all AFI/SAFIs carried, use single
>>>> BGP I/O etc ... And here you are not even separating this application level
>>>> information from routing information.
>>>>
>>>> Kind regards,
>>>> Robert
>>>>
>>>>
>>>> ---------- Forwarded message ---------
>>>> From: <[e-mail]>
>>>> Date: Mon, Jan 26, 2026 at 12:33 AM
>>>> Subject: I-D Action: draft-montrose-idr-gpu-capability-00.txt
>>>> To: <[e-mail]>
>>>>
>>>>
>>>> Internet-Draft draft-montrose-idr-gpu-capability-00.txt is now
>>>> available.
>>>>
>>>>    Title:   BGP Optional Transitive Attribute for Advertising GPU and
>>>> AI Accelerator Capabilities
>>>>    Author:  Alexander Montrose
>>>>    Name:    draft-montrose-idr-gpu-capability-00.txt
>>>>    Pages:   6
>>>>    Dates:   2026-01-25
>>>>
>>>> Abstract:
>>>>
>>>>    This document defines a new BGP path attribute, GPU_CAPABILITY, to
>>>>    allow network devices to advertise the availability, capacity, and
>>>>    characteristics of GPU and AI accelerators within a data center or AI
>>>>    fabric. This optional, transitive attribute enables schedulers,
>>>>    orchestration systems, and control-plane applications to discover GPU
>>>>    resources directly through BGP, integrating resource-awareness into
>>>>    routing and placement decisions. The attribute is TLV-based,
>>>>    extensible, and vendor-neutral.
>>>>
>>>> The IETF datatracker status page for this Internet-Draft is:
>>>> https://datatracker.ietf.org/doc/draft-montrose-idr-gpu-capability/
>>>>
>>>> There is also an HTMLized version available at:
>>>>
>>>> https://datatracker.ietf.org/doc/html/draft-montrose-idr-gpu-capability-00
>>>>
>>>> Internet-Drafts are also available by rsync at:
>>>> rsync.ietf.org::internet-drafts
>>>>
>>>>
>>>> _______________________________________________
>>>> I-D-Announce mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>> _______________________________________________
>>>> Idr mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>
>>>
>>> --
>>> Donatas
>>>
>>
>
> --
> Donatas
>