Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

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

Hi WG and chairs,

I would like to draw your attention that, the SRv6 Replication SID will break SRv6 architecture, scope and restrictions in many aspects.

Though it is still not defined what is the scope of “context”, leaving a big “hole” to explain in the future.

But through the past discussions we have known a little about it, for example, used as a VPN identifier in multicast scenario.

However, I think the Upstream-assigned SID or “DCB” SID in SRv6 for “context” need to be carefully evaluated by the WG.

Firstly, there is no definition of “Upstream-assigned SID” or “DCB” in SRv6.

Secondly, suppose an Ingress PE allocated an “Upstream-assigned SID” from its locator, and put the SID into the SID list after the Replication SID, what is expected to behave on every replication node to this Upstream-assigned SID ? make it an active SID, and then take it as a context ? or send it back to the Ingress PE ?

Further, I think there are many other differences between SRv6 data plane and MPLS data plane for a “Replication SID” to work in its multicast scenario context. For example, how is the “host originating an IPv6 packet” scenario (RFC8754,8986) supported ? How does the “ICMPv6 error message MUST NOT be originated as a result of receiving … a packet destined to an IPv6 multicast address” may be considered ?

In a word, the Replication SID in SRv6 data plane, is far from being a simple copy of MPLS data plane.

Note that, SRv6 has its unique characteristic that need to define its specific specification, like RFC8754,8986,9259, etc etc.

Also note that, the implementations disclosed in section 4.1 and 4.2 only include MPLS data plane. I assume they reflect the fact that Replication SID for SRv6 data plane is far from mature. Therefore I request the WG to first exclude SRv6 data plane of this draft from the WGLC scope. Then we can focus on the MPLS data plane part (Hopefully I can move from SRv6 problems if they are noted already, and then I can provide some comments on MPLS soon).

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: Rishabh Parekh [mailto:[e-mail]]
Sent: Thursday, December 8, 2022 6:52 AM
To: Xiejingrong (Jingrong) <[e-mail]>
Cc: James Guichard <[e-mail]>; SPRING WG <[e-mail]>; [e-mail]
Subject: Re: [spring] WGLC for draft-ietf-spring-sr-replication-segment

Jingrong,

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 ?

The VPN SID is only required when SR P2MP trees are shared across VPNs. It can be upstream assigned or globally assigned (from DCB) as described in SR P2MP MVPN<https://datatracker.ietf.org/doc/draft-ietf-bess-mvpn-evpn-sr-p2mp/> draft. If present, the VPN SID is after the Replication SID. For SR-MPLS, the VPN SID SHOULD NOT be assigned from SRGB or SRLB since it is an overlay context,

-Rishabh