Hi Gyan, I don’t fully understand the “… local block similar to SR-MPLS SRGB called the GIB Global Segment ID Block … “. Let me suppose it is “ … global block similar to SR-MPLS SRGB called the GIB Global Segment ID Block …”.
You say SRv6 Prefix SID is something global similar to SR-MPLS SRGB, and SRv6 Adj-SID is something local and similar to SR-MPLS SRLB, and then VPN SID for multicast can be the same as Adj-SID. That is exactly what I think is wrong and that’s the 2nd part of the “VPN SID in multicast” issue ---- SRv6 DCB SID for Multicast. Because in Multicast, there are normally more than 1 egress PE, and each egress PE will have a unique Locator to allocate the VPN SID even you say it is “local SID”, and the SRH can not encode these VPN SIDs. Comparably, in unicast, each node has a unique Locator to allocate “local SID” like 2001:db8:b:2::101 as End.X, it can be encoded in SRH SID List and not breaking the SRv6 architecture, though it is not the real practice we normally use SRv6 AFAIK. Back to Multicast, one may claim that, each egress PE node configure the same Block and the same Locator and then the same “FUNCT” value, and then it is an SRv6 DCB SID. However, as I questioned in [4] and I repeat it here: what is the 128bit DCB SRv6 SID looks like ? ffff:ffff:x:x:x:x:x:x? ff00:x:x:x:x:x:x:x? fe08:x:x:x:x:x:x:x? ::127.x.x.x ? (or maybe ::FFFF:127.x.x.x) ? Once the above question is answered, I think a conclusion can be reached that the SRv6 DCB SID is not an SRv6 SID because it does no longer have the “Locator” meaning, and hence break the SRv6 architecture. Not to mention many other impacts like breaking the meaning of SRH/SID-list/Segment-Left/etc, and many conflicting behaviors beyond those have already listed in [5]. FYI: The 1st part in the “VPN Sid in multicast” issue is ---- SRv6 Upstream-assigned SID for Multicast. I have described a lot on this 1st part of issue, like the following [5], and I also give some suggestions toward solving the issue like the following [6] and [8]. [8] https://mailarchive.ietf.org/arch/msg/spring/iEyXYqthZSGNAqrBe3fLA8LKaKo/ 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: Gyan Mishra [mailto:hayabusa...@gmail.com] Sent: Tuesday, January 24, 2023 2:06 PM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com> Cc: James Guichard <james.n.guich...@futurewei.com>; Rishabh Parekh <risha...@gmail.com>; SPRING WG <spring@ietf.org>; spring-cha...@ietf.org Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Hi Jingrong I am not sure this will help clarify. Within an SRv6 domain a block is allocated for the SRv6 domain B:N::/48 where B is the block and N is the locator globally routable within the domain. The SRv6 topological SID has a local block similar to SR-MPLS SRGB called the GIB Global Segment ID Block which the SRv6 locator prefix SID is assigned which is the N field made up of 16 bits, 64k global SIDs. There is also a LIB Local Segment ID similar to SR-MPLS SRLB, which is used to dynamically assign SRv6 Adj-Sid End endpoint behavior and also used for L3 VPN or MVPN service SID or for L2 VPN EVPN pseudowires SID and has total of 8192 SIDs. “ There MAY be SIDs after the Replication SID in the SRH of a packet. These SIDs are used to provide additional context for processing a packet locally at the node where the Replication SID is the Active Segment. The processing of SIDs following the Replication SID MUST NOT forward the SRv6 packet to some other node. The restrictions described in this paragraph apply to both un-compressed and compressed SRv6 encapsulation.” My interpretation is the SIDs following the Replication SID are service SIDs, maybe related MVPN SIDs on the egress PE to be processed on that node and not forwarded to another node. Hope that helps. Kind Regards Gyan On Thu, Jan 19, 2023 at 9:30 AM Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: 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<mailto:risha...@gmail.com>] Sent: Wednesday, January 18, 2023 11:15 AM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>> Cc: James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>; spring-cha...@ietf.org<mailto: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<mailto:spring@ietf.org> https://www.ietf.org/mailman/listinfo/spring -- [图像已被发件人删除。]<http://www.verizon.com/> Gyan Mishra Network Solutions Architect Email gyan.s.mis...@verizon.com<mailto:gyan.s.mis...@verizon.com> M 301 502-1347
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
