Authors, While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
1) <!-- [rfced] Please note that the abbreviated title of the document has been updated as follows. The abbreviated title only appears in the running header in the pdf output. Original: 1st nibble Current: First Nibble Following Label Stack --> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. --> 3) <!-- [rfced] Please clarify "in the context associated". Note that there is a similar sentence in the IANA section. Original: Although some existing network devices may use such a method, it needs to be stressed that the correct interpretation of the Post-stack First Nibble (PFN) in a PSH can be made only in the context associated using the control or management plane with the Label Stack Element (LSE) or group of LSEs in the preceding label stack that characterize the type of the PSH, and that any attempt to rely on the value in any other context is unreliable. Perhaps: Although some existing network devices may use such a method, it needs to be stressed that the correct interpretation of the Post-stack First Nibble (PFN) in a PSH can be made only in the context of using the control or management plane with the Label Stack Entry (LSE) or group of LSEs in the preceding label stack that characterizes the type of the PSH. Any attempt to rely on the value in any other context is unreliable. Or (similar to sentence in IANA section): Although some existing network devices may use such a method, it needs to be stressed that the correct interpretation of the Post-stack First Nibble (PFN) in a PSH can be made only in the context of the Label Stack Entry (LSE) or group of LSEs in the preceding label stack that characterizes the type of the PSH. Any attempt to rely on the value in any other context is unreliable. --> 4) <!-- [rfced] How may we update the text starting with "including..." to improve clarity? Original: * To stress the importance that any MPLS packet not carrying plain IPv4 or IPv6 packets contains a PSH, including any new version of IP (Section 2.4). Perhaps: * To stress that any MPLS packet not carrying plain IPv4 or IPv6 packets contains a PSH. This also applies to packets of any new version of IP (see Section 2.4). --> 5) <!-- [rfced] The sentences below are from the last two paragraphs of Section 1. In the first sentence, will readers understand what is meant by "the heuristic"? Would it be helpful to add more context, like that included in the second sentence? Original: Based on the analysis of load-balancing techniques in Section 2.1.1, this document, in Section 2.1.1.1, introduces a requirement that deprecates the use of the heuristic and recommends using a dedicated label value for load balancing. ... Furthermore, this document updates [RFC4928] by deprecating the heuristic method for identifying the type of packet encapsulated in MPLS. Perhaps: Section 2.1.1 of this document includes an analysis of load-balancing techniques; based on this, Section 2.1.1.1 introduces a requirement that deprecates the use of the heuristic method for identifying the type of packet encapsulated in MPLS and recommends using a dedicated label value for load balancing. ... Furthermore, this document updates [RFC4928] by deprecating this heuristic method. --> 6) <!-- [rfced] Would you like to alphabetize the list of abbreviations in Section 1.3 ("Abbreviations")? Or do you prefer the current order? Similarly, would you like to alphabetize the terms in Section 1.2 ("Definitions") or keep the current order? --> 7) <!-- [rfced] We updated this text as shown below. Specifically, we moved the third sentence of the first paragraph to follow the list and updated "A." to read "Example A:". Let us know any concerns. Original: Figure 1 shows an MPLS packet with Layer 2 header X and a label stack Y ending with Label-n. Then, there are three examples of an MPLS payload displayed in Figure 2. The complete MPLS packet thus would consist of [X Y A], or [X Y B], or [X Y C]. A. The first payload is a bare IP packet, i.e., no PSH. The PFN in this case overlaps with the IP version number. B. The next payload is a bare non-IP packet; again, no PSH. The PFN here is the first nibble of the payload, whatever it happens to be. C. The last example is an MPLS Payload that starts with a PSH followed by the embedded packet. Here, the embedded packet could be IP or non-IP. Updated: Figure 1 shows an MPLS packet with a Layer 2 header X and a label stack Y ending with Label-n. Figure 2 displays three examples of an MPLS payload: Example A: The first payload is a bare IP packet, i.e., no PSH. The PFN in this case overlaps with the IP version number. Example B: The next payload is a bare non-IP packet; again, no PSH. The PFN here is the first nibble of the payload, whatever it happens to be. Example C: This example is an MPLS Payload that starts with a PSH followed by the embedded packet. Here, the embedded packet could be IP or non-IP. Thus, the complete MPLS packet would consist of [X Y A], [X Y B], or [X Y C]. --> 8) <!-- [rfced] For readability, may we update this list as follows? Original: There are four common ways to load balance an MPLS packet: 1. One can use the top label alone. 2. One can do better by using all of the non-SPLs (Special Purpose Labels) [RFC7274] in the stack. 3. One can do even better by "divining" the type of embedded packet, and using fields from the guessed header. The ramifications of using this load-balancing technique are discussed in detail in Section 2.1.1.1. 4. One can do best by using either an Entropy Label [RFC6790] or a Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see Section 2.1.1.1). Perhaps: There are four common ways to load balance an MPLS packet: 1. Use the top label alone. 2. Use all of the non-SPLs (Special Purpose Labels) [RFC7274] in the stack. This is better than using the top label alone. 3. Divine the type of embedded packet and use fields from the guessed header. The ramifications of using this load-balancing technique are discussed in detail in Section 2.1.1.1. This way is better than the two ways above. 4. Use either an Entropy Label [RFC6790] or a Flow-Aware Transport (FAT) Pseudowire Label [RFC6391] (see Section 2.1.1.1). This is the best way. --> 9) <!-- [rfced] Would including some text to introduce the numbered list in Section 2.1.1.1 be helpful? If so, please provide the text. --> 10) <!-- [rfced] Would it be helpful to update "Support for" to "The framework for" in this sentence? Original: Support for MPLS Network Actions (MNAs) is described in [I-D.ietf-mpls-mna-fwk] and is an enhancement to the MPLS architecture. Perhaps: The framework for MPLS Network Actions (MNAs) is described in [RFC9789] and is an enhancement to the MPLS architecture. --> 11) <!-- [rfced] This sentence notes that the PFN value of 0x0 has two different formats, but the IANA registry in Section 3 lists the value 0x0 three times. Please review and let us know if any updates are needed. Original: This issue is described in section 3.6.1 of [I-D.ietf-mpls-mna-fwk] and is further illustrated by the PFN value of 0x0 which has two different formats depending on whether the PSH is a pseudowire control word or a DetNet control word ... --> 12) <!-- [rfced] How may we clarify "leading to [RFC4928]"? Original: It was then discovered that non-IP packets, misidentified as IP when the heuristic failed, were being badly load balanced, leading to [RFC4928]. Perhaps: It was then discovered that non-IP packets, misidentified as IP when the heuristic failed, were being badly load-balanced, leading to the scenario described in [RFC4928]. --> 13) <!-- [rfced] What does "it" refer to here? Original: It would assist with the progress toward a simpler, more coherent system of MPLS data encapsulation if the use a PSH for non-IP payloads encapsulated in MPLS was obsoleted. Perhaps: If the use a PSH for non-IP payloads encapsulated in MPLS were obsoleted, this would assist with the progress toward a simpler, more coherent system of MPLS data encapsulation Or: Obsoleting the use a PSH for non-IP payloads encapsulated in MPLS would assist with the progress toward a simpler, more coherent system of MPLS data encapsulation. --> 14) <!-- [rfced] Please review "to load-balancing MPLS data flows". Should the "load balance" be used instead of the "load-balancing"? Or is the current correct? Original: However, before that can be done, it is important to collect sufficient evidence that there are no marketed or deployed implementations using the heuristic practice to load-balancing MPLS data flows. Perhaps: However, before that can be done, it is important to collect sufficient evidence that there are no marketed or deployed implementations using the heuristic practice to load balance MPLS data flows. --> 15) <!-- [rfced] We removed the expansion "Network Service Header" in Table 1 as this is expanded previously in the document. If no objections, we will ask IANA to update the "Post-Stack First Nibble" registry accordingly prior to publication. Link to registry: https://www.iana.org/assignments/post-stack-first-nibble Original: | NSH | 0x0 | NSH (Network Service Header) | | | Base Header, payload Current: | NSH | 0x0 | NSH Base Header, paylod --> 16) <!-- [rfced] Abbreviations a) FYI - We updated the expansion for LSE as follows to align with the expansion used in RFCs-to-be 9789 and 9791. Also, "Label Stack Element" has not been used in published RFCs. Original: Label Stack Element Updated: Label Stack Entry b) FYI - We have added expansions for the following abbreviations per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Deterministic Networking (DetNet) Virtual Private LAN Service (VPLS) Media Access Control (MAC) --> 17) <!-- [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. RFC Editor/rv On May 13, 2025, at 9:19 PM, rfc-edi...@rfc-editor.org wrote: *****IMPORTANT***** Updated 2025/05/13 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/rfc9790.xml https://www.rfc-editor.org/authors/rfc9790.html https://www.rfc-editor.org/authors/rfc9790.pdf https://www.rfc-editor.org/authors/rfc9790.txt Diff file of the text: https://www.rfc-editor.org/authors/rfc9790-diff.html https://www.rfc-editor.org/authors/rfc9790-rfcdiff.html (side by side) Alt-diff of the text (allows you to more easily view changes where text has been deleted or moved): https://www.rfc-editor.org/authors/rfc9790-alt-diff.html Diff of the XML: https://www.rfc-editor.org/authors/rfc9790-xmldiff1.html Tracking progress ----------------- The details of the AUTH48 status of your document are here: https://www.rfc-editor.org/auth48/rfc9790 Please let us know if you have any questions. Thank you for your cooperation, RFC Editor -------------------------------------- RFC9790 (draft-ietf-mpls-1stnibble-13) Title : IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack Author(s) : K. Kompella, S. Bryant, M. Bocci, G. Mirsky, L. Andersson, J. Dong WG Chair(s) : Tarek Saad, Tony Li, Adrian Farrel 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
