Re: [mpls] Rtgdir early review of draft-ietf-mpls-1stnibble-02
Greg Mirsky <gregimirsky@gmail.com> Mon, 08 January 2024 17:26 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B739C15198D; Mon, 8 Jan 2024 09:26:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i59Pi5Z3HG7E; Mon, 8 Jan 2024 09:26:52 -0800 (PST)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A09F1C1519AF; Mon, 8 Jan 2024 09:26:45 -0800 (PST)
Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-dbdd013c68bso1163601276.2; Mon, 08 Jan 2024 09:26:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704734804; x=1705339604; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=RGrkoGvdnAIhY0H2ODHyjuk84qMXEkJZh9bmNoUiBAE=; b=QZwcFFaojQy2COqc0/vGuyXc2WXuVMPdccipsAUHMqE4NEvTGWcSGn6ympLrA/tIQ0 MMWc1EAw+uVmAuYoutzufO3xh2jeKgP1L7c3jkmFAvugnHBfuOkW+/f5GCeLC9B/McTG GJiNDryvyiPYNOz3Gh7Txve7L+KHdmjDdVF89RMHVz7osdGP561uOH+5tsFDmd1CbUo3 VFd4zD7JhryaIW2KU4u2hXhdw2JZHf1PzPYANUSteVGAtRcNaSCGT1pchdYeK+KMSSJ5 hjWPCRcfuUNzV4lWdlVmLeZ/B3ZKRXJ4JnoFT1RVMB2zE2O9R/USyVqSSQeqBZAcdxJ8 AYtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704734804; x=1705339604; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RGrkoGvdnAIhY0H2ODHyjuk84qMXEkJZh9bmNoUiBAE=; b=uo7Y8OJ3HLIClsnqIvQygOw0RAh6hnUpxgkovlizJrq+D/JKfoMxekGMaLKydRMZA9 A8sygKxTgQzzXG8/SQU0UMZmmjFNhkLlf79EVl835vfr4DkLFI/joczDX2TCJ5WiA+jC iTbAckvDD4ESboA/d9tCirAwkCASqGJwXTxYWB7l5MKfiiUaEAS/c9UJ6f4BeExpERZy /dBY0JObqfHWkAe26ffdhg7V2ADLgpLrLZOp7GcDS+/tQXEt/e5JfnlNbskH053Pjz/P o+VlNb+53QaVG/QCN0yt9RWxrVQ+uc7deDSjvr/lY5t0LeVrNNGKJNvcermTiFg3JMsc htdA==
X-Gm-Message-State: AOJu0Yz7UfSmj2NSEkxC2qqcBwJTq2htIEXZyAEo//hzs5s/Vquj1w5w 1zVFbl6govrbvmfJyCMmjnfI5Hu/qd00CJBiMxqZqu5zAUM=
X-Google-Smtp-Source: AGHT+IElrE9gNsslcy0CDIRw2pXGAmgai6+4Oibzw0ICOOKfpN0/oN4j9OCDshE9VbgBWNlcdEjX9nLc6mnfmXq55no=
X-Received: by 2002:a25:5f11:0:b0:dbd:b588:19e6 with SMTP id t17-20020a255f11000000b00dbdb58819e6mr1555577ybb.48.1704734804421; Mon, 08 Jan 2024 09:26:44 -0800 (PST)
MIME-Version: 1.0
References: <170369144851.49481.2327031942912557302@ietfa.amsl.com> <CA+RyBmWwnqu1TKJ6A98PQ2cnyJ7pbk72PX9Xh8HmLiMp7-mr7Q@mail.gmail.com> <3f257b80-072f-4a6b-a7de-d2ffee15809b@joelhalpern.com>
In-Reply-To: <3f257b80-072f-4a6b-a7de-d2ffee15809b@joelhalpern.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 08 Jan 2024 09:26:34 -0800
Message-ID: <CA+RyBmXBG+GspJLYds3i3o33M2h-jgVAOSthMK=tN9H=2Gm8-g@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: Routing Directorate <rtg-dir@ietf.org>, draft-ietf-mpls-1stnibble.all@ietf.org, mpls <mpls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000742f78060e7280ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/PIz_iqtigCEQ1jRBOciAnzL_1fo>
Subject: Re: [mpls] Rtgdir early review of draft-ietf-mpls-1stnibble-02
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jan 2024 17:26:53 -0000
Hi Joel, thank you for your expedient response. Would the following text address your concern: Embedded Packet: All octets beyond the PSH (if any). That could be an IPv4 or IPv6 packet , an Ethernet packet (for VPLS ([RFC4761], [RFC4762]) or EVPN [RFC7432]), or some other type of Layer 2 frame [RFC4446]. Regards, Greg On Sun, Jan 7, 2024 at 7:35 PM Joel Halpern <jmh@joelhalpern.com> wrote: > With regard to the parenthetical in the embedded backet definition, I > would suggest removing it. The examples do not seem to add value. This > document is not about why one carries things in MPLS. > > The other changes seem appropriate and reasonable. Thank you. > > Yours, > > Joel > On 1/7/2024 9:36 PM, Greg Mirsky wrote: > > Hi Joel, > thank you for your thoughtful comments. Please find my notes below tagged > by GIM>>. > > Regards, > Greg > > On Wed, Dec 27, 2023 at 7:37 AM Joel Halpern via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Joel Halpern >> Review result: Not Ready >> >> Hello, >> >> I have been selected as the Routing Directorate reviewer for this draft. >> The >> Routing Directorate seeks to review all routing or routing-related drafts >> as >> they pass through IETF last call and IESG review, and sometimes on special >> request. The purpose of the review is to provide assistance to the >> Routing ADs. >> For more information about the Routing Directorate, please see >> https://wiki.ietf.org/en/group/rtg/RtgDir >> >> This is a requested early Routing Directorate review, and as such is >> intended >> to help the Working Group and Document Editors with the subject document. >> >> Document: draft-ietf-mpls-1stnibble-02 >> Reviewer: Joel Halpern >> Review Date: 27-Dec-2023 >> IETF LC End Date: N/A >> Intended Status: Proposed Standard >> >> Summary: >> I have some minor concerns about this document that I think should be >> resolved. >> >> Major: >> >> Minor: >> The parantheticl about IP packets in the "embedded packet" definition >> is >> worded to imply that one would only put IP into MPLS for traffic >> engineering >> or VPN purposes. This seems misleading to me, and I strongly suggest >> removing the parenthetical. >> > GIM>> Our intention was to use two as examples, not to imply that the text > in parentheses presents an exhaustive list: > Embedded Packet: All octets beyond the PSH (if any). That could be > an IPv4 or IPv6 packet (e.g., for traffic engineering of IP > packets, or for a Layer 3 VPN [RFC4364]), an Ethernet packet (for > VPLS ([RFC4761], [RFC4762]) or EVPN [RFC7432]), or some other type > of Layer 2 frame [RFC4446]. > Would s/e.g./for example/ make that clearer? > >> >> Bullet 3 in section 2.1.1 on Load Balancing asserts that guessing the >> content type is always better than not doing so for load balancing >> purposes. If one guesses wrong, that may well not be true. I would >> suggest adding to the bullet a forward reference to the text below to >> caveat "even better". >> > GIM>> Thank you for the suggestion. Extended it as follows: > 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.3. > >> >> Section 2.1.3 is titled "recommendation" and starts with a "SHOULD", >> but >> then has a "MUST NOT" which does not seem to be qualified by the >> "SHOULD" >> It is unclear whether this is a flat requirement (belonging in the >> previous section) or is intended for when the "SHOULD" is being >> obeyed. >> > GIM>> To address your concern, the following update is proposed: > OLD TEXT: > It is RECOMMENDED that where load-balancing of MPLS packets is > desired, either an Entropy Label or a FAT Pseudowire Label SHOULD be > used; furthermore, the heuristic in Section 2.1.1.1 MUST NOT be used. > NEW TEXT: > It is RECOMMENDED that where load-balancing of MPLS packets is > desired, the load-balancing mechanism uses the value of a dedicated > label, for example, either an Entropy Label [RFC6790] or a FAT > Pseudowire Label [RFC6391]. Furthermore, the heuristic of guessing > the type of the embedded packet (Section 2.1.1.1) SHOULD NOT be used. > I hope that the update is acceptable. > >> >> Nits: >> The reference in the introduction to the MPLS Open Design team should >> be >> edited to refer to the MPLS Working group, since there is no longer >> an MPLS >> Open Design Team. >> > GIM>> Thank you. Done. > >> >> Should "LSE" be expanded on first use? (And included in the list of >> abbreviations?) >> > GIM>> Added Abbreviations as a new sub-section with LSE in it. > >> >> The paragraph at the end of the introduction needs to be resolved. I >> would >> suggest removing it. As far as I can tell, the WG has evinced little >> desire to make the change described there. >> > GIM>> Agreed and removed the last paragraph. > >> >> Paragraph 2 of section 2.1.3 on "recommendation" referes to >> "recommendation >> 2". But the recommendations (and requirements) are not numbered. So >> what >> is the referent? >> > GIM>> Ineed confusing. Would the following rewording make it clearer? > OLD TEXT: > A consequence of Recommendation 2 is that, while legacy routers may > NEW TEXT: > A consequence of the latter recommendation is that, while legacy > >> >> From I-D Nits >> >> ** The document seems to lack a Security Considerations section. >> > GIM>> Added Security Consideration section as follows: > NEW TEXT: > 4. Security Considerations > > This document proposes a new IANA registry and does not raise any > security concerns or issues in addition to ones common to networking > and those specific to MPLS networks. > >> >> ** The abstract seems to contain references ([RFC4928]), which it >> shouldn't. Please replace those with straight textual mentions of >> the >> documents in question. >> > GIM>> Done > >> >> == The 'Updates: ' line in the draft header should list only the >> _numbers_ >> of the RFCs which will be updated by this document (if approved); it >> should not include the word 'RFC' in the list. >> > GIM>> Thank you for pointing that out. Done. > >
- [mpls] Rtgdir early review of draft-ietf-mpls-1st… Joel Halpern via Datatracker
- Re: [mpls] Rtgdir early review of draft-ietf-mpls… Adrian Farrel
- Re: [mpls] Rtgdir early review of draft-ietf-mpls… Greg Mirsky
- Re: [mpls] Rtgdir early review of draft-ietf-mpls… Greg Mirsky
- Re: [mpls] Rtgdir early review of draft-ietf-mpls… Joel Halpern
- Re: [mpls] Rtgdir early review of draft-ietf-mpls… Greg Mirsky
- Re: [mpls] Rtgdir early review of draft-ietf-mpls… Joel Halpern