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) 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). 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). 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 <yingzhen.i...@gmail.com> > Sent: Sunday, February 25, 2024 6:44 AM > To: Ketan Talaulikar <ketant.i...@gmail.com>; spring-cha...@ietf.org > Cc: RTGWG <rt...@ietf.org>; spring@ietf.org; rtgwg-chairs > <rtgwg-cha...@ietf.org>; draft-cheng-rtgwg-srv6-multihome-egress-protection > <draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org> > 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 <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 > > 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. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
