Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

[Huzhibo <[e-mail]>]

Hi Alvro:
Please see inline.

Thanks

Zhibo
From: rtgwg [mailto:[e-mail]] On Behalf Of Alvaro Retana
Sent: Wednesday, February 28, 2024 8:55 PM
To: Yingzhen Qu <[e-mail]>; [e-mail]; Ketan Talaulikar <[e-mail]>
Cc: RTGWG <[e-mail]>; rtgwg-chairs <[e-mail]>; draft-cheng-rtgwg-srv6-multihome-egress-protection <[e-mail]>; [e-mail]
Subject: Re: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)


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.

----->HZB: rfc8754 or rfc8986 only defines that Processing is not changed by this document. This is only a general description of the standard SRv6, not a mandatory specification. Of course, as you said, the new endpoint behavior defined in this document has been posted to the Spring group discussion.

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

-----> HZB : This document does not modify the penultimate endpoint behavior. The P2 node described in this document is not the penultimate endpoint. We will modify it in the next version.
(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<http://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).

-----> HZB : In normal operations...The specific operations of PE3 are as follows, This section does not describe the PSP endpoint behavior, but the VPN SID endpoint  behavior. We will clarify in the next version.
                      This document defines the PSD Flavor, which is an extension of the original Endpoint behavior and does not conflict with the original Endpoint behavior.



On February 25, 2024 at 12:44:18 AM, Yingzhen Qu ([e-mail]<mailto:[e-mail]>) 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 <[e-mail]<mailto:[e-mail]>>
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)=