Hi Yingzhen, Thank you for the quick response. Looking forward to the further instructions. Further review are appreciated.
Best regards, Weiqiang From: Yingzhen Qu Date: 2024-01-02 11:22 To: Weiqiang Cheng CC: rtgwg-chairs; rtgwg; draft-cheng-rtgwg-srv6-multihome-egress-protection; jiangwenying Subject: Re: Request for WG adoption of draft-cheng-rtgwg-srv6-multihome-egress-protection Hi, Happy New Year! There are a few drafts queued up for LC or adoption calls, and as the holiday season comes to a close we'll start the process in the upcoming weeks. Please stay tuned. Thanks, Yingzhen On Mon, Jan 1, 2024 at 6:20 PM Weiqiang Cheng <chengweiqi...@chinamobile.com> wrote: > Dear Chairs， > > we have addressed all the received comments on the draft at the following > link: > > draft-cheng-rtgwg-srv6-multihome-egress-protection-05 > <https://datatracker.ietf.org/doc/html/draft-cheng-rtgwg-srv6-multihome-egress-protection-05> > > Furthermore, we have successfully verified the proposed solution with > running code. > > > In light of these, we kindly request the chairs to consider the adoption > of this draft. > > > Happy New Year！ > > Weiqiang Cheng > > > *From:* 姜文颖 <jiangweny...@chinamobile.com> > *Date:* 2023-09-20 15:50 > *To:* Yingzhen Qu <yingzhen.i...@gmail.com> > *CC:* rtgwg <rtgwg@ietf.org>; draft-cheng-rtgwg-sr > <draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org> > *Subject:* Re:Re: Questions about > draft-cheng-rtgwg-srv6-multihome-egress-protection > > Hi Yingzhen: > > We have addressed all the comments received till now. Co-authors believe > this document is mature enough, > > and we hope to request WG adaptation. > > > > 1. > > Comments1: About PSD definition, in section 3.2, there are the following > texts: > > " A penultimate SRv6 Segment Endpoint node is one that, as part of the > > SID processing, copies the last SID from the SRH into the IPv6 > > Destination Address and decrements the Segments Left value from one > > to zero. > > " > > [wenying] In Section 3.2 of "Version 05", we have deleted the above > description. > > > > " The PSD operation only takes place at the egress node and does not > > happen at any transit node. When a SID of PSD flavor is processed at > > a transit node, the PSD behavior is not performed as described in > > the pseudocode below since Segments Left would not be 1 or 0. > > " so to my understanding, P2 is the penultimate endpoint in the example in > > Figure 1, correct? however there is "PSD-flavored SID" on PE3. Please > clarify. > > > > [Zhibo] Yes, your understanding is correct. We will modify the description > > in the next version to avoid ambiguity. > > > > [Yingzhen]: Please do. The second quoted text here is not correct. > > > > [wenying] In Section 3.2 of "Version 05", we have modified the second > quoted text > > as follows to avoid ambiguity： > > “When a node (PE3 in Figure 1) receives a packet whose IPv6 DA is a SID > with > > PSD Flavor located in the penultimate position of the SRH Segment List > array，and > > that SID is a local SID,it indicates to remove the outer encapsulation of > the packet, > > and forward the packet according to the exposed packet. > > ...... > > Due to the above pseudocode modification,the PSD operation only takes > place at > > the egress node and does not happen at any transit node. When a SID of PSD > > flavor is processed at a transit node, the PSD behavior is not performed > since > > Segments Left would not be 1 or 0.” > > > > 2. > > Comments2: In Section 4, "After the configuration, PE1 determines that > PE3's > > backup SID is PE4's VPN SID through the routing optimization strategy of > BGP." > > Can you please elaborate how PE1 decides PE4 to be the backup SID? What if > the > > path for P2 to reach PE4 is P2->PE3->PE4? > > > > [Zhibo] According to the BGP route selection principle, the ingress PE > node selects > > the preferred route as the primary node and the second-best route as the > backup > > node. > > After egress protection is enabled, if PE3 fails, P2 forwards traffic to > PE4. If PE3 is > > the next hop of P2, P2 will forwards traffic to PE4 through the TI-LFA > backup path. > > This solution does not affect the implementation of this solution. > > > > [wenying] > > In Section 4 of "Version 05", we added the following explanation to > provide > > clarification: > > “After the configuration, according to the BGP route selection > > principle, the ingress PE node selects the preferred route as the > > primary node and the second-best route as the backup node. PE1 > > determines that PE3 is the primary egress node and PE4 is the backup > > egress node. PE3's backup SID is PE4's VPN SID.” > > > > 3. > > Comments3: In section 3.4, it mentions that P2 could be several hops away > from > > the egress node. In this case, if PE3 fails, how does P2 detect the > failure of PE3 > > quickly? What if a link between P2 and PE3 fails? > > > > [Zhibo] > > P2 detect the failure of PE3 via: > > • IGP convergence > > • BFD detection > > Traditional FRR also maximizes the protection scope and preferentially > considers > > node faults without distinguishing whether a link fault or node fault > occurs. > > > > BR. > > wenying > > > > > > -----Original Message----- > From: Yingzhen Qu [mailto:yingzhen.i...@gmail.com] > Sent: Friday, August 11, 2023 4:30 AM > To: Huzhibo > Cc: draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org; RTGWG > Subject: Re: Questions about > draft-cheng-rtgwg-srv6-multihome-egress-protection > > > > Hi Zhibo, > > > > Please see my reply below. > > > > Thanks, > > Yingzhen > > > > On Tue, Aug 8, 2023 at 6:15AM Huzhibo <huzh...@huawei.com> wrote: > > > > > Hi Yingzhen： > > > > > > Thanks for your comments, please see inline. > > > > > > > > > > > > Thanks > > > > > > Zhibo > > > > > > *From:* rtgwg [mailto:rtgwg-boun...@ietf.org] *On Behalf Of *Yingzhen Qu > > > *Sent:* Saturday, August 5, 2023 9:00 AM > > > *To:* draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org; > RTGWG < > > > rtgwg@ietf.org> > > > *Subject:* Questions about > > > draft-cheng-rtgwg-srv6-multihome-egress-protection > > > > > > > > > > > > Hi Authors, > > > > > > > > > > > > (as individual contributor) > > > > > > > > > > > > I reviewed the draft, and have the following questions: > > > > > > > > > > > > 1. > > > > > > About PSD definition, in section 3.2, there are the following texts: > > > > > > " A penultimate SRv6 Segment Endpoint node is one that, as part of the > > > > > > SID processing, copies the last SID from the SRH into the IPv6 > > > > > > Destination Address and decrements the Segments Left value from one > > > > > > to zero. > > > > > > " > > > > > > " The PSD operation *only takes place at the egress node *and does not > > > > > > happen at any transit node. When a SID of PSD flavor is processed at > > > > > > a transit node, the PSD behavior is not performed as described in > > > > > > the pseudocode below since Segments Left would not be 1 or 0. > > > > > > " > > > > > > so to my understanding, P2 is the penultimate endpoint in the example in > > > Figure 1, correct? however there is "PSD-flavored SID" on PE3. Please > > > clarify. > > > > > > [Zhibo] Yes, your understanding is correct. We will modify the > description > > > in the next version to avoid ambiguity. > > > > > > > > > > > [Yingzhen]: Please do. The second quoted text here is not correct. > > > > 2. > > > > > > In Section 4, "After the configuration, PE1 determines that PE3's backup > > > SID is PE4's VPN SID through the routing optimization strategy of BGP." > > > > > > *From:* rtgwg [mailto:rtgwg-boun...@ietf.org <rtgwg-boun...@ietf.org>] *On > Behalf Of *Yingzhen Qu > *Sent:* Saturday, August 5, 2023 9:00 AM > *To:* draft-cheng-rtgwg-srv6-multihome-egress-protect...@ietf.org; RTGWG < > rtgwg@ietf.org> > *Subject:* Questions about > draft-cheng-rtgwg-srv6-multihome-egress-protection > > > > Hi Authors, > > > > (as individual contributor) > > > > I reviewed the draft, and have the following questions: > > > > 1. > > About PSD definition, in section 3.2, there are the following texts: > > " A penultimate SRv6 Segment Endpoint node is one that, as part of the > > SID processing, copies the last SID from the SRH into the IPv6 > > Destination Address and decrements the Segments Left value from one > > to zero. > > " > > " The PSD operation *only takes place at the egress node *and does not > > happen at any transit node. When a SID of PSD flavor is processed at > > a transit node, the PSD behavior is not performed as described in > > the pseudocode below since Segments Left would not be 1 or 0. > > " > > so to my understanding, P2 is the penultimate endpoint in the example in > Figure 1, correct? however there is "PSD-flavored SID" on PE3. Please > clarify. > > [Zhibo] Yes, your understanding is correct. We will modify the description > in the next version to avoid ambiguity. > > > > 2. > > In Section 4, "After the configuration, PE1 determines that PE3's backup > SID is PE4's VPN SID through the routing optimization strategy of BGP."
_______________________________________________ rtgwg mailing list rtgwg@ietf.org https://www.ietf.org/mailman/listinfo/rtgwg
