Re: [mpls] mpls-open-dt: ancillary data commens

Loa Andersson <loa@pi.nu> Fri, 13 August 2021 10:20 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 13AB83A1206 for <mpls@ietfa.amsl.com>; Fri, 13 Aug 2021 03:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 Lk9ptXcFTvOX for <mpls@ietfa.amsl.com>; Fri, 13 Aug 2021 03:19:59 -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 98CFB3A1204 for <mpls@ietf.org>; Fri, 13 Aug 2021 03:19:59 -0700 (PDT)
Received: from [192.168.0.3] (c83-250-146-169.bredband.tele2.se [83.250.146.169]) (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 37D67349469; Fri, 13 Aug 2021 12:19:56 +0200 (CEST)
To: Toerless Eckert <tte@cs.fau.de>, mpls@ietf.org
References: <20210812160430.GH23297@faui48f.informatik.uni-erlangen.de>
From: Loa Andersson <loa@pi.nu>
Message-ID: <e02e551c-634a-12ec-e1cb-24c1f33cc021@pi.nu>
Date: Fri, 13 Aug 2021 12:19:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0
MIME-Version: 1.0
In-Reply-To: <20210812160430.GH23297@faui48f.informatik.uni-erlangen.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/p0B4p9I3Uwy462ITGcTpYh8mmRg>
Subject: Re: [mpls] mpls-open-dt: ancillary data commens
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 13 Aug 2021 10:20:05 -0000

Toerless,

I got your point, after thinking a bit, and not really convinced about 
the overload of "type". But I agree that "implicit", in-stack", and 
"after BoS" designates good "types", so I agree to change along thge 
lines you suggested, though I don't think changing the header only is 
enough.

First:

What about:

OLD
Types of ancillary data

    We have (tentatively) three different types of ancillary data

    - implicit, the indicator is sufficient, and a node knows what to do
      just because the indicator is there
    - "in-stack-data", the ancillary data is in the stack accompanying
      the indicator
    - "after the BoS", the ancillary data is found after the label stack

    Note: There might be a fourth possibility - the ancillary data is
    carried as part of the packet pay-load, but for the time being I'd
    like to excluded that method.
NEW
Positioning of ancillary data

    We have (tentatively) three different to include (position) ancillary
    data in an MPLS packet.

    - implicit, the indicator is sufficient, and a node knows what to do
      just because the indicator is there
    - "in-stack-data", the ancillary data is in the stack accompanying
      the indicator
    - "after the BoS", the ancillary data is found after the label stack

    Note: There might be a fourth possibility - the ancillary data is
    carried as part of the packet pay-load, but for the time being I'd
    like to excluded that method.
END

Does this work?

Second:

You had a comment about regardless how the ancillary data are 
positioned, it can be used to inform that there are data conveyed to the 
node by the control plane or that has been configured. I think that was 
intended to replace the "Note:" above.

Can you try to write a text.

/Loa

On 12/08/2021 18:04, Toerless Eckert wrote:
> a) Suggest to replace:
>     Types of ancillary data
>     with
>     Positioning of ancillary data
> 
>     Types is an overloaded term and make me for example foremost think it means semantics.
>     Positioning should hopefully be more precisely describin what this point describes.

-- 

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