-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feedback on Appendix D from Jingrong #22
Comments
Jingrong discussion with Rakesh on IDR Hi Jingrong, MessageHi Rajesh, (use the simple topology in the draft section 5.1 and 3.1) 1->2: (S=1, D=2)(16.DT4, B:4:REP::1, SL=2) (Customer-pkt) 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 ; IPv6 + SRH + IPv6 + SRH + CustomerPkt. 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. //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. //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. Thanks, |
Hi Jingrong, Please find the response inline in green color (placed in bold) Thanks Hi Sue and IDR Chairs, Thank you for reminding me to review this draft. For better understanding the comments I have made, let me use [1] as the Option-0 to explain: 1->2: (S=1, D=2)(16.DT4, B:4:REP::1, SL=2) (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. we r planning to mention this in our draft [SRv6 inter-domain mapping SIDs (ietf.org)] |
From: Jingrong Xie xiejingrong@huawei.com Fully understood. Jingrong. 本邮件及其附件可能含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件! From: Rajesh M [mailto:mrajesh@juniper.net] Hi Jingrong, Please find the response inline in green color. Thanks Hi Sue and IDR Chairs, Thank you for reminding me to review this draft. For better understanding the comments I have made, let me use [1] as the Option-0 to explain: 1->2: (S=1, D=2)(16.DT4, B:4:REP::1, SL=2) (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. we r planning to mention this in our draft SRv6 inter-domain mapping SIDs (ietf.org): //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. //Option-1, to separate 16.DT4 and B:4:REP::1 into different IPv6 Headers. See below: //Option-2, to separate 16.DT4 and B:4:REP::1 into different SRH headers. See below: Please Note: Both Options will cost more bytes in the step 1->2 and 2->4 but will cause less bytes in step 4->6; Second comment is about appendix D.2: In this approach, a unique service SID is allocated for each This Service SID scale impacts the overall convergence while This approach achieves strict color based forwarding for the service [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. 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, Juniper Business Use Only Hi Susan, +Rajesh to this thread, so that he can respond to Jingrong’s comments on draft-salih-spring-srv6-inter-domain-sids-02.html. Rajesh, Sue has added this email from Jingrong to github as an issue as-well: https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/issues/22 once you have a closure with Jingrong, you can summarize it there, and we can close the issue. Thanks Juniper Business Use Only Feedback on SRV6. Sue From: Jingrong Xie <xiejingrong@huawei.com> |
closed with the publication of draft-ietf-idr-ct-12 |
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-salih-spring-srv6-inter-domain-sids-02.html> 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 <draft-salih-spring-srv6-inter-domain-sids-02.html> 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
The text was updated successfully, but these errors were encountered: