Re: [mpls] Poll on MPLS forwarder characteristics

[Loa Andersson <[e-mail]>]

Adrian,

Thanks for handling this! Much appreciated!

One small detail, the chairs set the provisionally end date to 
2022-10-19 (October 19th).

/Loa

On 2022-10-10 11:39, Adrian Farrel wrote:
> 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 <[e-mail]> On Behalf Of Loa Andersson
> Sent: 21 September 2022 08:49
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; DetNet Chairs <[e-mail]>
> 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
> ([e-mail]) 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: [e-mail]
Senior MPLS Expert                          [e-mail]
Bronze Dragon Consulting             phone: [phone]