Re: [Tsv-art] [Idr] Tsvart early review of draft-ietf-idr-bgp-ct-srv6-03

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Joseph,

Thanks for your review comments. Sorry for the delay in response.


Please see inline. KV>

Thanks
Kaliraj



Juniper Business Use Only
From: Idr <[e-mail]> on behalf of Joseph Touch via Datatracker <[e-mail]>
Date: Thursday, March 28, 2024 at 7:25 PM
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [Idr] Tsvart early review of draft-ietf-idr-bgp-ct-srv6-03
[External Email. Be cautious of content]


Reviewer: Joseph Touch
Review result: Not Ready

This document was reviewed as per the following request:

TSV-DIR - Please look at this draft from the viewpoint of having intent (color)
aware customer traffic forwarded over a VPN overlay (tunnels) that forwarded
over a set of intent (color) aware underlay of tunnels.  Please consider the
problems with tunnels in your review of this text.

The document refers to these tunnels in a manner that appears consistent with
draft-ietf-idr-bgp-ct. As a side note, it would be preferable for this document
to refer to the terminology of this bgp-ct draft rather than repeating it, so
it would be more clear which terms are introduced herein. Avoiding duplication
also avoids the need to align the two sets of definitions upon publication.

KV> The terminology is given in place instead of reference to base bgp-ct draft, to aid in readability.
KV> We had received comments that it would be better to have the terminologies used in this document
KV> defined in this document itself. I am OK with either approach, but one thing to consider is: the Terminologies
KV> section of Base BGP-CT draft is not a strict subset of the BGP-CT-SRv6 draft.
KV> There may be some terms that are not used in CT-SRv6 draft. So slightly inclined towards in-place terminology.
KV> We will trim down terms that we see are not used in the draft.


TSV-DIR area of concern appears to originate in the bgp-ct draft rather than
herein. There are a variety of issues with tunnels not addressed in either
document, many of which are described in draft-ietf-intarea-tunnels (though not
refreshed, this remains an active INTAREA doc), notably the difference between
tunnel path MTU, tunnel egress MTU, and overall path MTU of the tunneling
service (which is dependent on the latter rather than the former), especially
the difficulty in determining the tunnel path MTU.


KV> The note on MTU is a valid deployment consideration, and we have added a note in draft-bgp-ct-30 Sec 11.4<https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html#section-11.4>
KV> This was done recently based on the TSVART review of bgp-ct draft. It is not clear which version of draft-bgp-ct
KV> was referred to in above comment. Please let me know if the text in 11.4 addresses your concern.
KV> We can further put a reference to rfc4459 or draft-ietf-intarea-tunnels which discuss tunnel/MTU issues in more detail.
KV> It may be better to refer to these documents which cover this comprehensively, rather than repeat it here.

The way in which both
documents refer to tunneling as (IMO) 'do a tunnel, whatever that involves' is
a bit of a disconnect with the idea that these tunnels, when deployed, provide
service assurances on which upper layers can plan. In particular, Section 4.1
of the bgp-ct doc gives some potentially relevant examples, but only for a
subset of the tunneling technologies described in the definition.

KV> Focus of the base BGP-CT draft is to map services over tunnels belonging to a certain transport-class,
KV> without dependency on details of each tunneling technology. That is why we don’t talk much
KV> about details of the intra-domain tunneling technology. The tunneling technology specific details are
KV> out of scope of the BGP-CT drafts.

KV> How the different intra-domain tunnels are stitched
KV> together to form an end-to-end CT tunnel using MPLS dataplane on inter-AS links is explained in draft-bgp-ct.
KV> And this draft-bgp-ct-srv6 describes how the same is achieved with SRv6 instead of MPLS.


Both documents would benefit from a more precise definition of the tunnel
technologies that have properties needed to support these methods. In
particular, a tunnel cannot provide "transport class aware" services unless

that can be assured by the layer over which the tunnel operates or by the
tunnel protocol itself. E.g., a tunnel cannot provide guaranteed BW over a
best-effort network, but a tunnel can create assured in-order delivery over an
underlay without such ordering guarantees.

KV> It seems there may be a disconnect on what transport class awareness means.

KV> ‘Transport Class’ is an abstract classification of the tunnels characteristics.
KV> a tunnel becomes TC-aware (participates in BGP-CT architecture), by being
KV> associated with a TC-ID, and allowing service routes to resolve over it using
KV> the Resolution-Scheme construct (ordered list of TC-IDs).

KV> It’s correct that it is Operator’s responsibility to classify tunnels with similar claracteristics
KV> into an appropriate Transport Class. So, a best-effort tunnel should not be put into a TC that provides BW guarantee.
KV> This is explained in draft-bgp-ct Sec 4.1<https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-30.html#section-4.1>



_______________________________________________
Idr mailing list
[e-mail]
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!Ez5U3Uwdrs9by8bJ8h-xID8xfCJzxpOEYs1W6e5FRzFsalsjIS-_ujPuoijLU1VDaqV9U3Ki-B8OAuE$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!Ez5U3Uwdrs9by8bJ8h-xID8xfCJzxpOEYs1W6e5FRzFsalsjIS-_ujPuoijLU1VDaqV9U3Ki-B8OAuE$>