IETF 117 MPLS WG Meeting Date/Time: Tuesday Session II, July 27, 2023 13:00 - 14:30 (local) Room: Continental 4 Chairs: Loa Andersson/Tarek Saad/Nicolai Leymann Secretary: Mach Chen Slides: https://datatracker.ietf.org/meeting/117/session/mpls/ Codimd for Notes Taking: https://codimd.ietf.org/notes-ietf-117-mpls/ Meetecho: http://www.meetecho.com/ietf117/mpls/ Jabber: xmpp:mpls@jabber.ietf.org?join Working Group Status Duration: 15 mins Presenter: Tarek Saad [Mathew]: Regarding the relationship between the MNA requirement document and the framework domcument. Based on the comments, maybe it time for the WG to think about merging the two documents into a single document, e.g., to address Sasha’s comment. Something to consider on the list. [Tony]: The framework document is stable and ready for WG LC. Missed the comment from Sasha, request Mathew to forward the email, then consider how to address the comment. [Matthew]: there were some comments that cited confusion about where some of the bits resided that may be helped by bringing the documents together. 1:13p 48 attendees MNA Status Duration: 15mins Presenter: Tarek Saad Tarek presented the slides. Report on the MPLS Network Actions interim calls. (Slide #2) [Joel]: We have not fully concluded on what to do when things are pushed onto the label stack whether those things contain a new ISD or not has not been fully addressed. What happens with the existing substack needs to be addressed. List discussion on the topic has been lacking. [Tarek]: I second your concern, the solution document (or maybe the requirement document) needs to specify how to handle the two cases(adding new ISD and modifying existing ISD). [Tony]: Should these be in the solution document or in the action definition document? [Joel]: This issue is not related to actions only, the problem can come up even if no actions. A new hop by hop ISD must be fixed especially if there are multiple actions present. There needs to be a base behavior that provides reliable results. [Tony]: I am OK to define a default defined behavior, but not possible to have the right answer without more info on the actions. [Tarek]: Good discussion and should be addressed in the documents specifically the cases and concerns. This is a good topic for an interim call. This is recorded action item, will continue to track and discuss it. [Stewart]: This is a sufficiently centralized issue that the framework or architecture document should address. It will apply to many applications across the ISD. [Tony]: Don’t understand what the framework document can say other than “do the right thing” without the details of the solution documented. If someone has specific suggestion text, please sent it to me (the author of framework document). (Slide #3) The presentations on the interim calls were noted along with where they can be found. Review and comment on those presentations was encouraged on the list. (Slide #4) [Stewart]: Note out on the list recently where there are some applications where jitter is worse than not having the packet meaning the scope of NFFRR is larger than anticipated. [Tarek]：There is a nfrr draft that is just expired, it will be refreshed soon. (back to Slide #3) [Andrew(AD)]: Going back to Slide #3 - you’ve asked for use cases here, is it true as of yet there is no consensus here where we are going with the use cases or PSD? [Tarek]: There are use cases presented and counter arguments to those use cases some specifically noting that ISD can solve the same case. e.g., iOAM use case noting PSD, but counters that iOAM can be done with ISD. [Andrew]: So it is the case that while there are use cases identified, there is no consensus on these use cases. [Tarek]: That is correct. (Slide #5) 1:31p 51 attendees IANA Registry for the First Nibble Following a Label Stack Duration: 10mins Presenter: Greg Mirsky ID: https://datatracker.ietf.org/doc/draft-ietf-mpls-1stnibble-02 Greg presented the slides. Slides detail all known use of the MPLS First Nibble (MFN) Note that there are some inconsistencies and some ambiguity. Determinism of payload based solely on first nibble is not always posible. See conclusions of slide deck. Control Word and ACH could be post stacks of their own, multi-PSH case. Terminology needs deciding. Draft is ready for Working Group Last Call [Tarek]: (as contributor) Is the first nibble still the right term? First nibble of payload or data? [Greg]: Should use more of Post Stack Header term - first nibble of post stack header - the first nibble of Post Stack Header can be first nibble of payload. Maybe it’s convenient that it can be reffered to as MPLS first nibble. [Tarek]: Need to rethink about the document title. [Greg]: Likely - When we have an appropriate term, will rethink the title and relevant IANA registry. [Tarek]: Are we expecting an IANA registery section before WG LC? Are there any specific requirements to the IANA registry? [Greg]: The current version vs the slides - for this registry we would mark the IP version numbers as reserved and point to the respective RFCs, but do not call them out as IPv4 and IPv6 but just reserved for this registry. Please refer to the slides. 1:43p 53 attendees LSP Ping/Traceroute for Enabled In-situ OAM Capabilities Duration: 10mins Presenter: Xiao Min ID: https://datatracker.ietf.org/doc/draft-xiao-mpls-lsp-ping-ioam-conf-state-01 Xiao Min presented the slides. Asking for comments and WG adoption. 1:49p 55 attendees The case for PSD Duration: 40 min Presenter: Stewart Bryant Stewart presented the slides on behalf of the MNA Chairs. (Slide 2) [Joel]: I have comments on the content of this particular slide. [Tarek]: How do we want to take questions? Want to have the session as interactive as possible. Go ahead with questions per slide. [Joel]: There is content in the slide that assumes facts that not in evidence. It’s not a question of ISD vs NOT ISD, or ISD vs PSD. If there is a max stack depth problem, this is not limited to ISD, but also impacts PSD. ISD that changes from packet to packet: no defined action in any internet draft that does this. Arguing against a case that doesn’t exist or that we have not agreed to is inappropriate. [Stewart]: If you put a variable parameter in the ISD, it will interact with ECMP. Fine with framework and requirements specifying that nothing would change one packet to the next as a restriction so we know where we are, restriction does not currently exist. But I don’t think that the restriction has been fomalized and I don’t think it’s necessarily what the group have brought into. [Andrew(AD)]: Have had a fair amount of interaction about this deck - in any summarization where claims are made, to avoid controversy, it is best where we say “the case is made” the deck should reference the emails from the list where the case and conclusion were made. IETF consensus decisions are on the list. The moment there is a claim of fact, it is helpful in future to cross reference against the mailing lists. [Stewart]: The case that ISD is made was based primarily on direction that the WG decided to go. Trying to highlight the positives vs the negatives of ISD. [Tony]: There are 11 bits of mutable space per-LSE that can be used. That is doable, although not pretty. The last bullet on page 2 doesn’t seems to be based on facts. [Stewart]: Are you asseting that there is not going to be this effect when you change the lower 20 bits of every LSE? [Tony]: As long as no one changes the lower 20 bits of each LSE, ECMP will not be affected. [Stewart] Correct, that means you only can put mutable data into the mutable 11 bits per 32 bit space, this is a limiation on the size and this talks to the complexity. [Joel]: That talks about the amount of mutable data however the claim on the slide is a different statement. [Stewart]: Disagree, different parts of the forwarder have difficulties with different parts of the stack. [Tony]: disagree with both - the size of the ISD is limited, the slide is correct on this. [Greg]: A lot of arguments here are based on some arbitrary evaluation of the current state of the hardware in the network. What is the benchmark that is being compared to? Introducting some function in an existing network is based on MSD and capabilities of nodes. These MSD limitations should not necessarily limit what we do. We learned from past, there are different capabilities and technology evolves, we deveploped a method of advertising capabilities as MSD. So, some nodes might not benifit from using MNA due to their limitation capabilities, but this should not stop some progress. And with time, the capablities of the system in the network will grow, the limitation on stack size may be a less concern or even no concern. [Stewart]: Another thing is if you want a large block, with PSD just put it in once; for ISD, it’s not sure whether you put several different in there or you have to keep replicating the ISD. [Greg]: If the stack size is a concern for e.g., fast forwarding then this could be a case for PSD. [Tony]: The framework document does have text about multiple blobs of ISD. There are ISD blobs of different scopes. There is expected to be one blob of each scope that a node might want to process. There should be no ambigulty about ISD process. [Rakesh]: I know a case called path tracing, about 14 hops(per hop needs 3 bytes), when using PSD, 42 bytes are needed; when using the ISD mutable space(the 11 bits per LSE), 31 LSEs (124 bytes) are needed. [Jie]:Thanks for the analizing of the cons and prons of ISD and PSD, it’s better to have them documented, so that can better understand which use cases can be met by ISD, and which use cases would require PSD. Regarding the lable stack size limitation when using ISD, one of the motivations of ISD is able to use the legacy hardware. We need to consider how to support functions by ISD with limited stack size, an analysis is necessary. [Greg]: Confused. Are we discussing different ways of building network processors? - when someone says “it is difficult to do in ISD”, what principle of lookups are being considered? What is the basis of such a statement? Generic or specific hardware? [Stewart]: What I want to bring to everyone’s attention is that ISD is not perfect, it has some limitations, and they should be documented. We should understand whether we can live with them or whether we will also need PSD. [Greg]：If we know there are ISD limitations then how does PSD help? [Stewart]: PSD helps for the end to end case. [Greg]: PSD will have the same problem as ISD of reaching the information. This slide is not thorough analysis of ISD and is too general [Tarek]: Rakesh made a case showing the overhead of the use case is optimized for PSD vs ISD for path tracing. This should be documented in the use cases. Highlight that there are optimizations that can be done with PSD. Please work with the WG to produce text and add it to the use case document. [Wim Hendrickx]: The hardware has a limit on the amount of data it can push or process into the stack - PSD or ISD doesn’t matter. To the point of the efficiency - personally would like to have one capability flexible enough for multiple use cases - the path tracing use case is not optimal with ISD, and the hop by hop use case is challenging for PSD. If ISD today is not flexible enough then let’s look at improve it - not necessarily ISD vs PSD, should consider to make MNA flexbile enough to support multiple use cases, would benefit from one mechanism with good flexibility. [Stewart]: I would love to do it in a single mechanism and it’s the right thing to do if we can. WG has much more work to do in this space. [Tony]: iOAM DEX has been discussed several times - there is a way to do path tracing without scribbling in the packet. Why would bend over backwards to something we said we didn’t want to do in the first place? We should keep arguements based on facts and use and not worry about taste. [Haoyu]: Complexity to parse the data is another consideration. Implementation in P4 for parsing ISD is challenging and more complex than PSD. For the iOAM case you can use different implementations of ISD for direct export but it is not a standard IOAM-DEX implementation. RFC has a well defined header format that can’t be coded in stack. To support the inter-domain iOAM case, you have to keep the iOAM-DEX header intact crossing domains. Thus need to comply to the encoding in the standard. [Rakesh]: (@Tarek) There is already a draft about the path tracing using PSD. [Tarek]: Should be referenced in the MNA use cases [Andrew]: (not as AD, as operator) Appeal to all vendors - the operators need to be able to take this to operate and debug it - there is currently a mess of complexity that is likely to lead to bugs, operational headaches and unstable networks. The points of the debates does not seem to be geared to the solution that reduces complexity, but rather rooted positions vs how to make it work in the best way for those that need to run the networks. Appeal to the vendors to keep in mind that an operator needs to use it effectively and efficiently. [Stewart]: More than happy to take Andew’s advise as an engineer into the design [Tony]: We are trying to keep it simple but MNA is not easy. Would be easy to throw away MNA and say don’t do this. If we want MNA then it is not simple. Suggestions for how to simplify are welcome. (Slide 3) [Stewart]: asking to document slide 3 in a high level document. [Tony]: the framework document does already try to say this. If changes needed, send text. [Stewart]: It is something we need to take on board as a group. (Slide 4) (Slide 5) [Haoyu]: The mpls extension header draft proposed solutions for some of the issues here. Can segment the label stack into multiple sections and put the extension header field after the fisrt section can solve the label depth issue. I will give a presentation on how use SR-MPLS with PSD next time. Will propose putting the entire SR label stack into the extension header, similar to SRv6 network programming. Have several use cases that are more mature than the ISD. (Slide 6) [Joel]: Putting aside the lack of clarity on the time of flight and focusing on Security. If there is any case for security for MPLS, it is not a PSD related issue. PSD has nothing to do with security. Fragmentation should and better be end to end or we are into having intermediate routers reassembling packets. Have hard time understanding how this applies to PSD or even MNA use cases. Would like to get ISD out the door and then look at use cases for PSD and how should we handle them, then move that work forward. We should not hold up ISD work for PSD. [Stewart]: more or less what I’m proposing [Joel]: OK but we should focus on that and not debate the points and assertiosn raised here. [Jeffery]: The use case I had in mind for PSD that involves the security of fragmentation. There are some common functionalities that may be applicable to different layers, like IPv6 bier, MPLS. It is preferred to use the same farmat. That means you need to do it with PSD. [Stewart]: Want to make sure we don’t to exclude PSD as a first class citizen in the design. Hooks should be in from the begining. Or there is a riks of accidentally precluding it. [Tarek]: Agree, Thanks! 2:34p 52 attendees Shuffling time: 0 mins