suehares
commented
6 months ago You might want to alphabetize the notations under "notation". I'm fine with that as well.
Consider also if
"End to end Tunnel" should be "End to End Tunnel (ETE tunnel)"
Closed suehares closed 5 months ago
suehares
commented
6 months ago You might want to alphabetize the notations under "notation". I'm fine with that as well.
Consider also if
"End to end Tunnel" should be "End to End Tunnel (ETE tunnel)"
suehares
commented
6 months ago Nit from Keyur's review
suehares
commented
6 months ago Jie Dong's comment
Jie: Does it refer to only BGP IP VPN, not BGP L2 VPN or EVPN? Suggest to make this clear.
Jie: It should be: Virtual Routing and Forwarding table.
Jie: It should be: Segment Identifier
suehares
commented
6 months ago Jie Dong's comment
“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.
“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.
“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.
Transport Class: A construct to group transport tunnels offering the same SLA.
Jie: Is it same SLA or similar SLA?
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? And is transport-target short for transport-class RT?
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.
kalirajv
commented
6 months ago Will take care of sorting Terminologies and Definitions in alphabetical order.
actually EP is already there in sec 2. will add 'endpoint of a tunnel' in that.
Recording response to Jie's comments here:
From: Kaliraj Vairavakkalai kaliraj@juniper.net Date: Sunday, November 5, 2023 at 3:30 PM To: Susan Hares shares@ndzh.com, Dongjie (Jimmy) jie.dong@huawei.com, idr@ietf.org idr@ietf.org Subject: Re: Some review comments on BGP-CT 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
From: Susan Hares shares@ndzh.com Date: Monday, October 23, 2023 at 10:38 AM To: Kaliraj Vairavakkalai kaliraj@juniper.net 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) jie.dong@huawei.com Sent: Monday, October 23, 2023 7:18 AM To: Susan Hares shares@ndzh.com; Jeffrey Haas jhaas@pfrc.org; Keyur Patel keyur@arrcus.com Cc: idr-chairs@ietf.org 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.
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
“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.
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.
Jie: It should be: Virtual Routing and Forwarding table.
KV> Done.
Jie: It should be: Segment Identifier
KV> Done.
“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.
“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
“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
kalirajv
commented
5 months ago Closed based on above thread
2 Terminology - I would prefer to see this list alphabetized to make it easier to look up terms, but perhaps that is just a personal preference.
https://datatracker.ietf.org/doc/review-ietf-idr-bgp-ct-18-rtgdir-early-hardwick-2023-12-18/
Sue's comment. It is very important for the abbreviations. It is very helpful for the definitions and notations.