[Idr] Opsdir early review of draft-ietf-idr-cpr-02

Dan Romascanu via Datatracker <noreply@ietf.org> Fri, 31 May 2024 19:07 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14201C1CAF53; Fri, 31 May 2024 12:07:52 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Dan Romascanu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171718247206.34624.2098415723570266398@ietfa.amsl.com>
Date: Fri, 31 May 2024 12:07:52 -0700
Message-ID-Hash: R6PANLLTGO6IU3O3JCT7DES4FMQNTFLI
X-Message-ID-Hash: R6PANLLTGO6IU3O3JCT7DES4FMQNTFLI
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-idr-cpr.all@ietf.org, idr@ietf.org, dromasca@gmail.com
X-Mailman-Version: 3.3.9rc4
Reply-To: Dan Romascanu <dromasca@gmail.com>
Subject: [Idr] Opsdir early review of draft-ietf-idr-cpr-02
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bF3TbgqW58XBTqtzmhJXLGzQcQs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Reviewer: Dan Romascanu
Review result: Has Issues

Thus is an early OPS-DIR review of draft-ietf-idr-cpr-02.

The document aims Informational Status.It describes a mechanism to advertise
IPv6 prefixes in BGP which are associated with Color Extended Communities to
establish end-to-end intent-aware paths for SRv6 services. Such IPv6 prefixes
are called "Colored Prefixes", and this mechanism is called Colored Prefix
Routing (CPR).

Operators that have under their responsibility multi-services networks running
BGP should be familiar with this document.

>From and Operational and Manageability point of view this document is Almost
Ready. I found two issues that require clarifications.

Operational Considerations are described in Section 4. I found two places where
clarifications are needed:

1. The first paragraph is unclear to me. What does the sentence 'While an
operator may prefer a BGP-based solution for the reasons described there.'
mean? I guess that this is related to the previous statement (' ... the
inter-domain intent-aware routing may be achieved with SR Policy across
multiple domains, and services with specific intent can be steered to SR Policy
at the ingress domain based on Color') with the intention of defining an
exception, but the grammatical inconsistency makes the statement vague.
Clarification is needed.

2. The following paragraph reads:

> There may be multiple inter-domain links between network domains,. A
   border node may receive CPR routes from multiple peering border
   nodes.  Then the border node may take the attributes of the inter-
   domain links and/or the attributes of the received CPR routes into
   consideration to select the best path for specific Colored Prefixes
   to better meet the intent.  The detailed mechanism is up to the
   operator's policy.

The first sentence seems incomplete. Moreover, what if the network domains
belong to different operators with different policies? Operator's policies need
to be somehow synchronized. How?