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://www.rfc-editor.org/authors/rfc9746.xml https://www.rfc-editor.org/authors/rfc9746.txt https://www.rfc-editor.org/authors/rfc9746.pdf https://www.rfc-editor.org/authors/rfc9746.html AUTH48 diffs: https://www.rfc-editor.org/authors/rfc9746-auth48diff.html https://www.rfc-editor.org/authors/rfc9746-auth48rfcdiff.html (side by side) Comprehensive diffs: https://www.rfc-editor.org/authors/rfc9746-diff.html https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (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://www.rfc-editor.org/search. --> > > [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://www.rfc-editor.org/rfc/rfc8126.html#section-6> 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%2Fwww.iana.org%2Fassignments%2Fbgp-extended-communities%2Fbgp-extended-communities.xhtml%23multihoming-redundancy-mode&data=05%7C02%7Cjorge.rabadan%40nokia.com%7Cf542c1ebba244091920f08dd4a4cd54a%7C5d4717519675428d917b70f44f9630b0%7C0%7C0%7C638748418004860420%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=GyQb77Pn3%2BYQkbog08ArVDY9Jsd7b3sH%2B%2F%2F0BQw%2BiJU%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://www.rfc-editor.org/styleguide/part2/#inclusive_language> 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://www.rfc-editor.org/faq/). > > 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://trustee.ietf.org/license-info). > > * 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://authors.ietf.org/rfcxml-vocabulary>. > > * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * 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://www.rfc-editor.org/authors/rfc9746.xml > https://www.rfc-editor.org/authors/rfc9746.html > https://www.rfc-editor.org/authors/rfc9746.pdf > https://www.rfc-editor.org/authors/rfc9746.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9746-diff.html > https://www.rfc-editor.org/authors/rfc9746-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9746-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9746 > > 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
