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

[Alexander Vainshtein <[e-mail]>]

Dear all,
I have been trying to follow this discussion, and, as of this moment, I am somewhat confused.

I have been taught that the two basic criteria for WG adoption of an individual draft are:

  *   It deals with a real and relevant problem
  *   It represents a valid first step to a solution of this problem.

Table 1 in Section 5 of the draft<https://datatracker.ietf.org/doc/html/draft-cheng-rtgwg-srv6-multihome-egress-protection-05#section-5> requests allocation of new SREv6 SID types thar are  for egress protection of SRV6 paths that are used for delivery of  BGP overlay services with the SRv6 underlay.

The Introduction in RFC 9252<https://datatracker.ietf.org/doc/html/rfc9252> (that defines these services) states (the relevant text is highlighted):

To provide SRv6 service with best-effort connectivity, the egress PE signals an SRv6 Service SID with the BGP overlay service route. The ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID provided by the egress PE. The underlay between the PEs only needs to support plain IPv6 forwarding [RFC8200].

It would be most helpful if the authors could answer the following questions:


  1.  Does the draft provide, among other things, egress protection for BGP SRv6 services with best-effort connectivity over an underly that supports just plain IPv6 forwarding?
  2.  If the answer to this question is positive, then:
     *   Which node(s) can act as the Penultimate Endpoint(s)?
     *   How can these nodes detect failure of the Egress Endpoint?
     *   How are procedures applied by the Penultimate Endpoint handled by the environment that only supports plain IPv6 forwarding?

If the simple but useful scenario above is not supported by the draft in question, it would not, from my POV, meet the second of the above-mentioned basic criteria for WG adoption.

My 2c,
Sasha

From: spring <[e-mail]> On Behalf Of Weiqiang Cheng
Sent: Wednesday, February 28, 2024 7:59 AM
To: bruno.decraene <[e-mail]>; yingzhen.ietf <[e-mail]>
Cc: ketant.ietf <[e-mail]>; rtgwg <[e-mail]>; draft-cheng-rtgwg-srv6-multihome-egress-protection <[e-mail]>; rtgwg-chairs <[e-mail]>; spring-chairs <[e-mail]>; spring <[e-mail]>
Subject: [EXTERNAL] Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

Hi Bruno and Yingzhen,
Thank you very much for your insightful comments and guidance.
Please see co-authors' feedback inline [co-author].

Thanks,
Weiqiang Cheng



From: bruno.decraene<mailto:[e-mail]>
Date: 2024-02-27 16:12
To: Yingzhen Qu<mailto:[e-mail]>
CC: Ketan Talaulikar<mailto:[e-mail]>; RTGWG<mailto:[e-mail]>; draft-cheng-rtgwg-srv6-multihome-egress-protection<mailto:[e-mail]>; rtgwg-chairs<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)
Hi Yingzhen,

Thank you for your answers and clarification. That really helps.
Please see inline [Bruno]

From: Yingzhen Qu <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 27, 2024 3:42 AM
To: DECRAENE Bruno INNOV/NET <[e-mail]<mailto:[e-mail]>>
Cc: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>; RTGWG <[e-mail]<mailto:[e-mail]>>; draft-cheng-rtgwg-srv6-multihome-egress-protection <[e-mail]<mailto:[e-mail]>>; rtgwg-chairs <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

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]<mailto:[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.

[Bruno] OK. Therefore that’s before the IGP convergence. Could you please remove the references to IGP convergences?


[co-authors]  OK. We will be updated in the new version.


2) "Penultinate node" vs "penultimate Endpoint."
RFC 8754 defines different type of nodes. https://datatracker.ietf.org/doc/html/rfc8754#section-3<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<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.

[Bruno] OK. Could you please clarify this in the draft? (the name and the need for multi-hop BFD hence a discussion about scaling and probably configuration.)
Do we agree that in the absence of an SR-Policy, that penultimate SR segment endpoint is in fact the ingress PE hence nothing changed? If so, could you please clarify in the draft that this only applies to traffic using SR-policies?


[co-authors]  This draft is not limited to the SR-Policy scenario. If there is no SR-Policy configured and only two SIDs exist, namely primary and backup, any intermediate node can bypass the failed tail node.
This can be enabled using a command control to activate this feature, or by extending a flag in the SRH header to indicate that skipping can be performed.
We will update the description in the next version.


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.

[Bruno] OK. Could you please clarify in the draft that this solution requires, on the penultimate SR segment endpoint, i.e., a P node, the knowledge of all VPN routes of the nominal PE which need to be protected by backup PE (and in the absence of configuration, this likely requires this P to have the knowledge, in the control plane, of all VPN routes).
Plus given that the dataplane needs to check the next SID in the SRH, it also requires the knowledge of the protected routes in the dataplane/FIB. If so, it’s not clear to me what’s the benefit of adding the backup SID in the SRH, since the P node needs to have these states in its FIB whatever so could “replace” the ultimate SID with this knowledge.  Given that this is the core of this draft, I’m not sure to get the key benefit of this solution.


[co-authors] There is no need to store VPN routes, and the control plane does not need to add entries. In the P node, using a mechanism similar to [I-D.ietf-spring-segment-protection-sr-te-paths], when the next SID is unreachable, the node can skip the unreachable SID and forward to the backup SID. This behavior can be controlled through configuration or by adding a flag in the SRH header to indicate whether to skip unreachable nodes.
We can clarify the point in the new version.


Thanks,
--Bruno


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]<mailto:[e-mail]>>
> Sent: Sunday, February 25, 2024 6:44 AM
> To: Ketan Talaulikar <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
> Cc: RTGWG <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; rtgwg-chairs <[e-mail]<mailto:[e-mail]>>; draft-cheng-rtgwg-srv6-multihome-egress-protection <[e-mail]<mailto:[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]<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
> > 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.

____________________________________________________________________________________________________________

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.

Disclaimer

This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.