Hi WG,
It seems like the technical concerns raised in my previous mails are not fully
understood, or taken seriously toward solving them, as I understand the reply.
To make my comments clear, please allow me to make them one by one, toward
solving it collaboratively by giving my opinion on each one, and explain why I
think SRv6 is broken by current proposal.
Thank you Rishabh, and please see my reply to each of your points in the mail
inline below with [XJR]. Don’t worry if they are not clear, as said they will
be brought up one by one like below the issue #1.
Issue #1: VPN SID in Multicast.
Topology: Src1----PE1----P1----PE2/PE3----Rcv2/Rcv3(connected to PE2/PE3
respectively)
My Opinion toward solving the technical issue:
1. PE1 allocate VPN SID 1/2/3 from its Locator for each MVPN (say MVPN 1/2/3)
that want to share a single replication tree, and advertise them to PE2 and PE3.
2. PE1 encapsulates the received packet in an outer IPv6 header, where the
destination address is P1.End.Replicate, and the source address is the VPN SID
1, 2 or 3, determined by the VRF the received packet belonging to.
3. P1 receive the packet, with the destination address being P1.End.Replicate,
the packet is replicated and sent to PE2 and PE3, with the destination address
changed to PE2.End.Replicate and PE3.End.Replicate respectively.
4. PE2/PE3 use this VPN SID 1, as in the source address of the packet, to
determine the VPN of the packet, and do the table lookup in the VPN for the
decapsulated (inner) packet.
5. PE2/PE3 can ping/traceroute this VPN SID 1/2/3 using RFC9259, or send ICMPv6
error message back to this VPN SID as a result of an exceptional condition of
above 3 to 4.
Why SRv6 is broken in current proposal IMO:
1. PE1 allocate VPN SID 1/2/3 from its Locator for each MVPN (say MVPN 1/2/3)
that want to share a single replication tree.
2. PE1 encapsulate the received packet in an outer IPv6 header with SRH, as I
assuming it, where IPv6 {DA = P1.Replicate}, SRH {SL=1, VPNSID1, P1.Replicate}
so the VPNSID1 is after the Rep SID.
3. P1 receives the packet, with the destination address being P1.End.Replicate,
replicates the packet and sends to PE2 and PE3, with the destination address
changed to PE2.End.Replicate and PE3.End.Replicate respectively.
//Look, the active SID is P1.End.Replicate, and the packet of the received
packet with SRH is meaning, by its semantics in current SRv6 architecture, that
the packet should then be proceeded to the Next SID (VPN SID1). The Locator of
the VPN SID1 is PE1, and the packet should go to PE1. Correct ?
//Or maybe one may say, the SRH in step 2 is {SL=0, VPNSID1, P1.Replicate}.
Then why “hiding” the VPNSID1 in the SRH that is determined not to use (SL=0) ?
IMO It is breaking SRv6 by the “hiding” things that is not semantically
suitable in SRv6 SRH. DOH is a much better choice if, for any reason, the
source address as I suggested above is not the taste.
//Or maybe one may say, the VPN SID is allocated from an “Global unique” space
named “DCB”. I would request the authors and WG to define that since I really
don’t understand it. Let me cite RFC8986 section 3.2: “Assign a unique
B:N::/64 block to each SRv6-enabled node in the domain”.
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:risha...@gmail.com]
Sent: Saturday, December 17, 2022 6:21 AM
To: Xiejingrong (Jingrong) <xiejingr...@huawei.com>
Cc: SPRING WG <spring@ietf.org>; spring-cha...@ietf.org
Subject: 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....@dmarc.ietf.org<mailto:40huawei....@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.
[XJR] A proposal that is not mandatory should not break SRv6 either IMO.
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.
[XJR] obviously I am talking about SRv6.
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 ☺. How does a PE assigning a SID and advertising to all other
PEs break SRv6 architecture?
[XJR] I have explained the technical concerns in detail in my mail I think,
which led to the “break” I used. Also I will explain it explicitly as above.
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.
[XJR] We have talked about “context”, and I have explained the technical
concerns in detail.
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.
[XJR] So why not tell me what is the 128bit DCB SRv6 SID looks like ? I still
don’t understand it with your explanation.
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.
[XJR] A host originating (SA=h1,
DA=End.Replicate)(UDP/ICMPv6,checksum)(payload), and how the checksum will be
processed.
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).
[XJR] How if a packet is replicated to 100 branch nodes, and each branch node
found that the HopLimit of the packet is 1.
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.
[XJR] See above.
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:risha...@gmail.com<mailto:risha...@gmail.com>]
Sent: Thursday, December 8, 2022 6:52 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,
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<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
