[mpls] Poll on MPLS forwarder characteristics

Loa Andersson <loa@pi.nu> Wed, 21 September 2022 07:49 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 24C78C14F6EB; Wed, 21 Sep 2022 00:49:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 M7fh5DXlpsqC; Wed, 21 Sep 2022 00:49:43 -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 9A372C1524C8; Wed, 21 Sep 2022 00:49:04 -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 6EB6236885F; Wed, 21 Sep 2022 09:49:01 +0200 (CEST)
Message-ID: <f6787646-f40b-b0b3-d7ce-5d0f7783651a@pi.nu>
Date: Wed, 21 Sep 2022 09:49:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2
Content-Language: en-CA
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
From: Loa Andersson <loa@pi.nu>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lqBWUZcQnYmmvwMoN7y4d16grN0>
Subject: [mpls] Poll on MPLS forwarder characteristics
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: Wed, 21 Sep 2022 07:49:44 -0000

Working Group(s),

In the discussions relating to adding MPLS Network Actions and Ancillary 
Data, several questions have arisen that would be best resolved by 
understanding how existing implementations function. The answers to 
these questions will not necessarily enable us to make firm decisions in 
one direction (because proof of a negative is hard), but might help us 
avoid proposals that would break implementations.

We have five questions below. Please send your responses to Adrian 
(adrian@olddog.co.uk) starting the email subject with “MPLS Forwarder 
Poll”. Adrian will anonymise them and make the batch of anonymised 
responses available to the MPLS Working Group. Using this approach 
ensures the confidentially of the data and nothing will be explicitly or 
implicitly leaked regarding the equipment behaviour of a specific 
vendor. If different implementations have different behaviours please 
indicate this.


1. Does your implementation look at anything more than the top label in 
the label stack? If so, does it

a) "scan ahead" examining the labels,
b) Simply use the Label Stack Entries as input to a hash,
c) Just search for the Bottom of Stack?
d) Something else

2. In the case where your implementation looks at label values below Top 
of Stack,

a) Does the scan-ahead recognise SPLs.
b) If so, what does it do if the label value is an SPL (bSPL or eSPL) 
that it does not recognise?

(Note that this question applies to RFC 3031/3032 implementations as 
well as RFC 6790/8662 implementations.

3. What value does your implementation set as
     a) The ELI TC field
     b) The ELI TTL
     c) The EL TC field
     d) The EL TTL

In each case what happens if the received bits in those fields are not 
as expected?

4.
    a) How does your Penultimate Hop Pop implementation (RFC 
3031/3032/3270/3443) process the TTL and TC (as EXP) from the popped 
Label Stack Entry?
    b) In particular, does it copy either field into the exposed 
top-of-stack Label Stack Entry (in the case where the popped label was 
not bottom of    stack)?

5. Does your Penultimate Hop Pop implementation examine the exposed top-
of-stack label to see whether it is a bSPL? If so, what does it do?

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