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

Hi Ketan/ALL:

    Please see inline.
From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ketan Talaulikar
Sent: Thursday, February 22, 2024 12:06 AM
To: Yingzhen Qu <yingzhen.ietf@gmail.com>
Cc: RTGWG <rtgwg@ietf.org>; spring@ietf.org; rtgwg-chairs <rtgwg-chairs@ietf.org>; draft-cheng-rtgwg-srv6-multihome-egress-protection <draft-cheng-rtgwg-srv6-multihome-egress-protection@ietf.org>
Subject: Re: [spring] WG Adoption Call - draft-cheng-rtgwg-srv6-multihome-egress-protection (02/09/24 - 02/24/24)

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"?
    ZHiBO > I think these two solutions have different application scenarios. draft-ietf-rtgwg-srv6-egress-protection-16 is more cost-effective and suit for scenarios that require high encapsulation efficiency. draft-cheng-rtgwg-srv6-multihome-egress-protection-05
is more automated, and suit for scenarios that expected to reduce OPEX. I think the two solution can evolve in parallel.

  *   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).

  *   If there is any implementation of the proposals, please voice it.
KT> I think this is the key question and look forward to the answer.

Coming to this document, please find below my comments/concerns:

1)  There is no pseudocode for the new VPN behavior with PSD that covers the entire behavior - i.e., one that covers not just the "normal" case but the failure scenarios as well (e.g., PE/CE link failure).
    ZHiBO > PSD only additionally extends the forwarding behavior with the VPN Sid at the penultimate hop. For details about how to switch to the next SRv6 Sid in a fault scenario, see draft-chen-rtgwg-srv6-midpoint-protection-14<https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/>.

2) The draft requires a transit IPv6 node to perform SRH processing for the SID that does not belong to it (this is some action that a P router needs to do when reachability to the PE is lost) and hence does not know what that SID behavior is. This is something very new for SRv6 and it can cause problems. e.g., consider the case that the active segment points to a BSID - what happens when a BSID is skipped.
   ZHiBO > Yes, this is the proxy forwarding behavior for the failure node. draft-li-rtgwg-enhanced-ti-lfa-09<https://datatracker.ietf.org/doc/draft-li-rtgwg-enhanced-ti-lfa/> describes how to prevent certain sids from being skipped.
Thanks,
Ketan

On Sat, Feb 10, 2024 at 1:00 AM Yingzhen Qu <yingzhen.ietf@gmail.com<mailto:yingzhen.ietf@gmail.com>> wrote:

Hi,

This email begins a 2 week WG adoption poll for the following draft:

draft-cheng-rtgwg-srv6-multihome-egress-protection-05 - SRv6 Egress Protection in Multi-homed scenario (ietf.org)<https://datatracker.ietf.org/doc/draft-cheng-rtgwg-srv6-multihome-egress-protection/>

Please review the document and indicate your support or objections by Feb 24th, 2024.

Please note that there is an existing WG document:draft-ietf-rtgwg-srv6-egress-protection-16 - SRv6 Path Egress Protection<https://datatracker.ietf.org/doc/draft-ietf-rtgwg-srv6-egress-protection/> Which proposes fast protections for the egress node and link of an SRv6 path through extending IGP and using Mirror SID. As you discuss adopting draft-cheng-rtgwg-srv6-multihome-egress-protection, please also consider:

·     Do we need these different solutions?

·     Technical merits and drawbacks of each solution

·     If there is any implementation of the proposals, please voice it.

Authors, please respond to the list indicating whether you are aware of any IPR that applies to the draft.

Also copying SPRING WG.

Thanks,

Yingzhen (RTGWG Co-chair)
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org<mailto:rtgwg@ietf.org>
https://www.ietf.org/mailman/listinfo/rtgwg