Hi!
Now that the terminology is a little more precise, I also looked at the
document and found a couple of cases where SIDs are skipped by SRv6 segment
endpoints, which is what Ketan is really concerned about (?).
These cases (see below) do not align with rfc8754 or rfc8986. IMO, any
proposed deviation from the existing specifications should be discussed in
spring (for rfc8986) or 6man (for rfc8754), and formal Updates to those
RFCs may be needed.
Thanks!
Alvaro.
(1) From §3.3 (Procedure on the Penultimate Endpoint):
IF the primary outbound interface used to forward the packet failed
or there is no FIB entry for forwarding the packet, the detailed
processing to be performed by the penultimate node is as follows:
IF SL = 1 THEN
SL decreases by 1 and becomes 0;
Update the IPv6 DA with Segment List[0];
FIB lookup on the updated DA;
Forward the packet according to the matched entry;
There seem to be two cases here: "the primary outbound interface used to
forward the packet failed" and "there is no FIB entry for forwarding the
packet". I assume (?) they are grouped because the result is that there is
no FIB entry for the destination -- IOW, the link going down results in no
alternate path available.
rfc8754 covers this case:
4.3.4. FIB Entry Is a No Match
Processing is not changed by this document.
The result of a non-existent FIB entry is to drop the packet, not to
forward it, as mentioned above. Changing that action requires an Update to
rfc8754 (and others).
As Bruno pointed out, questions related to "how does the node know" come up.
(2) The operation described in this draft depends on P2 (Figure 3) taking
on the role of the "Penultimate Endpoint". But the SRH used to illustrate
is "< A1:1::1, A2:1::A100, A3:1::B100, A4:1::B100>", which results in P2
being in the Segment List[2] position.
Also, PE3 also has penultimate endpoint functions in the draft.
rfc8754 and rfc8986 have explicit definitions of what the penultimate
segment endpoint is, and the use of P2 doesn't match any of them:
rfc8754:
Segment List[0..n]: 128-bit IPv6 addresses representing the nth
segment in the Segment List. The Segment List is encoded starting
from the last segment of the SR Policy. That is, the first element
of the Segment List (Segment List[0]) contains the last segment of
the SR Policy, the second element contains the penultimate segment
of the SR Policy, and so on.
rfc8986:
A PSP-flavored SID is used by the SR source node when it needs to
instruct the penultimate SR Segment Endpoint Node listed in the SRH
to remove the SRH from the IPv6 header.
...
A penultimate SR Segment Endpoint Node is one that, as part of the
SID processing, copies the last SID from the SRH into the IPv6
Destination Address and decrements the Segments Left value from one
to zero.
The PSP operation only takes place at a penultimate SR Segment
Endpoint Node and does not happen at any transit node. When a SID of
PSP flavor is processed at a non-penultimate SR Segment Endpoint
Node, the PSP behavior is not performed as described in the
pseudocode below since Segments Left would not be zero.
There are both terminology (using "penultimate" to describe any node other
than the one at Segment List[1]) and operation changes that would be
required in rfc8754 and rfc8986.
(3) From §4:
In normal operations...The specific operations of PE3 are as follows:
1) Remove the outer packet header and all its extension headers.
2) Look up the FIB table according to the destination address of the
original packet.
3) Send the packet to CE2 according to the FIB entry.
First, much more is needed to explain the operation (codifying with
pseudocode as all the other SRH-related operations). The PSP flavor is
specified in §4.16.1.2/rfc8986; it includes "S14. Update IPv6 DA with
Segment List[Segments Left]" (not the "destination address of the original
packet", as indicated above).
Changing how the PSP flavor works in "normal operations" would require an
Update of rfc8986. Note that this draft doesn't indicate how P2 would know
the proposed process would have to be used (vs existing cases).
On February 25, 2024 at 12:44:18 AM, Yingzhen Qu (yingzhen.i...@gmail.com)
wrote:
Dear SPRING WG and chairs,
I'd like to bring your attention to this adoption call happening in the
RTGWG WG.
The draft describes a SRv6 egress node protection mechanism in multi-home
scenarios. As Ketan has commented in his email below the proposal requires
a P router to process SRH with new endpoint behavior.
We'd like to get your comments about the proposed extensions. Please send
your reply to both the SPRING and RTGWG mailing lists.
Thanks,
Yingzhen
On Wed, Feb 21, 2024 at 8:06 AM Ketan Talaulikar <ketant.i...@gmail.com>
wrote:
> Hi Yingzhen/All,
>
> I have some concerns regarding the adoption of this document.
>
>
> - Do we need these different solutions?
>
> KT> No. There is one common author for both these drafts who is also from
> a vendor. I hope that person is also able to evaluate implementation
> aspects and pick one solution.
> KT> Does the adoption of this solution make the other draft "dead"?
>
> - Technical merits and drawbacks of each solution
>
> KT> The existing WG draft needs IGP protocol extensions and its
> implementation is very complex (as stated in the document under adoption)=
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
