Re: [mpls] Poll on MPLS forwarder characteristics

Hi all,

I just wanted to prod you all on this survey that the MPLS chairs kicked off. They have provisionally set an end date of 14th October, and it would be good to get your responses. 

IMHO it is not necessary for you to give definitive and company-approved answers (although that would be nice). It would still be helpful to give answers along the lines of, "I know one of our implementations does this," or, "I'm pretty sure our code does this."

Also don't worry about whose job it is to respond: I can easily coordinate if there are multiple responses from the same organisation.

So far, I have had some responses, but not enough to draw any conclusions.

Thanks,
Adrian

-----Original Message-----
From: mpls <mpls-bounces@ietf.org> On Behalf Of Loa Andersson
Sent: 21 September 2022 08:49
To: mpls@ietf.org
Cc: mpls-chairs@ietf.org; pals-chairs@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
Subject: [mpls] Poll on MPLS forwarder characteristics

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

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls