Re: [bess] PFN questions in rfc4732bis
Greg Mirsky <gregimirsky@gmail.com> Fri, 22 March 2024 01:07 UTC
Return-Path: <gregimirsky@gmail.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422E4C14F6B2; Thu, 21 Mar 2024 18:07:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_HI=-5, 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 sqTo1aL0L2Sa; Thu, 21 Mar 2024 18:07:16 -0700 (PDT)
Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) (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 1FBD3C14F5FC; Thu, 21 Mar 2024 18:07:16 -0700 (PDT)
Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-609fb0450d8so17416187b3.0; Thu, 21 Mar 2024 18:07:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711069635; x=1711674435; 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=QmXQZuPe5nvufQhlAy1UCsSMZca6P8UY0SXNFU2RnpY=; b=NXMDtSSnPNTiBE0sKRheHBt/O25z0Yz4WO/zF3y0/Gh090AfaRzmOQ0ZNcz6PXX2Lj zgtCVhhGrr1yW06X/7TdAqY3aWPahLLpwJ4gJL6XbqlVhIsjqTQJPlmr95DCjarkVmfB d0TLox+fMaGUJGheubIWr0rdVesPkzU3RFs0gf96RJxmTtgu5dJrIdkUOQ49ZHSQblNu Nor+xd2+86pw8+nmXN8uPqFrBw278Lw0rZtD4KFQBa/MK3uzc4I9PJn6lWTwZt4hcIXf QF3NY1aOTqAyaut6eYzTENlBFvEEj6f0khG4YgUufL796sTfYhGFjF00UHFPL89DYPGC zV+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711069635; x=1711674435; 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=QmXQZuPe5nvufQhlAy1UCsSMZca6P8UY0SXNFU2RnpY=; b=HjQQj7c3Y7Oyu8qsxFd5CEjt0caNdavwhCImiXkCCi0+d/SungSYw5aqzubKd5ySwy 0/I+MJETy3qGWvk+pNH5eM2UcuRCIPQZ53MCTdQJwN6b/kDCVYTkTm5RiWcLRR9x2wbI i0/gnulItnHwjwG5L+GHwjGKTLEQwlm19Bkcpt5eNo89o919fkNyPJnqEhvgStGtRPjT JUs4YqUBk6GxD+wXXWDwoq0e4nQwQmndru75wyUYsNUBmwK7bYQebFvwpdpHeiWOkO0a VTqHidaeLnDRuoW1wCeWzQCfJTo11tndEsab67qbN9G49AR4QNHHlnxsBbEUF9pll/32 1SMA==
X-Forwarded-Encrypted: i=1; AJvYcCWc3o74Qb9aw+s1+82JitOLL/EWo7hVxG+05Vo6MPZyhvz3TyomTBsrudiUp8D7FVcXJcWGQjY1aW/Jat2YQ1nuQ0PEUUE4dleXizkjCVGCrrGMrkpU0tTVJPDL3MrqfzKUyXzIwewEjOLsnOZ5rg4AFlpTv2T4TsRbhm5R7CPCEUlJ0piujLrX+4g8t7A=
X-Gm-Message-State: AOJu0Yz6yYC1U3F+l5oDnRzCsHq4wVyNntnRNpBplLG8W9Tkl2kvYDUC z9RI5h2tdc9hbKlunhJJ+s1BsauFKvLBKcmAMa/CCKcEYVIbHkTg9FaUxK1EPSsSQAzRS0rhbEp TlTbTKiZECR8lOcaVCt5h7MHnIuC5QSHwA5c=
X-Google-Smtp-Source: AGHT+IFh1Gw826NsdVw/2fzRiVwJeT6azMmvmfrrM5hldKjpU6aJdpUo1If77I0FJDlkTSPU/t6ZV6jS2rnYEK6djeI=
X-Received: by 2002:a81:73d7:0:b0:610:3b7a:c17d with SMTP id o206-20020a8173d7000000b006103b7ac17dmr905686ywc.6.1711069635112; Thu, 21 Mar 2024 18:07:15 -0700 (PDT)
MIME-Version: 1.0
References: <CA+RyBmXGC0Yz+UcXKtM5n0WHudpeuh5XvGYJ+WvGB2L6aa--qA@mail.gmail.com> <DS7PR08MB686229D6A591573C55DAB04AF7322@DS7PR08MB6862.namprd08.prod.outlook.com>
In-Reply-To: <DS7PR08MB686229D6A591573C55DAB04AF7322@DS7PR08MB6862.namprd08.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Fri, 22 Mar 2024 11:07:04 +1000
Message-ID: <CA+RyBmVahqefa1bv7EZ5rspLkJkZgaf7aKa0A-zCBa3KVbQZTQ@mail.gmail.com>
To: "Jorge Rabadan (Nokia)" <jorge.rabadan@nokia.com>
Cc: "draft-ietf-bess-rfc7432bis@ietf.org" <draft-ietf-bess-rfc7432bis@ietf.org>, "draft-ietf-mpls-1stnibble@ietf.org" <draft-ietf-mpls-1stnibble@ietf.org>, MPLS Working Group <mpls-chairs@ietf.org>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c97a9506143571e0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/dTSA8odjR-8q1e7KM5x-zAVHEYk>
Subject: Re: [bess] PFN questions in rfc4732bis
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Mar 2024 01:07:20 -0000
Hi Jorge, thank you for your expedient feedback to the proposed updates. I have several follow-up notes logged below under the GIM>> tag. Regards, Greg On Fri, Mar 22, 2024 at 9:30 AM Jorge Rabadan (Nokia) < jorge.rabadan@nokia.com> wrote: > Hi Greg, > > > > Thanks for getting back. > > My comments in line with [jorge]. > > > > Jorge > > > > *From: *Greg Mirsky <gregimirsky@gmail.com> > *Date: *Thursday, March 21, 2024 at 2:41 AM > *To: *draft-ietf-bess-rfc7432bis@ietf.org < > draft-ietf-bess-rfc7432bis@ietf.org>, draft-ietf-mpls-1stnibble@ietf.org < > draft-ietf-mpls-1stnibble@ietf.org>, MPLS Working Group < > mpls-chairs@ietf.org>, bess-chairs@ietf.org <bess-chairs@ietf.org> > *Subject: *PFN questions in rfc4732bis > > > > *CAUTION:* This is an external email. Please be very careful when > clicking links or opening attachments. See the URL nok.it/ext for > additional information. > > > > Dear All, > > following the presentation of our work on the Post-stack First Nibble > (PFN) to the BESS WG at IETF-119, I took an AP to come with questions and > proposals for the authors of rfc4732bis. I thought that once the authors of > the respective drafts converge on the updates, we share them with the BESS > WG. Below, please find my notes: > > · rfc4732bis recognizes MPLS Entropy label as a source of entropy > for load-balancing. 1stnibble draft also refers to RFC 6391 > <https://datatracker.ietf.org/doc/rfc6391/> as another optional source of > the entropy for load-balancing. Would it be helpful adding a refgerence to > RFC 6391 in the discussion of the load-balancing in rfc4732bis? > > [jorge] that should be fine. > > · The definition of the C flag in Section 7.11 is as follows: > > C If set to 1, a control word [RFC4448] MUST be present > > when sending EVPN packets to this PE. It is > > recommended that the control word be included in the > > absence of an entropy label [RFC6790]. > > To reflect the position expressed in the 1stnibble draft, perhaps the > following update is appropriate: > > NEW TEXT: > > C If set to 1, a control word [RFC4448] MUST be present > > when sending EVPN packets to this PE. > > END > > [jorge] I personally see no issue with the above update if the other > co-authors are ok too. > > · Furthermore, the following update may be considered in Section > 7.11.1: > > OLD TEXT: > > * per-ESI-and-EVI attributes P, B are conveyed, and; > > > > * per-EVI attributes MTU, Control Word and Flow Label MUST be zero. > > NEW TEXT: > > * per-ESI-and-EVI attributes P, B are conveyed; > > > > * per-EVI attributes MTU, and Flow Label MUST be zero, and; > > > > * per-EVI attribute Control Word MUST be set. > > [jorge] I don’t think the above change is correct. The reason is this > refers to the L2 attributes extended community sent along with the AD per > EVI routes in EVPN ELAN services (not EVPN VPWS), and this route is purely > used for multi-homing. The non-multihoming related attributes MUST be zero, > since they are signaled along with the inclusive multicast ethernet tag > route. So the current text is correct. > GIM>> I acknowledge that the use of the Control Word in this scenario that I am not familiar with. The motivation for proposing this update is based on my itnerpretation of the definition of the C flag in Section 7.11 (see above) and the intention of the draft-ietf-mpls-1stnibble to deprecate the use of non-PSH encapsulations of non-IP payload. As I understand the current text in question, by setting the Control Word to zero the control plane will produce packets without PSH (PW CW). If that is correct, then that is precisely what our work on the PFN aims to exclude. > > > · The text in Section 18, following the first paragraph, may be > replaced with the following text: > > NEW TEXT: > > In order to avoid frame misordering described in the above paragraph, > > and following conclusions of [I-D.ietf-mpls-1stnibble], the control word > > MUST be used in all use cases. > > END > > [jorge] so basically you are suggesting to use CW always and use MUST as > normative language, irrespective of a) the underlaying transport, b) > whether entropy label is used and c) whether deep packet inspection for > ECMP is used. The only problem that I see is that, till now, > implementations not supporting CW were still compliant with RFC7432 and > this bis draft. Now it would not be the case anymore. > > I personally think it might be better to use a SHOULD, e.g.: > > NEW: > > In order to avoid frame misordering described in the above paragraph, > > the control word SHOULD be used in all use cases > [I-D.ietf-mpls-1stnibble]. > > END > > > > But I’d like to hear from other coauthors and the BESS WG to see if this > is ok. > > Finally, if we were to add [I-D.ietf-mpls-1stnibble] as a reference, it > would be an informative reference. > GIM>> We've used SHOULD in RFC 8469 <https://datatracker.ietf.org/doc/html/rfc8469>, and believe that it is time to deprecate the practice of non-PSH encapsulation of non-IP payload in MPLS altogether, and use PSH/CW in all scenarios for non-IP payload. I'll note that the deprecation, as defined in draft-ietf-mpls-1stnibble, applies only to new deployments and implementations. (I believe that an intellegent implementation that supports non-PSH(non-CW) encapsulation is also capable of using PW CW encapsulation.) > > > Please share you questions, comments, and suggestions. > > > > Regards, > > Greg >
- Re: [bess] PFN questions in rfc4732bis Greg Mirsky
- Re: [bess] PFN questions in rfc4732bis Jorge Rabadan (Nokia)
- Re: [bess] PFN questions in rfc4732bis Greg Mirsky
- Re: [bess] PFN questions in rfc4732bis Menachem Dodge
- Re: [bess] PFN questions in rfc4732bis Menachem Dodge
- Re: [bess] PFN questions in rfc4732bis Luc André Burdet
- Re: [bess] PFN questions in rfc4732bis Jorge Rabadan (Nokia)