[Idr] Re: Fwd: I-D Action: draft-wang-idr-dpf-00.txt

[Robert Raszuk <[e-mail]>]

Hi Kevin,

I am sceptical if the proposed BGP extension is desired in BGP protocol.
But this is just my own opinion and as Jeff says I can be in "rough" on it.

But reading on your proposal I do think that marking this coloring on a per
BGP session basis (strict or loose) is a very bad idea. We have departed
from any per session marking when MP BGP Extensions have been introduced.
So if you want to continue I recommend a much more granular capability of
coloring. Ideally on a per NLRI/UPDATE MSG basis.

With your current proposal you have created a physical partitioning not
logical one.

Also can you elaborate in your draft (keeping in mind BGP native
recursiveness) why BGP CAR or BGP CT proposals fail to address your
objectives ? Are they broken and need fixing or you just prefer to start
fresh with yet one more way to achieve the same ?

Thank you,
R.



On Thu, Dec 4, 2025 at 10:18 PM Wang, Kevin <[e-mail]> wrote:

> Hi Robert,
>
> Unless we have perfect load balancing, congestion is always possible, even
> in a non-blocking Clos fabric. Also, there are other scenarios where
> avoiding fate-sharing paths is crucial.
>
> Thanks,
> Kevin
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Wednesday, December 3, 2025 at 3:59 PM
> *To: *Wang, Kevin <[e-mail]>
> *Cc: *Gyan Mishra <[e-mail]>, idr@ietf. org <[e-mail]>,
> lsr <[e-mail]>
> *Subject: *Re: [Idr] Re: Fwd: I-D Action: draft-wang-idr-dpf-00.txt
>
> Hi Kevin,
>
> Your draft explains how to do poor man's flex algo in BGP - ok.
>
> But could you elaborate why anyone would do that (and push more
> complexity) in a non-blocking CLOS fabric ?
>
> Cheers,
> R.
>
>
>
> On Wed, Dec 3, 2025 at 7:35 PM Wang, Kevin <[e-mail]> wrote:
>
> Hi Robert,
>
> Thank you for providing further details about your thoughts. What I heard
> that IGP was not initially adopted in DC fabrics was due to its scaling
> issues (mostly due to lsdb flooding), especially for the hyperscalers. I
> understand that there were efforts later trying to address the scaling
> issues from IGP side. I see your experience of using ISIS to successfully
> construct the fabric as a good example. Yes, it might be worth to write an
> ISIS for DC fabrics informational RFC, serving as an alternative to RFC
> 7938. There are also other efforts trying to bring traffic engineering
> technologies, such as RSVP, MPTE, etc to the DC fabrics. Like any other
> networks, the DC fabrics will probably also evolve over time.
>
> Having said that, most of today’s DC fabrics (at least for those DC
> customers I have dealt with) are designed following RFC 7938:
>
>    - Use Clos topology
>    - Use IP forwarding
>    - Use EBGP as the underlay routing protocol
>
> I guess the choices above are for technical reasons as well as business
> reasons. BGP DPF is developed under the assumptions/observations above. I
> agree that the DC fabrics might evolve and adopt other technologies such as
> IGP, RSVP, in the future. For the time being and the foreseeable future,
> BGP DPF would help to provide a lightweight traffic engineering for the DC
> fabrics.
>
> Thanks,
> Kevin
>
> *From: *Robert Raszuk <[e-mail]>
> *Date: *Tuesday, December 2, 2025 at 2:46 PM
> *To: *Wang, Kevin <[e-mail]>
> *Cc: *Gyan Mishra <[e-mail]>, idr@ietf. org <[e-mail]>,
> lsr <[e-mail]>
> *Subject: *Re: [Idr] Re: Fwd: I-D Action: draft-wang-idr-dpf-00.txt
>
> Dear Kevin,
>
> I know very well what RFC 7938 says. In fact I did review this document
> well before it became an RFC :)
>
> But what happened next is that while RFC7938 make a valid observation on
> how one can build MSDCs lots of folks misinterpreted it as the only guide
> on how to build even a few racks of DC fabrics.
>
> So yes, using BGP to construct dynamic routing in the DC fabrics has its
> use cases that are really applicable to only a handful of deployments. And
> I am not aware that any of the MSDCs would be asking you for logical
> transport planes within their fabrics.
>
> All other DCs would be much better off using IGP for underlay and BGP for
> overlay as a design pattern.
>
> When I constructed 10 full racks of hardware using ISIS folks were shocked
> - and pointed out that I am not using an IETF standard approach :). Then
> when I demonstrated that connectivity restoration upon any node or link
> failure is repaired in less then 50 ms the masks went off.
>
> Maybe what is actually needed is an  informational RFC - just like RFC7938
> - simply illustrating that one can construct DC using ISIS. It is obvious
> to me, but I admit there is no RFC I am aware of to show operators that
> "Large-Scale Data Centers" can be robustly build with IGPs.
>
> Kind regards,
> Robert
>
>
> On Tue, Dec 2, 2025 at 7:24 PM Wang, Kevin <[e-mail]> wrote:
>
> Hi Robert and Gyan,
>
> Thanks for your feedback! Your observation is correct that IGP Flex Algo
> could achieve the same. BGP DPF can be though as a BGP counterpart of IGP
> Flex Algo to some extent (though not precisely).
>
> As explained in the “Introduction” section of this draft, BGP DPF is
> designed for the current IP fabric environment where EBGP is usually the
> only protocol used for routing. Section 5 of RFC 7938 explains why DC
> fabrics use EBGP as the sole routing protocol.
>
> Thanks,
> Kevin
>
> *From: *Gyan Mishra <[e-mail]>
> *Date: *Tuesday, December 2, 2025 at 7:43 AM
> *To: *Robert Raszuk <[e-mail]>
> *Cc: *idr@ietf. org <[e-mail]>, lsr <[e-mail]>
> *Subject: *[Idr] Re: Fwd: I-D Action: draft-wang-idr-dpf-00.txt
>
> I agree with Robert that you could use RFC 9502 IGP Flex Algo in IP
> networks to build disjoint planes as desired.
>
> You could also use SRv6 with IGP Flex Algo with SR RFC 9350 which uses
> IPv6 data plane and build your disjoint planes.
>
> Thanks
>
> Gyan
>
> On Tue, Dec 2, 2025 at 6:32 AM Robert Raszuk <[e-mail]> wrote:
>
> Hi,
>
> In respect to the subject draft ... why would you not use IGP Flexible
> Algorithm for it ?
>
> Are you going to port now years of work from IGP to BGP to achieve the
> same ?
>
> Besides, in a non-blocking fabric latency is really not a factor. So you
> want to logically partition it to make it blocking them worry about what
> travels on which such logical plane ? Is this a reasonable direction ?
>
> Thx,
> R.
>
> ---------- Forwarded message ---------
> From: <[e-mail]>
> Date: Mon, Dec 1, 2025 at 10:49 PM
> Subject: I-D Action: draft-wang-idr-dpf-00.txt
> To: <[e-mail]>
>
>
> Internet-Draft draft-wang-idr-dpf-00.txt is now available.
>
>    Title:   BGP Deterministic Path Forwarding (DPF)
>    Authors: Kevin Wang
>             Michal Styszynski
>             Wen Lin
>             Mahesh Subramaniam
>             Thomas Kampa
>             Diptanshu Singh
>    Name:    draft-wang-idr-dpf-00.txt
>    Pages:   18
>    Dates:   2025-12-01
>
> Abstract:
>
>    Modern data center (DC) fabrics typically employ Clos topologies with
>    External BGP (EBGP) for plain IPv4/IPv6 routing.  While hop-by-hop
>    EBGP routing is simple and scalable, it provides only a single best-
>    effort forwarding service for all types of traffic.  This single
>    best-effort service might be insufficient for increasingly diverse
>    traffic requirements in modern DC environments.  For example, loss
>    and latency sensitive AI/ML flows may demand stronger Service Level
>    Agreements (SLA) than general purpose traffic.  Duplication schemes
>    which are standardized through protocols such as Parallel Redundancy
>    Protocol (PRP) require disjoint forwarding paths to avoid single
>    points of failure.  Congestion avoidance may require more
>    deterministic forwarding behavior.
>
>    This document introduces BGP Deterministic Path Forwarding (DPF), a
>    mechanism that partitions the physical fabric into multiple logical
>    fabrics.  Flows can be mapped to different logical fabrics based on
>    their specific requirements, enabling deterministic forwarding
>    behavior within the data center.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-wang-idr-dpf/
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-wang-idr-dpf/__;!!NEt6yMaO-gk!EP_lEYmqbOUApQqqOz-ZuP9CsojS2gbvLvgQfxoYTXPXtS-0yjfv8ElqZwJBCRfOLFY6nymWoR5eJlshPeG9$>
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-wang-idr-dpf-00.html
> <https://urldefense.com/v3/__https://www.ietf.org/archive/id/draft-wang-idr-dpf-00.html__;!!NEt6yMaO-gk!EP_lEYmqbOUApQqqOz-ZuP9CsojS2gbvLvgQfxoYTXPXtS-0yjfv8ElqZwJBCRfOLFY6nymWoR5eJjgsy_TY$>
>
> 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]
>
>