search

ietf-wg-idr / draft-ietf-idr-bgp-car

0 stars 0 forks source link

F3-WG-Issue-2: Support for SR-v6 #7

Closed sa1231-coder closed 8 months ago

sa1231-coder commented 1 year ago

Working on the updates.

suehares commented 1 year ago

Just to keep track this is what should be included:

  1. WG (chair + Jingrong) should agree upon a topology example
  2. CAR: Provide an illustration of SRv6 data plane (e.g., E2E SRv6 & intra-domain SRv6) based on a sample topology
  3. CAR: (DJ) Add additional options and operational considerations that do need to be described. (CAR authors planned in July to include them along with illustrations in the next version of the draft.)

On item 1, have you assumed a topology example?

If so, we should check this example on the list.

Cheerily, Sue

suehares commented 1 year ago

consider draft-wang-idr-cpr for its operational/deployment needs.

Please discuss these operational needs with the authors of the draft.

suehares commented 1 year ago

I'm going to check with Jie Dong on Monday (US Time).

sa1231-coder commented 8 months ago

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 @231: My SID table: B:C12:231:END:: => Update DA with B:C11:2:DT4:: @231: IPv6 Table B:C11:2::/48 => forward via ISISv6 FA path to E2 @E2: My SID table B:C11:2:DT4:: =>pop the outer header and lookup the inner DA in the VRF ==========Current text end===========

==========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 @231: My SID table: B:C12:231:END:: => pop the outer header encapsulated. SA>> Ack. Will update the text to “Remove the outer IPv6 Header” @231: IPv6 Table B:C11:2::/48 => forward via ISISv6 FA path to E2 @E2: My SID table B:C11:2:DT4:: =>pop the outer header and lookup the inner DA in the VRF ==========Correct text End===========

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:

  1. Regarding Section 9.1.2 and its illustration: If section 9.1.2 is considered useful, then the illustration in Appendix C.3 can be rephrased carefully to illustrate BGP CAR (E,C) with non-routed SRv6 Service SID. SA> I have attached the proposed diffs that updates the text and packet forwarding in the illustration C.3. I hope it helps.

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.

  1. Regarding Section 9.1.1 and its illustration: Currently section 9.2 and 9.3 are mainly about 9.1.1 as I understand it, and so do appendix C.1 and C.2 (corresponding to section 9.2.1 and 9.2.2 respectively). I consider they are OK, and for Appendix C.2 I would have the following update on my understanding, and my further suggestion on “wording and phrasing” work:

----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 @231: My SID table: B:C12:231:END:: => Update DA with B:C11:2:DT4:: @231: IPv6 Table B:C11:2::/48 => forward via ISISv6 FA path to E2

----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