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

Jingrong,
Replies @ [RP]

Thanks,
-Rishabh.

On Sat, Dec 10, 2022 at 5:22 PM Xiejingrong (Jingrong) <xiejingrong=
40huawei.com@dmarc.ietf.org> wrote:

> 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.
>

 [RP] It is natural to extend the concept of Replication SID as SR-MPLS
label to a SRv6 Endpoint behavior represented by FUNCT bits of SRv6 SID. I
don’t think this “… break[s] SRv6 architecture, scope and restrictions in
many aspects”.

First of this document does *not* mandate the “context” SID following the
SRv6 Replication SID; it just lays down the purpose and restriction on SIDs
following the Replication SID. Second, this draft makes it clear that the
scope of this "context" SID is local to a Leaf node.

>
>
> But through the past discussions we have known a little about it, for
> example, used as a VPN identifier in multicast scenario.
>
>
>
[RP] VPN context has been specified in the BESS MVPN/EVPN  SR-P2MP draft
for quite some time now. And it is only required when a SR P2MP tree is
shared across MVPNs.

> 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.
>

[RP] Just because something has not been defined yet, does not mean it can
never be defined J. How does a PE assigning a SID and advertising to all
other PEs break SRv6 architecture?

> 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 ?
>

[RP] This draft restricts a Leaf/Bud node using a “context” SID, if
present, just for local processing of a packet; the node MUST NOT forward
the packet as a result of using context SID.

>   3. Suppose a DCB SRv6 SID, 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 ?
>

[RP] The locator of "context" SID is not relevant since the packet will not
be re-forwarded. The FUNCT "context" bits are significant and the egress
PE/Leaf knows where this value is present in the SID based on SID structure
information from BGP Prefix SID attribute sent along with MVPN  A-D routes.

> 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 ?
>

[RP] If a host originates a packet with a locator of Replication Node with
appropriate Replication SID, it will be replicated as long as security
allows it. This is no different that a host originating a SRv6 packet with
any other SRv6 Endpoint behavior SID.

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 ?
>
1. “ICMPv6 error message MUST NOT be originated as a result of receiving …
> a packet destined to an IPv6 multicast address” is from RFC4443, to prevent
> a reflection amplification DDoS attack in my understanding.
>
>
>

[RP] Replication SID is not an IPv6 multicast address, but what is your
specific concern with ICMPv6 error messages? Note RFC 4443 does allow some
ICMPv6 error messages for IPv6 multicast packets (Section 2.4 (e.3)) and
acknowledges this exception can be used for DoS attack (Section 5.2 bullet
5).

>
> 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).
>

[RP] SRv6 Replication SID is an essential part of this document. Section
2.2 and the corresponding example illustrated in Appendix A.2 illustrates
how SRv6 Replication SID operates within the overall framework of SRv6
architecture.

>
>
> 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:rishabhp@gmail.com]
> *Sent:* Thursday, December 8, 2022 6:52 AM
> *To:* Xiejingrong (Jingrong) <xiejingrong@huawei.com>
> *Cc:* James Guichard <james.n.guichard@futurewei.com>; SPRING WG <
> spring@ietf.org>; spring-chairs@ietf.org
> *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
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>