Re: [Tsv-art] Tsvart early review of draft-ietf-idr-sr-policy-safi-00

[Ketan Talaulikar <[e-mail]>]

Hi David,

Thanks for your review.

-Ketan


On Thu, Feb 29, 2024 at 7:58 AM David Black via Datatracker <
[e-mail]> wrote:

> Reviewer: David Black
> Review result: On the Right Track
>
> The result of this early TSV-ART review's is "On the Right Track" rather
> than
> some form of "Ready" for the sole reason that the scope of this review is
> limited to the requested scope, namely:
> ---
> INT/Transport Area Review team:
> This routing document (draft-ietf-idr-sr-policy-safi) extends the color
> functions in the BGP Extended Community Color to aid the steering of
> traffic
> flows into particular routing paths.  Color tagging is part of the
> Intent-based
> signaling of upper-layer desire for VPNs within routing technology. Other
> drafts that provide functions to carry Intent are draft-ietf-idr-bgp-car
> (via
> color) and draft-ietf-idr-bgp-ct (via class).
>
> It would be good to get a transport reviewer to help see if we are really
> Transport/INT functions being defined.
> ---
>
> In addition to the drafts noted in that request, RFC 9256 (Segment Routing
> Policy Architecture) has already introduced the use of color in SR Policy
> (Segment Routing Policy).  Section 2.1 of RFC 9256 requires use of color
> for SR
> Policy identification, and section 8 of RFC 9256 makes extensive use of
> color
> in procedures for BGP steering of traffic based on SR Policies.  I don't
> believe that RFC 9256's extension of color to this sort of BGP steering
> poses
> any serious transport-related concerns, even if that BGP functionality is
> used
> to realize QoS differences among portions of traffic to the same
> destination.
> That's just as well, as any such concern would almost certainly also need
> to be
> raised against RFC 9256, a Proposed Standard RFC, and not just against this
> draft.
>
> This draft is primarily concerned with how BGP carries SR Policy
> information
> needed to realize the SR Policy functionality defined in RFC 9256.  That
> does
> not raise any transport-related concerns beyond RFC 9256.
>
>
>
>