Re: [mpls] agenda for the design team meeting tonight

[Alexander Vainshtein <[e-mail]>]

Loa and all,

Regarding one of the example questions in the agenda, namely "- does scanning the entire stack have performance impacts".



AFAIK most (if not all) off-the-shelf-available NPUs have limits on the depth of the label stack in which they, say, can see the <ELI, EL> pair - see also RFC 8662<https://tools.ietf.org/html/rfc8662> that has introduced the notion of Entropy Readable Label Depth (ERLD).



To me this means that in most cases scanning the entire label stack requires pushing the packet for slow path handling with the associated performance impact.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]



-----Original Message-----
From: mpls <[e-mail]> On Behalf Of Loa Andersson
Sent: Thursday, April 8, 2021 3:37 PM
To: [e-mail]
Cc: [e-mail]
Subject: [mpls] agenda for the design team meeting tonite



NOTICE: This email was received from an EXTERNAL sender.





Tentative agenda for the MPLS WG Open DT on carrying info in an MPLS packet 2021-04-08 ===========================================================================



Calling the meeting

-------------------



- Apologies

   -- Yes, we had problem, and the Webex did go out late

- The times in the agenda is one hour off from what we said, at the

   wg chair meeting.

- Unfortunate collision with the IESG Teleconference

   Time: 07:00 US/Canada Pacific

         09:00 US/Canada Central

         10:00 US/Canada Eastern

         14:00 UTC

         15:00 United Kingdom

         16:00 Germany, France, Belgium

         17:00 Finland



   No ADs can participate today.



Tentative DT Structure

-------------------



Coordination: Loa Andersson

- meeting week 1 (e.g. this week)





Track 1: J Doe

- meeting Week 2 and 4



Track 2: K Doe

- meeting Week 2 and 5





DT output / Track output

------------------------



- Document(s) that address general architecture, at BoS architecture and

   in the SPL architecture



- Could be a single document or three documents, possibly a BCP with

   3 RFC



- DT charter (?) anyone that want to work on it

   -- The design team will not takc over the solutions documents, but

      create architectural guidelines that should support the development

      of the solutions documents



DT input

--------

draft-bryant-mpls-dev-primer (walk through)





Questions

---------



- What questions do we want answered

   -- example 1 - would it be beneficial to know already from the

      top label what to look for

   -- example 2 - does scanning the entire stack have performance impacts



- Decisions?

   -- how to keep track



- How do we document this

   -- should we use the wiki?







/Loa

--



Loa Andersson                        email: [e-mail]<mailto:[e-mail]>

Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>

Bronze Dragon Consulting             phone: [phone]



_______________________________________________

mpls mailing list

[e-mail]<mailto:[e-mail]>

https://clicktime.symantec.com/3EHDLWkmGWWE4481kNXVLt36H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fmpls



Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.