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

Yingzhen Qu via Datatracker <noreply@ietf.org> Tue, 22 August 2023 19:47 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 F0E0FC1519A9; Tue, 22 Aug 2023 12:47:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yingzhen Qu via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
Cc: draft-ietf-idr-bgp-car.all@ietf.org, idr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 11.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <169273366797.57910.11605264693841606773@ietfa.amsl.com>
Reply-To: Yingzhen Qu <yingzhen.ietf@gmail.com>
Date: Tue, 22 Aug 2023 12:47:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/4SgOciKKtA9nap1M-f6eHRKNtWc>
Subject: [Idr] Opsdir early review of draft-ietf-idr-bgp-car-02
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Aug 2023 19:47:48 -0000

Reviewer: Yingzhen Qu
Review result: Has Issues

Hi,

Thanks for the draft.

I am the assigned OPSDIR reviewer to conduct an "early" review of this draft.

General comments:

There are lots of abbreviations in the draft. I'd suggest to add them
in the the terminology section. For example, I'd assume BR means Border
Router, but there might be different guessing.

In this draft, it says E is globally unique, which makes E-C in that
order unique. Can you please explain a bit more about the second unique?
I suppose it's possible to have two different source nodes, E1 and E2,
all reach destination E with color C, correct?

The draft has an informative reference to
[I-D.hr-spring-intentaware-routing-using-color], which is an important problem
statement for this solution. Will the problem statement draft progress as well?
Even so, to improve the readability of the bgp-car draft, I'd suggest adding
some text for a brief introduction of the problem.

IP Prefix NLRI was added in version -02. The use case is where a unique
routable IP prefix is assigned a given intent or color. In other words,
the IP is overloaded with a color. The same can be achieved using an IP
with a color. I'm not totally convinced that this type 2 NLRI is needed.
Please clearly specify when it should be used.

Please consider adding a section for operation considerations. There are
pieces of information about operation and deployment scattered in the
document, please consider group them together.

There are quite some sentences missing "." at the end. Please do an
editorial pass and fix them.

Detailed comments with line # from idnits:

478        The value set (or appropriately incremented) in the AIGP TLV
479        corresponds to the metric associated with the underlying intent of
480        the color.  For example, when the color is associated with a low-
481        latency path, the metric value is set based on the delay metric.

483        Information regarding the metric type used by the underlying intra-
484        domain mechanism can also be set.

comment: This statement lacks a clear definition how the metric should be set.

486        If BGP CAR routes traverse across a discontinuity in the transport
487        path for a given intent, add a penalty in accumulated IGP metric
488        (value by user policy).  For instance, when color C1 path is not
489        available, and route resolves via color C2 path (e.g., Appendix A.3).

How about the case where encapsulations are different? For example, SR
policy in one AS and IGP-FlexAlgo in the other AS vs. SR Policy in both ASes.

Section 2.7
504        The (E, C) route inherently provides availability of redundant paths
505        at every hop, identical to BGP-LU or BGP IP.

"every hop" is a bit confusing here since it may mean an IGP hop within
an AS. To my understanding, this section means ECMP or backup paths can
provide protection in case of failure within an AS domain without impact
other ASes.
"Path Availability" as the section title is not very clear. How about something
like "Inherent Path Protection"?

513        BGP ADD-PATH should be enabled for BGP CAR to signal multiple next
514        hops through a transport RR.

I'd suggest to change to "SHOULD be enabled".

526        The BGP CAR solution seamlessly supports this (rare) scenario while

I'd suggest adding a small paragraph explaining why this is a rare but
useful case. I would guess the tow domains used to belong to different
administrators, now they're trying to merge under one admin domain.
nits: personally I don't like how "(rare)" with parentheses is used
here, but I'd leave this to the authors.

806        NLRI instead of the BGP Prefix SID attribute.  The BGP Prefix SID
807        Attribute SHOULD be omitted from the labeled color-aware routes when
808        the attribute is being used to only convey the Label Index TLV.
Add a reference to Appendix D?

848        BGP CAR SRv6 SID TLV definitions provide the following benefits:

850        *  Native encoding of SIDs avoids robustness issue caused by
851           overloading of MPLS label fields.

853        *  Simple encoding to signal Unique SIDs (non-transposition),
854           maintaining BGP update prefix packing

856        *  Highly efficient transposition scheme (12-14 bytes saved per
857           NLRI), also maintaining BGP update prefix packing
minor: I don't think the text belongs to the encoding section. Maybe
part of "Operation Considerations"?

1019       *  If multiple instances of same type are encountered, all but the
1020          first instance MUST be ignored.

1022       *  If multiple instances of same type are encountered, all but the
1023          first instance MUST be ignored.
nits: please remove the repetition.

1025       *  A TLV is not considered malformed because of failing any semantic
1026          validation of its Value field.
Q: When should a TLV be considered malformed? and how should it be handled?

1033    3.  Service route Automated Steering on Color-Aware path
nits: Service Route Automated Steering on Color-Aware Path
Please check to make sure all section titles are consistent.

1044       destination, per-flow, CO-only.  For brevity, in this revision, we
1045       refer the reader to the [RFC9256] text.
nits: maybe change to something like "For brevity, please refer to [RFC9256]
section X for detail."?

1047       Salient property: Seamless integration of BGP CAR and SR Policy.
minor: personally I don't think this sentence belong to this section.

1055    4.  Intents
The section title and content don't seem to match. I don't quite understand
the purpose of this section.

1085       A separate document will analyze the BGP CAR supports for 3, 5 and 6.
Any reference?

1097    5.1.  (E, C) Subscription and Filtering
Q: how is this subscription sent between routers?

1115       *  If A does not have (E2, C1), it will advertise F (E2, C1) to its
1116          peer B
I suppose it meant to be "If A does not have subscription of (E2, C1)"

1124       On-demand filtering procedures are outside the scope of this
1125       document.
what's "on-demand filtering"?

1138       Two key principles used to address the scaling requirements are a
1139       hierarchical network and routing design, and on-demand route
1140       subscription and filtering.
Q: on-demand filtering is claimed to be out of the scope. (line #1124)

1342       Note: E1 does not need the BGP CAR (451, C1) route
Q: what's the benefit?

1545    7.  Routing Convergence
comments: Maybe section 2.7 and 7 should be put together somehow, but I'll
leave this to the authors.

1602       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1603       |  NLRI Length  |  Key Length   |   NLRI Type   |Prefix Length  |
1604       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Q: what's value of the NLRI Type here?

1664       service route is advertised by the egress PE with a Color Ext-Comm C.
nits: "Color Ext-Comm" is only used here once while "Color Extended-Community"
elsewhere.

Nits: this section 9.2.1 and 9.2.2 needs some editorial work. For
example, each bullet point should be a sentence finished with a ".".

1796       CAR SAFI may also be used for best-effort routes in addition to
1797       intent-aware routes.
Q: Should a color be specified here? or use the IP Prefix NLRI Type 2?

2008       This extension defines a new SAFI within a BGP and therefore does not
it should be two new SAFIs: BGP CAR/83 and BGP VPN CAR/84

2307       The examples use MPLS/SR for the transport data plane.  Scenarios
2308       specific to other encapsulations will be added in subsequent
2309       versions.
nits: this should be removed.

Thanks,
Yingzhen