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

Loa Andersson <loa@pi.nu> Thu, 27 April 2023 07:03 UTC

Return-Path: <loa@pi.nu>
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 E6ED0C151B10; Thu, 27 Apr 2023 00:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 loVAGd7e8j8o; Thu, 27 Apr 2023 00:03:38 -0700 (PDT)
Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0E62C15153F; Thu, 27 Apr 2023 00:03:36 -0700 (PDT)
Received: from [192.168.1.241] (c-8f02e353.020-236-73746f24.bbcust.telenor.se [83.227.2.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E5BE736A5AE; Thu, 27 Apr 2023 09:03:34 +0200 (CEST)
Message-ID: <e1ae626b-1f46-c60f-2f28-a30f04efb5f8@pi.nu>
Date: Thu, 27 Apr 2023 09:03:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0
Content-Language: en-GB
To: Tony Li <tony.li@tony.li>, Greg Mirsky <gregimirsky@gmail.com>
Cc: 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>
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>
From: Loa Andersson <loa@pi.nu>
In-Reply-To: <1F294BE2-6D8C-4187-970E-F19E75CB08D5@tony.li>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/48qmvyEeLoxMSyw2TrH6lcp5x7k>
Subject: Re: [mpls] [Detnet] [Pals] FW: New Version Notification for draft-jags-mpls-ps-mna-hdr-00.txt
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: Thu, 27 Apr 2023 07:03:41 -0000

Tony, Greg,

IN line please.

On 2023-04-25 21:33, 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.
> 
> 
>>     > - 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.

I agree with Tony that simple is good.

However, Ethernet PWs without a control word made it "un-simple"!

An Ethernet PW without a control word cab put any value in the first nibble.

The consequence is e.g. MNA PSD can not rely on the first nibble only to 
identify MNA PSD.

The P flag in the LSE following the MNA will uniquely identify MNA PSD.

Now there are two possibilities

1. we assign a MNA PSD first nibble

    - if we do so an MNA PSD capable node cannot rely solely on that
      first nibble to positively identify MNA PSD
    - a node that are looking at the first nibble to decide if it can
      do load balancing does not need to understand the MNA label or
      the P flag, it can look at the first nibble to decide that it
      should not do load balancing, the first nibble will be other
      than 4 or 6.

2. we do not assign a a MNA PSD first nibble

    - if we do so an MNA PSD capable node will rely only on the P flag
      to identify MNA PSD, we can mandate that a node sending MNA PSD
      shall put a specific value (other than 4 or 6) in the first nibble
      (zero comes to mind). We can further mandate an MNA PSD capable
      node shall ignore the first nibble.
    - a node that are looking at the first nibble to decide if it can
      do load balancing does not need to understand the MNA label or
      the P flag, it can look at the first nibble to decide that it
      should not do load balancing, the first nibble will be other
      than 4 or 6.

I think we need to decide which method we use.

It should be described in detailed in the first nibble draft.

Any solution that assign a first nibble or mandate that the first nibble 
is ignored, should reference that text in the first nibble draft.


/Loa

PS

I'm a bit concerned using the option 1. since the first nibble values is 
a scarce resource.


> 
> Tony
> 
> 
> 
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet

-- 
Loa Andersson                        email: loa@pi.nu
Senior MPLS Expert                          loa.pi.nu@gmail.com
Bronze Dragon Consulting             phone: +46 739 81 21 64