suehares
commented
1 year ago Jingrong discussion with Rakesh on IDR
[message 1]
Hi Jingrong, U r understanding is perfect. Sorry for the delayed response. Thanks Rajesh
Message
Hi Rajesh, No worry and thanks for your confirmation. A short comment is that, the SRv6 encapsulation in BGP-CT as I understand in the email below is costly. That’s the main concern from my side. Let me explain:
(use the simple topology in the draft section 5.1 and 3.1) {[1]----[2]----[4]}......{[6]----[8]----[10]}......{[12]----[15]----[16]}
1->2: (S=1, D=2)(16.DT4, B:4:REP::1, SL=2) (Customer-pkt) 2->4: (S=1, D=B:4:REP::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) 4->6: (S=1, D=B:6:REP6::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) // the B:4:REP::1 is no longer useful but still have to be carried in the packet. This is the core concern to me and the cause of impact below.
6->8: (S=6, D=8)(10, SL=1), (S=1, D=B:10:REP::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) //Another IPv6+SRH have to be encapsulated
12->14: (S=12, D=14)(B:16:END::1, SL=1), (S=1, D= B:16:END::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) //IPv6 + SRH + IPv6 + SRH + CustomerPkt. 14->16: (S=12, D= B:16:END::1)(B:16:END::1, SL=0), (S=1, D= B:16:END::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) //IPv6 + SRH + IPv6 + SRH + CustomerPkt.
//Problem have shown in the step 4->6 (and thus more steps are omitted), because the B:4:REP::1 is no longer useful but still have to be carried in the packet. //This is because, 16.DT4 is an Service SID, and B:4:REP::1 is a Transport SID, but they are carried in a single SRH, and thus not able to be remove alone because Service SID in the SRH is still useful. //To solve the problem, it may be possibly separate the two into different “layers”, just like MPLS do (VPN Label over BGP-LSP over IGP-LSP, using 3 Labels on top of one another).
//Option-1, to separate 16.DT4 and B:4:REP::1 into different IPv6 Headers. And this will solve the above problem caused by step 4->6.
1->2: (S=1, D=2)(B:4:REP::1, SL=1) (IPv6HDR2, S=1, D=16.DT4) (Customer-pkt)
2->4: (S=1, D=B:4:REP::1)(B:4:REP::1, SL=0) (IPv6HDR2
Thanks, Jngrong
kalirajv
Hi Sue and IDR Chairs,
Thank you for reminding me to review this draft. I have read the Section 7, section 18 and appendix D of this draft, and also the draft.
I think my previous comment [1] about the applicability of SRv6 data plane in BGP-CT is still open.
[1] https://mailarchive.ietf.org/arch/msg/idr/8Zqs8TgQctmg61V30l7oEi8Vf-A/
(The draft didn’t update since the comment [1] had made in July 2022).
For better understanding the comments I have made, let me use [1] as the Option-0 to explain: Option-0 (copy unchanged from [1] ): (use the simple topology in the draft section 5.1 and 3.1) {[1]----[2]----[4]}......{[6]----[8]----[10]}......{[12]----[15]----[16]}
1->2: (S=1, D=2)(16.DT4, B:4:REP::1, SL=2) (Customer-pkt) 2->4: (S=1, D=B:4:REP::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) 4->6: (S=1, D=B:6:REP6::1)(16.DT4, B:4:REP::1, SL=1) (Customer-pkt) //Problem have shown in the step 4->6 (and thus more steps are omitted), because the B:4:REP::1 is no longer useful but still have to be carried in the packet. //This is because, 16.DT4 is an Service SID, and B:4:REP::1 is a Transport SID, but they are carried in a single SRH, and thus not able to be remove alone because Service SID in the SRH is still useful. //To solve the problem, one may possibly separate the two into different “layers”, just like MPLS do (VPN Label over BGP-LSP over IGP-LSP, using 3 Labels on one another).
//Option-1, to separate 16.DT4 and B:4:REP::1 into different IPv6 Headers. See below: 1->2: (S=1, D=2)(B:4:REP::1, SL=1) (IPv6HDR2, S=1, D=16.DT4) (Customer-pkt) 2->4: (S=1, D=B:4:REP::1)(B:4:REP::1, SL=1) (IPv6HDR2) (Customer-pkt)
4->6: (S=1, D=B:6:REP6::1)(IPv6HDR2) (Customer-pkt) //Note: the SRH that carrying the Transport SIDs can be removed either by USD or PSP)
(other steps omitted)
//Option-2, to separate 16.DT4 and B:4:REP::1 into different SRH headers. See below: 1->2: (S=1, D=2)(B:4:REP::1, SL=1) (SRH2, SL=1, D=16.DT4) (Customer-pkt) 2->4: (S=1, D=B:4:REP::1)(B:4:REP::1, SL=1) (SRH2) (Customer-pkt)
4->6: (S=1, D=B:6:REP6::1)(SRH2) (Customer-pkt) //Note: the SRH that carrying the Transport SIDs can be removed either by USD or PSP)
(other steps omitted)
Please Note:
The summary so far is that, the applicability of SRv6 data plane in BGP-CT is still open (repeated).
Second comment is about appendix D.2:
In this approach, a unique service SID is allocated for each combination of service function (e.g. Prefix, VRF or Nexthop) and an egress SRv6 color sub-locator. This consumes "Num_Service_Functions x Num_SRv6-color-sub-locators" service SIDs per egress SN. This approach can be used by devices that possess limited SID stacking capabilities to be able to support differential services at the cost of more state in the transport network. These color Service SIDs //[X1] need to be present across the entire transport network for the forwarding to work. This makes the transport network state a function of the service layer SID state.
This Service SID scale impacts the overall convergence while executing operational procedures like color sub-locator modification, //[X2] where all the service routes have to be readvertised with their new Service SID computed as a result of the color sub-locator change. This also impacts BGP PIC (Prefix scale Independent Convergence) for the egress SN failure where all Service SIDs need to be withdrawn. //[X3]
This approach achieves strict color based forwarding for the service routes. However, it cannot achieve per service route fallback intent using resolution schemes as BGP CT procedures are not applied to service family routes.
[X1] In CPR draft, the transport layer nodes (PEs &ASBRs) need to be aware of the “Coloring Prefix” or Sub-Locator which covering the “SIDs” belonging to the same Color/Intent of a tenant/VPN/User. [X2] See above [X1]. Only the scale of “Coloring-Prefix” (not the scale of Service SIDs) is the factor to be aware by the Transport layer nodes, in signaling and FIB/Forwarding procedure. [X3] See above [X1] and [X2].
The Summary for the second comment is that, the CT authors seem not fully understand the CPR draft, for example the granularity in signaling/FIB-building procedure (per SID or per sub-locator).
Note, the “SRv6 data plane” is the really focusing aspect, and I would suggest that my previous comment about “SRv6 data plane” problem in CT draft can be fully understood firstly.
Regards, Jingrong