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

Loa Andersson <loa@pi.nu> Fri, 13 August 2021 10:20 UTC

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
Precedence: list

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

[mpls] mpls-open-dt: ancillary data commens Toerless Eckert
Re: [mpls] mpls-open-dt: ancillary data commens Loa Andersson
Re: [mpls] mpls-open-dt: ancillary data commens Loa Andersson