Ballot for draft-ietf-mpls-1stnibble
Yes
No Objection
No Record
Summary: Needs 2 more YES or NO OBJECTION positions to pass.
# Gunter Van de Velde, RTG AD, comments for draft-ietf-mpls-1stnibble-11 # Many thanks for this document. It contains very useful and timely information # I found this document well written and easy to follow. # line numbers are derived with the idnits tool https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-mpls-1stnibble-11.txt # idnits tool seems to complain about pre-RFC5378 work? #DETAILED COMMENTS #================= 96 However, in the data plane, there are scant clues regarding the PSH, GV> I am not native English speaker, and while the word 'scant' is most likely very accurately used here, i wonder if there is a more mainstream English alternate (e.g. 'very few') 151 MPLS packet: one whose Layer 2 header declares the type to be MPLS. 152 For Ethernet, that means the Ethertype is 0x8847 or 0x8848. GV> Would adding other common examples make sense? Ethernet: * 0x8847: Indicates an MPLS unicast packet. * 0x8848: Indicates an MPLS multicast packet. PPP: * 0x0281: MPLS unicast. * 0x0283: MPLS multicast. HDLC: * 0x0281: MPLS unicast. * 0x0283: MPLS multicast. MPLS-over-GRE or MPLS-over-IP (RFC4023) * When MPLS is transported over IP or GRE, the Layer 2 encapsulation does not directly identify MPLS. * Instead: * GRE uses Protocol Type 0x8847 (MPLS unicast) or 0x8848 (MPLS multicast). * IP tunnels do not have Layer 2 MPLS identification, as the MPLS label follows the IP header (IP Protocol Number 137). 188 TC S TTL GV> Could a reference pointer be added to what these properties represent? It is intuitive when familiar with MPLS, but that may not be the situation always. 286 Many other packet types are possible; in principle, any Layer 2 287 embedded packet is permissible. Indeed, in the past, packets of 288 Point-to-Point Protocol, Frame Relay, and Asynchronous Transfer Mode 289 protocols were reasonably common. GV> I wonder if the term "in the past" will age well with this rfc-to-be? 317 is better, but it may still be uneven. If, however, the embedded 318 packet is an IP packet, then the combination of (<source IP address>, 319 <dest IP address>, <transport protocol>, <source port>, and <dest 320 port>) from the IP header of the embedded packet forms an excellent 321 basis for load-balancing. This is what is typically used for load 322 balancing IP packets. GV> In Mobile networks the TEID within the 'divined' GTP-u header may be used too for IP load balancing 365 It is RECOMMENDED that where load-balancing of MPLS packets is 366 desired, the load-balancing mechanism uses the value of a dedicated 367 label, for example, either an Entropy Label [RFC6790] or a FAT 368 Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing 369 the type of the embedded packet, as discussed above, SHOULD NOT be 370 used. GV> is there a reason why the term SPL is not used/mentioned in this section? 458 With a registry, PSHs become easier to parse; not needing means 459 outside the data plane to interpret them correctly; and their 460 semantics and usage are documented. GV> I am not convinced that PSHs become easier to parse, but at least there is less need for a parser to make a guess. 483 2.5. Next Step to More Deterministic Load -balancing in an MPLS Network 484 485 Network evolution is impossible to control, but it develops over a 486 period of time determined by various factors. This document prevents 487 further proliferation of the implementations that could lead to 488 undesired effects affecting data flow. At some time in the future, 489 it was planned to obsolete MPLS encapsulations without PSH of non-IP 490 payload. Before that it is paramount to collect sufficient evidence 491 that there are no marketed or deployed implementations using the 492 heuristic practice to load-balancing MPLS data flows. GV> Here is written "At some time in the future, it was planned to obsolete MPLS encapsulations". I am not sure what this means or if this is formally documented somewhere? Is this a statement that this document can make without a relevant reference? G/
Thank you for writing this document -- I found it an especially easy, interesting and informative writeup... however, like John I'm somewhat confused by Sec 2.5 -- I suspect that there are some words missing around the "At some time in the future, it was planned to obsolete MPLS encapsulations ..." text. Also, much thanks to Adrian Farrel for the clear shepherd's writeup, especially the note about 6 authors. [Edit - I accidentally hit Send too early] Finally much thanks to Qin Wu for the OpsDir review, and to the authors for following up. Much appreciated.
Thanks for this document. I can’t understand section 2.5. It doesn’t appear to be normative or particularly actionable, so I’m not overly concerned by this, but you might want to look at clarifying your meaning. I would suggest a rewrite, if I understood what was intended.
Thank you for the work put into this document. There is indeed an issue with untagged MPLS payload that cannot simply be guessed on the first 4-bit of this MPLS payload. Based on our discussion, I have cleared my DISCUSS ballot: https://mailarchive.ietf.org/arch/msg/mpls/dhDj9y4tkMSNzmOtEHxnWj4DAEg/ The rest of this is only for archive purposes. # COMMENTS (non-blocking) ## IANA registry Documenting existing use of the nibble is useful, but I wonder why there is a need to create a IANA registry. Especially when this registry has no real 'key', i.e., the same code point is shared by multiple RFCs. Should the MPLS RFC be updated to force an update in this registry when defining a new PSH? Else, it is 'just' documenting and the registry will quickly become outdated. ## Title As this I-D includes recommendations for MPLS packets processing, the title should also include this part, e.g., "IANA Registry and Processing Recommendations for the First Nibble Following a Label Stack". ## Abstract s/memo/specification|document/ Unsure whether the text `The memo offers a rationale ... registering new values.` adds a lot of value (as it is implicit when making IANA considerations). Suggest removing it. I find it weird to read `Finally,` followed by two paragraphs... either move this sentence to the end of the abstract or remove 'Finally,'. ## Section 1 What is meant by "we" in `we mean existing artifacts`? The authors ? the WG ? The IETF ? Suggest rephrasing (e.g., using the passive voice). ## Section 1.2 Figure 2 explanations should really include the fact the PFN is also an integral part of the IP/non-IP packet. s/IP packet/IP header/ in figure 2, same for non-IP packet ## Section 1.3 AFAIK, there are still discussions about MNA, i.e., should MNA be part of this I-D ? This is of course related to my DISCUSS point above. ## Section 2.1.1 Unsure whether s/Load Balancing/ECMP Load Balancing/ would be better... ## Section 2.1.1.1 Is would be easier for the reader to s/However, this heuristic can work very badly for Figure 2, B/However, this heuristic can work very badly for non-IP packet/ ## Section 2.2 It is really unclear (to me at least) whether the first NEW TEXT actually replaces the OLD text, i.e., suggest moving the paragraph between OLD TEXT and NEW TEXT *before* the OLD TEXT. s/all cases when the MPLS payload is not an IP packet/all cases when the MPLS payload is neither an IPv6 not an IPv4 packet/ (in case another IP version happens in decades). s/This means that older implementations and deployments can continue to use that heuristic, while it must not be part of new implementations or deployments./This heuristic MUST NOT be part of new implementations or deployments./ Old implementations are not a concer of this PS except for deployment/security/operational considerations. ## Section 2.4 Some justifications are probably required for `There is *no need* to track future IP version number allocations in the Post-stack First Nibble registry.` ## Section 3.1 Should this IANA section provide some guidance on whether overloading a PFN by another protocol is allowed ? Are 0x4 and 0x6 really 'reserved' ? Should they rather be assigned to IPv4 and IPv6 ? Else, it looks like MPLS payload having those value are not valid. # NITS (non-blocking / cosmetic) ## ASCII art vs. SVG Suggest the use of the aasvg tool for nicer graphics in HTML / PDF rendering in 2024.