Hi Rishabh, The first question is solved. Thank you for taking the comment into consideration. For the second one regarding the SID after the replication SID, I still have some further question when considering it a “VPN SID”:
In MPLS data plane, Is the SID an Upstream-assigned Label ? Or an SRGB label (though may be a more strictly unique number than SRGB that is a relatively unique index/offset ) ? In SRv6 data plane, is the SID an “Upstream-assigned SRv6 SID”, which is allocated on Ingress PE and put in the SID list after the replication SID ? Thanks Jingrong From: Rishabh Parekh [mailto:risha...@gmail.com] Sent: Wednesday, December 7, 2022 6:32 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, In section 2.1 and 2.2, it says “An Anycast SID or BGP PeerSID MUST NOT appear in segment list preceding a Replication SID.” I don’t know BGP PeerSID very well, but for anycast SID, I think it may be useful and suitable to appear in seg list preceding a Replication SID. Can you please explain the two things and why MUST NOT ? SIDs in the segment list guide a packet to a Downstream Node, typically along a specific path. For example, the SR-MPLS Node SID of the downstream node in segment list can be used for this. An Anycast SID by definition belongs to two or more nodes and a packet is forwarded to only one of the nodes in an Anycast set. Therefore, Anycast SID of the downstream nodes cannot be used in the segment list. I realize now this restriction is really for SIDs identifying the downstream node, not for intermediate nodes in path from Replication node to the downstream node. I will see if we can make this clear in the next revision of the document. For BGP, we should have specified "BGP PeerSet SID" (RFC 8402 Section 4.2) to be exact. The reason is the same as the Anycast SID restriction. I feel hard to understand how the SIDs after the Replication SID are used. Does it mean a “VPN SID” or something like that ? The SIDs after the Replication SID provide additional context for processing the packet at the downstream node. "VPN SID" is one example of a context. Thanks, Rishabh. On Mon, Dec 5, 2022 at 6:54 PM Xiejingrong (Jingrong) <xiejingrong=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>> wrote: Hi WG and authors, I have read this document and have some questions. In section 2.1 and 2.2, it says “An Anycast SID or BGP PeerSID MUST NOT appear in segment list preceding a Replication SID.” I don’t know BGP PeerSID very well, but for anycast SID, I think it may be useful and suitable to appear in seg list preceding a Replication SID. Can you please explain the two things and why MUST NOT ? In Section 2.1, it says below: There MAY be SIDs after the Replication SID in the segment list 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 SR-MPLS packet to another node. In Section 2.2, it says below: 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. I feel hard to understand how the SIDs after the Replication SID are used. Does it mean a “VPN SID” or something like that ? 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:spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>] On Behalf Of James Guichard Sent: Monday, November 28, 2022 11:10 PM To: SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Cc: spring-cha...@ietf.org<mailto:spring-cha...@ietf.org> Subject: [spring] 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
