Hi Everyone, Draft "SRv6 Egress Protection in Multi-homed scenario" (draft-cheng-rtgwg-srv6-multihome-egress-protection) provides SRv6 path egress protection for a specific scenario, where the primary egress of the path and backup egress are dual-homed, the service SID of the primary egress and the service SID of the backup egress have the same behavior and need to be distributed to the ingress of the path. Draft "SRv6 Path Egress Protection" (draft-ietf-rtgwg-srv6-egress-protection) provides SRv6 path egress protection for general cases, including the specific scenario.
Best Regards, Huaimo On Wed, Feb 21, 2024 at 11: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 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). > > - 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). > 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. > > Thanks, > Ketan > > On Sat, Feb 10, 2024 at 1:00 AM Yingzhen Qu <yingzhen.i...@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 >> rt...@ietf.org >> https://www.ietf.org/mailman/listinfo/rtgwg >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
