Hi Jingrong, Please see inline.
From: Xiejingrong (Jingrong) <xiejingr...@huawei.com> Sent: Monday, February 20, 2023 4:39 AM To: Joel Halpern <j...@joelhalpern.com>; James Guichard <james.n.guich...@futurewei.com>; bruno.decra...@orange.com Cc: SPRING WG <spring@ietf.org> Subject: RE: [spring] WGLC for draft-ietf-spring-sr-replication-segment Hi Joel, and the WG chairs, As I commented in previous mail [B], the authors are trying the best to find some scattered pieces of sentences, sometimes from RFC8754, and sometimes from RFC8986 or RFC9256, to argue that the “VPN SID after Replication SID” is a valid solution. As an example, the piece of sentence “This document and section define a single SRv6 SID. Future documents may define additional SRv6 SIDs.” in https://www.rfc-editor.org/rfc/rfc8754.html#name-fib-entry-is-a-locally-inst<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8754.html%23name-fib-entry-is-a-locally-inst&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C610cc56e0c03476aea0208db13263ff0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638124827267776626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7PPapfUxy0FFDdCzp2d3k6Yv5v0NI7rEI%2F5q6PZhXTA%3D&reserved=0> was sometimes used as the above argument. But as I have answered in [B] to this, the piece of sentence does not support the Replication SID solution at all. Another example, as Joel may care more about, is the piece of sentence “End.B6.Encaps and End.B6.Encaps.Red (and End.BM)” in the following claim made by Rishabh. This claim is also documented in the WGLC document “At a Replication node, the Replication SID is the equivalent of Binding SID [RFC9256] of a Segment Routing Policy.”. I would guess it is used as the “key” piece for arguing that the “VPN SID after Replication SID” is a valid solution (because of the behavior of a Binding SID), and the following is my reason to guess so and please correct me if my guess is wrong. [Jim] The authors may consider revising this text as it seems to be true that a Replication SID is not the *equivalent* of a Binding SID in the sense that the forwarding operation is based upon a lookup of the local Replication state. To clarify this, we would offer as a starting point alternative text “at a replication node, the Replication SID operates from local replication state and the resulting behavior MAY look similar to a Binding SID”. Thanks! Jim, Joel & Bruno Use End.B6.Encaps defined in https://www.rfc-editor.org/rfc/rfc8986.html#name-endb6encaps-endpoint-bound-<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8986.html%23name-endb6encaps-endpoint-bound-&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C610cc56e0c03476aea0208db13263ff0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638124827267776626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yv66LEYjcVzFLx0MhKGIYyROMaydGykJIwLQbH5BUco%3D&reserved=0> as an example (in below), the step S15 *always* requires a push of new IPv6 header, not optionally. S01. When an SRH is processed { S02~S11 omitted…… S12. Decrement IPv6 Hop Limit by 1 S13. Decrement Segments Left by 1 S14. Update IPv6 DA with Segment List[Segments Left] S15. Push a new IPv6 header with its own SRH containing B S16. Set the outer IPv6 SA to A S17. Set the outer IPv6 DA to the first SID of B S18. Set the outer Payload Length, Traffic Class, Flow Label, Hop Limit, and Next Header fields S19. Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination S20. } Is the Replication SID really “equivalent” to this ? ---- that is to say, it *always* push a new IPv6 header when a packet is traversing the path toward the Leaf nodes ? ----Example 1, a Ingress PE (PE1) and 2 Egress PEs (PE2 & PE3) are the only Replication nodes of a network, and 2 SR-Policies are required to the 2 Egress PEs separately, what would the two packets (sent from PE1 to PE2 & PE3) supposed to be like ? { {IPv6 + SRH} { IPv6 + SRH} (IPv4 or IPv6 Customer Multicast Packet) } ? ----Example N, TO-BE-thought about… Then let’s go back to the “meaning” and “semantics” of the “Binding SID [RFC9256] of a Segment Routing Policy” : [RFC9256]: The Binding SID (BSID) is fundamental to Segment Routing [RFC8402]. It provides scaling, network opacity, and service independence. [RFC8402]: The BSID is bound to an SR Policy, instantiation of which may involve a list of SIDs. The Replication SID, as defined in the WGLC document, says “Replication State is a list of replication branches to the Downstream Nodes. In this document, each branch is abstracted to a <Downstream Node, Downstream Replication SID> tuple.”. I guess, the authors are arguing that, the Replication SID is bound to an Replication State that may have relation to 0,1 or N Downstream Nodes, and to each of the Downstream Nodes there *MAY* be an SR-Policy, so “the Replication SID is the equivalent of Binding SID”. However, Binding SID *always* bound to *an* SR-Policy, not allowing 0 or N SR-Policy(s), as defined in RFC8402,9256 and verified by the pseudo-code of RFC8986. Why are these two concepts claimed as “equivalent” by the WGLC document ? What does the claim of “equivalent of Binding SID” intends to argue ---- to argue the basic behavior of Replication-SID is reasonable, or to argue the behavior of Replication-SID following with an SRv6 VPN SID (Upstream-assigned or DCB) is reasonable ? I would suggest that we do not use such “scattered pieces of sentences/approximation” for argumentation, but focus on the comparison between the behavior of “normal SRv6”, the behavior of “alternative solutions (like DOH/Src.DT4/SRH TLV)”, and the behavior of “Replication SID with an SRv6 VPN SID in SRH”. Because the meaning of SRv6/SRH/SID-List/Segment-Left from RFC8402/8754/8986/8200 are more related to an overall architecture of SRv6 than the scattered pieces of sentences IMO. Thanks Jingrong References: [B] https://mailarchive.ietf.org/arch/msg/spring/ufUkSOy2_Tdkjr2AuVIr7gpnXzU/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fspring%2FufUkSOy2_Tdkjr2AuVIr7gpnXzU%2F&data=05%7C01%7Cjames.n.guichard%40futurewei.com%7C610cc56e0c03476aea0208db13263ff0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638124827267776626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FzNnsTpPDse90O%2BEEXcwnmlddbGnLXGkmQcI6nEdHwo%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:spring-boun...@ietf.org] On Behalf Of Joel Halpern Sent: Thursday, February 16, 2023 10:55 PM To: Rishabh Parekh <risha...@gmail.com<mailto:risha...@gmail.com>>; James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> Cc: bruno.decra...@orange.com<mailto:bruno.decra...@orange.com>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment Would it make sense to note (in an operability section or similar) that the replication behavior does under soem circumstances result in a packet with a partially processed segment list in an SRH and a destination address that does not appear explicitly or by mechanical manipulation in the SRH? (Yes, I think this still complies with the SRv6 and general segment routing architectures. It is however something that operators using this technique need to be aware of.) Yours, Joel On 2/16/2023 12:29 AM, Rishabh Parekh wrote: James, Replies inline @ [RP] On Wed, Feb 15, 2023 at 6:58 AM James Guichard <james.n.guich...@futurewei.com<mailto:james.n.guich...@futurewei.com>> wrote: Hi Rishabh, Authors, & WG: Having reviewed the latest version of 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%7C610cc56e0c03476aea0208db13263ff0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638124827267776626%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=V2qQeZDH0VcTULxsFXENDKrEmxA5g06JzTUc7szMhKQ%3D&reserved=0> I would appreciate some clarification from the authors on the specifics of packet replication and forwarding between the replication point and downstream nodes. The draft as I read it bases forwarding at a replication point on the combination of a replication SID which triggers and selects the behavior and the replication state held at that node. The replication state indicates which downstream nodes the packet should be replicated to and those nodes may or may not be adjacent to the replication node. In the non-adjacent case my understanding is that the replication state may include an additional segment-list and this seems to be what the text in section 2.2. is saying by referencing H.Encaps.Red to re-encapsulate the packet with a new SRH and outer IPv6 header. If this is correct could it be made more explicit; at a minimum I would expect to see a reference to RFC 8986 section 5.2. [RP] Your understanding is correct. We can add a reference to RFC 8986 Section 5.2 as you suggest, but you say "... could it be made more explicit ..". Do you mean the current text is not clear about this? In addition to this I would like to clarify the case where re-encapsulation is not needed i.e. when an explicit path to a downstream node is not necessary and best path forwarding suffices. The text says that in this case the outer IPv6 header is re-used and the downstream replication SID is written into the IPv6 header destination address. This address is most likely NOT contained within the SRH which is a detachment from the normal SRv6 forwarding case and I would like to hear the authors and WGs opinions on this. [RP] Yes, an encapsulation is not needed when a Downstream node is adjacent or best path forwarding to a non-adjacent node is sufficient. The downstream node's Replication SID (from Replication State) is written in outer IPv6 DA and packet is forwarded based on the locator of the downstream node. Our (i.e. authors) opinion is that is permissible within the SRv6 architecture by new End.Replication behavior (associated with incoming local Replication SID) defined in the draft. Furthermore, there is already precedence in SRv6 architecture to process an incoming packet based on local state and forward the modified packet. RFC 8986 defines End.B6.Encaps and End.B6.Encaps.Red (and End.BM) functions that rely on local SR policy state to modify an incoming packet. Thanks, -Rishabh
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
