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

[Gyan Mishra <[e-mail]>]

Hi Alexander

Do you think some of what you are looking for could be addressed by CATS WG
or even  draft
https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-31
.

This document describes a new Edge Metadata Path Attribute added to a BGP
UPDATE message [RFC4271 <https://www.rfc-editor.org/info/rfc4271>] for
egress routers to advertise the Metadata about 5G low latency edge services
directly attached to the egress routers. 5G [TS.23.501-3GPP
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-5g-edge-service-metadata-31#TS.23.501-3GPP>
]is characterized by having edge services closer to the Cell Towers
reachable by Local Data Networks (LDN). From an IP network perspective, the
5G LDN is a limited domain [RFC8799
<https://www.rfc-editor.org/info/rfc8799>] with edge services a few hops
away from the ingress nodes. Only selective UE services are considered as
5G low latency edge services.


The AI DC related attributes  could possibly leverage this drafts opaque
metadata  path attribute and be used for AI DC path preference to carry
data related to your use case.

Kind Regards

Gyan

On Sun, Jan 25, 2026 at 7:16 PM 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]
>