Re: [Pals] [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt

Greg Mirsky <gregimirsky@gmail.com> Wed, 26 April 2023 21:43 UTC

Return-Path: <gregimirsky@gmail.com>
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 484E4C14F693; Wed, 26 Apr 2023 14:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 R-7oox8EpJeJ; Wed, 26 Apr 2023 14:43:17 -0700 (PDT)
Received: from mail-yw1-x112c.google.com (mail-yw1-x112c.google.com [IPv6:2607:f8b0:4864:20::112c]) (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 32F04C14CF15; Wed, 26 Apr 2023 14:43:17 -0700 (PDT)
Received: by mail-yw1-x112c.google.com with SMTP id 00721157ae682-54f6f0dae19so59989087b3.0; Wed, 26 Apr 2023 14:43:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682545396; x=1685137396; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=KeoZIsrx2S6U+gdfB20ty+KdKetsD2R1xnuUwR2+eXc=; b=pAGCqNjvCuV7JNK4eGV2IhvlxfqlXo+PbQWIq8/Ua2dCxuVhTp0ngt/+JI8dErJ93V npfnbz8Xnv7SFyAcyLfWQw96PRGr2PepWTcqvh1JuakMmqMcJakeQbAfjIPm50PkAVQz dk0FqonBGAy/I2Kl0coPOiw1I9XTyjXkWCpqJChxDSJtrNX6iRYd/rqxYZhPDUwsaaGt uvqhZrxW7T1BIjqpxHwdRioZdGebUvO71KownLMgRr7NYKlw4CavHLFvHO7s0TQcqNIS nXiVeHMR7LBwl84bq7aU+f1mH3ltHDVwXC8EXSfMFhBaAAsxqvCNhA77SoO7gSmDeeMa wdOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682545396; x=1685137396; 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=KeoZIsrx2S6U+gdfB20ty+KdKetsD2R1xnuUwR2+eXc=; b=Jqhs6nuR2cG4l340dAoYnw+GiBIkv4WkGy0nsWNN1m4ZdUSpcBHsQgwf0i94bP8pCr CclP85kSMKJU9oemHAiem8peodaNY09DTmfjSfc6pMIkQ0rY1buYZvRYqMVKu3z+dYcf xfDJfSLjRxTmiBe5KUfxstcESgd/6IEr/iLWB54pqnGsCAmDnMVo8YnoHoUdOfUComNu XaXKI0TdOxHbBfut+GMa2pbQBL2Iyzo1KERb0GRJvY1e44wHhtZlvD6r3R6W/03SoigI T1RS4m9OuKgSoXBDKOXyKRBrdSFa3ZY87ifXm47OaKI6lpVR6wK1dFpxDltTh4+kv7Z0 gjhA==
X-Gm-Message-State: AAQBX9cLuGL+AtUe5hBHfAIRlodobrsFiEPn9Ixy0KUakEEqL0W0SCzS edHkGfEBrGaGjTr+LWtM6VPkpNDzBWiUKN7lFbLuOnKO
X-Google-Smtp-Source: AKy350YOXwX+JcWM870PVpZbeOteyddgBtEgK4bKk8EyGd5gFeM/y+JTcj2CGLDqfr7TkbPq1KT3kLw33i3L9bzNo18=
X-Received: by 2002:a81:6207:0:b0:549:2623:6f65 with SMTP id w7-20020a816207000000b0054926236f65mr14875026ywb.33.1682545395927; Wed, 26 Apr 2023 14:43:15 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR11MB4064AF61278C1AE671A11927D0BA9@MN2PR11MB4064.namprd11.prod.outlook.com> <570EEC5D-4167-4461-B4A1-96ABAFA949C7@gmail.com> <CAMZsk6cnOh5AHtSmR3=jVX7VsJwkAcbq0VPSCH=edjkXChnH8w@mail.gmail.com> <40b332dd-d33a-6dd8-574f-af0a0be49efb@pi.nu> <CAMZsk6fNZ7EpzRq_rVSwzKoe=z2S_ucxuYfVMAR6cS9ZwZ3G5w@mail.gmail.com> <a8bb80ab-199c-90dd-3c09-fb407f7663a5@pi.nu> <2D696DF1-3BD1-4C2C-AFCA-747B237B94C1@tony.li> <b5a00076-1dc6-ce95-273d-242a791791f7@pi.nu> <1154B6AF-B6FE-4449-B46C-88FFD2AB4C2D@tony.li> <CA+RyBmWWrV=z0eU306jF32LTu52bbm_6OLUXga9d1x2rDgEJkw@mail.gmail.com> <1F294BE2-6D8C-4187-970E-F19E75CB08D5@tony.li>
In-Reply-To: <1F294BE2-6D8C-4187-970E-F19E75CB08D5@tony.li>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 26 Apr 2023 14:43:04 -0700
Message-ID: <CA+RyBmUZstZNprAevVndECvFdj81PZwbP36XyoSwLEZd4o0V+A@mail.gmail.com>
To: Tony Li <tony.li@tony.li>
Cc: Loa Andersson <loa@pi.nu>, mpls <mpls@ietf.org>, "Jaganbabu Rajamanickam (jrajaman)" <jrajaman=40cisco.com@dmarc.ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>, mpls-chairs <mpls-chairs@ietf.org>, draft-jags-mpls-ps-mna-hdr@ietf.org, pals-chairs@ietf.org, pals@ietf.org, DetNet WG <detnet@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a48e8405fa442071"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/A5pV_u99r5n5dtKBQ2HnXCZbLYk>
Subject: Re: [Pals] [mpls] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2023 21:43:22 -0000

Hi Tony,
thank you for your response. Please find my notes below, tagged GIM2>>.

Regards,
Greg

On Tue, Apr 25, 2023 at 12:34 PM Tony Li <tony.li@tony.li> wrote:

>
> Hi Greg,
>
> Sorry for the delay.
>
>
> If a transit node needs to find PSD, it can scan the entire label stack
>> for the bottom of stack bit.  I can’t think of a good reason to ever do
>> this, given that it’s a transit node and should be payload indifferent.
>>
> GIM>> I got confused. I am too not seeing the case when an LSR starts
> looking for PSD unless it has found a proper NAS.
>
>
>
> I’m told that some legacy transit nodes choose to look at the payload to
> extract ECMP.  A legacy implementation that does this and finds any MNA PSD
> is going to be mightily confused and would never see MNA ISD.  An MNA
> specific nibble here would be helpful in ensuring that it realizes that
> it’s about to make a mistake.
>
GIM2>> The PALS (PWE3 at that time) WG was faced with the result of
allowing PW CW to be optional in Ethernet PW in the scenario you've
described.  Because of the allocation of MACs with the first nibble 0x4 or
0x6, the payload was misinterpreted by a transit node as IPv4 or IPv6. And
thus, the WG published RFC 8469
<https://www.rfc-editor.org/rfc/rfc8469.html>. But I only know of cases
when a transit node mistakes the payload for IPv4 or IPv6. In principle, a
transit node must not draw a conclusion about the payload type based on the
value of the first nibble after the BoS LSE. If we agree on that, then
using any value other than 0x4 and 0x6, e.g., 0x0, should be satisfactory.
WDYT?

>
>
> > - we will only include the MNA first nibble if there is an MPLS Label in
>> the packet. right? Existing (legacy) non-MMA capable implementations will
>> not recognize the MNA first nibble as "MNA follows, only understand that
>> this is something unrecognised. What does legacy implementations do with
>> unrecognized first nibbles today?
>>
>>
>> There is not much point in having an MNA first nibble unless there is
>> also MNA PSD.  And there is not much point in MNA PSD unless there is a
>> label stack involved. Therefore, yes, there should be a label in the label
>> stack.
>>
> GIM>> More confusion in my head. Why it must be "an MNA first nibble" but
> not any non-IPv4 and non-IPv6?
>
>
>
> Just for clear semantics. I am a very big fan of avoiding overloading.
>
GIM2>> Considering the limited number of unused values, re-using what we
can seems like a reasonable trade-off.

>
> Tony
>
>
>