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

[Ketan Talaulikar <[e-mail]>]

Hi Alvaro,

You've got my concern! And you have also brought out all the details that
need to be clarified and worked through for this proposal.

Thanks,
Ketan


On Wed, Feb 28, 2024 at 6:24 PM Alvaro Retana <[e-mail]>
wrote:

>
> 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 ([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]>
> 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)=
>
>