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

[Yingzhen Qu <[e-mail]>]

Hi Bruno,

Thank you for the feedback, really appreciate it.

Let me try to answer your questions with my understanding, and the authors
please chime in.

Thanks,
Yingzhen

On Mon, Feb 26, 2024 at 5:07 AM <[e-mail]> wrote:

> Dear Yingzhen,
>
> At your request, I have quickly parsed the draft.
>
> It's not completely clear to me how the solution works given that the
> terminology used is a bit loose.
>
> 2 questions on the terminology:
>
> 1) "protection" vs "restoration". The document largely uses the term
> "protection", in particular in its title. This usually assumes that
> protection is precomputed, local to the penultimate node (before the
> failure) and hence can be fast.
> I'm assuming that "protection" is indeed meant. Please correct me if this
> is wrong. In which case, the node doing the protection is usually called
> PLR and is reacting before the IGP convergence. If so, it would be good for
> the document to reflect this (use the term PLR, remove the reference to IGP
> fast convergence)
> (On the other hand, if would meant restoration following IGP convergence,
> the gain seems limited to me as the ingress would equally be able to react
> to IGP convergence and with PIC edge it would do it fast)
>
> [Yingzhen]:  "Protection" is the right term.

2) "Penultinate node" vs "penultimate Endpoint."
> RFC 8754 defines different type of nodes.
> https://datatracker.ietf.org/doc/html/rfc8754#section-3
> In particular, a transit node is a regular IPv6 router which does not
> process the SRH. While a EndPoint is a node receiving an IPv6 packet where
> the destination address of that packet is locally configured as a segment
> or local interface
>
> Can you please clarify whether your Penultimate Endpoint (§3.3) is a
> Transit Node or an SR Segment Endpoint Node?


> - If the Penultimate Endpoint (§3.3) is a Transit Node, then as per
> RFC8200 it's not allowed to process the SRH.
> https://datatracker.ietf.org/doc/html/rfc8200#section-4 Hence your
> proposal would not be compliant with RFC 8200
> - If the Penultimate Endpoint (§3.3) is an SR Segment Endpoint Node, the
> Ingress needs to specifically adds a Segment of this node. (typically End
> or End.X). If so please clarify this in the document (in particular
> in§3.1). Note that by doing so, you are adding a new point of failure (the
> failure of this Penultimate Endpoint). How do you protect from this added
> case of failure? If you don't, I would argue that the gain is debatable as
> you replace one type of failure (PE failure) by another type of failure (P
> failure).
>
> [Yingzhen]: This should be "penultimate SR segment endpoint". A transit
node may not have the capability to process a SRH. With that being said,
the penultimate SR endpoint may be several hops away from the PE, and this
requires some failure detection mechanisms, such as multi-hop BFD.

>
> I have another question on §3.3
> How does the penultimate Endpoint know that it can/needs to perform the
> new behavior? My guess would be by looking at the next SID (the one from
> the egress) and discovering that the behavior of this SID is End.D* with
> PSD. That would seem to require this P node to be aware of all VPN routes,
> which is typically not the case, frown upon and does not scale well as the
> P nodes would have 10s of PE (if not 100).
>
> [Yingzhen]: my understanding is that this protection mechanism is not to
be deployed for all PEs, but only a subset of them. Otherwise I agree with
you that it doesn't scale.

On a side note, the abstract seems a bit short to me.
>
> So thanks for clarifying the document,
> Regards,
> --Bruno
>
> >
> > -----Original Message-----
> > From: Yingzhen Qu <[e-mail]>
> > Sent: Sunday, February 25, 2024 6:44 AM
> > To: Ketan Talaulikar <[e-mail]>; [e-mail]
> > Cc: RTGWG <[e-mail]>; [e-mail]; rtgwg-chairs <
> [e-mail]>;
> draft-cheng-rtgwg-srv6-multihome-egress-protection <
> [e-mail]>
> > Subject: Re: WG Adoption Call -
> draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
> >
> > 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
> > > KT> 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)
> >
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
> recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.
>