Hi Alvro: Please see inline. Thanks
Zhibo From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Alvaro Retana Sent: Wednesday, February 28, 2024 8:55 PM To: Yingzhen Qu <yingzhen.i...@gmail.com>; spring-cha...@ietf.org; Ketan Talaulikar <ketant.i...@gmail.com> Cc: RTGWG <rt...@ietf.org>; rtgwg-chairs <rtgwg-cha...@ietf.org>; draft-cheng-rtgwg-srv6-multihome-egress-protection <draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org>; spring@ietf.org 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 (yingzhen.i...@gmail.com<mailto: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<mailto: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
