Hi Jorge, Yes, my mistake for not updating this previously. Thanks for confirming that the update is correct; we will continue with publication shortly.
Thank you, RFC Editor/sg > On Mar 4, 2025, at 3:22 AM, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > wrote: > > Hi Sandy, > > Yes, I missed this, I thought you had updated also the text to “unassigned” > everywhere. > > The update is correct. > > Thank you very much for catching this and all the work! > > Jorge > > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Date: Monday, March 3, 2025 at 1:42 PM > To: Wen Lin <w...@juniper.net> > Cc: Ali Sajassi (sajassi) <saja...@cisco.com>, Kiran Nagaraj (Nokia) > <kiran.naga...@nokia.com>, Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, > RFC Editor <rfc-edi...@rfc-editor.org>, bess-...@ietf.org > <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, Jeffrey > (Zhaohui) Zhang <zzh...@juniper.net>, Gunter van de Velde (Nokia) > <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org > <auth48archive@rfc-editor.org> > Subject: Additional question - Re: AUTH48: RFC-to-be 9746 > <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Authors, > > The figure in Section 2.1 was previously updated to indicate “Unassigned”. > However, the text had not been updated. We have corrected the text as > follows: > > Original: > * SHT = 11 is a reserved value, for future use. > > Current: > * SHT = 11 is Unassigned. > > We would appreciate a confirmation from one or more of you that this update > is correct. Otherwise, please provide new text. > > Thank you, > RFC Editor/sg > > > > > > > On Mar 3, 2025, at 12:46 PM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > > wrote: > > > > Authors, > > > > Wen, thank you for your review; we have noted your approval on the AUTH48 > > page <https://www.rfc-editor.org/auth48/rfc9746>. With Wen’s approval, we > > have all of the required approvals, so we will proceed with publication > > shortly. > > > > Thank you, > > RFC Editor/sg > > > >> On Mar 3, 2025, at 12:03 PM, Wen Lin <w...@juniper.net> wrote: > >> > >> Hi Sandy and Jorge, > >> > >> Thank you for advancing the draft to this stage. > >> > >> I reviewed the latest. It looks good. I approve the publication as an > >> RFC. > >> > >> Wen > >> > >> > >> Juniper Business Use Only > >> > >> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >> Date: Monday, March 3, 2025 at 10:07 AM > >> To: Ali Sajassi (sajassi) <saja...@cisco.com> > >> Cc: Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com>, Jorge Rabadan (Nokia) > >> <jorge.raba...@nokia.com>, RFC Editor <rfc-edi...@rfc-editor.org>, Wen Lin > >> <w...@juniper.net>, bess-...@ietf.org <bess-...@ietf.org>, > >> bess-cha...@ietf.org <bess-cha...@ietf.org>, Jeffrey (Zhaohui) Zhang > >> <zzh...@juniper.net>, Gunter van de Velde (Nokia) > >> <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org > >> <auth48archive@rfc-editor.org> > >> Subject: Re: AUTH48: RFC-to-be 9746 > >> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > >> > >> [External Email. Be cautious of content] > >> > >> > >> Hi Ali, > >> > >> Thank you for your review. We have noted your approval on the AUTH48 page > >> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9746__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537247873%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Ucckk9%2FMcJRok6q4pGrmKUygMS6VEl%2F9lotjsQTHsdE%3D&reserved=0 > >> >. We will wait to hear from Wen before continuing with the process. > >> > >> Thank you, > >> RFC Editor/sg > >> > >> > >>> On Mar 2, 2025, at 1:09 PM, Ali Sajassi (sajassi) <saja...@cisco.com> > >>> wrote: > >>> > >>> Hi Sandy, > >>> > >>> I reviewed it and it looked good . Thanks for your work. I approve the > >>> publication of this RFC. > >>> > >>> Cheers, > >>> Ali > >>> > >>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>> Date: Friday, February 28, 2025 at 11:39 AM > >>> To: Kiran Nagaraj (Nokia) <kiran.naga...@nokia.com> > >>> Cc: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, RFC Editor > >>> <rfc-edi...@rfc-editor.org>, w...@juniper.net <w...@juniper.net>, Ali > >>> Sajassi (sajassi) <saja...@cisco.com>, bess-...@ietf.org > >>> <bess-...@ietf.org>, bess-cha...@ietf.org <bess-cha...@ietf.org>, > >>> zzh...@juniper.net<zzh...@juniper.net>, Gunter van de Velde (Nokia) > >>> <gunter.van_de_ve...@nokia.com>, auth48archive@rfc-editor.org > >>> <auth48archive@rfc-editor.org> > >>> Subject: Re: AUTH48: RFC-to-be 9746 > >>> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > >>> > >>> Hi Wen and Ali, > >>> > >>> Please note that we await your review of RFC-to-be 9746 before continuing > >>> with the publication process. Please review and let us know if any > >>> updates are needed or if you approve the RFC for publication. > >>> > >>> The current files are available here: > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.xml__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRFwUxWIg%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537268861%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0hn2joXwvtAE8kQDF7L9pVVCcc7AXgvZpDtazh%2BVFoU%3D&reserved=0 > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.txt__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRQeRvL-8%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537285365%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6XKuYtBzzTNV7PkwxnwrX7mc6HsVHq%2FHtUheXqkB%2Fl4%3D&reserved=0 > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.pdf__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR_d3ClH8%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537301361%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oa%2FDrcczSHy7JUKuBWM6HXsDr5kKgl6fgCRzYEtyKEI%3D&reserved=0 > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRpeiSVBE%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537319315%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BZWAm2iEXvY9HIN5nF0a3G1RS6TFKa993HS0U9R3eE4%3D&reserved=0 > >>> > >>> AUTH48 diffs: > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-auth48diff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR9rk8n_E%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537339500%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RsrfnWZRwdjXXfyLRj9LFXgs7J%2FnzuU8nH0EnItq%2FE4%3D&reserved=0 > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-auth48rfcdiff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vROUPpKvo%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537355082%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Z%2FyBe1yfJq%2FEdfGB3vvGuo%2FSZ7C6Bt7JD419Qg1spqw%3D&reserved=0 > >>> (side by side) > >>> > >>> Comprehensive diffs: > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-diff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRNyybZAs%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537369933%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=737adizvdal5BcPHnbV98t23EEB2bW7YbPAV7HaKXpI%3D&reserved=0 > >>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-rfcdiff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRxzIodOY%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537382300%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6KVM1RavzNDRD7MmRLVPjA0r5w9vKNKLVkRdDMzTpD8%3D&reserved=0 > >>> (side by side) > >>> > >>> Thank you, > >>> RFC Editor/sg > >>> > >>> > >>> > >>>> On Feb 24, 2025, at 10:40 AM, Sandy Ginoza > >>>> <sgin...@staff.rfc-editor.org> wrote: > >>>> > >>>> Hi Kiran, > >>>> > >>>> Thank you for your review. We have noted your approval on the AUTH48 > >>>> page > >>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9746__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537394342%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6W17SAQm2fgjAwBzSkzAgcAsAaV6md03jWTul5bK8rU%3D&reserved=0 > >>>> >. > >>>> > >>>> Thank you, > >>>> RFC Editor/sg > >>>> > >>>> > >>>>> On Feb 24, 2025, at 9:10 AM, Kiran Nagaraj (Nokia) > >>>>> <kiran.naga...@nokia.com> wrote: > >>>>> > >>>>> Hi Sandy, > >>>>> Thank you very much for you work on this. The RFC looks good to me and > >>>>> I approve it for publication. > >>>>> > >>>>> Thanks > >>>>> Kiran > >>>>> > >>>>> -----Original Message----- > >>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>>>> Sent: Monday, February 24, 2025 8:41 AM > >>>>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > >>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Kiran Nagaraj (Nokia) > >>>>> <kiran.naga...@nokia.com>; w...@juniper.net; saja...@cisco.com; > >>>>> bess-...@ietf.org; bess-cha...@ietf.org; zzh...@juniper.net; Gunter van > >>>>> de Velde (Nokia) <gunter.van_de_ve...@nokia.com>; > >>>>> auth48archive@rfc-editor.org > >>>>> Subject: Re: AUTH48: RFC-to-be 9746 > >>>>> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > >>>>> > >>>>> [You don't often get email from sgin...@staff.rfc-editor.org. Learn why > >>>>> this is important > >>>>> athttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRj2C5yYI%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537406045%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=niMkB4LiPDDOTjnqSCTKsqLd5gW1z7QnqkTyMgs83bE%3D&reserved=0 > >>>>> ] > >>>>> > >>>>> CAUTION: This is an external email. Please be very careful when > >>>>> clicking links or opening attachments. See the URL nok.it/ext for > >>>>> additional information. > >>>>> > >>>>> > >>>>> > >>>>> Hi Jorge, > >>>>> > >>>>> Thank you for your review. We have noted your approval on the AUTH48 > >>>>> page > >>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9746__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537417936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YIIbVGiRgpAHv3267pywTqiiUcAUKMA%2FT01101qxxW8%3D&reserved=0 > >>>>> >. Please note that we will wait to hear from your coauthors as well > >>>>> before continuing with the publication process. > >>>>> > >>>>> Thank you, > >>>>> RFC Editor/sg > >>>>> > >>>>> > >>>>>> On Feb 24, 2025, at 2:57 AM, Jorge Rabadan (Nokia) > >>>>>> <jorge.raba...@nokia.com> wrote: > >>>>>> > >>>>>> Hi Sandy, > >>>>>> > >>>>>> Looks good. > >>>>>> I approve the RFC for publication. > >>>>>> > >>>>>> Thanks! > >>>>>> Jorge > >>>>>> > >>>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>>>>> Date: Wednesday, February 19, 2025 at 4:31 PM > >>>>>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com> > >>>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>, Kiran Nagaraj (Nokia) > >>>>>> <kiran.naga...@nokia.com>, w...@juniper.net <w...@juniper.net>, > >>>>>> saja...@cisco.com <saja...@cisco.com>, bess-...@ietf.org > >>>>>> <bess-...@ietf.org>, bess-cha...@ietf.org > >>>>>> <bess-cha...@ietf.org>,zzh...@juniper.net <zzh...@juniper.net>, Gunter > >>>>>> van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, > >>>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > >>>>>> Subject: Re: AUTH48: RFC-to-be 9746 > >>>>>> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > >>>>>> > >>>>>> [You don't often get email from sgin...@staff.rfc-editor.org. Learn > >>>>>> why this is important at > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Faka.ms%2FLearnAboutSenderIdentification__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRj2C5yYI%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537429841%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3OcyhvMsykfLH7R4XGcSjLmjh2KV%2BaS20VIJV%2FDXJ6g%3D&reserved=0 > >>>>>> ] > >>>>>> > >>>>>> CAUTION: This is an external email. Please be very careful when > >>>>>> clicking links or opening attachments. See the URL nok.it/ext for > >>>>>> additional information. > >>>>>> > >>>>>> > >>>>>> > >>>>>> Hi Jorge, > >>>>>> > >>>>>> Thank you for your detailed review. We have updated the document > >>>>>> based on the replies below, but please review these followup notes. > >>>>>> > >>>>>> a) We updated the terms as noted here. However, we left “Local Bias” > >>>>>> and “Split-Horizon Type” in Table 1, and where the values seemed to > >>>>>> refer to the IANA value or the expansion of SHT. Please review and > >>>>>> let us know if any adjustments are needed. > >>>>>> > >>>>>>> [jorge] Since RFC7432 was the first spec that introduced the concept, > >>>>>>> we should probably use “split-horizon”. > >>>>>>> [jorge] if we follow the same reasoning as in (a), we should use > >>>>>>> “local-bias” > >>>>>>> [jorge] “Geneve” based on the same reason. > >>>>>> > >>>>>> > >>>>>> > >>>>>> b) We updated the text to refer to Table 2. Please let us know if you > >>>>>> prefer otherwise. > >>>>>> > >>>>>>> [jorge] it refers to the multihoming redundancy mode field in table > >>>>>>> 2 (of section 5, IANA considerations) > >>>>>> > >>>>>> > >>>>>> > >>>>>> The current files are available here: > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.xml__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRFwUxWIg%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537441857%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=EYDvLYGW60xfCrBNLVx%2BQVs3N3QdoK92p%2Bv%2FQlAuXjI%3D&reserved=0 > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.txt__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRQeRvL-8%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537453995%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wdwpGrTV5jM07D2ZM4B6q%2BaOnxhMql7F0nl%2BTdi0Z1Y%3D&reserved=0 > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.pdf__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR_d3ClH8%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537465951%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3E%2FrVJI69K%2BJCeZzN8FtUDrX%2BB7tQqYNocOXAlrDbo8%3D&reserved=0 > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRpeiSVBE%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537477976%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ENGYvqCKw3jpNBNc2JOvwrdzjx1siNr3GA8vkvhj%2FlQ%3D&reserved=0 > >>>>>> > >>>>>> AUTH48 diffs: > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-auth48diff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR9rk8n_E%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537491109%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9UAR6evHg5LkmxBG9xA8CmCzLZ6EJNRxbSnCJs323EQ%3D&reserved=0 > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-auth48rfcdiff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vROUPpKvo%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537506037%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=c8S%2BmTUVUF8oR2iCHCWJXGliGNvKdg7v5drPnKkckk0%3D&reserved=0 > >>>>>> (side > >>>>>> by side) > >>>>>> > >>>>>> Comprehensive diffs: > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-diff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRNyybZAs%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537521250%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sFR8a67v4t5khwAnUxf6wOb43mMf0nW2m%2FNkitw0n2s%3D&reserved=0 > >>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-rfcdiff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRxzIodOY%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537535846%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=2o2AQShj44MbOD82Y7Mj3F7UmKCAI%2BXoi2LfpHlpqyA%3D&reserved=0 > >>>>>> (side by > >>>>>> side) > >>>>>> > >>>>>> Please review the updates carefully and let us know if any corrections > >>>>>> are needed or if you approve the RFC for publication. > >>>>>> > >>>>>> Thank you, > >>>>>> RFC Editor/sg > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On Feb 18, 2025, at 10:40 AM, Jorge Rabadan (Nokia) > >>>>>>> <jorge.rabadan=40nokia....@dmarc.ietf.org> wrote: > >>>>>>> > >>>>>>> Dear RFC-editor team, > >>>>>>> > >>>>>>> Thank you very much for your work on this. > >>>>>>> Please find our comments to your suggestions below with [jorge]. > >>>>>>> > >>>>>>> Thanks! > >>>>>>> Jorge > >>>>>>> > >>>>>>> > >>>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >>>>>>> Date: Monday, February 10, 2025 at 7:36 PM > >>>>>>> To: Jorge Rabadan (Nokia) <jorge.raba...@nokia.com>, Kiran Nagaraj > >>>>>>> (Nokia) <kiran.naga...@nokia.com>, w...@juniper.net > >>>>>>> <w...@juniper.net>, saja...@cisco.com <saja...@cisco.com> > >>>>>>> Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>, > >>>>>>> bess-...@ietf.org <bess-...@ietf.org>, bess-cha...@ietf.org > >>>>>>> <bess-cha...@ietf.org>, zzh...@juniper.net <zzh...@juniper.net>, > >>>>>>> Gunter van de Velde (Nokia) <gunter.van_de_ve...@nokia.com>, > >>>>>>> auth48archive@rfc-editor.org<auth48archive@rfc-editor.org> > >>>>>>> Subject: Re: AUTH48: RFC-to-be 9746 > >>>>>>> <draft-ietf-bess-evpn-mh-split-horizon-11> for your review > >>>>>>> > >>>>>>> > >>>>>>> CAUTION: This is an external email. Please be very careful when > >>>>>>> clicking links or opening attachments. See the URL nok.it/ext for > >>>>>>> additional information. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Authors, > >>>>>>> > >>>>>>> While reviewing this document during AUTH48, please resolve (as > >>>>>>> necessary) the following questions, which are also in the XML file. > >>>>>>> > >>>>>>> 1) <!-- [rfced] Please insert any keywords (beyond those that appear > >>>>>>> in the title) for use on > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fsearch__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR7P8vQMA%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537550158%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=0u3a9Hqeauo%2FtU6ox8zIl4%2BQ5%2F1UqvUWQZkHOgdeOt4%3D&reserved=0 > >>>>>>> . --> > >>>>>>> > >>>>>>> [jorge] some keywords: > >>>>>>> > >>>>>>> EVPN Multihoming, Split Horizon Filtering, Local Bias, ESI, > >>>>>>> encapsulations, SHT > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 2) <!-- [rfced] We see the following terms used in various ways in > >>>>>>> the RFC Series. This document was consistent in their use of the > >>>>>>> capitalziation for the terms below. Is this the preferred form for > >>>>>>> future documents related to this subject? > >>>>>>> > >>>>>>> a) RFC 7432 uses "split-horizon" (lowercase and hyphenated) when > >>>>>>> acting as an adjective appearing before the noun, while this document > >>>>>>> uses the initial-capitalized form without a hyphen consistently. > >>>>>>> > >>>>>>> Examples from this document: > >>>>>>> Split Horizon procedure > >>>>>>> Split Horizon filtering > >>>>>>> Split Horizon method > >>>>>>> Split Horizon behavior > >>>>>>> Split Horizon Type (SHT) > >>>>>>> > >>>>>>> [jorge] Since RFC7432 was the first spec that introduced the concept, > >>>>>>> we should probably use “split-horizon”. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> b) "Local Bias" (this document) vs "local-bias" per RFCs 8365 and > >>>>>>> 9252 > >>>>>>> > >>>>>>> [jorge] if we follow the same reasoning as in (a), we should use > >>>>>>> “local-bias” > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> c) "GENEVE" (this document) vs "Geneve" per RFC 8926 > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] “Geneve” based on the same reason. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 3) <!-- [rfced] Please review the following questions and changes > >>>>>>> regarding the terminology list in Section 1.1. > >>>>>>> > >>>>>>> a.) We have made some adjustments for readability and to demonstrate > >>>>>>> 1:1 relationships between abbreviations and their expansions. Please > >>>>>>> carefully review and let us know any objections. > >>>>>>> > >>>>>>> [jorge] looks good, thanks. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> b.) We were unable to find the "EVPN Ethernet Auto-Discovery per ES > >>>>>>> route" > >>>>>>> explicitly mentioned in RFC 7432. May we update this item as follows > >>>>>>> for accuracy and concision? > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> * A-D per ES route: refers to the EVPN Ethernet Auto-Discovery per > >>>>>>> ES route defined in [RFC7432]. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> > >>>>>>> A-D per ES route: Auto-Discovery per Ethernet Segment route (as > >>>>>>> defined in > >>>>>>> [RFC7432]). > >>>>>>> > >>>>>>> [jorge] yes, that’s the one. Thanks. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> c.) Arg.FE2 is mentioned in RFC 9252; however, RFC 9252 says that > >>>>>>> "the Arg.FE2 notation [is] introduced in [RFC8986]". Would you like > >>>>>>> to update the citation below to RFC 8986? > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> * Arg.FE2: refers to the ESI filtering argument used for Split > >>>>>>> Horizon as specified in [RFC9252]. > >>>>>>> > >>>>>>> [jorge] I’d prefer to keep RFC9252. Although first introduced in > >>>>>>> RFC8986, it’s use is really specified in RFC9252. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> d.) Several abbreviations appear in this document but are not > >>>>>>> included in this terminology list (see some examples below). Please > >>>>>>> review and let us know if you would like to add these or any > >>>>>>> additional terms to this list. > >>>>>>> > >>>>>>> Type-Length-Value (TLV) > >>>>>>> Route Targets (RTs) > >>>>>>> Provider Edge (PE) > >>>>>>> Customer Edge (CE) > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] yes please, add those to the terminology list. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 4) <!-- [rfced] The parentheses in the text below seem to contain a > >>>>>>> mixture of abbreviations and additional context. For clarity and > >>>>>>> readability, may we update as follows? > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> The ingress Network Virtualization Edge (NVE) device appends a > >>>>>>> label > >>>>>>> corresponding to the source Ethernet Segment Identifier (ESI label) > >>>>>>> during packet encapsulation. The egress NVE verifies the ESI > >>>>>>> label when > >>>>>>> attempting to forward a multi-destination frame through a local > >>>>>>> Ethernet Segment (ES) interface. If the ESI label matches the site > >>>>>>> identifier (ESI) associated with that ES interface, the packet is > >>>>>>> not > >>>>>>> forwarded... > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> > >>>>>>> The ingress NVE device appends a label corresponding to the > >>>>>>> source ESI > >>>>>>> (the ESI label) during packet encapsulation. The egress NVE > >>>>>>> verifies > >>>>>>> the ESI label when attempting to forward a multi-destination frame > >>>>>>> through a local ES interface. If the ESI label matches the site > >>>>>>> identifier (the ESI) associated with that ES interface, then the > >>>>>>> packet > >>>>>>> is not forwarded... > >>>>>>> > >>>>>>> [jorge] your suggestion is good, please go ahead. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --> > >>>>>>> > >>>>>>> > >>>>>>> 5) <!-- [rfced] For clarity and consistency with other list items, > >>>>>>> may we adjust the term "(SR-)MPLS" as seen below? > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> This document classifies the tunnel encapsulations used by EVPN into: > >>>>>>> > >>>>>>> 1. IP-based MPLS tunnels > >>>>>>> > >>>>>>> 2. (SR-)MPLS tunnels, that is, MPLS and Segment Routing with MPLS > >>>>>>> data plane tunnels > >>>>>>> > >>>>>>> 3. IP tunnels > >>>>>>> > >>>>>>> 4. SRv6 tunnels > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> > >>>>>>> This document classifies the tunnel encapsulations used by EVPN into: > >>>>>>> > >>>>>>> 1. IP-based MPLS tunnels > >>>>>>> > >>>>>>> 2. MPLS and SR-MPLS tunnels > >>>>>>> > >>>>>>> 3. IP tunnels > >>>>>>> > >>>>>>> 4. SRv6 tunnels > >>>>>>> > >>>>>>> [jorge] yes, go ahead please. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> b.) "(SR-)MPLS" also appears in the instances below. For ease of the > >>>>>>> reader, may we update these instances similarly? > >>>>>>> > >>>>>>> Originals: > >>>>>>> > >>>>>>> * (SR-)MPLS tunnels only support ESI Label-based Split Horizon > >>>>>>> filtering > >>>>>>> > >>>>>>> | (SR-)MPLS | ESI Label filtering | No | Yes | > >>>>>>> > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] sure > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 6) <!-- [rfced] Please review the artwork in Section 2.1 and let us > >>>>>>> know what "Section 5" refers to and if any other updates are needed. > >>>>>>> Perhaps this refers to Table 3? > >>>>>>> > >>>>>>> Original: > >>>>>>> RED = "Multihoming Redundancy Mode" field (section 5) > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] it refers to the multihoming redundancy mode field in table > >>>>>>> 2 (of section 5, IANA considerations) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 7) <!-- [rfced] The figure in Section 2.1 indicates that value 11 is > >>>>>>> "reserved for future use". However, table 3 (and the IANA registry) > >>>>>>> indicates the value is unassigned. "Reserved" and "Unassigned" have > >>>>>>> distinct meanings. Please review "Well-Known Registration Status > >>>>>>> Terminology" in RFC 8126 > >>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8126.html*section-6__%3BIw!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRz303NOo%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537564547%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=PZbO03yDU6wN4pe6dmVKeMwDjdQUVyBZkxbJG5eSxrw%3D&reserved=0 > >>>>>>> > and let us know which is correct. > >>>>>>> > >>>>>>> Section 2.1 (double hyphen changed to single hyphen so this comment > >>>>>>> appears correctly in the XML file: > >>>>>>> 1 1 -> reserved for future use > >>>>>>> > >>>>>>> Table 3: > >>>>>>> | 11 | Unassigned | | > >>>>>>> > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] please change the figure to “Unassigned” > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 8) <!-- [rfced] How may we adjust the text below to avoid using an > >>>>>>> RFC as an adjective? > >>>>>>> > >>>>>>> Original: > >>>>>>> An egress NVE MUST NOT use an SHT value other than 00 when > >>>>>>> advertising an A-D per ES route with [RFC9012] Tunnel encapsulation > >>>>>>> types of VXLAN (type 8), NVGRE (type 9), MPLS (type 10), or no BGP > >>>>>>> tunnel encapsulation extended community at all. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> An egress NVE MUST NOT use an SHT value other than 00 when > >>>>>>> advertising an A-D per ES route with the following tunnel > >>>>>>> encapsulation > >>>>>>> types from [RFC9012]: VXLAN (type 8), NVGRE (type 9), MPLS (type 10), > >>>>>>> or no BGP > >>>>>>> Tunnel Encapsulation Extended Community at all. > >>>>>>> > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] your suggestion looks good to me > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 9) <!-- [rfced] How may we update the citations in the text below? > >>>>>>> We were unable to find either "Tunnel encapsulation type 19" or > >>>>>>> "GENEVE" encapsulation in [RFC9012]. We note that the IANA entry > >>>>>>> refers to RFC 8926 (19 Geneve Encapsulation). > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE > >>>>>>> encapsulation ([RFC9012], Tunnel encapsulation type 19, > >>>>>>> [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. > >>>>>>> > >>>>>>> Perhaps: > >>>>>>> > >>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE > >>>>>>> encapsulation [RFC9012] (and tunnel encapsulation type 19 > >>>>>>> [EVPN-GENEVE]) MAY > >>>>>>> use an SHT value of 01 or 10. > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] Hmm.. I think this is more accurate: > >>>>>>> > >>>>>>> ORIGINAL: > >>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE > >>>>>>> encapsulation ([RFC9012], Tunnel encapsulation type 19, > >>>>>>> [I-D.ietf-bess-evpn-geneve]) MAY use an SHT value of 01 or 10. > >>>>>>> > >>>>>>> NEW: > >>>>>>> > >>>>>>> An egress NVE advertising A-D per ES route(s) for an ES with GENEVE > >>>>>>> encapsulation (tunnel encapsulation type 19 in the BGP Tunnel > >>>>>>> Encapsulation attribute [RFC9012]) MAY > >>>>>>> use an SHT value of 01 or 10. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 10) <!-- [rfced] How may we rephrase the title of this section to > >>>>>>> avoid using an RFC as an adjective? > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> 2.4. Backwards Compatibility With RFC8365 NVEs > >>>>>>> > >>>>>>> Perhaps (no RFC mentioned): > >>>>>>> > >>>>>>> 2.4. Backwards Compatibility with NVEs > >>>>>>> > >>>>>>> Perhaps (RFC mentioned): > >>>>>>> > >>>>>>> 2.4. Backwards Compatibility with NVEs from RFC 8365 > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] use the latter one please – “2.4. Backwards Compatibility > >>>>>>> with NVEs from RFC 8365” > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 11) <!-- [rfced] May we make these registry titles plural? > >>>>>>> > >>>>>>> Multihoming Redundancy Mode -> Multihoming Redundancy Modes Split > >>>>>>> Horizon Type -> Split Horizon Types > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] I don’t think so, it reads better the way it is > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 12) <!-- [rfced] Because "mode" is part of the registry and column > >>>>>>> titles, does "mode" need to appear in description? > >>>>>>> > >>>>>>> From Table 3 and the IANA registry [1]: > >>>>>>> +=======+=============================+===========+ > >>>>>>> | Value | Multihoming redundancy mode | Reference | > >>>>>>> +=======+=============================+===========+ > >>>>>>> | 00 | All-Active mode | [RFC7432] | > >>>>>>> | 01 | Single-Active mode | [RFC7432] | > >>>>>>> > >>>>>>> [1] > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Feur03.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fww__%3BJSUl!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR2IYPsDg%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537578952%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=TLmqqGWjsZs5sw%2B421LEo7ycVq8jNiQ2G3a3BzR8Ook%3D&reserved=0 > >>>>>>> w.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp-extended-c > >>>>>>> ommunities.xhtml%23multihoming-redundancy-mode&data=05%7C02%7Ckiran. > >>>>>>> nagaraj%40nokia.com%7C4f6980c5bf9a4351ccd608dd54f24d2a%7C5d471751967 > >>>>>>> 5428d917b70f44f9630b0%7C0%7C0%7C638760122149077373%7CUnknown%7CTWFpb > >>>>>>> GZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI > >>>>>>> kFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=7XZv%2B8E8kYSZvSG > >>>>>>> cFZAMh00gKiO2DkZa5QJEVpFJOjk%3D&reserved=0 > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] no, it does not. You can change those values to “All-Active” > >>>>>>> and “Single-Active” and remove the “mode”. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 13) <!-- [rfced] Please review the following questions and changes > >>>>>>> regarding the terminology used in this document: > >>>>>>> > >>>>>>> a.) We note that the term "MPLSoX" does not appear in this document > >>>>>>> after it is introduced in Section 1. May we remove this term from > >>>>>>> the terminology list? > >>>>>>> > >>>>>>> Original: > >>>>>>> * MPLSoX: refers to MPLS over any IP encapsulation. Examples are > >>>>>>> MPLS-over-UDP or MPLS-over-GRE. > >>>>>>> > >>>>>>> [jorge] But it appears in the introduction and it may still help if > >>>>>>> the reader does not know what MPLSoX means in the introduction… I > >>>>>>> would leave it. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> b.) FYI - For consistency with RFCs 8402, 8986, and 9252, we have > >>>>>>> updated the terms below as follows. Please review and let us know any > >>>>>>> objections. > >>>>>>> > >>>>>>> Original: > >>>>>>> > >>>>>>> Segment Routing with MPLS data plane (SR-MPLS) Segment Routing with > >>>>>>> IPv6 data plane (SRv6) > >>>>>>> > >>>>>>> Current: > >>>>>>> > >>>>>>> SR over MPLS (SR-MPLS) > >>>>>>> Segment Routing over IPv6 (SRv6) > >>>>>>> > >>>>>>> --> > >>>>>>> > >>>>>>> [jorge] sounds good, thanks. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 14) <!-- [rfced] The references in this document do not appear to be > >>>>>>> sorted. > >>>>>>> Would you like to order them alphanumerically? --> > >>>>>>> > >>>>>>> [jorge] yes, please > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> 15) <!-- [rfced] Please review the "Inclusive Language" portion of > >>>>>>> the online Style Guide > >>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fstyleguide%2Fpart2%2F*inclusive_language__%3BIw!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRPqqoIkQ%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537592369%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=VtsDj1prnlJmkto944lL7AXHklPQKc9CWr%2B8wbqdkW8%3D&reserved=0 > >>>>>>> > > >>>>>>> and let us know if any changes are needed. Updates of this nature > >>>>>>> typically result in more precise language, which is helpful for > >>>>>>> readers. > >>>>>>> > >>>>>>> Note that our script did not flag any words in particular, but this > >>>>>>> should still be reviewed as a best practice. --> > >>>>>>> > >>>>>>> [jorge] I checked, but couldn’t identify anything to change. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thank you. > >>>>>>> > >>>>>>> RFC Editor > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Feb 10, 2025, at 7:28 PM, rfc-edi...@rfc-editor.org wrote: > >>>>>>> > >>>>>>> *****IMPORTANT***** > >>>>>>> > >>>>>>> Updated 2025/02/10 > >>>>>>> > >>>>>>> RFC Author(s): > >>>>>>> -------------- > >>>>>>> > >>>>>>> Instructions for Completing AUTH48 > >>>>>>> > >>>>>>> Your document has now entered AUTH48. Once it has been reviewed and > >>>>>>> approved by you and all coauthors, it will be published as an RFC. > >>>>>>> If an author is no longer available, there are several remedies > >>>>>>> available as listed in the FAQ > >>>>>>> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Ffaq%2F__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRXEli_vU%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537605235%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=tYmOk6PzDX1M9WpITK3%2BkVc6uWUCoARYDfL5xaIRkV0%3D&reserved=0 > >>>>>>> ). > >>>>>>> > >>>>>>> You and you coauthors are responsible for engaging other parties > >>>>>>> (e.g., Contributors or Working Group) as necessary before providing > >>>>>>> your approval. > >>>>>>> > >>>>>>> Planning your review > >>>>>>> --------------------- > >>>>>>> > >>>>>>> Please review the following aspects of your document: > >>>>>>> > >>>>>>> * RFC Editor questions > >>>>>>> > >>>>>>> Please review and resolve any questions raised by the RFC Editor > >>>>>>> that have been included in the XML file as comments marked as > >>>>>>> follows: > >>>>>>> > >>>>>>> <!-- [rfced] ... --> > >>>>>>> > >>>>>>> These questions will also be sent in a subsequent email. > >>>>>>> > >>>>>>> * Changes submitted by coauthors > >>>>>>> > >>>>>>> Please ensure that you review any changes submitted by your > >>>>>>> coauthors. We assume that if you do not speak up that you > >>>>>>> agree to changes submitted by your coauthors. > >>>>>>> > >>>>>>> * Content > >>>>>>> > >>>>>>> Please review the full content of the document, as this cannot > >>>>>>> change once the RFC is published. Please pay particular attention to: > >>>>>>> - IANA considerations updates (if applicable) > >>>>>>> - contact information > >>>>>>> - references > >>>>>>> > >>>>>>> * Copyright notices and legends > >>>>>>> > >>>>>>> Please review the copyright notice and legends as defined in > >>>>>>> RFC 5378 and the Trust Legal Provisions > >>>>>>> (TLP – > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Ftrustee.ietf.org%2Flicense-info__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRMZaFfHE%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537619123%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Hq6XwMk9rkNzv6GB2Az1Hm3v5rHoAC7Sl4EHAEQMRi0%3D&reserved=0 > >>>>>>> ). > >>>>>>> > >>>>>>> * Semantic markup > >>>>>>> > >>>>>>> Please review the markup in the XML file to ensure that elements of > >>>>>>> content are correctly tagged. For example, ensure that <sourcecode> > >>>>>>> and <artwork> are set correctly. See details at > >>>>>>> <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fauthors.ietf.org%2Frfcxml-vocabulary__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vROfzigsg%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537632341%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=3DegLXcHuoWD1%2FFQQMxE0zXGENmTa9bOYTsJEBiGJik%3D&reserved=0 > >>>>>>> >. > >>>>>>> > >>>>>>> * Formatted output > >>>>>>> > >>>>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>>>> formatted output, as generated from the markup in the XML file, is > >>>>>>> reasonable. Please note that the TXT will have formatting > >>>>>>> limitations compared to the PDF and HTML. > >>>>>>> > >>>>>>> > >>>>>>> Submitting changes > >>>>>>> ------------------ > >>>>>>> > >>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as > >>>>>>> all the parties CCed on this message need to see your changes. The > >>>>>>> parties > >>>>>>> include: > >>>>>>> > >>>>>>> * your coauthors > >>>>>>> > >>>>>>> * rfc-edi...@rfc-editor.org (the RPC team) > >>>>>>> > >>>>>>> * other document participants, depending on the stream (e.g., > >>>>>>> IETF Stream participants are your working group chairs, the > >>>>>>> responsible ADs, and the document shepherd). > >>>>>>> > >>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list > >>>>>>> to preserve AUTH48 conversations; it is not an active discussion > >>>>>>> list: > >>>>>>> > >>>>>>> * More info: > >>>>>>> > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fietf-announce%2Fyb6lpIGh-4Q9l2US__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCXlkn0U%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537646242%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=g3PjtImsMjyC54zbdOTt4RFcVUjsvd%2BmhzrOdYUMzqQ%3D&reserved=0 > >>>>>>> xIAe6P8O4Zc > >>>>>>> > >>>>>>> * The archive itself: > >>>>>>> > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fauth48archive%2F__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR8SD3tkc%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537663336%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=9S%2FqAndF7QF74Ee8E%2BH82phRe24ipE5Jqp9l4jDDl%2Bs%3D&reserved=0 > >>>>>>> > >>>>>>> * Note: If only absolutely necessary, you may temporarily opt out > >>>>>>> of the archiving of messages (e.g., to discuss a sensitive > >>>>>>> matter). > >>>>>>> If needed, please add a note at the top of the message that you > >>>>>>> have dropped the address. When the discussion is concluded, > >>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and > >>>>>>> its addition will be noted at the top of the message. > >>>>>>> > >>>>>>> You may submit your changes in one of two ways: > >>>>>>> > >>>>>>> An update to the provided XML file > >>>>>>> — OR — > >>>>>>> An explicit list of changes in this format > >>>>>>> > >>>>>>> Section # (or indicate Global) > >>>>>>> > >>>>>>> OLD: > >>>>>>> old text > >>>>>>> > >>>>>>> NEW: > >>>>>>> new text > >>>>>>> > >>>>>>> You do not need to reply with both an updated XML file and an > >>>>>>> explicit list of changes, as either form is sufficient. > >>>>>>> > >>>>>>> We will ask a stream manager to review and approve any changes that > >>>>>>> seem beyond editorial in nature, e.g., addition of new text, > >>>>>>> deletion of text, and technical changes. Information about stream > >>>>>>> managers can be found in the FAQ. Editorial changes do not require > >>>>>>> approval from a stream manager. > >>>>>>> > >>>>>>> > >>>>>>> Approving for publication > >>>>>>> -------------------------- > >>>>>>> > >>>>>>> To approve your RFC for publication, please reply to this email > >>>>>>> stating that you approve this RFC for publication. Please use > >>>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to see your > >>>>>>> approval. > >>>>>>> > >>>>>>> > >>>>>>> Files > >>>>>>> ----- > >>>>>>> > >>>>>>> The files are available here: > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.xml__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRFwUxWIg%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537677130%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XxuIM6GNsLE%2FIhcZA4GVj6z1tkPgGHdC7TikZOAAGkQ%3D&reserved=0 > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRpeiSVBE%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537690160%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=63tZzIE1qiX4hhKnTzPJU8u%2BW61fOkp7JeDWQGQE0jg%3D&reserved=0 > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.pdf__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR_d3ClH8%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537703047%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ohkS86QoWQ%2FAbgPWt4%2B5P2CAnJdVZbr140Eo%2BiMKVZk%3D&reserved=0 > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746.txt__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRQeRvL-8%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537715617%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=28PoZKVu4RarC4qokTEnKEZjaETCCVVsUe0num6Fnc8%3D&reserved=0 > >>>>>>> > >>>>>>> Diff file of the text: > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-diff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRNyybZAs%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537728783%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=nlToxROyirujENweWE7v3uTGXgFkogRetFTrnyadONA%3D&reserved=0 > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-rfcdiff.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRxzIodOY%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537741270%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=sh8fb3LHrWmfaR50rJrBsAPahmxGSk4ib1G3LHObYvM%3D&reserved=0 > >>>>>>> (side by > >>>>>>> side) > >>>>>>> > >>>>>>> Diff of the XML: > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauthors%2Frfc9746-xmldiff1.html__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vR9ybFjas%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537755307%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=ng7gPOhWxWZC981KSaC0yFtVqibTchVfdDjx2BZ8KsA%3D&reserved=0 > >>>>>>> > >>>>>>> > >>>>>>> Tracking progress > >>>>>>> ----------------- > >>>>>>> > >>>>>>> The details of the AUTH48 status of your document are here: > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.rfc-editor.org%2Fauth48%2Frfc9746__%3B!!NEt6yMaO-gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM-b8rfBd5vRCx3kJs0%24&data=05%7C02%7Cjorge.rabadan%40nokia.com%7C459db1cc3e5b460543e708dd5a9c3171%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638766349537768384%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=w0fCeWQwLOsPp7ofKhwLN%2BDIyrH1rv9RdfRYw%2Bh2nIY%3D&reserved=0 > >>>>>>> > >>>>>>> Please let us know if you have any questions. > >>>>>>> > >>>>>>> Thank you for your cooperation, > >>>>>>> > >>>>>>> RFC Editor > >>>>>>> > >>>>>>> -------------------------------------- > >>>>>>> RFC 9746 (draft-ietf-bess-evpn-mh-split-horizon-11) > >>>>>>> > >>>>>>> Title : BGP EVPN Multi-Homing Extensions for Split Horizon > >>>>>>> Filtering > >>>>>>> Author(s) : J. Rabadan, K. Nagaraj, W. Lin, A. Sajassi > >>>>>>> WG Chair(s) : Matthew Bocci, Stephane Litkowski, Zhaohui > >>>>>>> (Jeffrey) Zhang > >>>>>>> > >>>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de Velde > >>>> > >>> > >> > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
