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:risha...@gmail.com]
Sent: Thursday, December 22, 2022 2:00 AM
To: Xiejingrong (Jingrong) <xiejingr...@huawei.com>
Cc: SPRING WG <spring@ietf.org>; spring-cha...@ietf.org
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=40huawei....@dmarc.ietf.org<mailto:40huawei....@dmarc.ietf.org>>
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
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
