Hi Rishabh, WG: You say: “Your point [1] (Context SID in SRH), has already been discussed back-and-forth a few times in this thread.“ However, My core point that, the VPN SID (either Upstream-assigned or DCB) after the Replication SID, is breaking the SRv6 architecture, had never been directly answered but always been ignored (and avoided I guess). Example-1: Upstream-assigned VPN SID after the Replication SID, there are many details I have shown in [1], and there are many questions there. but you had always being ignored, and say you are “local” behavior. See below. Example-2: DCB VPN SID after the Replication SID, I have asked you to show what is the “DCB VPN SID” looks like in [4], but you had always been ignoring and avoiding. So, the core point had never been answered, and you say it has been discussed back-and-forth.
You say: “In SRv6 architecture, it is the function associated with a local SID that determines how a packet, including any additional headers like SRH, is processed.” However, as I comment in detail in [1], the local SID that defined in this document, overwrite the behavior that is defined in SRv6/SRH/SID-List/Segment-Left, hence break SRv6 architecture in semantics. Once again, the point is never directly answered, but ignored. You say: “In our solution, a transit replication node does not process the SID in SRH.” However, As I comment in detail in [1], the core point that the VPN SID (either Upstream-assigned or DCB) after the Replication SID is breaking the SRv6 architecture, is shown by so many differences between transit node and egress node, between behaviors of SRv6 and behaviors of your solution. You say: “You on the other hand have not provided any pointers to back up your claim like any MUST clause that mandates processing SRH for a local SID.” However, as explained above, “a local SID” is just a cause that avoid my above comment that, the draft is breaking the SRv6 architecture in semantics ---- the meaning of SRv6/SRH/SID-list/Segment-Left and so on. It is the responsibility of the authors to provide pointers to first define “local SID” term, and then its usage in the context of Replication SID, and then explain how does the “local SID” NOT break the SRv6 architecture in semantics. You ask for my back up pointers, but my back up pointers is to my comment that “the draft is break SRv6 architecture in semantics” as above. You haven’t solve my comment (with many detailed questions) but ask me to give a point to your wrong claim. If you are willing to know my points on your wrong claim of “local SID”, then here it is my comment: the local SID DCB, and SRv6 DCB SID is also breaking SRv6 architecture in semantics. If you are willing to know my points on how to solve the “VPN SID in Multicast” problem, then I can tell you that I have provided some options in [5], and the draft [6] can provide more details about using Source Address to carry VPN SID in multicast. You say: “For point [3], Jeffrey has addressed it in this response …The gist is that it is justifiably outside of the scope of this document.” However, the VPN SID (either Upstream-assigned or DCB) after the Replication SID is tightly related to the Replication SID, and the “breaking SRv6 architecture” question. Therefore, no matter whether it is moved, moved in rev-10 of this document, or moved out of the document in later revision if you think there are some other luckier wg, it is still a Spring problem. I guess Jeffrey knows [6] quite well, because it was blocked and then the Src.DT4/6/46 defined there was no longer discussed, and after that the End.DTMC4/6/46 was defined in the wing draft [7] of this draft and work as SRv6 DCB SID in signaling for SR-P2MP (the Replication SID solution). I think they can be read comparably, and the story behind that may help to understand why my valid comments is consistently being resisting. You say: “While it is outside the scope, to your point “there is no definition of … DCB in SRv6”, an IPv6 address is by nature from a “Domain-wide Common Block” because it is globally unique.” However, this is a question that “break the SRv6 architecture”. It is surely the choice of your and your coauthor’s whether to claim it is outside the scope, but it is still an “SRv6 architecture” problem. The SRv6 DCB SID is a completely new term that is created by SRv6 Replication SID, and I guess you need to first define the term, and then its usage in the context of Replication SID, and then explain how does the “SRv6 DCB SID” NOT break the SRv6 architecture in semantics. Seems like the “local SID” above and the “globally unique” SRv6 DCB SID are the same concept, so please define them and the relationship between them, seriously. Thanks Jingrong [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 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments 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: Rishabh Parekh [mailto:risha...@gmail.com] Sent: Wednesday, January 18, 2023 11:15 AM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com> Cc: James Guichard <james.n.guich...@futurewei.com>; SPRING WG <spring@ietf.org>; spring-cha...@ietf.org Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Jingrong, Your point [1] (Context SID in SRH), has already been discussed back-and-forth a few times in this thread. Our solution is not wrong technically. In SRv6 architecture, it is the function associated with a local SID that determines how a packet, including any additional headers like SRH, is processed. In our solution, a transit replication node does not process the SID in SRH. You on the other hand have not provided any pointers to back up your claim like any MUST clause that mandates processing SRH for a local SID. For point [3] (https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/__;!!NEt6yMaO-gk!DaNN7hKLM7QHvhFUXVLHBjZiskVFZBxVGfqX5_RbBh2rht738yavbsN6sEKXY7k4I5A3GxZ3ZXeEiW5A6dGdlA5KGz6BQtPT$>), Jeffrey has addressed it in this response: https://mailarchive.ietf.org/arch/msg/spring/0e3eP8W78HOXbvUwDcYajx-LomQ/. The gist is that it is justifiably outside of the scope of this document. While it is outside the scope, to your point “there is no definition of … DCB in SRv6”, an IPv6 address is by nature from a “Domain-wide Common Block” because it is globally unique. Thanks, -Rishabh On Fri, Jan 13, 2023 at 11:36 PM Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi WG: Thank you Jim, Joel & Bruno for updating the status of the WGLC and committing that every comments will be addressed and confirmed by the committers. However, my comments, for example the “issue #1 VPN SID in Multicast” we have heavily argued [1], are not confirmed but seem to hide by simply saying in [2] that: “We have published the next revision of the draft addressing comments so far.” I have being waiting for the authors to solve the issue #1, and then we can discuss the next issues one by one in detail. But from the claim as shown above, I am fairly unsure if the authors are willing to solve my comments. Back to my previous comments [3], I want to suggest once again to the WG to kindly consider to first exclude SRv6 data plane of this draft from the WGLC scope and so we can discuss on SR-MPLS data plane. [1] https://mailarchive.ietf.org/arch/msg/spring/659RqpS2eOabwBpist6iH6nGgrw/ r [2] https://mailarchive.ietf.org/arch/msg/spring/zo41ZDrH2Nq_xishIOly8ga19Ns/ [3] https://mailarchive.ietf.org/arch/msg/spring/B-A45Bw5vFMhvv3B2isxdfV5_DY/ Thanks Jingrong 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments 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:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] On Behalf Of James Guichard Sent: Wednesday, January 11, 2023 12:04 AM To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 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 <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> 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/ 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 _______________________________________________ spring mailing list spring@ietf.org<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
