Session Date/Time: 16 Mar 2026 08:30
Adrian Farrel: Hello, hello, MPLS. It's possible that there are a few people still outside getting cookies and sugar and coffee and and whatever, but the time has come, and so we will start. We are Adrian here, Tony at the back of the room shutting the door, and Tarek at home and presumably wishing he was in bed, but anyway.
Tarek Saad: I'm still awake.
Adrian Farrel: Good. Do chip in Tarek when you see stuff going wrong. This is the note well. We are the IETF. You are expected to have read this material and to follow it. Please click on the links or use the QR code, and if you have any care or concern about this, please come to your working group chairs or area directors for clarification. But read and and obey. These are all the links for important places. Most important of those at this precise moment is the minute-taking tool, and that's been pasted into the chat as well by Tarek. Please join in and help take the minutes, although I know Mach will polish them.
Agenda bashing. We've got a fairly short agenda, but this is your opportunity to say do things in a different order, don't do things, or help, you forgot something. Second half of the agenda. I don't hear anybody complaining, so we'll move on. Since the since the last meeting, we have one errata filed. I did that because there was a lot of confusion being caused about what is an IPv6 unnumbered interface. It looks like a fairly straightforward thing for us to do, but it would be really nice if there was discussion about this on the list. Kitan, hello, you're in the queue, please talk.
Kitan: Thanks Adrian for raising this one. I'll try to go into the details and try to respond on that errata thread to get some discussion kickstarted in the working group.
Adrian Farrel: Lovely. Thank you. Obviously the int-area guys have got some something to say about this. No liaisons going either way, and no new RFCs since last time, but we have got a document now with the RFC editor, that's the MNA header, and we've got two documents with the IESG. One just queued in publication requested, and one that the AD is actually processing. So stuff has been popping out of the working group and is moving through. To fill the gap, we have adopted four new working group documents since last time. Three of them are at 00 and one of them has been respun to pick up comments that were made during the adoption poll. These are now working group drafts, they belong to you, so please review them and comment on them so that the authors can move them forward. And then some of the working group documents have been updated, moving along. Two of them have recently had routing directorate early reviews, and more work needed. The PS header has has gone through working group last call and needs just a bit of polish, and then we will do the shepherding and move it out. And then the fourth one there is on the agenda today, the NRP selector, which is work in progress, and Jie will talk about it. Okay, nothing to say there. A couple of new individual documents that are are kind of progressing, one of them on the agenda today so we'll hear about FRR extensions. And then there's a pile of other individual documents that people should be working on, thinking about, deciding whether they need to bring them into the working group if they're mature enough. And that is us for working group status. Any questions, comments, or we'll move on? Okay then, moving on.
Jie Dong: Good afternoon everyone, this is Jie Dong from Huawei. I'm going to give an update about this draft called "Carrying the NRP information in the MPLS packet", basically we are using the PSD for this information. Carrying NRP related Information in MPLS Packets Okay, here are some recap of the background information. Firstly we know that the NRP or Network Resource Partition is defined as a set of network resources allocated on a connected set of links in the underlay network. The concept has been introduced in the RFC 9543 and can be used as an underlay network resource constructs to support one or a group of the network slice or enhanced VPN service in as described in RFC 9732. And in the data plane, there are different options to indicate where, which NRP a packet belongs to. And here we are talking about the mechanism using a dedicated identifier called NRP Selector ID. This document describes a mechanism to carry the NRP information including the NRP selector ID in the MPLS packet using the MNA post-stack data. So that the transit nodes can know which NRP a packet belongs to and the NRP-specific packet processing and forwarding can be performed on each hop along the path. And this PSD-based approach is considered to be complementary to the ISD-based NRP selector encoding as defined in the MNA NRP selector draft. So here are the encoding of this information in the MNA PSD. The format format in aligns with the encoding in the PSD header draft for the NRP information, a new PS NRP op code is needed and the value is to be assigned. And here we also have a flags field, the most significant bit is defined for the strict match indication. And here the NRP Selector ID is defined as a four-octet network-wide unique uniquely identifier for an NRP. And we also have some optional fields to carry NRP-related information as the ancillary data of this action. As can be seen here, the PSD encoding allows to carry a four-octet NRP selector ID efficiently. And it also allows to carry further information for future extensions like based on the flags and the ancillary data encodings. This draft also talks about the procedures, like the insertion of this action, the forwarding behavior, and also the decapsulation at the egress. There are also some description about the capability advertisement and the negotiation, but for the details please check the draft. So here are the next steps. I would appreciate review and feedbacks, then we can revise the draft accordingly. We already got some comments from the IANA about the registry we need to update it. After that hopefully we can get the draft working group last call, because it's a part of the MNA work. I think it's also need to be shipped. Okay, comments?
Adrian Farrel: You have Joel. Go ahead, Joel.
Joel Halpern: Very small request. I have no problem with what you're trying to do here, having this as an alternative is entirely understandable. Could you next time you refresh it change the title of the draft to say "Carrying NRP information in MNA post-stack data"? Because... thank you.
Jie Dong: Sure, we can do.
Pavan Beeram: Pavan Beeram, HPE. Can you elaborate more on the ancillary data that you have in there? Why do we need it? I mean, the basic idea is that you'd use the selector ID to map it to some policy that is already available, which would have all the gory details that you would need, right? Why do you have to pack ancillary data?
Jie Dong: Yeah, I think the so far is just a reserved field for future extension. Just some of the examples in my mind, maybe not that concrete, is like maybe we can carry some statistics of the NRP matching information or some related other information so that can be monitored or collected by the egress. Yeah. But that is out of the scope of this document. Yeah.
Adrian Farrel: Jim.
Jim Guichard: Yeah hi Jie. One one thing that's sprang to my mind when I looked at this is any particular reason why you've gone with a 32-bit selector ID? Because looking at the in-stack we've already got an 8-bit, the 13-bit, a 20-bit, and now we got a 32-bit. Which is kind of making my head spin. So I'm just wondering if if that's been discussed in any detail and, you know, any feedback on why such a large number.
Jie Dong: Yeah, I think some of this discussion happened in the TEAS working group and also the NRP scalability draft gives some use cases of and the expected number of NRPs needed in different cases or scenarios. For some use cases, because we are mapping 3GPP network slices to the IETF slices and NRPs, they have the 32-bit identifier that may make the mapping more convenient. Yeah.
Jim Guichard: Okay. Thanks.
Adrian Farrel: Although I do have a question on that, and I think Joel's just made the point in the chat as well: this is an NRP ID, not a slice ID.
Jie Dong: Yeah, it's NRP ID, NRP Selector ID.
Adrian Farrel: Okay, moving on. Thank you. STAMP Extensions for Reflecting STAMP Packet MPLS Extension Headers
Rakesh Gandhi: Good afternoon everyone, my name is Rakesh Gandhi from Cisco Systems, and presenting this draft on behalf of my co-authors. It's the STAMP extensions for reflecting the packet MPLS extension headers. So this is basically IPPM draft, individual document there, and because of the intersections related to the MPLS MNA work, we presenting to get review comments from this working group. So agenda is look at the requirements, the summary of the procedure, updates that we have done in the draft, and the next steps. This is basically for IPPM working group. So requirements is to use the STAMP for hop-by-hop and edge-to-edge measurements for both two-way and one-way measurements. The goal is to leverage the existing implementation of MNA on the midpoint nodes as they are agnostic to the STAMP packets anyways. and the scope is the STAMP that has TLV extensions for both in-stack MNA, post-stack MNA, and the draft covers the use case related to IOAM. For example, if you're doing hop-by-hop latency measurement using STAMP. So idea is that the STAMP packet carries the MNA in-stack and post-stack header as shown in this diagram. When packet is received on the session reflector, the STAMP has TLVs, so basically the information that's collected between the sender and reflector is copied into the STAMP TLV and send it back to the sender for with that would help for hop-by-hop delay or all of the IOAM telemetry and PM information that it it needs. there is one-way measurement mode where basically there is a STAMP TLV that controls the return packets, and when that's present then none of this MNA headers are added in the on the return side. So this was a draft that had IPv4, IPv6 data plane as well as MPLS data plane and it was split into two drafts. So IPv6 part is there in the IPPM working group document and MPLS is the this particular draft. We had great review comments from Greg when this was presented IPPM working group, and based on that we have added new sections to make sure that it covers hop-by-hop, I-to-E scope, but the select scope is out of scope. and the packet with MNA should be must be received by the egress node as per the MNA draft. So it basically asks for couple of STAMP TLVs from IANA. So there is work going on in the MPLS working group related to the encapsulation for STAMP. and there are cases like the encapsulation can be added dynamically by the data plane or can be explicitly added by control plane. Irrespective of how the encapsulation is added, which has MNA in-stack/post-stack, the reflector receives them and copies them and back and returns them to the sender. So welcome your review comments. We wanted to get review done by the MPLS working group since it's it's related to MNA. This was part of the IPPM working group previously. So we're asking there for adoption. Thank you.
Adrian Farrel: Is there anything you can share with us about implementation status?
Rakesh Gandhi: So this has not been implemented.
Adrian Farrel: Thank you. Supplement of BGP-LS Distribution for SR Policies and State
Miao Liu: Hi everyone, I'm Miao Liu from ZTE, and I'm presenting this IDR draft because part of it is related with MPLS MNA. So RFC 9057 already supports to collect the configuration and state of the SR policy on the node and advertise it via BGP-LS, and variety TLVs are defined to enable the headend to report the information at different levels: so it can report that at the candidate path level, at the segment list level, and also the SR segment information. So reporting MPLS labels inserted in the segment list is supported by this RFC. So you can use SR segment sub-TLV of segment type A to carry in general any MPLS label, but it is specified that the TC, S, and TTL must be set to zero. So only the label information. and it is not supported that to report MPLS LSEs with non-zero TC, TTL fields, especially for the in-stack MNA substack. So as we know, MNA substack solution repurposed the TC and TTL fields to carry additional information. So MNA such as NRP, IOAM can be inserted into the segment list in the format of LSEs, in the format of LSEs, and so the context of the LSEs inserted in the segment list may also be required by the controller when the headend reports a state of the SR policies via BGP-LS. here's a BGP-LS extension. So MNA substack sub-TLV is defined in SR segment list TLV, so it can carry one or more four-octet field to carry the MNA substack information. so here's the history of draft. I only highlighted and listed the MNA-related ones. So last IETF, in the version 3, so the MPLS LSE sub-TLV is added for MNA is added in this draft and presented. and last month, in the version 5 is presented in IDR interim meeting. So we received some comments. So the first is that what's the relationship between the in-stack MNA and SR policy architecture? So it is under discussion in Spring working group. and second is how to carry the MNA information in BGP-LS? So using a dedicated sub-TLV or a new segment type. So currently we choose a dedicated sub-TLV. and the comments about the backward compatibility considerations. So in this version, the first change is that the MNA substack sub-TLV replaces MPLS LSE sub-TLV, considering that besides MNA substack, there seems no other use cases now that need to report the MPLS LSEs with non-zero TC and TTL fields inserted into the segment list via BGP-LS. And the backward compatibility consideration is also added. So if you don't know it, so you just skip it and process main part. So that's all. Welcome feedback and comments.
Adrian Farrel: Obviously this is an IDR document, and thank you for bringing it to our attention. Is there anything you need from the MPLS working group?
Miao Liu: So the first is that if you're interested in this topic, so is the in-stack MNA individual a new segment type or it is a independent information? So please you can attend the discussion in the Spring at least. and about the format of the sub-TLV. So please review it if it's defined correctly or we missed something. So if you're if you are interested. That's all.
Adrian Farrel: Tarek, sorry.
Tarek Saad: Yeah hi, this is Tarek. I wanted to ask if you have a use case for reporting a general MPLS LSE not MNA-specific.
Miao Liu: So besides MNA, it seems no other use cases that you need to report the whole LSEs information inserted in the segment list. Before the introduction of MNA, so in LSE, just entropy labels, entropy label, special purpose labels. So you can so they may need to report it just use the segment type A, so just report the MPLS the 20-bit label part. But for the LSEs information, there seems no other use cases besides MNA substack from my point of view now. Yeah.
Tarek Saad: Thank you.
Adrian Farrel: Okay, thank you. Good luck in Ops area. Export of MPLS Network Action (MNA) Information in IPFIX
Miao Liu: So the next is also not MPLS but kind of related with MPLS is related with MPLS MNA. It's an individual draft in OPSAWG. So IPFIX is the short for IP Flow Information Export protocol. It serves as a means for transmitting traffic flow information over the network from a exporter to a collector. So important part of the IPFIX is information element. It is a description of an attribute that may appear in a IPFIX record. So for to carry the MPLS label stack and in-stack and post-stack information, there are already some IPFIX information elements defined. So the first is the MPLS top label stack section and stack section 2, stack section 3, etc. It carries the label, EXP, and S fields, with no TTL fields from the corresponding LSE in the label stack. And the first the second is about the MPLS label stack section. So it can carry a series of N bytes from the MPLS label stack of a exported packet. So starting from an offset. And for the post-stack, you there is MPLS payload packet section. It carries a series of N bytes from the MPLS payload from a exported packet. But if the MPLS MNA information of the packet needs to be reported via IPFIX, so existing information elements are not the best choice because use the existing information elements, you can only export the raw MPLS in-stack information, your MPLS label stack, or the post-stack information. So you need additional procedures are required at the network analyzer to parse the information elements to see if there's any MNA information carried in it and what's the detailed information. So this brings extra complexity in the network analyzer and also the bigger IPFIX packet size because you have you have to export the context information to know whether there's MNA in it. So this draft currently defines some basic IPFIX elements. So for the in-stack MNA, the blue one, the first one is the MPLS MNA substack. So export the whole MNA substack information via IPFIX. And the first the second is the MNA LSE format B, so the red one. So the reason why format C and D is not defined because their position is not fixed and there seems much there seems not much help to solely export format C and format D. And for the post-stack MNAs, so also the first one information element defined is the post-stack MPLS header section to export the whole post-stack MPLS header. And the second one is MNA post-stack MPLS header type. So it can it is used to carry the post-stack MPLS header type, which is the top header of all the post-stack network actions. So that's all. Question to the MPLS working groups: So are the information elements defined properly? So is it enough? Is these information elements enough? So or there are more information elements to need to be defined to export the more detailed information in the stack. That's all.
Adrian Farrel: It all looks quiet here. Thank you for that and good luck in Ops area. Signaling Optimization Objective and Bounded Metrics for MPLS Fast Reroute Backup LSP Tunnels
Pavan Beeram: Over the next few minutes, I will introduce you to a new draft that talks about enhancements to the MPLS RSVP-TE Fast Reroute procedures. My name is Pavan Beeram, my colleague Abhishek Deshmukh is the other co-author listed on this slide. RFC 4090 has been around for more than two decades now. the Fast Reroute procedures defined in this RFC are widely deployed. the RFC introduced an RSVP object called the Fast Reroute object, which is reproduced here to help jog your memory. It is used for requesting local protection at the PLRs that are traversed by the primary path. It also is used to specify what type of local protection is needed to be invoked at each PLR. In addition to this, the Fast Reroute object is also used to carry a limited set of backup path computation constraints like the bandwidth, the hop limit, and the resource affinities. There is currently no mechanism for the ingress of a protection-desiring LSP to influence the optimization objective that gets used for backup path computation. the same goes for any nuanced constraints like bounded metrics. Implementations tend to rely on local policy that exists on the PLRs to get these additional attributes. So what this new draft does is try and plug this gap. It introduces a new TLV-based object called Fast Reroute extension to carry these additional attributes that can be used by the PLRs for backup path computation. the object itself and the procedures are defined in such a way that the backwards compatibility with existing implementations stays intact and it is also extensible enough to leave room for any new types of optimization objectives or constraints to be added to the mix if and when they are needed. the next couple of slides quickly go over some terminology that's extensively used in this draft. When we say optimization objective or an optimization metric in this draft, we are simply referring to a quantifiable metric that a path computation algorithm optimizes for. The set of examples specified in the draft. The second term that's extensively used is the bounded metric. When we say bounded metric, we are referring to a path computation constraint that is used to define a bound that a compute a computed path must satisfy. This bounded metric can be of link scope, it could be of path scope, and again there are examples of this specified in the draft for each of these categories. the next couple of slides go over the procedures that come into play when we intro when you introduce this functionality. At the ingress of a protection-desiring LSP, there may be explicit configuration to specify the optimization objective and the bounded metrics for backup path computation. And if such explicit configuration exists, the expectation is that an ingress implementation that is adhering to this draft would be able to signal these additional attributes in a new object called the Fast Reroute extension object that's carried in the path message. the Fast Reroute extension object must be included only as a companion to the Fast Reroute object. What that means is that the ingress must include the Fast Reroute extension object only if it has already included the Fast Reroute object. There is also provisions made for the ingress to be able to figure out whether a PLR has actually catered to the request or not. This is done by introducing a new RRO sub-object flag called FRR extension protection which the PLR would set only if it has successfully catered to the request. In terms of the procedure the PLR, a PLR implementation that is not able to recognize this object, it would simply ignore it and forward it as is to the next stop. This is made possible by the class number that we would end up picking. A PLR implementation that is able to recognize the object and is able to successfully cater to the request will set the RESV RRO sub-object flag that I talked about earlier to indicate to the ingress that it was successfully able to cater to the request. and for some reason if it's not able to cater to the request, it would simply fall back onto the local policy that would exist on the PLR, just like it would do today, and in such a scenario the flag, the RESV RRO sub-object flag will not be set. the next four slides go over the protocol extensions in grave detail. I'll quickly touch upon some highlights. As you can see here, the Fast Reroute extension object contains a series of TLVs. We've defined a couple of TLVs in this draft, the first of that is the optimization metric TLV. the higher-level case is that you would include only one optimization metric for a given path, but the draft does provide procedures to handle scenarios where there is a desire to specify multiple optimization objectives. the second metric TLV that we have introduced in this draft is the bounded metric TLV. There's a flag in here, the L flag, which indicates whether this is of path scope or of link scope. Again the draft does cover scenarios where multiple bounded metrics are specified in this object. the last protocol extension of interest here is the RRO IPv4/IPv6 sub-object flag that I alluded to earlier. This is set by the PLR if it's successfully able to cater to the request captured in the Fast Reroute extension object. this my last slide. we would like to request the working group to review it and let us know if you have any questions, comments, or useful feedback. we believe that the document is sufficiently baked to be considered for working group adoption, and this functionality would be part of shipping code pretty soon so we would like to take this opportunity to put in a very, very early code point allocation request.
Adrian Farrel: Hi, this is Adrian Farrel and totally speaking as an individual here, not as working group chair. It's a lovely draft, I haven't read it, but listening to you it felt very like PCEP. the the you're sort of requesting computation and setting objective functions and specifying metrics, and that's all okay. I just suggest looking at how PCEP does that and making sure you're not missing anything and maybe sharing the registry of objective functions or or whatever.
Pavan Beeram: So we have I mean we have a couple of things to copy to follow rather. I mean there's the PCEP extension and then we also have a YANG module that defines the optimization objective and the bounded metrics. the draft currently is consistent with how the module YANG module is specified. the PCEP ext PCEP object definitions are kind of lacking in a couple of areas, they could eventually be addressed, but yeah I mean it's not consistent with it because PCEP is kind of lacking a couple of things.
Adrian Farrel: Tarek.
Tarek Saad: Yes hi, this is Tarek as an individual contributor. I just wanted to ask, it is commonly the case that multiple primary LSPs will share a backup path on a PLR. and with this optimization objective carried on multiple LSPs, when can you, you know, is there a constraint that you're adding on sharing of the bypass backup path? Should it be the same objective function for example for it to be shared?
Pavan Beeram: Yes, yeah I mean if you I mean in essence you're trying to create multiple bypass path profiles or backup path profiles, right? and if there are multiple primaries seeking the same set of profiles then you would end up creating say one bypass to cater to all of the primaries that are traversing that link. So it's in a way you're creating a small set of bypass path profiles. I mean, one may wonder why, I mean after two decades why why do we need this, right? I think the simple answer is the number of path profiles that are being deployed are have increased over over time and the amount of customization that's needed for providing these backup paths has also the requirements have changed, so that's the reason why we're doing this.
Tarek Saad: Okay, thank you.
Rakesh Gandhi: Rakesh Gandhi from Cisco Systems. So thanks Pavan for the draft. So when we do path computation at the headend today there are lot more constraints, it could be affinity, SRLG, there is lots lots going on. So is it intention to also extend all of these things to do everything that headend does? and the second question is that headend also does for RSVP bandwidth as a constraint too. So if you signal if you ask the the PLR to do bandwidth-aware backup computation then just to add to what Tarek was saying, if you doing sharing of the backup then you have to recompute the the path of the backup for the additional bandwidth and stuff like that. So these are just few additional considerations to to think about. Thanks.
Pavan Beeram: Yeah the first part of your question, we I mean the object is obviously extensible enough to dump whatever you need to dump, but we want to be cognizant of the fact that we don't want to carry everything. We're just trying to add basic stuff. I mean optimization objectives a very basic thing, it just needs a flag what type of optimization objective you need you need, and there are simple bounded metrics that are currently missing. I understand that you could go really fancy with this, but yeah I mean what we have done in this draft is just add things that we believe are important at the same time leave room for anybody who wants to try out new things. the second question about bandwidth, I mean bandwidth is already signaled today via Fast Reroute object and implementations do create multiple bypasses in case you cannot accommodate the bandwidth that was requested.
Rakesh Gandhi: Okay, thanks.
Pavan Beeram: Thank you. Operations, Administration and Maintenance (OAM) for Network Resource Partition (NRP) in MPLS Network
Li Yan: Hello everyone, this is Li Yan from China Mobile. I'm going to present the updates of our draft "OAM for NRP in MPLS network". As a quick reminder, this document describes the implementation of OAM for NRPs, and we extend the existing OAM tools such as ping and traceroute to achieve this. and based on that we can not only verify the reachability but also we can verify the resource availability. and the initial version of this draft was presented on the last IETF meeting and we have updated two versions since then. Thank you all for all the valuable comments from the meeting and mailing list. and the key improvements includes that we have refined the error codes and clarified the processing behavior and we also update the security and IANA consideration. and finally we corrected several editorial errors. and I will focus on the previous two improvement. and the first one about the error code. In the version in the previous version we have defined only one type error code, and for the real operation we found that there is a big difference between "I don't know this NRP" and the other one "I know this NRP but there are not enough or available resource now." So we split this error code into two to realize these things and we can exactly diagnose the fault. Maybe the first one is the configuration problem and the second one is the maybe the resource allocation things or the congestion or the resource exhaustion maybe. and the second improvement, we clarified the processing behavior about for the transit node. In the previous version maybe there are some confusions some some some some reader may wonder that whether or not the transit node need to recognize the NRP ID to check it in the data plane. So to ask this question we add some text to explicitly clarify this. We want to see that we just follow the current RFC 80 8029 and the MPLS Echo request is sent to the control plane through the router alert or TTL expiration. and the check action is located in the control plane not the forwarding plane. So we think that there is no change for the MPLS data plane to forward the packet. So we think is compatible and consistent with the current protocol. Hope this updates can resolve or address the concerns for the last meeting and we welcome more the comments and suggestion at any time. So we also request the adoption call. That's all, thank you.
Adrian Farrel: Go ahead Joel.
Joel Halpern: Could you go back to the two error codes because I'm not sure I understand what the second one is about. I fully understand you can get an OAM message that's supposed to be going on some NRP and that NRP is not provisioned on this device whether it knows it or not that distinction that's fine. But I don't know what NRP resource unavailable means if the NRP is provisioned on the device on this path. If it's there it's there. There isn't a are you assuming the case of the OAM doesn't fit in the bandwidth allocated but other things do? I can't figure out what case would be NRP resource unavailable.
Li Yan: I try to understand your question. and the resource available I will give you a example. For example, the NRP has the configured has been configured to some queue or some sub-interface with some bandwidth, but maybe when forwarding the packet the bandwidth of the queue or the sub-interface is not enough and too many flows has occupied this line. So we want to describe this situation.
Joel Halpern: I don't think that's resource unavailable. you'll need to write down some examples and we can try to figure out what it is, but it's not resource unavailable I think. Because the NRP is provisioned there, the queue is provisioned there, it's available. and these always have to be able to accept packets. I mean, I think you need to spell this out in more detail. Thanks.
Li Yan: Maybe we we can discuss further and add some text to clarify this. Thank you Joel.
Adrian Farrel: Tarek.
Tarek Saad: Yeah hi, again. Thanks for the presentation. My question is about the first error code or the first error you're returning. you're combining unknown with not supported. I understand the unknown, it can be for example not configured NRP on the transit node. I'm not sure about not supported. maybe that's and and if you can, you know, describe such a case maybe it should be separate error code. can you clarify?
Li Yan: Okay maybe we can also separate this two. But I also maybe explain want to explain the difference between the the unknown maybe it seems like the node doesn't recognize the NRP ID maybe it's does not the support the NRP. and not...
Tarek Saad: Yeah that's the confusion is "does not recognize" or "does not have it configured" is two different things, right?
Li Yan: Yeah, the configuration or the support support of this feature. Maybe they support this feature but just not config this NRP ID on this node. So that's the difference.
Tarek Saad: Okay, and if they're different, I think there is a case to splitting them then, not the same error.
Li Yan: Not the same, I agree, maybe we can also separate them. Thank you.
Adrian Farrel: I believe Joel just gave us the correct clarification here: the better answer would be to say "NRP not provisioned."
Li Yan: Yeah, yeah, yeah. Thank you.
Adrian Farrel: Last call, any other questions? Okay, thank you. Oh thank you all. Is that everything? That's everything. Unless anybody wants to say something MPLS related. Anybody want to share a packet with a stack? Then we are done I think. See you all in the corridors, on the mailing list, and in Vienna.
Mach Chen: Yes, sir. Thank you.
Adrian Farrel: I'll see you in two weeks then. You said not next week. Okay. Bye. Serious? Nice.