Closed sa1231-coder closed 8 months ago
Just to keep track this is what should be included:
On item 1, have you assumed a topology example?
If so, we should check this example on the list.
Cheerily, Sue
consider draft-wang-idr-cpr for its operational/deployment needs.
Please discuss these operational needs with the authors of the draft.
I'm going to check with Jie Dong on Monday (US Time).
Jingrong is fine with the latest text. Please see the thread below
From: Jingrong Xie [xiejingrong=40huawei.com@dmarc.ietf.org](mailto:xiejingrong=40huawei.com@dmarc.ietf.org) Date: Thursday, November 30, 2023 at 11:47 PM To: Swadesh Agrawal (swaagraw) [swaagraw@cisco.com](mailto:swaagraw@cisco.com) Cc: Dhananjaya Rao (dhrao) [dhrao@cisco.com](mailto:dhrao@cisco.com) Subject: RE: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023) - Follow-up on Adoption call issue regarding SRv6 support
Hi Swadesh,
Thanks for your reply on my comments. Those comments are all minor ones and suggestions, and I am fine with your point to keep them in current shape.
One small nit in the last part of appendix C.2 (just before C.3):
==========Current text begin=========== Packet forwarding
@E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red
==========Correct text Begin (the line with first "@231")=========== Packet forwarding
@E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red
One more discussion/remind about removing the SRH with SL==0 by node-121: If B:C13:121:END:: is an End SID with PSP flavor, then it is right according to RFC8986 to remove the SRH with SL==0 (after update DA). if B:C13:121:END:: is an End SID without PSP flavor, then it is right to NOT remove the SRH with SL==0 (after update DA) as illustrated in C.2 currently. Therefore, I am fine to keep it unchanged, but just want to discuss/remind on this point. SA>> Sure. It’s an example with PSP flavor, an optimized implementation should support it.
Regards, Jingrong
本邮件及其附件可能含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件! This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
From: Swadesh Agrawal (swaagraw) [mailto:swaagraw=40cisco.com@dmarc.ietf.org] Sent: Thursday, November 30, 2023 6:56 AM To: Jingrong Xie [xiejingrong@huawei.com](mailto:xiejingrong@huawei.com) Cc: Dhananjaya Rao (dhrao) [dhrao@cisco.com](mailto:dhrao@cisco.com) Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023) - Follow-up on Adoption call issue regarding SRv6 support
Hi Jingrong,
Thanks for the review and comments. Sorry for the delayed reply. Reason for it was due to more urgent CAR related closures. I am starting the private thread to close on the comments you provided among us before replying on the list. Please find my response inline starting with SA>
Regards Swadesh
From: Idr [idr-bounces@ietf.org](mailto:idr-bounces@ietf.org) on behalf of Jingrong Xie [xiejingrong=40huawei.com@dmarc.ietf.org](mailto:xiejingrong=40huawei.com@dmarc.ietf.org) Date: Monday, August 14, 2023 at 11:39 PM To: Susan Hares [shares@ndzh.com](mailto:shares@ndzh.com), idr@ietf.org [idr@ietf.org](mailto:idr@ietf.org) Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023) - Follow-up on Adoption call issue regarding SRv6 support
Hi Sue,
I consider the issues about SRv6 support in CAR are resolved, and the left thing is about wording and phrasing in the shepherding procedure.
I am not good at shepherding a document, but I would like to share my suggestions for considering in the following “wording and phrasing” work:
If section 9.1.2 is considered not useful, then the illustration in Appendix C.3 can be removed, together with section 9.1.2. I would prefer the later one, because a non-routed Service SID (VPN) over transport end-to-end BGP Path over intra-area IGP Path is always OK but will cause encap cost in SRv6. But I would let the authors and shepherd to decide on this. SA> RFC 9252 describes service steering of non-routed SRv6 service SID over SR policy. Section 9.1.2 extends it across multi domain n/w using BGP CAR, similar to such scenarios with SR-MPLS. The section is required for completeness of solution and helps illustrate technical details.
----updated understanding on the procedure of appendix C.2----
@E1->121: {(E1.loop,B:C13:121:END::) (B:C11:2:DT4::; 1) } [IPv4-User-Packet]
@121->231: {(121.loop,B:C12:231:END::) } {(E1.loop, B:C11:2:DT4::) (B:C11:2:DT4::; 0) } [IPv4-User-Packet]
@231->E2: {(E1.loop, B:C11:2:DT4::) (B:C11:2:DT4::; 0) } [IPv4-User-Packet]
----Checking the following description currently in appendix C.2, I would suggest that ONLY the packet on wire is illustrated (like above), because the behavior (according to some state like IPv6/SID Table) is more detailed and should have done before the brief text---- SA> We as authors believe that referring to behaviors of RFC 8986 is formal description and reduces issues due to different interpretations. RFC 8986 has pseudo code of each of the applicable behaviors.
@E1: IPv4 VRF V/v => H.Encaps.red <B:C13:121:END::, B:C11:2:DT4::>
@121: My SID table: B:C13:121:END:: => Update DA with B:C11:2:DT4::
@121: IPv6 Table: B:C11::/32 => H.Encaps.red
----Further, I would suggest that the SRH with SL==0 is Popped or deleted, with the following two options for consideration---- ----option-1, Divide the service and transport into 2 layers of IPv6 header @E1---- @E1->121: {(E1.loop,B:C13:121:END::)} {(E1.loop, B:C11:2:DT4::)} [IPv4-User-Packet] //Use 2 IPv6 headers to divide the service and transport into 2 layers of encapsulation. @121->231: {(121.loop,B:C12:231:END::) } {(E1.loop, B:C11:2:DT4::) } [IPv4-User-Packet] //No longer have an SRH from the first step above. @231->E2: {(E1.loop, B:C11:2:DT4::) } [IPv4-User-Packet] SA> Yes, both options are valid with different tradeoffs. We’ve chosen to illustrate the collapsed/merge encapsulation as it’s simpler for the ingress PE. But it’s just an example
----option-2, Do POP & Encapsulation @121---- @E1->121: {(E1.loop,B:C13:121:END::) (B:C11:2:DT4::; 1) } [IPv4-User-Packet] @121->231: {(121.loop,B:C12:231:END::) } {(E1.loop, B:C11:2:DT4::) } [IPv4-User-Packet] //Pop the SRH with SL==0 and thus no longer have an SRH with SL==0. @231->E2: {(E1.loop, B:C11:2:DT4::) } [IPv4-User-Packet]
Note in option-2 that, this kind of behavior to pop the SRH with SL==0 together with a further encapsulation, is very similar to the behavior of a Binding SID in Section 4.13 of RFC8986. Unfortunately it seemed not careful enough in RFC8986 to get this right ---- the pseudo code in section 4.13 of RFC8986 did not pop the SRH with SL==0 when it could. I’d like to bring this to Spring for discussion. SA> The above example behavior is not based on Binding SID in section 4.13 of RFC 8986. (Note: This is the exact reason we believe referring to behaviors of RFC 8986 is more formal and normative description then showing packets. Removes incompatibility due to different interpretations). SA> The relevant case is in fact the PSP flavor of Endpoint behavior. Updated packet is submitted for IPv6 lookup. IPv6 lookup result in encapsulation.
Thanks, Jingrong
本邮件及其附件可能含有华为公司的保密信息,仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用(包括但不限于全部或部分地泄露、复制、或散发)本邮件中的信息。如果您错收了本邮件,请您立即电话或邮件通知发件人并删除本邮件! This e-mail and its attachments may contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, August 14, 2023 11:01 PM To: idr@ietf.org Subject: Re: [Idr] WG LC for draft-ietf-idr-bgp-car-02 (7/10/2023 to 7/24/2023) - Follow-up on Adoption call issue regarding SRv6 support
Jingrong:
Are the issues you raised regarding SRv6 support in the WG LC for draft-ietf-idr-bgp-car-02 Resolved?
This was denoted as adoption call issue F3-WG-02- SRV6 Support.
Original email: IDR mail link: https://mailarchive.ietf.org/arch/msg/idr/7C7dlvIgZuNNx3rLorC6S24Ta50/
The review email you sent on 7/18/2023 https://mailarchive.ietf.org/arch/msg/idr/ZTJk3xKtwG1Xw0vkUEFjpYmbfLY/
Your additional support for draft-ietf-idr-bgp-car-02 on 8/1 https://mailarchive.ietf.org/arch/msg/idr/eFIvPtDdFWwU2MczU6XwzHape9M/
Thank you, Sue
Working on the updates.