[spring] [EXPERIENCE] //RE: WGLC for draft-ietf-spring-sr-replication-segment

["Xiejingrong (Jingrong)" <[e-mail]>]

Hi Jim and the WG:

Please allow me to provide the [EXPERIENCE], as promised in previous mail,  that a valid comment may be understood and adopted but may need quite a long time.

In July 2019, I comment on SRv6-OAM draft, and the main points there (see [A.1] and [A.2] below):
it is easy for an SID to support sending the ICMPv6 packet to CPU, and support pinging this SID just the same as pinging a classic IPv6 address.
The normal use of End.DT4 doesn't require an SRH header, while the pinging of the End.DT4 need to add an SRH with an End.OTP and the End.DT4. That is something bad.

In June 2020, the above comment is understood and adopted by the SRv6-OAM and SRv6-PGM document, which was later the RFC9259 and RFC8986 respectively.
The End.OP together with the use of SRH in SRv6-OAM is no longer used in SRv6-OAM rev-05. (See [A.3] below).
The modification in SRv6-PGM rev-16 is to make the SRv6 more “smooth” with IPv6, instead of using the semantics of SRv6 SID to “override” the behavior of normal IPv6 packet. (See the Pseudo-code in Section 4.1 of the rev-16 in [A.4] below ).


References:
[A.1] [2019.7.10] [Comments on <draft-ali-6man-spring-srv6-oam-02>] https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY<https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY/>/<https://mailarchive.ietf.org/arch/msg/ipv6/F_FtBGQNE51rL80h23XHmAqdQyY/>
[A.2] [2019.7.19] [Re: [spring] Comments on <draft-ali-6man-spring-srv6-oam-02>] https://mailarchive.ietf.org/arch/msg/spring/Nwf6EuJvox_RqXStnL3B_Ms5ngY<https://mailarchive.ietf.org/arch/msg/spring/Nwf6EuJvox_RqXStnL3B_Ms5ngY/>/<https://mailarchive.ietf.org/arch/msg/spring/Nwf6EuJvox_RqXStnL3B_Ms5ngY/>
[A.3] [2020.6.12] [SRv6-OAM adopted the above comments] https://author-tools.ietf.org/iddiff?url1=draft-ietf-6man-spring-srv6-oam-05
[A.4] [2020.6.27] [SRv6-PGM modified accordingly] https://author-tools.ietf.org/iddiff?url1=draft-ietf-spring-srv6-network-programming-16

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: spring [mailto:[e-mail]] On Behalf Of Xiejingrong (Jingrong)
Sent: Thursday, February 16, 2023 3:47 PM
To: James Guichard <[e-mail]>
Cc: SPRING WG <[e-mail]>; [e-mail]; Rishabh Parekh <[e-mail]>
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jim, and the WG:

Thank you Jim and the chairs very much for all of your patience to my comments on this topic.


For the question: “you believe the proposal breaks the SRv6 architecture as the forwarding relies upon local state rather than state carried within the SRH. Do I have that right?”:

The short answer is yes. My point is that, the local state of a “Replication SID” (which is in DA and acting as active SID), makes the many conflicting behaviors when a VPN SID is carried in SRH (and hence after the Replication SID).


For the request “If this is the case then you need to be specific in terms of which text/sentences in the document are in conflict with which text/sentences of existing RFCs.”:

I think I have provided the text/sentences of existing RFCs where the solution of this document is conflicting with in [1]. The sentences include:
SRv6(8986): The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.
SRH(8754): Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).
RH(8200): The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.
Segment Left(8200): 8-bit unsigned integer.  Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination.


And the text/sentences in the document is “SIDs after the Replication SID in the SRH of a packet.”.

The text/sentences in the document, has been summarized as “VPN SID after Replication SID”, and I assume that has been clear through previous discussions.


The “conflicting” is that, normal SRv6  will NOT override the behavior that is defined in the term of SRv6/SRH/RH/SL, but the local state of the Replication SID does this overriding, hence conflicting.
For an SRv6 packet (S=PE1, D=P1.End.Replicate) (SRH SL=1, VPN SID) received by P1, the active SID is P1.End.Replicate and there is an VPN SID to be processed as indicated by SL=1. The VPN SID, however, is not processed as normal but be processed with an “overriding behavior” by the state of  the “Replication SID”.

Even worse, such “overriding behavior” is various greatly in different nodes, for example, Ingress Node, transit node, egress node, and bud node.

Such a worse divergence of behavior has partly been listed in [1], but had always been avoided in the discussion.

Such a divergence of “overriding behavior” is not directly shown in the WGLC draft, but is, IMO, scattered in various drafts that are acting as the backing solution of this draft.

To make this more easy to understand, it may be helpful to have a comparative thinking like this:
What are the benefits of using SRH for VPN SID in multicast instead of using DOH ? ----DOH does not have the restriction in semantics of SRH/RH/SL that is conflicting.
What are the benefits of using SRH for VPN SID in multicast instead of using Src.DT4 as defined in [6] ? ----Src.DT4 does not have the restriction in semantics of SRH/RH/SL and  can save the encapsulation cost.


For the point “As written I think Rishabh’s forwarding example is accurate as he describes a lookup on the Replication SID and the action is to either update the outer IPv6 address with the downstream nodes address, or re-encapsulate the packet with a new IPv6 header and SRH.”:

As answered above, when there is an VPN SID after the Replication SID, and the VPN SID is expecting to be processed by the indicating of SRH SL==1, it is however not processed as normal but be processed with an “overriding behavior” by the state of  the “Replication SID”. That is the “conflicting” to SRv6 architecture.
The “re-encapsulate the packet with a new IPv6 header and SRH” behavior add the “divergence of behavior” of the “Replication SID” as described above.
BTW, the “re-encapsulate the packet with a new IPv6 header and SRH” will cause a higher cost in the packet size that is beyond the normal engineering IMO, and please allow me to talk about it in more detail later.


For the point “attention to  https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst which talks about the definition of future SIDs and their behaviors”:
I think I have explained about “Local Segment” and “Global Segment” to Gyan in [8] and got Gyan’s understanding in [9].
The steps S15/S16/S21/S22 in the pesuedo-code of above link (RFC8754 4.3.1.1) may provide a useful reference to understand my previous comment about “processed as normal” of SRv6,  and “overriding behavior” of “Replication SID”.


Finally, I would like to remind that, the “breaking SRv6 architecture because of VPN SID in Multicast” is not the only concern I have on this document.
I would be happy to continue the arguement about the “VPN SID in Multicast” question,  along with many other questions that is still queued in my mind (as I mentioned previously).
It may need time for the authors to understand my comments in my experience [EXPERIENCE], and I would try to be patient for the understanding and discussion and hope I can get your great patience too.
I would also like to write a draft [DRAFT] to explain in detail about the impacts of SRv6-multicast approaches to SRv6 architecture in general for the WG to evaluate.


Thanks,
Jingrong


[REFERENCES] Following links are references that I have used in above mail or previous mails:

[1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/

[2] https://mailarchive.ietf.org/arch/msg/spring/zo41ZDrH2Nq_xishIOly8ga19Ns/

[3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/

[4] https://mailarchive.ietf.org/arch/msg/spring/ou0V6vmWm4hlAk4I9Cuad1QXzIo/

[5] https://mailarchive.ietf.org/arch/msg/spring/DygdlzN2PiyXkN8RKjy3mb53mYE/

[6] https://datatracker.ietf.org/doc/html/draft-xie-bier-ipv6-mvpn-01

[7] https://datatracker.ietf.org/doc/html/draft-ietf-bess-mvpn-evpn-sr-p2mp-06
[8] https://mailarchive.ietf.org/arch/msg/spring/x49aMfShzK_mM3wf8_FRLoRgZYo/
[9] https://mailarchive.ietf.org/arch/msg/spring/FyoRJdW2fMx1yVid0ddl8Pz4QeY/


[EXPERIENCE]: Experience of comments to be understood and adopted in a very long time.
--TO BE provided.

[DRAFT]: About impacts of SRv6-multicast approaches to SRv6 architecture.
--TO BE provided.


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
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: spring [mailto:[e-mail]] On Behalf Of James Guichard
Sent: Thursday, February 16, 2023 12:05 AM
To: Xiejingrong (Jingrong) <xiejingrong=[e-mail]<mailto:xiejingrong=[e-mail]>>; [e-mail]<mailto:[e-mail]>; Rishabh Parekh <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Jingrong & document authors,

I would like for now to leave aside the issue of whether or not application/VPN specifics should be outside the scope of this SPRING document (I will however be revisiting this point in subsequent emails) and focus on bringing closure to the technical comments detailed in https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D&reserved=0>.

As I read through your comments Jingrong I think I can summarize your objection to be that you believe the proposal breaks the SRv6 architecture as the forwarding relies upon local state rather than state carried within the SRH. Do I have that right? If this is the case then you need to be specific in terms of which text/sentences in the document are in conflict with which text/sentences of existing RFCs. As written I think Rishabh’s forwarding example is accurate as he describes a lookup on the Replication SID and the action is to either update the outer IPv6 address with the downstream nodes address, or re-encapsulate the packet with a new IPv6 header and SRH. I might draw your attention to  https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst which talks about the definition of future SIDs and their behaviors.

Further your comments appear to me to suggest that the VPN identification encapsulated at PE1 acts like a normal VPN SID in the sense that forwarding is based upon that IPv6 address. I don’t think that is the intent here; I think the SID is used as an identifier for the VPN itself so that the downstream nodes are given the correct VPN forwarding context i.e. they are not supposed to use that SID to forward the packets back to PE1. Perhaps the authors could clarify this point further?

Hi Rishabh, it would be helpful if you could review the comments in https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D&reserved=0> again and perhaps provide more clarity on the expected behavior as there seems to be a difference in understanding of the actual operation.

Thanks!

Jim

From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of Xiejingrong (Jingrong)
Sent: Friday, February 10, 2023 9:55 AM
To: [e-mail]<mailto:[e-mail]>; Rishabh Parekh <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi WG,

I don’t agree with Bruno’s point that “this draft could be better restricted to the SR-replication segment itself, leaving any application/VPN specifics outside the scope of this SPRING document”.
As I commented in [8] to the same point, the backing solution of this document is tightly related the SR-Rep Segment and the VPN identifier.
The SR-Rep Segment provides the semantics/context for the many conflicting behaviors ---- the behavior of the {SR-Rep Segment + VPN Segment} together,  and the behavior of normal SRv6.
If it is claimed that this draft is only about SR-rep segment itself, I don’t think it is toward to answer the “breaking SRv6 architecture” question.

For the point that “For the SRv6 dataplane, as the IPv6 destination address is modified en route …”
I have some similar comments previously, and I still have more comments on this topic but they are queued for the “breaking SRv6 architecture” comment above to be solved.

Thanks,
Jingrong

[8] https://mailarchive.ietf.org/arch/msg/spring/_1sSZCfCZWlHwXvYpfOtDZZ9M3g/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2F_1sSZCfCZWlHwXvYpfOtDZZ9M3g%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0fgFYpM5Wp6C0oYLCbyj7jNiHSnGDjFTg8RzkFnQ8Mw%3D&reserved=0>


本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
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: spring [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, February 10, 2023 5:28 PM
To: Rishabh Parekh <[e-mail]<mailto:[e-mail]>>
Cc: SPRING WG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi Rishabh, authors

Speaking as an individual contributor.
Following a request, I've done a review of the latest version of the draft.
Please find below some proposed comments.

--
As a general comment, may be this draft could be better restricted to the SR-replication segment itself, leaving any application/VPN specifics outside the scope of this SPRING document. This may help with the resolution of some WGLC comments.

--
Ideally, SR Replication and SRv6 compression would be orthogonal hence SRv6 compression would not need to be referenced, not to mention recommended ("SHOULD use a Compressed SID (C-SID) container with Downstream Replication SID as the Last uSID"). If you chose to keep recommending or even proposing uSID, you would need a normative reference to the SRv6 compression document, which may delay the RFC publication of this document. Also, depending on your choices, a uSID End.Replicate Endpoint behavior may be needed to be allocated by the IANA.

--
In general, there are two replication SIDs/nodes: the one instantiating the replication SID and the downstream one.
In order to help the reader, making this explicit in some sentences could be useful. e.g.

§2.1 SR-MPLS

OLD: There MAY be SIDs preceding the SR-MPLS Replication SID
NEW: SIDs MAY be added before the downstream SR-MPLS Replication SID

--
For the SRv6 dataplane, as the IPv6 destination address is modified en route, there seem to be some impact for the ICMP ping checksum.
cf https://datatracker.ietf.org/doc/html/draft-ietf-spring-srv6-srh-compression-03#section-10.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-spring-srv6-srh-compression-03%23section-10.2&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QhmU8ZZCzycpGTNEbVNUV7oygTsT196ShDhB0GYtyd4%3D&reserved=0>
Probably, it would be useful to cover this in the document.

Hope this helps.
Regards,
--Bruno



Orange Restricted
From: spring <[e-mail]<mailto:[e-mail]>> On Behalf Of James Guichard
Sent: Tuesday, January 10, 2023 5:04 PM
To: SPRING WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Hi WG:

Just a quick update on the status of this WGLC. The authors are working on the various comments received so far on the list and will also most likely publish a new version of the document once all comments have been addressed. For this reason the chairs will keep this WGLC open until those actions have taken place and commenters have confirmed that their comments have been addressed.

Thanks!

Jim, Joel & Bruno

From: James Guichard
Sent: Monday, November 28, 2022 10:10 AM
To: SPRING WG <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: WGLC for draft-ietf-spring-sr-replication-segment

Dear WG:

This email starts a 2-week Working Group Last Call for https://datatracker.ietf.org/doc/draft-ietf-spring-sr-replication-segment/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-replication-segment%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C59bc7fddac014518488008db0b76fb95%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638116377898936638%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hMN8Q50SRhD8RoJTdJzdC%2Bdi5q0DESr1gr5XdZxWBjI%3D&reserved=0>

Please read the updated document if you haven’t already and send your comments to the SPRING WG list no later than December 12th 2022.

If you are raising a point which you expect will be specifically debated on the mailing list, consider using a specific email/thread for this point.

Lastly, if you are an author or contributor please respond to indicate whether you know of any undisclosed IPR related to this document.

Thanks!

Jim, Joel & Bruno



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.