Hi Megan, Please check inline below for responses.
On Fri, Aug 29, 2025 at 11:58 PM Megan Ferguson < [email protected]> wrote: > Hi Ketan, > > Having another look at the current diff of RFC-to-be 9832, we see the use > of “extended community” when used generally (as you mentioned), but are > uncertain of whether the following fit “general” use: > > Route Target extended community > Transport Class Route Target extended community (later just Transport > Class RT) > “Transport Class” extended community > Color extended community *and* Color Extended Community > Encapsulation extended community > Transitive Extended Community > non-transitive Transport Class extended community > > In RFC-to-be 9830, we see: > Route Target extended community > Color Extended Community > > Some research from past RFCs shows the following forms to be significantly > more frequently used: > > Route Target Extended Community > Color Extended Community > KT> The above two are names of two types of ECs and hence capitalization is appropriate. This would also apply to the Encapsulation & Transport Class Route Target. The "transitive" and "non-transitive" are adjectives and hence don't need capitalization in my view. Encapsulation Extended Community > KT> Refer to https://www.rfc-editor.org/rfc/rfc9012.html#section-4.1 Thanks, Ketan > Transitive Extended Community > > Would you mind reviewing these to ensure these appear as desired with the > conversation with Jeff in mind? > > Thank you. > > Megan Ferguson > RFC Production Center > > On Aug 28, 2025, at 5:16 PM, Megan Ferguson < > [email protected]> wrote: > > Hi Nats and Kaliraj, > > Thank you for your replies and kind words. > > We have recorded your approvals at the AUTH48 status page (see below). > > We will send a separate request to IANA to update the SAFI Values registry > to match Table 1 in the document. Once we confirm the updates have been > made in the IANA registry, we will move this document to AUTH48-DONE*R to > await the completion of AUTH48 of the other documents in C534 (see below). > > The AUTH48 status page for this document can be found here: > https://www.rfc-editor.org/auth48/rfc9832 > > The relevant cluster information can be found here: > https://www.rfc-editor.org/cluster_info.php?cid=C534 > > Thank you. > > Megan Ferguson > RFC Production Center > > On Aug 27, 2025, at 4:03 PM, Natrajan Venkataraman <[email protected]> > wrote: > > Hi Megan, > > I have reviewed the comprehensive diff after internal discussions with > Kaliraj and Reshma. I would like to extend my thanks to you and the AUTH48 > team for suggesting these changes. These changes have improved the > readability of this draft quite extensively with fewer abbreviations and > consistent usage of new definitions that aid the overall flow. > > Very Pleased and Thank You, > Nats. > > > Juniper Business Use Only > > From: Kaliraj Vairavakkalai <[email protected]> > Date: Wednesday, August 27, 2025 at 2:47 PM > To: Megan Ferguson <[email protected]>, Jeffrey Haas < > [email protected]> > Cc: [email protected] <[email protected]>, Natrajan > Venkataraman <[email protected]>, [email protected]<[email protected]>, > [email protected] <[email protected]>, Sue Hares <[email protected]>, > John Scudder <[email protected]>, [email protected]< > [email protected]>, Reshma Das <[email protected]>, > [email protected]< > [email protected]> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > review > > Hi Megan, > > We have adopted this version with only a few slight tweaks (e.g., the > title of Section 6.3 has been changed to use “Multiple Types” to match the > change in paragraph 1 of that section). Please review and let us know if > any further changes are necessary. > > > I am good with the changes. > > Thanks > Kaliraj > > > Juniper Business Use Only > > From: Megan Ferguson <[email protected]> > Date: Wednesday, August 27, 2025 at 9:19 AM > To: Jeffrey Haas <[email protected]> > Cc: Kaliraj Vairavakkalai <[email protected]>, [email protected] > <[email protected]>, Natrajan Venkataraman <[email protected]>, > [email protected] <[email protected]>, [email protected]< > [email protected]>, Sue Hares <[email protected]>, John Scudder < > [email protected]>, [email protected] < > [email protected]>, Reshma Das <[email protected]>, > [email protected] < > [email protected]> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > review > > [External Email. Be cautious of content] > > > Hi Jeff, > > Great question. > > Generally, the RPC strives for consistency (to the extent possible): > 1) within a doc > 2) within a cluster > 3) within the series > > We also (generally) suggest less marking of terms (capping, quoting, > hyphenating, using <tt> tags, etc.) whenever possible as these are > difficult to keep consistent over time and can even be > distracting/confusing to the reader if overused or inconsistently applied. > > Because of previous mixed use in RFCs for the term in question, we went > with the guidance we received from the authors of RFC-to-be 9830 (see the > cluster page herehttps:// > urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OmZiXBOw$ > for a list of those authors). > > If you feel this is in error or are considering using the capped form in > the possible future -bis and are hoping these docs will match up, please > feel free to discuss with the authors of this document (and the related > cluster docs) and let us know if changes are necessary/desired. > > Please let us know if we can be of further assistance on this matter. > > Megan Ferguson > RPC Production Center > > > On Aug 27, 2025, at 6:44 AM, Jeffrey Haas <[email protected]> wrote: > > Megan, > > I had one question while reviewing the changes from the editors. This is > prompted by work in IDR to do a -bis on RFC 4360, for extended communities. > > RFC 4360 is itself not terribly consistent about the use of the > capitalization of the feature. In a significant portion of the document, > it is labeled "Extended Community" when used in a proper noun context. > > In the diff for -ct, it has been consistently lower-cased. > > What's the thinking here, and how much of this is tied specifically to RFC > 4360 itself? > > -- Jeff > > > On Aug 26, 2025, at 7:03 PM, Megan Ferguson < > [email protected]> wrote: > > Hi Kaliraj, > > Thank you for updating the file and your guidance. > > We have adopted this version with only a few slight tweaks (e.g., the > title of Section 6.3 has been changed to use “Multiple Types” to match the > change in paragraph 1 of that section). Please review and let us know if > any further changes are necessary. > > Once we receive approvals of this version from both authors, we will > communicate changes that affect the related IANA registries (i.e., the > change in Table 1) to IANA prior to moving forward in the publication > process. Note that this document will also await the completion of AUTH48 > for the other documents in Cluster C 534 (see below). > > Please be sure to review the files carefully as we do not make changes > once the document is published as an RFC. > > The files have been posted here (please refresh): > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.txt__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1Og1erqnp$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.pdf__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OsHPrJ91$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OmpW_MC0$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OlfxcXC-$ > > The relevant diff files have been posted here (please refresh): > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OiD6pEI8$ > (comprehensive) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-rfcdiff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OiMQMkSR$ > (side by side) > > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-auth48diff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OlbhPs7C$ > (AUTH48 changes only) > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-auth48rfcdiff.html__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OqnflwE8$ > (side by side) > > The AUTH48 status page for this document can be found here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9832__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1Oryt4ZjY$ > > The relevant cluster information can be found here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OmZiXBOw$ > > > Thank you. > > Megan Ferguson > RFC Production Center > > > > > On Aug 22, 2025, at 5:39 PM, Kaliraj Vairavakkalai <kaliraj= > [email protected]> wrote: > > Hi RFC-ed, > > I made another git push with changes to address some pending warnings like > “Artwork too wide”. > > Please git pull, same location: > https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OjkbE0cp$ > > Thanks > Kaliraj > > Juniper Business Use Only > > From: Kaliraj Vairavakkalai <[email protected]> > Date: Friday, August 22, 2025 at 2:04 AM > To: [email protected] <[email protected]>, Natrajan > Venkataraman <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] < > [email protected]>, [email protected]<[email protected]>, John Scudder < > [email protected]>, [email protected]< > [email protected]>, Reshma Das <[email protected]>, > [email protected]< > [email protected]> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > review > > Hi RFC-ed, > > We went thru the comments and incorporated them. Accepted most of them. > > For some of the comments, I have left responses in the xml under the > <rfced> tag, with the prefix KV> > > Please go thru the revised document and let us know. > > Here is the link to the updated xml in github: > > > https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/369e32c114263e81a02fb556f80c765daa8b7927/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OstcI15X$ > > Thanks > Kaliraj > > From: Kaliraj Vairavakkalai <[email protected]> > Date: Wednesday, August 20, 2025 at 1:47 AM > To: [email protected] <[email protected]>, Natrajan > Venkataraman <[email protected]> > Cc: [email protected] <[email protected]>, > [email protected]<[email protected]>, [email protected] < > [email protected]>, [email protected]<[email protected]>, John Scudder < > [email protected]>, [email protected] < > [email protected]>, Reshma Das <[email protected]>, > [email protected] < > [email protected]> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > review > > Hi RFC-Editor, thanks for the update. Cc: coauthors notify alias. > > We’ll go thru the comments and update the xml, as appropriate. > > I added the xml to github ( > https://urldefense.com/v3/__https://github.com/ietf-wg-idr/draft-ietf-idr-bgp-ct/blob/main/rfc9832.xml__;!!NEt6yMaO-gk!CtVxd3F0un2uRDdgew9XF8FOCNDOgGV9P15pxDfv6LpLFikM3w78TPndbWglNX1eu4QpShg_UqHwSJPVJ-v1OjkbE0cp$ > ), before making any updates. > > Thanks > Kaliraj > From: [email protected] <[email protected]> > Date: Tuesday, August 19, 2025 at 7:33 PM > To: Kaliraj Vairavakkalai <[email protected]>, Natrajan Venkataraman < > [email protected]> > Cc: [email protected] <[email protected]>, > [email protected] <[email protected]>, [email protected] < > [email protected]>, [email protected]<[email protected]>, John Scudder < > [email protected]>, [email protected]< > [email protected]> > Subject: Re: AUTH48: RFC-to-be 9832 <draft-ietf-idr-bgp-ct-39> for your > review > > [External Email. Be cautious of content] > > > 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://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.xml__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZoweX5uA$ > ) 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://urldefense.com/v3/__https://www.rfc-editor.org/search__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZupPNXMg$ > . --> > > > 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://urldefense.com/v3/__https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml*non-transitive__;Iw!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZgtmHNek$ > . > > 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*exp_abbrev__;Iw!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZkxxo_JU$ > , 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://urldefense.com/v3/__https://www.rfc-editor.org/cluster_info.php?cid=C534__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlogh6yX$ > ). 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://urldefense.com/v3/__https://www.rfc-editor.org/styleguide/part2/*inclusive_language__;Iw!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZnTZNoS1$ > > > 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://urldefense.com/v3/__https://www.rfc-editor.org/faq/__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZstiK5j7$ > ). > > 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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZt6OaEvX$ > ). > > * 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!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZi1qSbP_$ > >. > > * 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 > > * [email protected] (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). > > * [email protected], 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-4Q9l2USxIAe6P8O4Zc__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZnfk71To$ > > * The archive itself: > > https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/browse/auth48archive/__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZuVpXIoS$ > > * 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, > [email protected] 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/rfc9832.xml__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZoweX5uA$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZjPUtWjU$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.pdf__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZj1i_6IV$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832.txt__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZhDbPuaY$ > > Diff file of the text: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-diff.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlBYxDQS$ > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-rfcdiff.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZrY73q37$ > (side by side) > > Diff of the XML: > > https://urldefense.com/v3/__https://www.rfc-editor.org/authors/rfc9832-xmldiff1.html__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZlTF61c9$ > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > > https://urldefense.com/v3/__https://www.rfc-editor.org/auth48/rfc9832__;!!NEt6yMaO-gk!CpdeuCqI8PCIv68GqufUhvmJWnSWfHLV2v0ivn-CIKGMICfusysvERBe1Zo7vaSSDiF5j7re9Xkxm0QwZu7y6odS$ > > 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 -- [email protected] To unsubscribe send an email to [email protected]
