Re: [spring] Issue #1: VPN SID in Multicast //RE: WGLC for draft-ietf-spring-sr-replication-segment

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

Hi Rishabh, and WG:

(The reply to each of your email points can be found  inline below marked with [XJR1223]).

For the main point under this issue -- how the current proposal is breaking the SRv6 architecture, please allow me to explain by some more details.

Issue #1: VPN SID in Multicast.

Topology: Src1----PE1----P1----PE2/PE3----Rcv2/Rcv3(connected to PE2/PE3 respectively)

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 ?

Rishabh’s point:
P1 is a pure Replication Node, it will just replicate incoming packet as (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1} and {SA=PE1, DA=PE3.Replicate){SL=1, VPNSID1} to PE2 and PE3 respectively. PE2 and PE3 as Leaf nodes will process the SRH and the upper layer header.

My Point:
1. P1 is receiving a packet (SA=PE1, DA=P1.Replicate){SL=1, VPNSID1}.
As in my above example, it is assuming that, P1 is an SR-replication-capable node.
In the case, I think the DA should be P1.Replicate, not PE2.Replicate. Correct?


2. Now, Let’s check the current SRv6 architecture from the semantics. What should P1 process the incoming packet ?

It is an SRv6 packet, with the active SID being P1.Replicate, and the Next SID is VPNSID1.
According to the semantics of SRv6, and SRH, and SID list, and Segment Left, the packet should be proceeded to the Next SID (VPN SID1), correct?
Let us check each of them:

l  SRv6(8986): The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header.

l  SRH(8754): Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).

l  RH(8200): The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.

l  Segment Left(8200): 8-bit unsigned integer.  Number of route segments remaining, i.e., number of explicitly listed intermediate nodes still to be visited before reaching the final destination.
Let’s suppose, an SRv6 engineer capture this packet using a tool like Wireshark, how will this SRv6 engineer expect the packet to be processed ? ---- The packet should be proceeded to the Next SID (VPN SID1), correct ?
The packet is a normative SRv6 packet ---- IPv6 packet, with the SRH, valid SL and valid SID List.
The packet is a statelessly and self-description [1], and the correct behavior according to SRv6 architecture (think how the SRv6 engineer expect it) is obvious ---- The packet should be proceeded to the Next SID (VPN SID1), correct ?

But What does the current proposal do to this packet ? ---- The current proposal doesn’t proceeded to the Next SID, but do it statefully, as if SRv6 SRH/SL semantics is re-writable, just because it is the Replication SID.
That is the conflict ---- Between the stateful Replication SID, and the stateless/self-descripting SRH and SL.
I call this conflict “break”.
Whether this word is precise or not, I would like to listen to the working group and the IETF community.


3. Further, Let me explain it by another list of 4 comparable cases.
In above case, P1 received a packet (SA=PE1, DA=P1.Replicate){SL=1, VPNSID1},  with the active SID being an SID of itself, P1 doesn’t proceed to Next SID.
In another case, P1 received a packet(SA=PE1, DA=P1.End){SL=1, VPNSID1},  with the active SID being an SID of itself, P1 does proceed to Next SID, and send this packet back to PE1 (VPN SID1 is allocated from PE1).
In another case, PE2 received a packet (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1},  with the active SID being an SID of itself, PE2 does proceed to Next SID, but the packet is not sent back to PE1 (VPN SID1 is allocated from PE1).
In another case, PE2 received a packet (SA=PE1, DA=PE2.End){SL=1, VPNSID1},with the active SID being an SID of itself, PE2 does proceed to Next SID, and the packet is sent back to PE1 (VPN SID1 is allocated from PE1).
Look again, there are 4 cases with the packet the same in shape but behave completely different.
The Replication SID, as the context of the VPNSID1, is making these difference, and “breaking” the SRv6 that we normally understand it statelessly and self-description.


4. Now let me give another example from implementation point:
Suppose the VPN SID1 is installed in the FIB of PE2 [RFC8986], so that when the above example packet (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1}is received by PE2, and PE2 proceeds to VPN SID1, lookup VPN SID1 in FIB Entry, and behave to not sending this packet back to PE1.
Now, the application on PE2, the SRv6 Ping [RFC9259] is used and a packet (SA=PE1, DA=VPNSID1, NH=ICMPv6)(ICMPv6 echo request) is constructed. How does this PE2 data plane do  when it lookup VPN SID1 in FIB Entry ? does it send this packet to PE1 ?
One may say, when the above example packet (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1}is received by PE2, it does not lookup VPN SID1 in FIB Entry. Then what is the correct implementation ? has this VPN SID ever become “active SID” in the case ? is this VPN SID really an SRv6 SID semantically?


[1] self-description: RFC5655 is using this word, and I understand it as similar to “stateless”. Please correct me if it is not proper for SRv6 SRH/SL.

Thanks,
Jingrong

(Please also read the separate reply to each of your points embedded inline below marked with [XJR1223], as I mentioned in the beginning of the mail).

本邮件及其附件可能含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
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: Rishabh Parekh [mailto:[e-mail]]
Sent: Thursday, December 22, 2022 2:00 AM
To: Xiejingrong (Jingrong) <[e-mail]>
Cc: SPRING WG <[e-mail]>; [e-mail]
Subject: Re: [spring] Issue #1: VPN SID in Multicast //RE: WGLC for draft-ietf-spring-sr-replication-segment

Xingrong,
Replies inline @ [RP2]


On Sat, Dec 17, 2022 at 1:34 AM Xiejingrong (Jingrong) <xiejingrong=[e-mail]<mailto:[e-mail]>> wrote:

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 ?

[RP2] SRv6 architecture does not mandate SRH processing for a local SID. From RFC 8986:

Section 1 Introduction:
A function is locally defined on the node where it is executed and may range from simply moving forward in the segment list to any complex user-defined behavior

Section 4  SR Endpoint Behaviors
The list is not exhaustive. In practice, any behavior can be attached to a local SID; for example, a node N can bind a SID to a local Virtual Machine (VM) or container that can apply any complex processing on the packet, provided there is an SRv6 Endpoint Behavior codepoint allocated for the processing.

P1 is a pure Replication Node, it will just replicate incoming packet as (SA=PE1, DA=PE2.Replicate){SL=1, VPNSID1} and {SA=PE1, DA=PE3.Replicate){SL=1, VPNSID1} to PE2 and PE3 respectively. PE2 and PE3 as Leaf nodes will process the SRH and the upper layer header.

[XJR1223] Please see above my reply and more detailed explanation.

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

[RP2] There is no “hiding” as explained above.
[XJR1223] Good to know that VPNSID1 is not hiding, but explicitly placed in SRH with SL=1 to indicating. So we can focus the discussion on above case.

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

[RP2] draft-ietf-bess-mvpn-evpn-aggregation-label describes the concept of DCB. But again why does it matter how the FUNCT bits (corresponding to VPN context) are allocated – upstream on PE1 or from globally unique space?
[XJR1223] Please see above my reply and detailed explanation. It is not about FUNCT bits, but Locator bits. The SRv6 VPN SID1 is allocated from Locator of PE1 (upstream-allocated SRv6 SID case), and the SRv6 VPN SID1 is allocated from Locator of WHAT in a “DCB” concept ?

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

[RP2] As explained above, optional context SID does not “break” SRv6 architecture.
[XJR1223] Please see above my reply and detailed explanation. I understand the SRv6 architecture by the semantics of Locator/SRH/SL etc.

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.


[RP2] I see. We can add a section in the draft about not originating ICMPv6 errors for Replication SID except for exceptions allowed by RFC 4443 for IPv6 multicast groups. We can also add a security note documenting potential security concerns as described in Section 5.2 bullet 5.
[XJR1223] Good to see this is understood and accepted. I can help on tracking this kind of things in another issue #. I have some further notes on this topic (security) for solving altogether.


-Rishabh