From nobody Thu Apr 9 07:28:40 2020 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981673A07D3 for ; Thu, 9 Apr 2020 07:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6tnfIxOA4F7 for ; Thu, 9 Apr 2020 07:28:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A2DE3A07B5 for ; Thu, 9 Apr 2020 07:28:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9F3CEF4070B; Thu, 9 Apr 2020 07:28:17 -0700 (PDT) To: stewart.bryant@gmail.com, agmalis@gmail.com, ibagdona.ietf@gmail.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, agmalis@gmail.com, stewart.bryant@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mdolegow@cisco.com, pals@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200409142817.9F3CEF4070B@rfc-editor.org> Date: Thu, 9 Apr 2020 07:28:17 -0700 (PDT) Archived-At: Subject: [Pals] [Technical Errata Reported] RFC8469 (6082) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 14:28:38 -0000 The following errata report has been submitted for RFC8469, "Recommendation to Use the Ethernet Control Word". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6082 -------------------------------------- Type: Technical Reported by: Michal Dolegowski Section: 3 Original Text ------------- Thus, if the source MAC address of an Ethernet frame carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. Corrected Text -------------- Thus, if the destination MAC address of an Ethernet frame carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. Notes ----- The first nibble of an Ethernet frame is the first nibble of the destination MAC address, not the source MAC address. The erroneous packet reordering occurs for traffic traveling toward the device with the 0x4... or 0x6... MAC address Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8469 (draft-ietf-pals-ethernet-cw-07) -------------------------------------- Title : Recommendation to Use the Ethernet Control Word Publication Date : November 2018 Author(s) : S. Bryant, A. Malis, I. Bagdonas Category : PROPOSED STANDARD Source : Pseudowire And LDP-enabled Services Area : Routing Stream : IETF Verifying Party : IESG From nobody Thu Apr 9 08:24:14 2020 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDCA33A09C4 for ; Thu, 9 Apr 2020 08:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3dwP16tFKIAY for ; Thu, 9 Apr 2020 08:24:11 -0700 (PDT) Received: from layerfree.net (heronab2.miniserver.com [89.200.138.104]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F5F3A09BB for ; Thu, 9 Apr 2020 08:24:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)); envelope-from=173.38.220.38; Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Giles Heron In-Reply-To: <20200409142817.9F3CEF4070B@rfc-editor.org> Date: Thu, 9 Apr 2020 16:24:05 +0100 Cc: Stewart Bryant , agmalis@gmail.com, ibagdona.ietf@gmail.com, db3546@att.com, aretana.ietf@gmail.com, martin.vigoureux@nokia.com, mdolegow@cisco.com, pals@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <266FFF4C-2FD3-4103-902C-1A6C24E72058@layerfree.net> References: <20200409142817.9F3CEF4070B@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-IP-stats: Incoming Last 0, First 0, in=3, out=0, spam=0 ip=HiddenIP Archived-At: Subject: Re: [Pals] [Technical Errata Reported] RFC8469 (6082) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 15:24:13 -0000 Yes - I think that's correct. And I must confess the source of the issue is probably section 4.6 of = RFC4448 so this one is probably my fault rather than that of the RFC8469 = authors (or maybe I should just blame Luca!) Giles > On 9 Apr 2020, at 15:28, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC8469, > "Recommendation to Use the Ethernet Control Word". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6082 >=20 > -------------------------------------- > Type: Technical > Reported by: Michal Dolegowski >=20 > Section: 3 >=20 > Original Text > ------------- > Thus, if the source MAC address of an Ethernet frame carried over > the PW without a control word present begins with 0x4 or 0x6, it > could be mistaken for an IPv4 or IPv6 packet. This could, > depending on the configuration and topology of the MPLS network, > lead to a situation where all packets for a given PW do not follow > the same path. >=20 > Corrected Text > -------------- > Thus, if the destination MAC address of an Ethernet frame carried over > the PW without a control word present begins with 0x4 or 0x6, it > could be mistaken for an IPv4 or IPv6 packet. This could, > depending on the configuration and topology of the MPLS network, > lead to a situation where all packets for a given PW do not follow > the same path. >=20 > Notes > ----- > The first nibble of an Ethernet frame is the first nibble of the = destination MAC address, not the source MAC address. The erroneous = packet reordering occurs for traffic traveling toward the device with = the 0x4... or 0x6... MAC address >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party =20 > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC8469 (draft-ietf-pals-ethernet-cw-07) > -------------------------------------- > Title : Recommendation to Use the Ethernet Control Word > Publication Date : November 2018 > Author(s) : S. Bryant, A. Malis, I. Bagdonas > Category : PROPOSED STANDARD > Source : Pseudowire And LDP-enabled Services > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 > _______________________________________________ > Pals mailing list > Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals From nobody Thu Apr 9 14:50:52 2020 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51BEA3A0FC3 for ; Thu, 9 Apr 2020 14:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI104Rrkplj4 for ; Thu, 9 Apr 2020 14:50:46 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 552C83A0F93 for ; Thu, 9 Apr 2020 14:50:41 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id y3so342150qky.8 for ; Thu, 09 Apr 2020 14:50:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Dl1Vhn9eoGH6ub9LjZuXF0OegPZjJZP5mfIHaM48KGE=; b=VvbHtq8TtmtpYDRtEiR1DVSFicXPZ0NOWPsqRppSd0h8glS+Du5hopSpN2d5jv8O6h KPLm9OJuKrJJjwr2RXsh6HlV9K3qteWSOKMfF++i1ADEnJ+qpsYRvFG2Vdrweve9fFMa afPP9lOxcbr7KraSDbhlxx8gHBu5177/GTeJjo4nj+xju8fkTgsnV1ZbmYapqvS2hF8I HVu6sXX531JemT28J32cAXJS4kqhATHZ/YJFIT9jk/kOxFTZ57RXsZHHZgUmi3puvUIM PthNAsRvKt9O7Z4xZqRKT3lYryqS6oGdudI7lSm/OXwpo/cwYncUeq/0lupiF7pPiJl1 g/3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Dl1Vhn9eoGH6ub9LjZuXF0OegPZjJZP5mfIHaM48KGE=; b=tHaZyqsMT5prkr7wIgV0WoQOoCpcD2hWbv94oDwSQuchtewtTeqYI6VSHX9of16b6F vumXkrTi4ECtPLFDuaCEq03AzQmKX1ATisDctB2XmRSPYTcQpsDtYEPkZ72JlRVfCBE5 epXmboUR/7ye0CLoqsiHWRR0usTMtbebkKT1Z7zh/w30fyE6MGthSQTYMs+dBvPt6XOe qzBHKeNVV8e/yopn33AZcoNBFuHH9nze2zNxiludTtNvibdJRiZcEvRa+lblCrAlDXST xbfl1NGoDVCJPzf+XWurcyIUf1icguW9V4R1jWfvSfkB3bRXPH6z7p3xO9I1Bwr+ufyX 6VAw== X-Gm-Message-State: AGi0PuYgGFtb/xhUxRBbY0wdPtuaAMUvU8Nh1jdsZLo1XwAE8pT270md vO3DxGCsZEYI2XGJ1o5GtR03Jc5Ka2G1MM1Dj6A= X-Google-Smtp-Source: APiQypIZtYmy7pFNb7aowSswQAfptRubRYNandhtl01uNrOXre8CsA5ysaI+7Ds6vzgkAYus+3Pu3hYIQLPB0jsF8zo= X-Received: by 2002:a37:62d7:: with SMTP id w206mr987490qkb.406.1586469040263; Thu, 09 Apr 2020 14:50:40 -0700 (PDT) MIME-Version: 1.0 References: <20200409142817.9F3CEF4070B@rfc-editor.org> <266FFF4C-2FD3-4103-902C-1A6C24E72058@layerfree.net> In-Reply-To: <266FFF4C-2FD3-4103-902C-1A6C24E72058@layerfree.net> From: "Andrew G. Malis" Date: Thu, 9 Apr 2020 17:50:29 -0400 Message-ID: To: Giles Heron Cc: RFC Errata System , Stewart Bryant , Ignas Bagdonas , "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , Martin Vigoureux , "Michal Dolegowski (mdolegow)" , pals@ietf.org Content-Type: multipart/alternative; boundary="0000000000009795e505a2e29b86" Archived-At: Subject: Re: [Pals] [Technical Errata Reported] RFC8469 (6082) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2020 21:50:52 -0000 --0000000000009795e505a2e29b86 Content-Type: text/plain; charset="UTF-8" Giles, Thanks, I've confirmed this as well. And many thanks for taking the blame! :-) Since it doesn't affect the recommendations in the RFC, my advice to Deborah is to mark this "Hold for document update". Stay healthy, Andy On Thu, Apr 9, 2020 at 11:24 AM Giles Heron wrote: > Yes - I think that's correct. > > And I must confess the source of the issue is probably section 4.6 of > RFC4448 so this one is probably my fault rather than that of the RFC8469 > authors (or maybe I should just blame Luca!) > > Giles > > > On 9 Apr 2020, at 15:28, RFC Errata System > wrote: > > > > The following errata report has been submitted for RFC8469, > > "Recommendation to Use the Ethernet Control Word". > > > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6082 > > > > -------------------------------------- > > Type: Technical > > Reported by: Michal Dolegowski > > > > Section: 3 > > > > Original Text > > ------------- > > Thus, if the source MAC address of an Ethernet frame carried over > > the PW without a control word present begins with 0x4 or 0x6, it > > could be mistaken for an IPv4 or IPv6 packet. This could, > > depending on the configuration and topology of the MPLS network, > > lead to a situation where all packets for a given PW do not follow > > the same path. > > > > Corrected Text > > -------------- > > Thus, if the destination MAC address of an Ethernet frame carried over > > the PW without a control word present begins with 0x4 or 0x6, it > > could be mistaken for an IPv4 or IPv6 packet. This could, > > depending on the configuration and topology of the MPLS network, > > lead to a situation where all packets for a given PW do not follow > > the same path. > > > > Notes > > ----- > > The first nibble of an Ethernet frame is the first nibble of the > destination MAC address, not the source MAC address. The erroneous packet > reordering occurs for traffic traveling toward the device with the 0x4... > or 0x6... MAC address > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC8469 (draft-ietf-pals-ethernet-cw-07) > > -------------------------------------- > > Title : Recommendation to Use the Ethernet Control Word > > Publication Date : November 2018 > > Author(s) : S. Bryant, A. Malis, I. Bagdonas > > Category : PROPOSED STANDARD > > Source : Pseudowire And LDP-enabled Services > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > > --0000000000009795e505a2e29b86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Giles,

Thanks, I've confirmed this = as well. And many thanks for taking the blame! :-)

Since it doesn't affect the recommendations in the RFC, my advice=C2= =A0to Deborah is to mark this "Hold for document update".

Stay healthy,
Andy

On Thu, = Apr 9, 2020 at 11:24 AM Giles Heron <giles@layerfree.net> wrote:
Yes - I think that's correct.

And I must confess the source of the issue is probably section 4.6 of RFC44= 48 so this one is probably my fault rather than that of the RFC8469 authors= (or maybe I should just blame Luca!)

Giles

> On 9 Apr 2020, at 15:28, RFC Errata System <rfc-editor@rfc-editor.org> w= rote:
>
> The following errata report has been submitted for RFC8469,
> "Recommendation to Use the Ethernet Control Word".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6082
>
> --------------------------------------
> Type: Technical
> Reported by: Michal Dolegowski <mdolegow@cisco.com>
>
> Section: 3
>
> Original Text
> -------------
> Thus, if the source MAC address of an Ethernet frame carried over
> the PW without a control word present begins with 0x4 or 0x6, it
> could be mistaken for an IPv4 or IPv6 packet.=C2=A0 This could,
> depending on the configuration and topology of the MPLS network,
> lead to a situation where all packets for a given PW do not follow
> the same path.
>
> Corrected Text
> --------------
> Thus, if the destination MAC address of an Ethernet frame carried over=
> the PW without a control word present begins with 0x4 or 0x6, it
> could be mistaken for an IPv4 or IPv6 packet.=C2=A0 This could,
> depending on the configuration and topology of the MPLS network,
> lead to a situation where all packets for a given PW do not follow
> the same path.
>
> Notes
> -----
> The first nibble of an Ethernet frame is the first nibble of the desti= nation MAC address, not the source MAC address.=C2=A0 The erroneous packet = reordering occurs for traffic traveling toward the device with the 0x4... o= r 0x6... MAC address
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please
> use "Reply All" to discuss whether it should be verified or<= br> > rejected. When a decision is reached, the verifying party=C2=A0
> can log in to change the status and edit the report, if necessary. >
> --------------------------------------
> RFC8469 (draft-ietf-pals-ethernet-cw-07)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Recommen= dation to Use the Ethernet Control Word
> Publication Date=C2=A0 =C2=A0 : November 2018
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: S. Bryant, A. Mali= s, I. Bagdonas
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD<= br> > Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Pseudowire An= d LDP-enabled Services
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Routing<= br> > Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>
> _______________________________________________
> Pals mailing list
> Pals@ietf.org > https://www.ietf.org/mailman/listinfo/pals

--0000000000009795e505a2e29b86-- From nobody Fri Apr 10 10:27:23 2020 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002973A0A56 for ; Fri, 10 Apr 2020 10:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWCZarMIUQ_C for ; Fri, 10 Apr 2020 10:27:16 -0700 (PDT) Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267253A0A55 for ; Fri, 10 Apr 2020 10:27:16 -0700 (PDT) Received: by mail-wr1-x432.google.com with SMTP id g3so3035832wrx.2 for ; Fri, 10 Apr 2020 10:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=60IyksJOGmIXG9CSLTK5PiohKuRr1M6QJw5YrGjdyJU=; b=nxGh6laRBl582/Q9ITap39EbH0kbSQCyNkIXFnUDyHChfqHOOeeReGymJmeNstc7wE AGi1Xf+hXLibhkwlPxrPXJ8LflJyffa7vv00TBsTKYa4wQTKJfSlVGmwM4hrAtOSIzZK StyNvpjvYFaRd0qcR1NeemFB/LwkfxFy4v51j7njJvz6DISCRcdATH26iHCT2AbEo6Xp 3oQrQknQ0QA2qB9kfrhr6X5x7q5M4OG+o5FLRgIF2gUdD64FUpbz4GDRDm68rn65hl2m CZBS3kvFRFNqENJjsuMSnHydOukrgv3PD5SS0y6QuFRuhBRmT6Dern7cLUK5HIyMR1tF u7UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=60IyksJOGmIXG9CSLTK5PiohKuRr1M6QJw5YrGjdyJU=; b=UZNl/+VMfwMJPXQ4vSMhcRHDTKH0Fh4DRfRUm68FP8UI+4fqEp0uGTNoRkPHMwYoxE asCSkpRAHSOeFRLH9Z2gyr++CrswM8hKBFPmeoIHnOdorSAP0B4GXhE4jZJTUYvyMGLz HG0SAsGl2TSw062KvHw1vmxOGGiND4Ym0v2CiOnSLVhc+Kv+JEwE8cvF20O0780v+SEW HrR+0+q6BAJghKysIgdFNC1tkO3iJF3a3V1wKaCXOwoOdTzko6hXL5K/FWlUbBjk/KXA +CT9TUq9SUaRwjjgKRMv/MXRebXHvHVYG/f+0f5SDDrftdG1aMDGZXh+18qs6FIV2RIq twvA== X-Gm-Message-State: AGi0PuYfYLQ+qfhE/5RfI1JKswbMdhDIhWqJJhZGaHNH5rOSE2926TGy CL/e8j5+J5kqhN1MqHosUDw= X-Google-Smtp-Source: APiQypJTfI3oKlQ9G+gjGmo34If5eoEOXJa+E2JYIiDgk9r/aHP36Uv5foGRYsM31U/xd9KS/n+iZg== X-Received: by 2002:adf:d846:: with SMTP id k6mr5458321wrl.268.1586539634535; Fri, 10 Apr 2020 10:27:14 -0700 (PDT) Received: from broadband.bt.com ([2a00:23a8:4140:0:e972:a787:6592:a176]) by smtp.gmail.com with ESMTPSA id v131sm3825184wmb.19.2020.04.10.10.27.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2020 10:27:13 -0700 (PDT) From: Stewart Bryant Message-Id: <4EF69811-1DC9-41F6-94E0-C3685D246487@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_34F6C035-EE7E-4901-B991-AA15335843A6" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 10 Apr 2020 18:27:08 +0100 In-Reply-To: Cc: Stewart Bryant , Giles Heron , RFC Errata System , Ignas Bagdonas , "BRUNGARD, DEBORAH A (ATTLABS)" , Alvaro Retana , Martin Vigoureux , "Michal Dolegowski (mdolegow)" , pals@ietf.org To: "Andrew G. Malis" References: <20200409142817.9F3CEF4070B@rfc-editor.org> <266FFF4C-2FD3-4103-902C-1A6C24E72058@layerfree.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Pals] [Technical Errata Reported] RFC8469 (6082) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 17:27:21 -0000 --Apple-Mail=_34F6C035-EE7E-4901-B991-AA15335843A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think it was my fault I am so used to IP having the SA first that I forgot that Ethernet has = the DA first. Of course the DA first is more logical. Stewart > On 9 Apr 2020, at 22:50, Andrew G. Malis wrote: >=20 > Giles, >=20 > Thanks, I've confirmed this as well. And many thanks for taking the = blame! :-) >=20 > Since it doesn't affect the recommendations in the RFC, my advice to = Deborah is to mark this "Hold for document update". >=20 > Stay healthy, > Andy >=20 >=20 > On Thu, Apr 9, 2020 at 11:24 AM Giles Heron > wrote: > Yes - I think that's correct. >=20 > And I must confess the source of the issue is probably section 4.6 of = RFC4448 so this one is probably my fault rather than that of the RFC8469 = authors (or maybe I should just blame Luca!) >=20 > Giles >=20 > > On 9 Apr 2020, at 15:28, RFC Errata System = > wrote: > >=20 > > The following errata report has been submitted for RFC8469, > > "Recommendation to Use the Ethernet Control Word". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6082 = > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Michal Dolegowski > > >=20 > > Section: 3 > >=20 > > Original Text > > ------------- > > Thus, if the source MAC address of an Ethernet frame carried over > > the PW without a control word present begins with 0x4 or 0x6, it > > could be mistaken for an IPv4 or IPv6 packet. This could, > > depending on the configuration and topology of the MPLS network, > > lead to a situation where all packets for a given PW do not follow > > the same path. > >=20 > > Corrected Text > > -------------- > > Thus, if the destination MAC address of an Ethernet frame carried = over > > the PW without a control word present begins with 0x4 or 0x6, it > > could be mistaken for an IPv4 or IPv6 packet. This could, > > depending on the configuration and topology of the MPLS network, > > lead to a situation where all packets for a given PW do not follow > > the same path. > >=20 > > Notes > > ----- > > The first nibble of an Ethernet frame is the first nibble of the = destination MAC address, not the source MAC address. The erroneous = packet reordering occurs for traffic traveling toward the device with = the 0x4... or 0x6... MAC address > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party =20 > > can log in to change the status and edit the report, if necessary.=20= > >=20 > > -------------------------------------- > > RFC8469 (draft-ietf-pals-ethernet-cw-07) > > -------------------------------------- > > Title : Recommendation to Use the Ethernet Control = Word > > Publication Date : November 2018 > > Author(s) : S. Bryant, A. Malis, I. Bagdonas > > Category : PROPOSED STANDARD > > Source : Pseudowire And LDP-enabled Services > > Area : Routing > > Stream : IETF > > Verifying Party : IESG > >=20 > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals = >=20 --Apple-Mail=_34F6C035-EE7E-4901-B991-AA15335843A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think it was my fault

I am so used to IP having the SA first that I forgot that = Ethernet has the DA first. Of course the DA first is more = logical.

Stewart

On 9 Apr 2020, at 22:50, Andrew = G. Malis <agmalis@gmail.com> wrote:

Giles,

Thanks, I've confirmed this as well. And many thanks for = taking the blame! :-)

Since it doesn't affect the recommendations in the RFC, my = advice to Deborah is to mark this "Hold for document = update".

Stay = healthy,
Andy


On Thu, Apr 9, 2020 at 11:24 AM Giles = Heron <giles@layerfree.net> wrote:
Yes - I think that's correct.

And I must confess the source of the issue is probably section 4.6 of = RFC4448 so this one is probably my fault rather than that of the RFC8469 = authors (or maybe I should just blame Luca!)

Giles

> On 9 Apr 2020, at 15:28, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
>
> The following errata report has been submitted for RFC8469,
> "Recommendation to Use the Ethernet Control Word".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid6082
>
> --------------------------------------
> Type: Technical
> Reported by: Michal Dolegowski <mdolegow@cisco.com>
>
> Section: 3
>
> Original Text
> -------------
> Thus, if the source MAC address of an Ethernet frame carried = over
> the PW without a control word present begins with 0x4 or 0x6, it
> could be mistaken for an IPv4 or IPv6 packet.  This could,
> depending on the configuration and topology of the MPLS network,
> lead to a situation where all packets for a given PW do not = follow
> the same path.
>
> Corrected Text
> --------------
> Thus, if the destination MAC address of an Ethernet frame carried = over
> the PW without a control word present begins with 0x4 or 0x6, it
> could be mistaken for an IPv4 or IPv6 packet.  This could,
> depending on the configuration and topology of the MPLS network,
> lead to a situation where all packets for a given PW do not = follow
> the same path.
>
> Notes
> -----
> The first nibble of an Ethernet frame is the first nibble of the = destination MAC address, not the source MAC address.  The erroneous = packet reordering occurs for traffic traveling toward the device with = the 0x4... or 0x6... MAC address
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, = please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party 
> can log in to change the status and edit the report, if necessary. =
>
> --------------------------------------
> RFC8469 (draft-ietf-pals-ethernet-cw-07)
> --------------------------------------
> Title               : = Recommendation to Use the Ethernet Control Word
> Publication Date    : November 2018
> Author(s)           : S. Bryant, A. = Malis, I. Bagdonas
> Category            : PROPOSED = STANDARD
> Source              : Pseudowire = And LDP-enabled Services
> Area                : = Routing
> Stream              : IETF
> Verifying Party     : IESG
>
> _______________________________________________
> Pals mailing list
> Pals@ietf.org
> https://www.ietf.org/mailman/listinfo/pals


= --Apple-Mail=_34F6C035-EE7E-4901-B991-AA15335843A6-- From nobody Fri Apr 10 12:01:31 2020 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 517043A104A; Fri, 10 Apr 2020 12:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXdEAcaVY8Ur; Fri, 10 Apr 2020 12:01:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 803AA3A0F15; Fri, 10 Apr 2020 12:00:46 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 35AAAF406F6; Fri, 10 Apr 2020 12:00:32 -0700 (PDT) To: mdolegow@cisco.com, stewart.bryant@gmail.com, agmalis@gmail.com, ibagdona.ietf@gmail.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: db3546@att.com, iesg@ietf.org, pals@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200410190032.35AAAF406F6@rfc-editor.org> Date: Fri, 10 Apr 2020 12:00:32 -0700 (PDT) Archived-At: Subject: [Pals] [Errata Held for Document Update] RFC8469 (6082) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2020 19:01:25 -0000 The following errata report has been held for document update for RFC8469, "Recommendation to Use the Ethernet Control Word". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6082 -------------------------------------- Status: Held for Document Update Type: Technical Reported by: Michal Dolegowski Date Reported: 2020-04-09 Held by: Deborah Brungard (IESG) Section: 3 Original Text ------------- Thus, if the source MAC address of an Ethernet frame carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. Corrected Text -------------- Thus, if the destination MAC address of an Ethernet frame carried over the PW without a control word present begins with 0x4 or 0x6, it could be mistaken for an IPv4 or IPv6 packet. This could, depending on the configuration and topology of the MPLS network, lead to a situation where all packets for a given PW do not follow the same path. Notes ----- The first nibble of an Ethernet frame is the first nibble of the destination MAC address, not the source MAC address. The erroneous packet reordering occurs for traffic traveling toward the device with the 0x4... or 0x6... MAC address -------------------------------------- RFC8469 (draft-ietf-pals-ethernet-cw-07) -------------------------------------- Title : Recommendation to Use the Ethernet Control Word Publication Date : November 2018 Author(s) : S. Bryant, A. Malis, I. Bagdonas Category : PROPOSED STANDARD Source : Pseudowire And LDP-enabled Services Area : Routing Stream : IETF Verifying Party : IESG