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://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-...@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
