Hi, These changes are complete:
https://www.iana.org/assignments/bgp-extended-communities thanks, Amanda Baber IANA Operations Manager On Mon Mar 03 21:37:42 2025, sgin...@staff.rfc-editor.org wrote: > Hi IANA, > > Please make the following updates in the "Border Gateway Protocol > (BGP) Extended Communities” registry. Updates are noted below; they > can also be viewed in <https://www.rfc-editor.org/authors/rfc9746- > rfcdiff.html>. > > A) EVPN ESI Label Extended Community Flags > https://www.iana.org/assignments/bgp-extended-communities/bgp- > extended-communities.xhtml#evpn-esi-label-extended-community-flags > > Old: > 6-7 Split Horizon Type > > New (hyphen): > 6-7 Split-Horizon Type > > > B) Multihoming Redundancy Mode > https://www.iana.org/assignments/bgp-extended-communities/bgp- > extended-communities.xhtml#multihoming-redundancy-mode > > Old: > 00 All-Active mode > 01 Single-Active mode > > New (remove “mode”): > 00 All-Active > 01 Single-Active > > > C) Split Horizon Type > https://www.iana.org/assignments/bgp-extended-communities/bgp- > extended-communities.xhtml#split-horizon-type > > C.1) Old title: > Split Horizon Type > > New (hyphen): > Split-Horizon Type > > > C.2) Old column header: > Split Horizon Type Value > > New (hyphen): > Split-Horizon Type Value > > > C.3) Old value 10: > 10 ESI Label based filtering > > New (hyphen): > 10 ESI Label-based filtering > > > Please let us know if you have any questions. Otherwise, please let > us know when the updates are complete. > > 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-editor@rfc- > > editor.org>, Wen Lin <w...@juniper.net>, bess-...@ietf.org <bess- > > a...@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://urldefense.com/v3/__https://www.rfc- > > editor.org/auth48/rfc9746__;!!NEt6yMaO- > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > b8rfBd5vRCx3kJs0$ >. 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- > > > a...@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://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746.xml__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vRFwUxWIg$ > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746.txt__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vRQeRvL-8$ > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746.pdf__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vR_d3ClH8$ > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746.html__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vRpeiSVBE$ > > > > > > AUTH48 diffs: > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746-auth48diff.html__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vR9rk8n_E$ > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746-auth48rfcdiff.html__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vROUPpKvo$ (side by side) > > > > > > Comprehensive diffs: > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vRNyybZAs$ > > > https://urldefense.com/v3/__https://www.rfc- > > > editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO- > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > b8rfBd5vRxzIodOY$ (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://urldefense.com/v3/__https://www.rfc- > > > > editor.org/auth48/rfc9746__;!!NEt6yMaO- > > > > gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > > b8rfBd5vRCx3kJs0$ >. > > > > > > > > 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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO- > > > >> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >> b8rfBd5vRj2C5yYI$ ] > > > >> > > > >> 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://urldefense.com/v3/__https://www.rfc- > > > >> editor.org/auth48/rfc9746__;!!NEt6yMaO- > > > >> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >> b8rfBd5vRCx3kJs0$ >. 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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vRj2C5yYI$ > > > >>> ] > > > >>> > > > >>> 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://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746.xml__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vRFwUxWIg$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746.txt__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vRQeRvL-8$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746.pdf__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vR_d3ClH8$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746.html__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vRpeiSVBE$ > > > >>> > > > >>> AUTH48 diffs: > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746-auth48diff.html__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vR9rk8n_E$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746-auth48rfcdiff.html__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vROUPpKvo$ (side > > > >>> by side) > > > >>> > > > >>> Comprehensive diffs: > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vRNyybZAs$ > > > >>> https://urldefense.com/v3/__https://www.rfc- > > > >>> editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO- > > > >>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>> b8rfBd5vRxzIodOY$ (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://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/search__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vR7P8vQMA$ . --> > > > >>>> > > > >>>> [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://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/rfc/rfc8126.html*section-6__;Iw!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRz303NOo$ > 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://urldefense.com/v3/__https://eur03.safelinks.protection.outlook.com/?url=https*3A*2F*2Fww__;JSUl!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vR2IYPsDg$ > > > >>>> 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://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRPqqoIkQ$ > > > > >>>> 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://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/faq/__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRXEli_vU$ ). > > > >>>> > > > >>>> 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://urldefense.com/v3/__https://trustee.ietf.org/license- > > > >>>> info__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRMZaFfHE$ ). > > > >>>> > > > >>>> * 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://urldefense.com/v3/__https://authors.ietf.org/rfcxml- > > > >>>> vocabulary__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vROfzigsg$ >. > > > >>>> > > > >>>> * 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://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf- > > > >>>> announce/yb6lpIGh-4Q9l2US__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRCXlkn0U$ > > > >>>> xIAe6P8O4Zc > > > >>>> > > > >>>> * The archive itself: > > > >>>> > > > >>>> https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vR8SD3tkc$ > > > >>>> > > > >>>> * 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://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746.xml__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRFwUxWIg$ > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746.html__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRpeiSVBE$ > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746.pdf__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vR_d3ClH8$ > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746.txt__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRQeRvL-8$ > > > >>>> > > > >>>> Diff file of the text: > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746-diff.html__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRNyybZAs$ > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746-rfcdiff.html__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRxzIodOY$ (side by > > > >>>> side) > > > >>>> > > > >>>> Diff of the XML: > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/authors/rfc9746-xmldiff1.html__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vR9ybFjas$ > > > >>>> > > > >>>> > > > >>>> Tracking progress > > > >>>> ----------------- > > > >>>> > > > >>>> The details of the AUTH48 status of your document are here: > > > >>>> https://urldefense.com/v3/__https://www.rfc- > > > >>>> editor.org/auth48/rfc9746__;!!NEt6yMaO- > > > >>>> gk!ErqyiwcvobhfZGnddynq4nkgc3FEiFen7Wf9AQFlv2wWv11b0vnmwSP7OnDfhEUrx3WCFM- > > > >>>> b8rfBd5vRCx3kJs0$ > > > >>>> > > > >>>> 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
