Theresa, thanks for your review. Tarek, thanks for addressing Theresa’s comments. I entered a No Objection ballot.
Alissa > On Feb 11, 2020, at 2:57 PM, Tarek Saad <tsaad....@gmail.com> wrote: > > Hi Theresa, > > Thanks again for your feedback and confirmation. > The document has been scheduled for a telechat. I accept your suggestion, and > I'll hold your comment for the next update of the document. > > Regards, > Tarek > > On 2/11/20, 12:23 PM, "Theresa Enghardt" <i...@tenghardt.net> wrote: > > Hi Tarek, > > Thanks for the replies and the new revision, and sorry for the late > response. > > Your recent revision addresses most of my comments. > > Please find one further comment below: > > On 29.12.19 20:38, Tarek Saad wrote: >> […] >> 3.3 >> "the PLR MUST ensure bypass tunnel assignment can satisfy the protected >> LSP MTU >> requirements post FRR" - Is there an existing mechanism to do this? >> [TS]: Section 2.6 in RFC3209 describes a mechanism to determine whether a >> node should fragment or drop a packet that exceeds the Path MTU as >> discovered using RSVP signaling on primary LSP path. A PLR can leverage the >> RSVP discovered Path MTU on the backup and primary LSP path to ensure MTU is >> not exceeded after rerouting traffic on to the bypass tunnel. > > I think it'd be helpful to add a reference to that RFC and section here. > > Best, > Theresa > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
