Re: [Idr] Some review comments on BGP-CT

[Kaliraj Vairavakkalai <[e-mail]>]

Hi Sue, Jie,

I incorporated Jie’s comments in draft version 18, along with Jeff’s comments.

https://www.ietf.org/archive/id/draft-ietf-idr-bgp-ct-18.html

Some responses inline.

Thanks
Kaliraj



Juniper Business Use Only
From: Susan Hares <[e-mail]>
Date: Monday, October 23, 2023 at 10:38 AM
To: Kaliraj Vairavakkalai <[e-mail]>
Subject: FW: Some review comments on BGP-CT
[External Email. Be cautious of content]

Kaliraj:

They were sent only to the IDR chairs.  I will ask Jie to send to the IDR Mail list.

Sue

From: Dongjie (Jimmy) <[e-mail]>
Sent: Monday, October 23, 2023 7:18 AM
To: Susan Hares <[e-mail]>; Jeffrey Haas <[e-mail]>; Keyur Patel <[e-mail]>
Cc: [e-mail]
Subject: Some review comments on BGP-CT


Hi Sue, Jeff and Keyur,

Please find below some review comments on BGP-CT. Sorry for the delay in sending them out.

These comments was mainly on version -14, so some of them may already be resolved in recent updates.


1.       Abstract

It talks about using BGP-CT as a construct to realize IETF network slices. As I know, the network slice framework does not mention intent-based routing mechanisms. Thus the relationship between CT and network slicing is not that clear. Suggest to remove this.

KV> It is relevant to network slicing.
    There is also mention on control plane extensions to achieve this kind of slicing - in network slicing overview draft.
    Ref: https://www.ietf.org/archive/id/draft-boucadair-teas-ietf-slicing-overview-04.html#section-6.1


2.       Introduction

“The mechanisms defined in this document are agnostic to the tunneling technologies. These can be applied homogeneously to intra-domain tunneling technologies used in brownfield networks as well as greenfield networks. E.g. MPLS Traffic Engineering (TE) or Segment Routing (SR)).”

Jie: The brownfield and greenfield description depends on the time and the technology used in the network first, thus may not be accurate in all cases. Suggest to remove brownfield and greenfield here.

KV> above statement does not indicate a specific technology as brownfield or greenfield. It just says CT can be used in all these deployments.


3.       Terminology

- BGP VPN: VPNs built using RFC4364 mechanisms.

Jie: Does it refer to only BGP IP VPN, not BGP L2 VPN or EVPN? Suggest to make this clear.

KV> It referes to the base VPN architecture. Which L3VPN, L2VPN, EVPN follow.

- VRF: Virtual Router Forwarding Table

Jie: It should be: Virtual Routing and Forwarding table.

KV> Done.

- SID: SR Segment Identifier

Jie: It should be: Segment Identifier

KV> Done.



4.       Section 2.1 Definitions

“Service Family: A BGP address family used for advertising routes for "data traffic" as opposed to tunnels (e.g. AFI/SAFIs 1/1 or 1/128).”

Jie: AFI/SAFI 1/1 is not used for tunnels.

KV> actually that’s what above statement means. It is used to advertise routes for destinations in ‘data traffic’.
KV> I will remove the ‘as opposed to tunnels’ part, if it confused you.

“Tunnel Ingress Route: A Route to Tunnel Destination/Endpoint that is installed at the headend (ingress) of the tunnel using a tunneling mechanism.

Jie: This term is a little strange to me. It is the route to the tunnel egress/endpoint, not to the ingress. And in the following sections a short term “ingress routes” is also used, which is even more confusing whether it is the route to the ingress or egress.

KV> Ok, let me call it just “Tunnel Route”. Done.

“Tunnel Domain: A domain of the network containing Service Nodes (SNs) and Border Nodes (BNs) under a single administrative control that has tunnels between them. An end-to-end tunnel spanning several adjacent tunnel domains can be created by "stitching" them together using MPLS labels (or an equivalent identifier based on the forwarding architecture).”

Jie: The second sentence is about how end-to-end tunnel can be created in MPLS data plane. Suggest to split out from the Tunnel Domain definition.

KV> Done.

Transport Class: A construct to group transport tunnels offering the same SLA.

Jie: Is it same SLA or similar SLA?

KV> changed to similar.

Mapping Community: Any BGP Community/Extended Community on a BGP route that maps to a Resolution Scheme. e.g., color:0:100, transport-target:0:100.

Jie: Allow many communities to be used as mapping community is flexible, while may add complexity in implementation. Why not simply define a specific type of community as mapping community?

KV> this flexibility is found to be useful, in order to differentiate the needs of service and transport routes.

And is transport-target short for transport-class RT?

KV> Yes, explained transport-target in sec 2.1

Transport Plane: An end-to-end plane consisting of transport tunnels belonging to the same Transport Class. Tunnels of the same Transport Class are stitched together by BGP CT route readvertisements with next hop self to enable Label-Swap forwarding across domain boundaries.

Jie: The second sentence does not belong to the definition of transport plane, it is more about the realization.

KV> I think it is ok to explain how it is realized.


5.       Section 3 Architecture overview

“Overlay routes carry sufficient indication of the desired Transport Classes using a BGP community which assumes the role of as a "Mapping Community". A Resolution Scheme is identified by its "Mapping Community", where its configuration can either be auto-generated based on TC ID or done manually.”

Jie: suggest to be more accurate on “a BGP community” here. Can any type of BGP community/extended community/large community be used for the role of “mapping community”.

KV> yes. The receiver of BGP route can use any community like attribute to map to a resolution-scheme. Added Clarifying text


6.       Section 4 Transport Class

“A Transport Class is also configured with RD and import/export RT attributes. Creation of a Transport Class instantiates its corresponding TRDB and Resolution Schemes on that node.”

Jie: Suggest to provide some text about why RD and RT are configured for transport class.

KV> I think Protocol Procedures explain in good detail how RD and RT are used.

Review comments on the remaining sections will be provided later.

Best regards,
Jie