Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
NOTE: For this document in particular, we request that the authors consider updating the edited XML file (https://www.rfc-editor.org/authors/rfc9832.xml) directly as there are a number of instances in which it may be easier for them to do so than to explain the changes to the RPC (and may save iterations for both sides). 1) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 2) <!--[rfced] We see mention of the "TEAs Network Slices Framework" in the Abstract, may we update as follows to clarify the document you are mentioning? Original: These constructs can be used, for example, to realize the "IETF Network Slice" defined in TEAS Network Slices framework. Perhaps: These constructs can be used, for example, to realize the "IETF Network Slice" defined in the TEAS Network Slices framework (RFC 9543). --> 3) <!--[rfced] In the following text snippets, please review the format of attributes for the following: a) Should all of these names be in all caps (for example, code 25 is in initial caps while code 8 is in all caps)? b) Should they all use "attribute type code", "BGP attribute code", or "attribute code" in their parentheticals? Or are these purposely different? Original: A BGP attribute that carries community. Examples of BGP CCAs are COMMUNITIES (attribute code 8), EXTENDED COMMUNITIES (attribute code 16), IPv6 Address Specific Extended Community (attribute code 25), and LARGE_COMMUNITY (attribute code 32). ... TEA: Tunnel Encapsulation Attribute (attribute type code 23) ... It is carried in BGP extended community attribute (BGP attribute code 16). ... ..., or IPv6-address specific RT (BGP attribute code 25). ... ...UDP tunneling information is carried using the Tunnel Encapsulation Attribute (code 23)... --> 4) <!--[rfced] Please review the use of "color field" in the following text and let us know if it should instead be "Color Value field" to match the use in RFC 9012. (Note that the quotations around field names depend on your response to that related question.) Original: ...with the Flags field set to 0 and the color field set to 100. Perhaps: ...with the "Flags" field set to 0 and the "Color Value" field set to 100. --> 5) <!--[rfced] Regarding figures, artwork, and SVG: a) Please review that all lines in <artwork> are 69 characters or less. If not, please consider how figures may be updated in order to fit this limitation (some warnings of outdenting from xml2rfc exist). b) FYI - the RPC does not edit SVG figures. If any changes are made to their ASCII equivalents, authors should incorporate these changes into the SVG and resubmit these changes to the RPC. --> 6) <!-- [rfced] We had a few questions related to the text below: a) We note that [RFC4360] doesn't appear to use the term "EXT-COMM". Please review the following citation for accuracy. b) Please also review this text for redundancy and let us know if/how this text may be rephrased (we have already removed the EXT-COMM link). Current: The "Transport Class" Route Target Extended Community is a transitive extended community [RFC4360] of extended type, which has the format as shown in Figure 2. --> 7) <!--[rfced] Should the names in the following paragraph (and anywhere they are mentioned throughout the document) be made more uniform (i.e., should Route Target be added to the first use of "extended community")? See a later question related to the quotation use as well. Original: This document also reserves the Non-Transitive version of Transport Class extended community (Section 13.2.1.1.2) for future use. The "Non-Transitive Transport Class" Route Target Extended Community is not used. If received, it is considered equivalent in functionality to the Transitive Transport Class Route Target Extended Community, except for the difference in Transitive bit flag. Perhaps: This document also reserves the Non-Transitive version of the Transport Class Route Target extended community (Section 13.2.1.1.2) for future use. The Non-Transitive Transport Class Route Target extended community is not used. If received, it is considered equivalent in functionality to the Transitive Transport Class Route Target extended community, except for the difference in the Transitive bit flag. --> 8) <!-- [rfced] We note that "color:0:100" isn't used in [RFC9012]. It's defined in this document (See Section 2.1. Definitions and Notations). Please review the citation in the following text for accuracy (or need of a possible rewording). Current: An example of mapping community is "color:0:100", described in [RFC9012], or the "transport-target:0:100" described in Section 4.3 in this document. --> 9) <!--[rfced] If our addition of "exist" does not capture your intent, please review the original text and suggest another rephrase. Original: If more than one distinct Mapping Communities on an overlay route map to distinct Resolution Schemes with dissimilar Intents at a receiving node, it is considered a configuration error. Perhaps: If more than one distinct Mapping Community on an overlay route map to distinct Resolution Schemes with dissimilar Intents at a receiving node exist, it is considered a configuration error. --> 10) <!--[rfced] Because "information" is a noncount noun, it would be unusual to say "multiple information". How may we update? Perhaps "Multiple Types of Encapsulation Information"? Original: 6.3. Carrying multiple Encapsulation Information and ...route allows carrying multiple encapsulation information. --> 11) <!-- [rfced] We note that Section 3 of [RFC8669] uses "Prefix-SID" rather than "Prefix SID". May we update to make these consistent? Current: The SID information for SR with respect to MPLS Data Plane is carried as specified in Prefix SID attribute defined as part of Section 3 of [RFC8669]. --> 12) <!--[rfced] Please review our updates to the text below and confirm that we have interpreted your list correctly (i.e., the BGP CT route is originated with RD:EP in the NLRI along with a Transport Class RT, and the endpoint being a protocol next hop). If this is not the intent, please provide another rephrase. Original: The egress node of the tunnel, i.e. the tunnel endpoint (EP), originates the BGP CT route with RD:EP in the NLRI, Transport Class RT and PNH as EP. Current: The egress node of the tunnel, i.e., the tunnel endpoint (EP), originates the BGP CT route with RD:EP in the NLRI, a Transport Class RT, and a PNH as the EP. --> 13) <!-- [rfced] Please confirm the following citation as [RFC9350] doesn't appear to use the term "ISIS Flex-Algo" (we note that it does contain the term "Flex-Algorithm"). Current: AS2 is further divided into two regions. There are three tunnel domains in provider's space: AS1 uses ISIS Flex-Algo [RFC9350] intra-domain tunnels. AS2 uses RSVP-TE intra-domain tunnels. --> 14) <!--[rfced] Please review the use of a comma in the following situations: a) Between "1" and "128" in the following. We have seen 1/128 in the earlier parts of this document: are these different meanings? This occurs in more than one place. Original: Service nodes PE11, PE12 negotiate service families (AFI: 1 and SAFIs 1, 128) on the BGP session with RR16. b) Throughout Section 8.3 and elsewhere in the document, we replaced many commas with "and" as we believe this was the intended meaning. Please review and let us know any objections. --> 15) <!--[rfced] We note that this document uses TC ID to refer to a Transport Class Identifier in the Terminology section. Please review the use of TC (without ID) in the text below where it seems the expansion is "Transport Class identifier" and let us know if/how to update. Original: ...transport-target:0:<TC> and a RT carrying <eSN>:<TC>, where TC is the Transport Class identifier, and eSN is the IP address used by SN as BGP next hop in its service route advertisements. --> 16) <!--[rfced] We see the following similar sentences in back-to-back paragraphs. Please review and let us know if/how we can reduce redundancy. Original: This is possible using mechanism described in Appendix D, such that advertisement of PE loopback addresses as next-hop in BGP service routes is confined to the region they belong to. An anycast IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts the SNs in a region from other regions in the network. Such that advertisement of PE loopback addresses as next-hop in BGP service routes is confined to the region they belong to. An anycast IP-address called "Context Protocol Nexthop Address" (CPNH) abstracts the SNs in a region from other regions in the network. --> 17) <!--[rfced] We had the following questions related to the IANA Considerations section: a) We would like to make sure we understand the structure of the IANA Considerations section. Currently, we see: 13.1 and 13.2 - seem to add values to existing registries with some duplication to later sections (see question c below) 13.2.1-13.2.1.1.2 - all under a heading of "Existing Registries" 13.2.2 - 13.2.2 All under a heading of "New Registries" 13.3 - Adds two code points to an existing registry Perhaps we could update to something structured along the lines of updates to existing registries and creation of new ones? 13. IANA Considerations 13.1. Existing Registries 13.1.1. New BGP SAFI 13.1.2. New Format for BGP Extended Community 13.1.3. Registries for the "Type" Field 13.1.3.1. Transitive Types 13.1.3.2. Non-Transitive Types 13.1.4. MPLS OAM Code Points 13.2. New Registries 13.2.1. Transitive Transport Class Extended Community Sub-Types Registry 13.2.2. Non-Transitive Transport Class Extended Community Sub-Types Registry With something like the following text in Section 13 itself to introduce the actions: This document registers values in existing registries and creates new registries as described in the following subsections. NOTE: Please review our question c) below before responding. Please let us know if this restructuring would be agreeable. b) Please note that we have updated the capitalization (to lowercase) of the values in Tables 4 and 6 to match the use in the corresponding IANA registries. Please review and let us know any objections. c) Section 13.2 made us expect that 0xa would be registered in both the "BGP Transitive Extended Community Types" registry and the "BGP Non-Transitive Extended Community Types" registry. However, we do not see a registration of 0xa in the "BGP Non-Transitive Extended Community Types" registry at https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#non-transitive. We do see an entry for "0x4a" for "Non-Transitive Transport Class", that is mentioned in the current Section 13.2.1.1.2. Please review this section for accuracy and redundancy with Sections 13.2.1.1.1 and 13.2.1.1.2 and let us know if/how we may update (or if we are just missing something on our end?). d) Section 13.2 says: Taking reference of [RFC7153] , the following assignments have been made: As none of the new entries in the registries list RFC 7153 as a reference themselves, should this text instead read: The registries below each reference RFC 7153. Or is there another way to rephrase? e) FYI - Any updates made to text that appears in IANA registries will be communicated by the RPC to IANA upon the completion of AUTH48. --> 18) <!--[rfced] As Section 14.1 (Transport Class ID) is no longer in the IANA Considerations sections, we have made some updates to help the reader. Please review this section carefully and let us know any concerns. --> 19) <!--[rfced] We note that the reference to draft-kaliraj-bess-bgp-sig-private-mpls-labels-09 has been replaced by draft-kaliraj-bess-bgp-mpls-namespaces. Please review this reference entry / citation and let us know if/how updates should be made.--> 20) <!--[rfced] The citation tag [BGP-CT-UPDATE-PACKING-TEST] is a bit long. Might we update to something shorter?--> 21) <!--[rfced] Please note that we have slightly modified the format of the Contributors section to make it more similar to the use in past RFCs and the guidance of RFC 7322 ("RFC Style Guide"). Please let us know any objections.--> 22) <!--[rfced] We had the following questions/comments related to abbreviation use throughout the document: a) Abbreviations that appeared without expansion have been expanded upon first use following guidance from RFC 7322 ("RFC Style Guide"). Please review these expansions for accuracy. b) We made some updates to the list of abbreviations in the Terminology section to match their use in past RFCs. We also flipped the expansion of TC-BE for a better 1:1 match between the abbreviation and the expansion. Please review carefully and let us know any objections. c) We see BN expanded as "Border Node". Past use in RFCs points to "Boundary Node". Please review and let us know if any updates should be made. d) The term "Labeled ISIS" and the abbreviation "L-ISIS" don't appear in RFC 8867, and RFC 8867 does not appear in the References section of this document. Please review the citation to this RFC in the Terminology section and let us know if/how to update. e) [RFC4684] uses "Route Target (RT) Constrain" rather than "Route Target Constrain (RTC)". We do see "Route Target Constraint (RTC)" in RFC 9125 (when citing RFC 4684). Please let us know if we should adopt the same form here (i.e., Route Target Constraint (RTC)). f) TC is expanded as Traffic Class in the companion documents (RFCs-to-be 9830 and 9831). This document expands it as Transport Class. Please review and let us know if we should make this consistent (see also TC ID and TC-BE). g) To follow the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev, we will update to have the following abbreviations expanded on first use and then use the abbreviated form thereafter unless we hear objection: Transport Class (TC) Route Target (RT) Route Target Constrain (RTC) (see related query above) Community Carrying Attribute (CCA) BGP Classful Transport (BGP CT) Address Family Identifier (AFI) Route Distinguisher (RD) Endpoint (EP) Next Hop (NH) Transport Route Database (TRDB) Ingress Service Node (iSN) Egress Service Node (eSN) Autonomous System (AS) Per-Hop Behavior (PHB) --> 23) <!--[rfced] We had the following questions related to terminology used throughout the document: a) Please note that we updated to use the following forms with relation to capitalization, hyphenation, etc. to match use/guidance in other documents in this cluster (see https://www.rfc-editor.org/cluster_info.php?cid=C534). Please review and let us know any objections: BGP UPDATE message Color Extended Community Route Target extended community data plane Please review the different treatment of "Extended Community" vs. "extended community" and confirm that this difference is intentional. b) Keeping point a) in mind, please review the names of the communities and extended communities throughout the document for consistency. We see varied use of quotation marks, places where words may be missing, differences in capitalization, etc. Examples below: Transport Class Route Target extended community vs. Transport Class extended community vs. "Transport Class" extended community (see also Transport Class Route Target vs. transport-class route-target) Transport Target Extended community transitive extended community vs. Transitive Extended Community Non-Transitive Extended Community vs. "Non-Transitive Transport Class" Route Target extended community vs. Non-Transitive Transport Class Extended community vs. "Non-Transitive Transport Class route target extended community" vs. Non-Transitive Transport Class vs. Non-Transitive version of the Transport Class extended community Mapping Community vs. Mapping community vs. mapping community Community vs. community (when used alone; see also communities) Extended Community vs. extended community (when used alone; see also extended communities) c) The following terminology seems to use inconsistent marking (i.e., capitalization, hyphenation, etc.) throughout the document. Please review these instances and consider if/how they may be made uniform: Resolution Scheme vs. resolution scheme vs. "Resolution Scheme" Route Target vs. route target Ingress domain vs. ingress domain Ingress node vs. ingress node Ingress PE vs. ingress PE (see also egress) Intent vs. intent Inter-AS vs. inter-AS (and Intra-AS vs. intra-AS) Option C vs. option c (and others like option b etc.) BGP Classful Transport vs. Classful Transport Classful Transport BGP route vs. Classful Transport route vs. BGP Classful Transport family routes Classful Transport NLRI vs. Classful Transport NLRI Prefix vs. Classful Transport prefix vs. "Classful Transport" SAFI NLRI Transport Tunnels vs. transport tunnels Transport-target vs. transport-target transport-target:0:100 vs. transport route target 0:200 vs. route target "transport-target:0:100" vs. transport class 100 routes Transport Family vs. Transport family vs. transport family (see also families) Transport class vs. transport class vs. Transport Class "Transport Class ID" field vs. "Transport Class" identifier Transport Class ID 100 vs. Transport Class 100 Color vs. color vs. 'Color' vs. "Color" (FYI 9830 is using Color) color:0:100500 vs. Color:0:100 Transposition scheme vs. transposition scheme vs. Transposition Scheme operator vs. Operator service family vs. Service family service route vs. Service route FLEX-ALGO vs. Flex-Algo vs. FlexAlgo MPLS label vs. MPLS Label Implicit-NULL vs. Implicit Null vs. Implicit NULL special label 3 (Implicit NULL) vs. value 3 (Implicit-NULL) RD:EP vs. "RD:EP" vs. 'RD:Endpoint' vs. "RD:Endpoint" vs. RD,EP vs. "RD, EP" (see also RD, RT) gold vs. Gold bronze vs. Bronze d) Terms including "best effort": we have updated these terms to appear as hyphenated when in attributive position (modifying a noun) but left them open otherwise. However, there is variance related to their quotation, capitalization, etc. remaining. Please review the terms and let us know if/how further updates for uniformity may be made (note: the list below includes our hyphenation changes). best-effort transport class vs. Best-Effort Transport Class "Best-Effort" transport class TRDB vs. Best-Effort TRDB vs. TRDB for best effort "best-effort" transport class routes vs. best-effort transport route 'Best-effort' SLA vs. best-effort SLA "Best-Effort Transport Class Route Target" vs. Best-Effort Transport Class Route Target "Best-Effort" Resolution Scheme vs. Best-effort resolution scheme vs. best-effort resolution scheme e) Please review the following similar instances and let us know if/how they should be made uniform. SAFI 76 (BGP CT) SAFI 76 "Classful Transport" AFI/SAFI 1/76 (Classful Transport SAFI) AFI/SAFI 1/128 (MPLS-labeled VPN address) Inet-VPN SAFI 128 SAFI 128 (L3VPN) f) There are many places in which quotation marks are used that we are uncertain of their meaning/purpose and they are inconsistent (appearing sometimes and not others or single quotes in some places while double or no quotes in others). Please review the use of quotation marks generally throughout the document. We suggest removing quotation marks unless they are absolutely necessary to convey a specific meaning (e.g., directly quoting another work). A few examples below from back-to-back sentences in which quotation seems to be used inconsistently when used with "Transport Class Route Target Extended community". There are many other uses of quotation marks with many other terms to review. Original: These mechanisms are applied to BGP CT routes (AFI/SAFI: 1/76 or 2/76) using "Transport Class Route Target Extended community". vs. A BGP speaker that implements procedures described in this document and Route Target Constrain [RFC4684] MUST also apply the RTC procedures to the Transport Class Route Target Extended communities carried on BGP CT routes (AFI/SAFI: 1/76 or 2/76). and see the mixed use in this paragraph: This document also reserves the Non-Transitive version of Transport Class extended community (Section 13.2.1.1.2) for future use. The "Non-Transitive Transport Class" Route Target Extended Community is not used. If received, it is considered equivalent in functionality to the Transitive Transport Class Route Target Extended Community, except for the difference in Transitive bit flag. g) Other documents in this cluster do not use quotations around field names (and RFC-to-be 9830 chose to skip quotes for field names in AUTH48). As there is mixed use in this document, would you like to update to match this convention? Some examples: "Transport Class ID" field 'Transport Class ID' field Policy Color field Next hop Address field BGP next hop field Local Administrator field MPLS Label field <TC> field "Type" field Value field 'Color' field --> 24) <!--[rfced] Please review uses of the slash "/" character in text and consider whether "and", "or", or "and/or" might be clearer for the reader. --> 25) <!--[rfced] Please note that we have removed the linking of some terms in the document as links are provided in the citations immediately adjacent to the terms. Please let us know any objections. --> 26) <!-- [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. --> Thank you. Megan Ferguson RFC Production Center *****IMPORTANT***** Updated 2025/08/19 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/rfc9832.xml https://www.rfc-editor.org/authors/rfc9832.html https://www.rfc-editor.org/authors/rfc9832.pdf https://www.rfc-editor.org/authors/rfc9832.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9832-diff.html https://www.rfc-editor.org/authors/rfc9832-rfcdiff.html (side by side) Diff of the XML: https://www.rfc-editor.org/authors/rfc9832-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9832 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9832 (draft-ietf-idr-bgp-ct-39) Title : BGP Classful Transport Planes Author(s) : K. Vairavakkalai, Ed., N. Venkataraman, Ed. WG Chair(s) : Susan Hares, Keyur Patel, Jeffrey Haas Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
