Session Date/Time: 22 Jul 2026 09:30
[00:00:04] Italo Busi: The DOS means off guard. I better be careful. Yeah. Because there's no parent here.
[00:00:49] Oscar González de Dios: Well, good morning, everybody. And welcome to the first session. So remember that we have two sessions today. This one, upstairs, and the next one in the afternoon, downstairs. So here, first of all, our IETF Note Well, so you are reminded that you already all the IETF patent policies. So I'm pretty sure that even you have read this thousands of times. Please take care of it again. And here, everybody, please, in order that we are allocated proper room and then we are comfortable, just please sign in the session data tracker so we know how many people have attended and we get good rooms. And here, if you are in in remote, just turn off everything unless you are you are speaking. And whenever you go to the to the queue, even in the queue, your name appears, just please say the name before before coming. So here, especially the notes, Pavan already typed in the chat the link to the notetakers. I think it's be the main notetaker today, our secretary. But I think we encourage people, especially in the discussions, to to capture everything.
[00:02:19] Italo Busi: I mean, even we will have to go later today.
[00:02:25] Oscar González de Dios: We have scheduled the the sessions today in two in two parts. So here, in this this first sessions where we will go mainly through the working for the different working group documents and especially which is the update, which is the status, and so on. And more in the ACTN POI and the slicing that we have the different documents. And finally, the agenda is, as you see here, fitted for all all these presentations. But but if if there is time, okay, we can start with two presentations that we have a slotted for the afternoon. Okay? So then we will give more time in the afternoon for discussions. Okay? So here, just to to let you know that how we plan this is that in the afternoon, we are going to introduce some new topics that we will see whether they are of interest for the group and should be here, like the like the power of word traffic engineering that we have some one one presentation in the in the afternoon. And, especially, we have a block for the MTE and then a set of a set of document that, especially those those two first blocks, I think, might might have some discussion that if we have time today to in the first session to present the the first the first one, the the two drafts or one of the drafts, we will have more time for for discussions. Okay? But this is how we plan it. So just a very later on, Pawan will go in more detail with the documents, but you see that we are in in the good track now, and we have, like, around four documents in the RFC Editor queue. We have also requested the publication of the path computation and the POI applicability. So those documents that have been around for years, even I could say even a decade maybe, because it's, 28 versions of the of the of the documents. So we are finally cleaning our our queue. So we have also one document, the layer three te-topo that we are in the waiting for the write up. So so so we are we'll be there soon,
[00:05:02] Pawan Beeram: and we have started recently the last call for a couple of of documents, the telemetry autonomics, and the controller models. Okay? So please reply reply to the list. And then we have don't have any new working groups nor document nor. So
[00:05:23] Oscar González de Dios: we have there was one liaison. I remember the last day in CCAMP, they said that there was no liaisons coming. Yes. There was one liaison coming incoming from ITU-T to update information in the IMT 2020 and the IMT 2030 road map. It was to, but the the deadline has already passed. So, well, we have not any response to to them by now. So, I mean, unless someone is willing to contribute with a response, I think we don't need to do anything at least that we know of. Even wasn't aware of having this this one. So but it's it's here. Right? So at least now everybody's aware, and no one can say that ITU has not informed us. Okay? And finally, the usual reminder of the IPR disclosure process that everybody needs to answer. And as you know, in in our working group, we follow, let's say, a double check. We poll before adopting the document, and, also, we poll before going to last call. K? So so here, we have had some issues with the past with some contributors when they move out or when they retire or when they change company and change topic. So, I mean, be aware that if you participate, if you go out and so on, I mean, you need to you are still contributor of that of that document. And, also, we have the the GitHub of the working group where we place the the drafts that are working group items. So as usual, please, once your document now is a working group document, bring it to to the GitHub better because it will be a good home for for it, and you will be able to do the same same things as as before. And, also, if you are author of our working group document, please always send the update before the the meeting even if you are not presenting it because it has not not relevant update. And here, also, we have the wiki where we try to keep as best as possible the the status in addition to the one that you find in the data tracker, but this one is, let's say, a bit more simple way. And then I will let Pawan go into more depth in the different working group documents.
[00:08:59] Pawan Beeram: Okay. Wait. Not able to
[00:09:03] Luis M. Contreras: stop sign.
[00:09:12] Huawei Representative: Okay. That worked.
[00:09:20] Pawan Beeram: K. Next on the agenda is working with document status. Thanks as usual to Italo for helping compile this deck. As we saw in the slides that Oscar just presented, we have six documents in what we call the post publication stage. There are four in RFC Editor's queue, couple of them for which we just put in a publication request. There are four on the four working documents that are on the agenda today, so that leaves us with 22 documents and the status of each of those 22 documents are captured in the slide deck. We have one document in what we call the post working group last call stage. This is the l3-te-topo document. It has been in that stage for a while now. The authors have just finished addressing the last pending item. This was a scoping related comment that was made by the routing directorate. And that with that, I think that document should progress to the next stage. Italo has volunteered to be the shepherd for that, so he will be working with the authors and taking it to the publication stage. As Oscar mentioned, we do have two documents that are currently in working group last call, the ACTN PM telemetry, autonomous document, and the NS controller models document. The last call for both of them ends, I believe, end of next week. We have not seen any discussion for those happen, on the list, probably because of travel and the idea, but, we I mean, if you don't see any discussion, we may have to push it out by another week. But, if you haven't read it, please do review it, Send in your concerns. If there are any gaps that you identify and would like to see, get at us before we push a publication request, now would be a good time. In the last few weeks, I mean, we have had, several documents get tagged with this working group last call ready status. That's great. I think we have about nine documents here listed that can that are deemed to be working group last call ready as per the office. So we will try to align them up all for working group last call between now and the the San Francisco IETF. So let me dwell on some of them as part of this deck, and then we'll get started with the presentations for the day. The NS IP/MPLS document is deemed to be working group last call ready. That we do have it on our agenda today. Tarek will talk about how we have addressed the last few pending items that were there. As part of the NRP bag, we have two other documents. I think the first one is on slide eight. Yeah. This is the NRP scalability document. This will progress along with the NS IP/MPLS document. So please do review them in anticipation of a working group last call. That should get triggered as soon as this current the two documents that are currently in working group last call complete their stint. The n r p yang document will probably follow after the two other companion NRP documents are done. Bo has said that there may be some further alignment that would be needed before we get there, but I would like to think that yeah. I mean, we we should have enough time to push it out before the San Francisco IETF. We have three other short documents that two RSVP cryptography documents are also deemed to be working group last call ready. We had one round of reviews from the security folks. We will try to get in a few more reviews, but, I they should also get lined up, before the next IETF. The same goes for the in place LSP bandwidth update document. This was adopted fairly recently, but there aren't any open issues at this point in time. All the comments that were received during adoption, especially from our friends at Arista, they have all been addressed. So this should also get out of our queue. The topology profiles document is something that we would need some careful input. It is deemed to be working group last call ready, so please do review it. We this will probably be I mean, we'll finish the other working group last calls and get to this, but this is an important document because it will help us position as something that can be used for other use cases as well. The last document that I would like to draw your attention to is the the last one, the topology filter document. The n r p yang document has a dependency on this, so this will probably get progress along with the n r p yang document. We did we did go through a YANG Doctors review. Rashad had sent out his comments a while back. The authors took their own sweet time, and I think they finally managed to address all the comments. They'll work with Rashad and make sure that all of his comments are addressed, but they should also get lined up for working group last call. Any other questions either on the documents that I just covered or the ones that are captured on the list? I don't see anybody lining up. So with that, let's jump to the first presentation of the day, and I believe that's Dan.
[00:15:19] Huawei Representative: Yeah.
[00:15:40] Pawan Beeram: Okay. You're doing okay. Okay. Go ahead. Just
[00:15:45] Daniel King: multitasking while I wait for slides and a clicker. I suppose I could start speaking, actually. It's my favorite pastime. Thank you. This this document, ACTN POI Service Assurance, And it's actually a a a piece of companion work with our ACTN applicability document for packet over optical. So, essentially, it's sort of how you use the ACTN architecture for a couple of specific scenarios. And when you deploy that and you've got all of your sort of instantiated controllers and and and capabilities and interfaces, etcetera, how do you actually monitor the services that you're creating over this multilayer infrastructure? Thanks, guys. And it relies heavily, actually. This document relies heavily on the ACT and POI applicability document itself, which is sort of rapidly making its its way through the IESG and RFC editor's queue. We have pretty much the same authors actually on both documents, which is quite useful. And you can see in the GitHub, we keep it updated, and you can see the various kind of issues, etcetera, that are currently open. Essentially, they're the sort of the talking points, the main talk talking points of the document. Now what what's been the sort of substantive discussion for for this specific document on our sort of by by monthly call? Actually, it turns out, when we originally scoped the work for service assurance on this sort of multi domain, multilayer, single provider deployment model, it turns out that is a much more complicated network than we originally anticipated. So let me sort of caveat that statement. In terms of complexity, it's the packet layer that we were sort of really struggling with. Optical is sort of relatively deterministic in terms of what needs to be exposed in order to troubleshoot a particular service, especially when there's dependencies that run on top of that, in this case, sort of packet and, more specifically, VPN technologies and sort of VPN based services. When we anticipated in the original topology where we had sort of multi PNCs. So we'd have multiple optical PNCs, multiple packet PNCs. We thought we could sort of extract information across these layers, across these domains in a relatively straightforward way. Turns out, actually, for for certain types of VPN technology, getting the performance monitoring information, some of the telemetry data, some of the characteristics in real time and maybe real time subjective, but but certainly sort of in operation services is actually quite a bit more complicated than we thought. And what we want to do, and sort of we're asking the working group at this point, and I expect to have a few people come to the mic in a moment, is is it okay to kind of rescope the document at this stage and sort of reduce the complexity of the problem and just agree that maybe and it's on the packet layer instead of having multiple PNCs and then having to collect information from each of those PNCs that's then provided abstracted to the MDSC so that something in the event of some degradation or cessation of service that kinda goes outside of the committed boundaries of the SLA and maybe the SLO, can we then sort of trigger a change on one PC one p packet PNC, or do we need to assume that it's always gonna be sort of multi p PNC deployments? So this this is the new scope. So what's the difference if you did a sort of diff? It's essentially just kind of reducing the number of of packet PNCs that we expect to kinda coordinate across and extract VPN information from in order to suggest potential changes in the event that during the service assurance cycle, there is a need to either change the packet layer connectivity or drop down to the optical layer and actually start to adjust some of the lower layer connectivity that then permeates its way through to the packet domain. And the reason why we're having to kind of just narrow the scope and some of the complexity around the the the network that we're trying to model is just extracting information and correlating that information is actually a lot more complicated than originally anticipated. So, Italo, do you want to go to the mic at this point? I I think so, because then we can cover other things.
[00:21:09] Italo Busi: Okay. Thank you. Italo Buzzi from away. I think it makes sense to me to reduce the scope. The original intent, we were really excited by the ACTN POI applicability because in the applicability, we were actually able to do a multilayer and multidomain. And that was because the 8795 topology model was well designed and integrating two layers or integrating two domains in the packet or in the optical was is exactly the same. So we have very good tools and the same for the tunnel. We have very good tools to to to create the path across domain and across layers as well as to create topology view across domain across layers. When we look at the SLA assurance, we found that it's not that simple. And and and the most complexity is how do we do SLA assurance across two packet domains, which is not what the main focus of our work is Right. How we can correlate an issue in the optical domain with an issue in the packet domain. So we Yeah. We can focus on that. And the the issue of understanding when it is a multi domain, where is the problem is maybe independent from the fact that you have an optical network or you don't have an optical network. So it's better, in my opinion, to split given the complexity and the actual scope.
[00:22:19] Daniel King: Yeah. So to summarize, we focus on the vertical layering rather than the horizontal layering.
[00:22:26] Oscar González de Dios: Dan, as you mentioned that You want
[00:22:28] Daniel King: to As a chair or as a operator?
[00:22:30] Oscar González de Dios: As a chair as a chair. Okay. So as you wanted as you wanted to ask the the working group whether it was relevant to reduce the scope, Just it would be good just to clarify here what you are meaning by domain, if it's an IGP domain or it is that it is a single controller, and you don't care whether it is multiple, let's say, areas or multiple. Just just to clarify, that's that's Cool. Cool.
[00:22:57] Daniel King: Yeah. We will do that. And and we'll move this to the list as well. Right? I mean, there are people who have a who will have an opinion that aren't in the room right now as well. So we we won't make any changes to the document and publish that
[00:23:12] Oscar González de Dios: document until we get a consistent support. Just just clarify the the scope what you mean is this, and this is what is written, question, full stop. Thank you.
[00:23:28] Italo Busi: Yes. Thank you, Oscar. I discovered while working on this slide with Daniel that you're right. The domain term is mean different instruments, different people. In the POI applicability, we define the domain as the sub network which is under this the control of a single PLC domain.
[00:23:46] Daniel King: Right.
[00:23:46] Italo Busi: PLC controller. So that's the that's the idea is that we have only one packet PLC, which they can be a can be single layer or multi layer. It doesn't matter. It's that's a single packet PLC that controls the IP network and a single optical PLC which control the optical network.
[00:24:02] Daniel King: Yeah. It's it's when you start having multiple controllers that things start to get really complex. So it's
[00:24:12] Pawan Beeram: primarily the inter operator, inter MDSC. Yeah. Yeah. If you can, yeah, formulate that scoping discussion by Yeah. In the reviews.
[00:24:23] Daniel King: And it I mean, the the thing is it does deviate slightly from the ACT and POI applicability document because although we originally used the same topology model, it it's now augment maybe not augmented, but it's reduced. Yeah. But I think for this document, what what the plan is is just to kind of scope it very early on in the document so it's clear. Cool.
[00:24:45] Takeo Miyasaka: Oh, yeah.
[00:24:51] Swaminathan Ananthakrishnan: Hi. Swami, Nokia. Is this, simplification only for the packet domain or also for the optical domain?
[00:24:59] Daniel King: It is for the optical domain as well. So so
[00:25:06] Swaminathan Ananthakrishnan: we I I can understand the the complexity in the in the packet domain. Right? I don't know what What? Complexities in the optical zone.
[00:25:16] Daniel King: Nothing changes in the optical layer. So the we still have multiple p yeah. So we still have multiple o PNCs. So there's still multiple optical PNCs. It's just we have one single packet PNC.
[00:25:31] Swaminathan Ananthakrishnan: Okay. So MDSC, one packet PNC, multiple optical PNC's.
[00:25:37] Daniel King: Yeah.
[00:25:38] Swaminathan Ananthakrishnan: That's okay. Then I'm good.
[00:25:39] Daniel King: Cool. Cool. Cool. Cool. Sorry. Yes.
[00:25:47] Italo Busi: I I understand the argument, but in the current PO applicability, are assuming a one one optical PNC for each pack of PNC. We we we were we were we have taken out the scope, the multi domain optical. There were there were some feedbacks that usually there is a one to one between optical and IP domains at that time. But I don't know whether we want to go over multiple It's
[00:26:11] Daniel King: more it's more likely that we would have multiple optical PNCs that provide connectivity for a packet.
[00:26:16] Italo Busi: For the same op packet domain. Okay. So we can
[00:26:18] Daniel King: because you could have, like it could be a three node hop. It could be
[00:26:22] Italo Busi: So that's going to be a more bigger change with respect to POI applicability. Well
[00:26:28] Daniel King: So further further discussion is Okay.
[00:26:29] Italo Busi: Yeah. It's it's okay, but I don't see major issue on either one of
[00:26:35] Daniel King: the Yeah. I mean but, basically, the complexity comes from when you start trying to get multiple sources of information from different packet.
[00:26:42] Swaminathan Ananthakrishnan: Applications. Yes. Yes.
[00:26:44] Italo Busi: But but the current POI applicability is assuming that the the
[00:26:48] Daniel King: One to one.
[00:26:48] Italo Busi: There is only one optical domain providing connectivity for a given packet domain. That's why
[00:26:53] Oscar González de Dios: Okay.
[00:26:53] Italo Busi: So depends on how much we want to deviate from that assumptions.
[00:26:57] Daniel King: Yeah. Cool. Cool. Cool. Cool. Okay. So and then, really, that's that's kind of the main the main contentious issue that requires some substantive discussion. I just kind of extended the scope in real time there. We had some additional text on root cause analysis as well, and we need to just check again our sort of normative, informative dependencies as well, make sure those are consistent. And as always, review comments, very welcome. That's kind of it.
[00:27:43] Huawei Representative: Yeah. Thanks.
[00:28:16] Pawan Beeram: Correct?
[00:28:18] Tarek Saad: Hello. I can you hear me? I'm trying to grab the slide clicker.
[00:28:24] Pawan Beeram: You should you should have it.
[00:28:26] Tarek Saad: Okay. Thank you. Hello, everyone. This is an update on the working group document, draft-ietf- teas-ns-ip-mpls. This is, about realizing network slices in IP/MPLS networks. My name is Tarek. I'm with Cisco. I'm presenting this update on behalf of the coauthors. We've made two updates recently to the document revision eight and nine. The focus of the first update was to address the outstanding comments that were documented in the document itself in section nine more specifically. There were eight comments that were addressed. There was no, major change to the core of the document. We will talk about the updates that we made down in the in the slides. The revision line incorporated an the definition of an RP domain. The document had used it in multiple sections, but now we've added it into the terminology section, more formal. I'm just flashing the eight, issues that were documented in section nine and how they were how and where they were addressed, just for further, read. The first issue, there was an ask, to have some examples in an appendix and for for the NRP partition modes. We in in appendix a one, two, and three, we've documented three of those examples. The first for addressing partition mode data plane only. This is in this mode, the head end pushes the selector or adds the selector to the packet. Transit nodes apply the per hop behavior, and no NRP routing state is is maintained in in on nodes in this mode. In the second example where we're doing partitioning in the control plane, no selector is carried in the packets. The the ingress or a PCE computes a NRP state aware, TE path. And in this case, isolation, is achieved at admission time to make sure that, the path is placed correctly on the resources that are assigned to the NRP. The third mode, or the third example, that addresses the partition of, the third mode in the document, which is the combination of data plane and control plane, it, it it describes how, both partition modes can work together to give the strongest isolation, that we need. The second issue that we addressed is clarification on the relationship between physical network, fill filter topology, and and RP topology. The physical network is is basically the, the resources that are, at hand. And then we can filter the full resources, in the network, and that defines a filter a filter topology. The the same filter topology can be assigned to one or more NRP topologies. And and and then there was the explicit description of the three modes that I went over in the previous slide, and that was clarified in this issue. The next issue that we tackled is the fallback behavior. When a packet arrives with unrecognized NRP selector, the default, behavior is to drop, and that is the recommended in the document. There could be other behaviors that, can be policy driven, be it best effort or mapped to the default NRP on the on the box or the node. Again, this is controlled by a local policy and optionally can be carried in the on in the NRP selector itself. There was a a further issue that we tackled about the service demarcation point locations that are for the NRP itself. There are multiple variants of this. We documented all of them, and, basically, it defines where traffic and the selectors the classifier where traffic is is classified and where the NRP selector is is assigned or or set in the packets. Further issues that we tackled about discovering NRP capabilities or incapabilities before we start sending traffic, We documented multiple options. One of them is a controller based, you know, kind of archive of what capabilities in the network is there. The other is static configuration as a fallback, and and we did not recommend, you know, advertising those into a routing protocol that can impact routing conversions. So if there's other ways of disseminating this information in such that, it's not impacting routing conversions, I mean, it's yet to to be seen, but we think the controller based mechanism should suffice. And then we tackled the issue of crossing multiple NRP domains where each NRP domain, possibly can have its own NRP selector. There are multiple ways where we can do stacking of NRP selectors where each NRP selector own is owned by one domain. And as we transit domains, the the domain is checking and applying the associated NRP hop behavior of map to that NRP selector. The other is when we do mapping as we transit domains, a selector is mapped to another selector, and there's a there's some kind of coordination needed where one selector maps to the other one or one type of NRP maps to the other one as we cross domains in this mode in this way. And we highlighted the use of PCE or hierarchical PCE when we are crossing multiple domains, in this case. There was an issue to tackle some additional security or concerns or threats introduced with with this document. We've identified four threats, and we added mitigation for each. The first was about the NRP policy being manipulated, and second, disclosure or of NRP state and and, you know, unrelated information about that. The fallback abuse, we talked about, packets being dropped, when they don't map to NRP, and that could be also abused. And the the idea of inter domain NRP selector spoofing and deriving certain information from the flow that's transiting the domain itself. We've added a normative reference as well at the to address one comment. The last update that we made in revision nine was to introduce this, actually, to document the the definition of NRP domain into the terminology section. I'll I'll not go word for word. I'll leave it to the interested authors to, review the the definition and let us know if there's anything that needs our attention. This is my last slide, and the authors think that all the comments related to or outstanding comments have been addressed. The document in the state right now is we think is ready for last call progressing to to last call. Thank you.
[00:38:04] Pawan Beeram: You have one question?
[00:38:09] Huawei Representative: From Huawei. Could you go back to the slide about the fallback? Yeah. I think here it says that can this indicator can optionally be signaled within the NRP selector itself. Just want to to clarify whether it should be part of the selector. If it we are using a dedicated selector ID, will this information be carried as part of the selector ID, or it is within the encoding of the together with the selector ID but separately? Is that something can be clarified?
[00:38:55] Tarek Saad: We, in the document yes. Sure. Thank you, Jiming Ji. In the document, we did not define any encoding for any data plane, so we kept it agnostic of the data plane encoding. Nevertheless, there was a poll done in this working group, and it was deemed interesting
[00:39:21] Italo Busi: to
[00:39:21] Tarek Saad: the working group to carry this additional information inside the the packet. So as part of the NRP selector itself, the idea of I I think I I I put a term there signaled, but I meant to say it's it's carried in the selector itself. It's not a control plane signal thing. It's it's carried in the packet, the the instruction whether to drop or not. But we did not define any encoding in the document about that about how we carry it in the packet.
[00:40:01] Huawei Representative: Yeah. So it's, that, at least will not give a limitation on where this piece of information will be encoding in the with, an IP selector or selector ID. Is that correct?
[00:40:15] Tarek Saad: Yeah. That that's exactly what I'm trying to say. We did not define a a specific encoding to where do we put this and how is it encoded in the packet. So I'll we left that exercise to the specific data plane that's going to be defining the NRP selector itself.
[00:40:34] Huawei Representative: Okay. Thank you. And another quick question is I just went through draft quickly. It seems there are some examples which are specific to the MPLS encoding, like the override service label as an NRP selector. Or do we need to go to the that specific in this draft or that will be left in to the MPLS working group?
[00:41:06] Tarek Saad: Yeah. Thanks. So the the idea was to have an example and to be a meaningful example. So we needed, and the usual I mean, we are in the MPLS working group. Sorry, we are in TEAS, but, no. I I I meant to say that I meant to say that we needed to give an realistic example, and we chose MPLS for the example. If you I I cannot abstract it and still call it example. That's the challenge.
[00:41:37] Huawei Representative: Yeah. Okay. Maybe you
[00:41:38] Pawan Beeram: And it's in the appendix. It's a example if you think another set of examples need to be added. Please feel free to send some text.
[00:41:47] Huawei Representative: Okay. Okay. I will take a further look. Thank you.
[00:41:51] Tarek Saad: Thank you, g.
[00:41:54] Pawan Beeram: Thanks, Tarek. Believe Louis is the next presenter.
[00:42:30] Luis M. Contreras: Hello, everyone. This is Luis. I will present the update on on the network slice application draft on behalf of my co authors, of course. So, basically, the the point here is to to refresh the fact that we we presented in in IETF 115 in London an update where we were addressing one of the latest on the same as the receipt. But we during the discussions, we realized that we forgot to address another liaison that was received received in December. So, basically, now with this new version, we are addressing that that liaison that is the 2006 from 3GPP SA2. The previous one was for the from the RAN group. So it's it's was more or less was covering in 06. Now we are in 07. We are covering the the one that we missed that was received in in December. So, basically, the consequence of addressing this this liaison statement, we rise we opened three issues. We basically fragmented the liaison in in three different issues. All the the issue list is is available in in this GitHub. So you can easily check and and and, basically, yeah, see what what were the proposed changes. We recently sent to the mailing list an email explaining the way in which we address the the changes. So there is yeah. Again, you can track easily the the issue, the proposed solution for the issue, and also the diff particular for each of those issues. And, essentially, what we did was to, yeah, to go to different parts of the document. We've introduced clarifications on terminology. Basically, the comment there was that the the terminology should be adjust or or basically make it consistent with the terminology in 3GPP. 3GPP is basically the owner of that terminology. So, yeah, we we essentially do that. We also do a fixing on the identifiers. We were playing with different identifiers in for slices. And and, again, we adjust the the those identifiers to the way in in which the 3GPP is defining them. We also provided additional details on the process of mapping the slides, so what will be the interaction between the different 3GPP management system entities and network slice controller. And with this an overall improvement of the text, so going through typos and and and so. The next steps well, once we we send that previous email to the list, I can issue some further comments. So we have included as well the the reference here. And, essentially, we need to introduce new fixes in sections four dot two, five dot one, and sixteen two. So we will do as a next step. We couldn't make it before this meeting. So, yeah, it will be our very next step. We need to update the referencing references in in general in the in the zero six version sorry. Sorry. In 07, we updated the one related to IETF drafts, but we need to update the ones related to 3GPP specs so that we can point out to the latest versions coming from 3GPP. And a third thing that we want to do is to refresh on the contribution list because what you see that the this document was a result of of merging up to five other documents. We have a long list of contributors. So we want to to go through that because some of the affiliations has changed. Maybe some of them are not, let's say, available now. So we want basically to go through that and and and yeah. In in case that we have some issue to talk with the chairs what will be the the way of resolving just to avoid new blocking points in the future. So maybe moving the contributors to the acknowledgement part or or or basically refresh those that are available and and basically, yeah, avoiding blocking points. Our idea is with that to produce a new version targeting September. The document is is long, 70 pages, so we'll take some time to go through that. So apart from covering the comments, we we want to do a a final pass, let's say. But, of course, additional reviews are always welcome, so there is an opportunity to again, so we would like to encourage the the working group to go through the document. And if something is detected, something is basically problematic, we have time to to face it. And then a question for the chairs will be, once we have this stable version, if the chairs consider that will be convenient to create a or to generate a new liaison statement or reply back to the previous one so that we can confirm that everything is okay or or not if we can go along. So, basically, this is an open question maybe to be answered in September once we have the new version or or so.
[00:47:13] Pawan Beeram: Yeah. Reply seems app, but we'll work with the liaison manager and figure out an appropriate way of sending it.
[00:47:19] Luis M. Contreras: Okay. K. Thank you. So this
[00:47:22] Oscar González de Dios: is all from from my side.
[00:47:41] Luis M. Contreras: Yeah. So next doc document is about the instantiation of IETF Network Slice Service Management service provider networks, and I will, again, present on behalf of my my colleagues, Amir, Victor, Oscar, and Ahmed. So here, the the idea was basically, well, okay. We we have the the NBI model that is defined in this, but we need to realize later on the the slices either in in using service model or network models or L3SM, L2SM, L3NM, or L2NM. So, basically, here, the the the what we are doing is to basically train to map what will be or trying to work on what will be the mapping between parameters that they define in the slice towards the parameters that are defined in these service and network models. So we were working on this. The new version, essentially, what we focus was in the functional and capability alignment. So a part of the mapping of the parameters, so also to understand what would be the function the how the functionality would map. In the slice model, we are defining some functionality that maybe could represent some gaps in the service and network models, and this was basically the focus of the update. So as said, what we are doing here is play basically trying to look for consistency between what is the request of the slides and what will be the implementation either using network or or service model. We focus, as said, in this capability functional capability alignment. This is open to interpretation. So here, the what we would like basically, probably our next step would be to send an email to to the mailing list asking for your views as well because is is let's say, how we do interpret the the align the alignment of these functionalities and capabilities. For instance, we are talking about capabilities that in network and slide service model refer to as a low SLA templates, as a low SLA hierarchy, connect connection groups, custom topology, performance monitoring, feasibility check, and test test only functionality, let's say. All of this is somehow referring the slicing service model. So and then we have done set this mapping to the service model and and the network model into different tables. Again, this is our our view or interpretation, so it will be great if we can somehow get a common ground among all of us that this mapping is is correct. With this mapping, we identify some gaps that probably could derive further work in the either in the service or network models so that we can basically, yeah, have from the request of the size up to the realization either with service or or regular model, a complete mapping so that, yeah, basically, we can go from one end to the other end. So next step will be providing additional examples, maybe, to to illustrate the the the potential realization in in multi domain, gathering feedback, encourage comments from the from the group. And, also, if if the church remember, there was some discussion that maybe this could be moved on in in some point in time. So maybe something that we'd also have in the horizon. Maybe could be the the next one or over. Right now, we will keep working here, but just for for refreshing this to the audience. Thank you.
[00:50:53] Pawan Beeram: Yeah. For for now, we just continue progressing the documents that we have. We haven't had any formal discussion with the OPSAWG folks about it.
[00:51:03] Luis M. Contreras: Okay. I
[00:51:04] Oscar González de Dios: think that tomorrow is the session with OPSAWG, so they are I mean, it's one of the things that
[00:51:09] Luis M. Contreras: we can clarify also. Okay. Thank you.
[00:51:13] Pawan Beeram: Thanks. We we have about nine minutes left, so we're gonna squeeze in one more presentation. We're gonna use slide the presentation slot 14, which is.
[00:51:42] Takeo Miyasaka: So hello, everyone. My name is Takemiyasaka. So today, I'll talk about the ACTN Extension for the inter operator coordination. Actually, this is very related to the first topic which is talked by the Dan on the ACTN and POE assurance. But this is trying to talking about the multiple operator, not the single operator multi-domain. Anyway, so I'd like to talk about this operator. This is a zero zero version document. So objectives. So as I said in the first slide, so this, you know, slide, you know, draft is trying to extend the existing ACTN framework in order to, you know, realize the, you know, the connection between the different operators, MDSC. So background. So why this extension is required? So as you may be aware, the current ACTN framework only assume a single operator I mean, single administrator authority. And that if I understand correctly, there's no, you know, static, you know, definition about the interface between the different operators MDSC. I mean, the inter-MDSC interfaces. So I think this slide is trying to talk about use cases or motivation of this draft. So currently, in this kind of zero zero version document includes three use cases, like inter operator optical connectivity and the inter operator IPTE, like multi-operator RSVP-TE or SR-TE. But this diagram is trying to show the third one is multi inter connection for like for the AI data centers. So, actually, so in this diagram, there are two operator. Like, operator a is a data center operator, and operator b is some kind of network carrier operator. And, also, I forgot to add that the CNC of the operator a, but some, you know, the, you know, the customer with data center try to send the, you know, the end to end traffic engine pass between the location one, location two to the operator a's MDSC. But this operator does not have, you know, the enough network resources between the location one, location two. In that case, it's sort of operator a of the MDSC need to send some request to put to the other network carrier, in this case, operator b. In it also means that there's need to the in the, you know, interface or API between the MDSC of operator a and operator b. Like, needing to, you know, change the list of abstract resource information and send us some, you know, the provisioning, you know, some past provision request to the operator b. So, actually, so due to the time constraint, I I will skip the detail of this slide. But as I said, the current, you know, the SGTN framework only talking about a single operator scenario, so there's no inter you know, definition of the, you know, inter MDS interfaces. But, of course, there's a, you know, hierarchical model for the MDSC, but it also assumes a single operator. I mean, the root MDSC have, you know, the full knowledge or full control of the lower domains in in MDSC. So this is a proposed extension to the ACTN framework. So there's, you know, MMI interface. These are MDSC-to-MDSC interface. But as I said, in order to realize such kind of inter operator scenarios, so we need to, you know, connect different operator m d s e like this diagram. So as I said, this kind of the MMI interface will, know, enables some kind like shares, abstracted topology, abstract resource information between different operator and jointly establish the end to end traffic engineering pass. So, yes, next step. As I said, this is a fast version of this document. So so we so for the next version of this talk, so we will, you know, define on the describe the part is the risk requirement of the MMI, and we will do a complete requirements of other interface, and we will add the protocol consolidation for these interface. And, also, we will also talking about more applicability or use cases of the is this kind of multi-operator things. Anyway, so this is the version of this. So please leave you this document and the feedback. Your feedback comments are always welcome. Thank you.
[00:56:02] Oscar González de Dios: Then? Do we have five minutes?
[00:56:04] Takeo Miyasaka: Yeah. Four minutes. Oh, many minutes.
[00:56:09] Daniel King: Cool. Thanks. Really timely because this this Yeah. Topic has come up on on our ACT and POI assurance calls. But I am wondering if this is a soluble problem because the Metro Ethernet Forum, formerly known as METH, now known as MEF, they have their life cycle orchestrator, and they have sort of legato and a whole series of APIs that was supposed to allow coordination sort of setup and tear down of resources across providers. Has that project failed from your perspective, or it doesn't actually have the capabilities that you guys need?
[00:56:54] Takeo Miyasaka: So you are talking about the LSO and the amplifier. Right? Right. Yes. So, actually, so we are now starting to the gap analysis for the m m MEF LSO. So we will, you know, include this kind of gap analysis in the next version of this document.
[00:57:09] Daniel King: Okay, cool. Thanks.
[00:57:15] Dhruv Dhody: Hi. One thing I wanted to mention was that when we were discussing the original CNC and this idea of multiple operators came in, most of the time, we made this assumption that, oh, you could act like a CNC. One MDSC can act like a CNC for another operator and just fits the architecture. We really don't need to define so but I think you have some use cases where you are thinking that it's not a CNC relationship, and you need to but then is this two operators which are not really, like, trusting of each other? They have some kind of cooperation agreement in which it's not like a customer versus, like, an operator relationship. It is like two operators who have but then what is the boundary between when it is a multi domain versus two operators who are just deciding to work well with each other? From a technical architecture point of view, I think those things we need to just break down a little bit before we jump into what this interface would look like. Thank you.
[00:58:21] Daniele Ceccarelli: Daniele Ceccarelli. So I share a little bit Dan's view that this is probably not exactly working for IETf, but never mind. If if we believe that it's good, we can we can try to work on that. What I was questioning or better trying to better understand is the applicability of this document. Because as as example, you are bringing, an operator in a data center and an operator in the transport network. But do we have MDSCs in data centers? Are are operators are deploying MDSCs in data centers? That's something that I'm not seeing. I might be wrong. I I would be happy to be to to be wrong. Is there any other example that you can bring where this would be applicable? Because this one to me is not something that we we see that frequently in efforts. Okay. So, actually, I
[00:59:16] Takeo Miyasaka: can't afford your comments, so please discuss them later, I'm afraid.
[00:59:22] Pawan Beeram: Tula, you have less than a minute.
[00:59:27] Italo Busi: Okay. Very quickly because Drew made more or less my comment. Maybe you can take a a figure a look at figure 10 of the RSC eighty three forty five where the scenario that Drew described of the MDSC acting as a CNC, and we can discuss why this is not applicable to this use case.
[00:59:44] Takeo Miyasaka: Yes. This is thank you.
[00:59:47] Pawan Beeram: Thank you. Thanks for being flexible. Yeah. That brings us to the end of session one. We will meet again. It's not in the same room, so please find your way there. Thank you.
[01:00:05] Daniel King: Here.
Session Date/Time: 22 Jul 2026 12:00
[00:00:21] Session Chair: Okay. Good afternoon, everybody. Please log in to the data tracker for the session. We are starting our second T session. So the first so first of all, as even though we have had our first session, please read the note well. You have seen it many times this week, but still we need to go for it. And then we will start with the first slot to present the power conserving path placement strategy. Okay? So this is our first power of our traffic engineering work here in this.
[00:01:05] Zafar Ali: Ron?
[00:01:25] Session Chair: Thank you.
[00:01:27] Ron Bonica: Hello. Ron Bonica, HP. And I'm here to, one more time, talk to you about a power conserving path placement strategy. You heard about this at the, two IETFs ago. An introduction to remind you what we're here for. A robust network has enough capacity to satisfy demand during peak hours. It actually has a little more to, give you some redundancy. Most networks have a daily utilization pattern. They might be busy in the daytime, less busy at night. So you have sufficient capacity during peak hours and excess capacity during non peak hours. This excess capacity costs money, and it has an environmental impact. So it would be nice if you had just the right amount of capacity all day long. That's the goal here. So we have this power conserving path placement strategy. During periods of low demand, it concentrates traffic onto the smallest possible set of links, and those links are supported by the smallest possible set of network resources. That leaves some network resources idle or nearly idle. The idle or nearly idle network resources can be powered down until they're needed again. An easy way to remember the concept is when you leave a room, turn off the lights. Somebody got the humor. Anyway, PCPPS leverages CSPF. Without CSPF, without PCPS, CSPF, each link has a metric. And c s p CSPF computes a path that doesn't violate constraints and has the lowest cumulative metric. In our strategy, CSPF with p c p p PPS, each link has a new PCPPS metric. CSPF computes the, computes a path that doesn't violate constraints and has the lowest PCPPS metric. This PCPPS metric is like the old metric except it takes power consumption into consideration. In fact, a few more details about it. It's derived the PCPPS metric is derived from power information. On the local node, this information is either obtained from the hardware or it's configured, and it's advertised in an IGP. It's advertised in the IGP. Obviously, information about power consumption on remote nodes is learned from the IGP, and all this is stored in the TED. So you can compute paths with information from the TED just the way we have previously. So what updates have we made to the draft, recently? Well, previously, we assumed that a sleeping interface consumes no power. This is true on many, many hardware architectures, but not true on all. So we've replaced the concept of power utilization with the concept of potential power savings. Potential power savings is the difference between power consumption when you're all all the way up and functioning and when you're sleeping. Thanks to Carlos Pignataro for pointing this out. The intended status of the draft has changed from informational to proposed standard. Excuse me. The reason for that is there's an LSR draft that refers to this, the LSR draft that talks about how to advertise our information. Well, that LSR draft, changes bits on the wire. Because it changes bits on the wire, it needs to be proposed standard. That draft references this one, so now this one needs to be proposed standard too. And there have been many, many editorial changes. So what is the ask? We would ask for a call for adoption so that we can move this draft forward, we can get serious review on it, and also so that this draft can inform the LSR draft that I just talked about. Questions?
[00:06:22] Session Chair: Does any people from the working group have questions? Otherwise, have the very first comment is that regarding the the metrics and regarding the power savings, we need to have an alignment with the green working group. That is where, say, the source of information of power has been defined. So we need to be just to be sure that we are consistent. So please keep a coordination between Green and this work.
[00:06:50] Ron Bonica: Tony Lee has done that coordination, and I see him coming to the mic.
[00:06:55] Tony Lee: Yeah. We had the discussion with Green. We already have agreement with them. We do not have exactly overlapping data because our data space requirements are much more stringent. There, you're doing a yang model. We're trying to embed bits as few bits as possible in the IGP. So we agree that we have the right information in both locations. So we think we're coordinated already.
[00:07:20] Session Chair: Okay. So please keep keep this coordination. So, Zafar?
[00:07:29] Zafar Ali: Zafar- least Cisco Systems. So I did send you a comment yesterday. I am overall questioning a few things, not not everything. And you I don't think you're answering that question. First thing is that when you do such a low level of modeling, then you have to be able to make sure that the power value that you're carrying is correct. So the question is, do you have to do that level of monitoring or or is the attribute that give you best bang with a buck is the interface level and we do some simplification. Around those lines is is is my question, and that's where it connects with the the the the two data models thing. It's that that is what my concern. It it goes back to your own statement in LSR group that you did not realize that there's the power in this sleeping bandwidth is is not zero, which means that I can I can see that when I have to implement it, I will have difficulty or or this power group that much power, that that much power and is is maybe too fine grand of modeling, and and maybe is is the attribute is really a laser or interface level that that you want to keep it at level and not to go in a lower frame rate? This is what what I meant when I say the data model and the the thing has to be correct so that people can implement it easily, can deploy it easily.
[00:09:10] Ron Bonica: Okay. In response to that, when we first started the project, every piece of hardware that we looked at had a sleeping power consumption of zero. Carlos Pignattaro brought to our attention that there were other pieces of hardware in the world that might not. So we changed the model. We didn't have to change much. All we had to change is the name of a variable, changing it from absolute power consumption to power savings, potential. Now as for where do we get this information, there are two possible sources. First, a hardware component may make it accessible through a programmatic interface. There might be a way to ask the hardware, you know, how much power do you consume when you're sleeping? How much do you consume when you're awake? We don't know of a piece of hardware that does that. So another way is to do it by configuration. The hardware vendor publishes this in a spec sheet. You enter it in your CLI or however you configure your router, and you have it. But in either case, you're you're pretty sure that it's correct. It's not something that is in, you know, the LSR protocols or, you know, we don't we don't specify how you get the information. But, you know, if you've configured it, it better be correct.
[00:10:54] Zafar Ali: Yeah. I I think some level of, like, what is the what is the best level or do it work with? Maybe the laser interface level or all. That kind of simplification can help. Because otherwise, if you keep it too generic and, like, some people will say, oh my god, is this power supply that that component and all that? And people don't even know what what is the actual power when when when it's actually getting traffic, was it not getting traffic, and there's a there's a whole lot of room, for simplification here, and that's, we're happy to talk to you offline.
[00:11:29] Lou Burger: I'm not sure. Think we
[00:11:30] Session Chair: can continue the discussion in the list, the technical discussion. And then because in sake of time, I would like to start with the with the topic of the drafting in the in the WG. So first, I would like to to ask the working group a question, first of all, before this particular draft. And is that if the working group thinks that this power aware traffic engineering, okay, so using traffic in engineering for this particular purpose to save energy, is a topic of interest for the working group. K? So please. So I see a significant number of yes there. There are a couple of no's. So if those that voted no want to say why do you think that this is not a place to do power aware traffic engineering, please stand up or otherwise send it also to to the list. But but it's interesting to understand why why you think it's not interesting. Is the topic a not not is rapid? I'm saying that the topic itself. The but there are two knows. So if if anyone that knows want to stand up and just say it, okay. If not, send it send it to Lisa. So we have, like, a pretty much amount of of people going for that. And then, I would like then, that as it seems there is a good interest in the in the topic. If this particular document, the one that we have just seen, is a good starting point to work within this working group in the topic. There will be other strategies, other other topic other ways to do this traffic engineering, but at least this particular one, do you think it's a good starting point? So, well, the same number of notes as we had before, it keeps it keep remains. So even we have at least one that thinks that the work is inter and then the work is interested in the working group, and this document might not be the the best. Also, if if you can give reasons, also please either send it to the list or stand up now to to say why don't you think. So it's more or less half the people that set the power power where traffic engineering need is a good place in in this set supported document. So we will continue that option in in the list in in any case. And, also, of course, listen to the people that said the notes. K. Thank you very much. Okay. So we can jump to our next topic in the agenda. So we will now go for the second slot on the IPS VBT extensions for the point to point IPT and HPT panels.
[00:15:28] Pavan Beeram: This is an update on the IPRCPT document. This document discusses how RCPT tunnels can be realized on a native v four v six forwarding plane. This was presented to the TEAS working group at IETF 105, a good seven years back. So why are we reviving it now? Well, as you know, there there are these new workloads that are causing havoc in certain data center interconnect and wide area networks. They're posing some interesting bandwidth engineering challenges. And operators who have MPLS running, they do have the toolkit to cater to it. But operators who are using native v four v six without an MPLS, there isn't any distributed bandwidth engineering solution at their disposal, and this draft is an attempt to address that. I'm presenting this on behalf of my coauthors, Tarek Saad and Andy Smith. Since it's been seven years since we presented this, let me just do a quick recap. The prerequisite for this solution is that each egress maintains what we call an egress address block or an EAB. So it's it's a a block of address IP addresses that the TEE application of the egress maintains. These are not globally routable addresses. Only they show up only in places where RSVPTS program them. The IPT tunnel setup sequence is fairly similar to how you would expect in an MPLST network. The ingress of the IPT tunnel would use either an on box PC or an off box PC, get the path computed. And once the path is computed, it would RCBT would signal the path. RCBT would use a path message with the generalized label request, inspecting the egress to assign a specific address from the address block and bind it to the tunnel. The egress binds that address to the tunnel and signals it in the label object of the recipe. And as the recipe makes its way back to the ingress at each transit node, there is an EAB route programming that comes into play, and the EAB route will point to the next hop based on what's there in the ERO for that particular hop. And once the signaling sequence is complete and the tunnel is deemed ready to carry traffic, the ingress will encapsulate the traffic with the e a b address as the outer IP destination. This is an illustration of the setup sequence. It is not that visible. Let me let me walk you through that. So in this particular example, the t tunnel is from r 1 to r 4. The ERO is B-D-F. There is an egress address block, which is a v six prefix at r four, and then there's a service network that's sitting somewhere beyond the egress. The path message goes in with a generalized label request object with a switching type v six, which is basically an instruction to the egress to assign a v six address to the tunnel, and then that gets reflected back in the res v. And as the res v makes its way to the ingress, there is the corresponding route that gets programmed. And when the packet is steered onto the tunnel, you can see that the e a b address is used as the destination at address in the outer header. And when it gets to the egress, it gets decapsulated and sends its way to to the service network. This highlights a few key properties of this paradigm. I mean, I'll highlight I'll dwell on a couple of them. If you have multiple IPT tunnels merging at a transit node and they traverse the same path from that point on to the egress, you could potentially use the same e a b address for both of them. So if you have a mesh of t tunnels, that could save some address and programming footprint. The EAB addresses, as I said, are from a private space for IPv four. The recommendation is to use RFC nineteen eighteen addresses from RFC nineteen eighteen space, and for v six, use RFC forty one ninety three space. And all the other bandwidth engineering tools that RFCPD offers will be inherited in this paradigm as well. So whatever I've mentioned so far, they were already available in the old version. So when we decide to revive it, we thought it would be useful to also add a switching type for SRv six. With when EABs are used in SRv6 network, they're taken from a dedicated SRv6 locator. These aren't IGP advertised. The egress programs, the EAB with SRv6 end behavior. So when that traffic arrives, it would trigger SRH processing and not plain decap, and the ingress uses reduced SRH encoding. The EAB is used only in the I p v six destination address. The only thing that's carried in the segment list is the service set. So the path is enforced per hop by per hop route programming and not by us not using SRH. These are some of the changes that we made in this new version. Besides the SRH six specific discussion, we also added a section that talked about MTU considerations because you're talking about encapsulation. We clarified transit node processing. We clarified how the EAB is managed of the egress. We also updated security considerations because we brought in this new switching type. That one takeaway that I would like you to have from this presentation is that it is possible to do RSCPT based bandwidth engineering in native v four v six and SRV six networks. And at this point, I would I'm asking for the working group is to review the document and reach out to us if you have any questions or concerns about the approach that's being advocated.
[00:21:43] Session Chair: So, Kriti?
[00:21:49] Kireeti Kompella: Kireeti Kompella. Thank you for the document to you and your coauthors. I will be using or referring to this in my MPTE document because we want to use both an MPLS and an IP controlled data plane. And the current way of doing IP data plane for MPTE is a little cumbersome. It's a much better solution. But this requires the EAB. So we'll leave both in. From the point of view of using this solution, I'll just point to your document. And in the MPTE document, we'll say how to use the other method.
[00:22:27] Pavan Beeram: Sounds good. Zafar?
[00:22:38] Zafar Ali: Zafar- ali- Cisco Systems. I had the same comment in MPLS working group that you mentioned when you presented this for and this comment is specific to SRv6 for SRMPLs, not for others. SR is a stateless fabric, and the program is programmed by IGP And it's programmed in a distributed fashion regardless the user scalability and all those attributes SR come from that. It's part of the SR architecture. And what you are doing is you are introducing state in the fabric through our SAPT signaling. The programming is already done. When it was done for MPLS, it was for programming labels, label switch part. So there's a large deviation from the base SR architecture here, and if you want to go there, then you have to modify the architecture document, the base SR architecture.
[00:23:39] Pavan Beeram: We can have a discussion in spring about this, about whether how whether this is actually violating any anything in this architecture or not. At this point, all I'm saying is I'm trying to bring in bandwidth engineering toolkit to a forwarding plane that's either native v four, v six, or SRv six. But your I I note your comment, but we can have a larger discussion about any violations if a if any that are happening because of what is being advocated here. Point taken.
[00:24:07] Zafar Ali: Okay. Thank you.
[00:24:14] Lou Burger: Hi. Uberger. Have you thought about operating sort of tunnels? So you're adding in you're doing IP and IP. Why? Because you're already gonna have to program the data plane and doing nonstop non shortest path forwarding for the endpoint. So what's the real value of doing IP and IP?
[00:24:39] Pavan Beeram: So you're saying, why I mean, you can you can use the address that's
[00:24:44] Lou Burger: You're gonna do n tuple matching anyway. Right? It's not gonna be just on destination.
[00:24:49] Pavan Beeram: It's the issues with the fallback. So if something goes wrong with what gets programmed, you don't want some other protocol using the same route and creating a route for that protocol and taking over, causing loop looping and things like that. Having having a private address used, specifically just like a label, will ensure that the loop free semantics that you get within PLS are kind of mimicked. That was the high level thinking.
[00:25:20] Lou Burger: That that's a reasonable answer. The problem comes up as if you wanna have multiple tunnels that end up at the same place, you're still gonna have to do the n tuple matching. I don't think you covered that in the document, and I might have missed it. Co author wants to say something, apparently.
[00:25:43] Session Chair: Oh. I
[00:25:44] Pavan Beeram: think it's covered, but, yeah, I can respond to it.
[00:25:46] Lou Burger: Okay. I I don't think I I saw that. The other thing is it's interesting to bring in SRV six here.
[00:25:57] Pavan Beeram: And Why not was the
[00:25:59] Lou Burger: Because you already you now have a new document. At the time, I think, when you first presented this, there wasn't the the RSVP SR document. Right? That's new. It yes. So why not cover all of SR in one place?
[00:26:14] Pavan Beeram: This is I mean, there was this is still an IPT document. Right? So it will cover v four v six, and SR v six is the other IP flavor
[00:26:23] Lou Burger: that Yeah. Feels like you might well, it doesn't really matter. The tunnel one was really the main question. Thanks.
[00:26:32] Session Chair: So as mentioned, please give feedback, send comments to the list, and then we will keep progressing. So now we move to the, let's say, the second big topic of the afternoon, and it's going to be the discussion on multipath traffic engineering, which I do believe we start with architecture with. May yeah. So whenever you are done with the discussion, you can come to. Go for the multipath traffic engineering. Is this you? Is it you? Or it is you?
[00:27:15] Pavan Beeram: No. No. That's fine.
[00:27:15] Session Chair: Okay. Okay. So we start first with okay. That you put put the wrong we start with the architecture. Yeah. This one.
[00:27:39] Kireeti Kompella: Hey. Thanks. Can I see your list? Cool. So we've talked about MP-TE. I want to give you an update on where we are with this. And I'll do a quick recap, but I'll keep it short because we we do have time for questions, and I wanna keep that. That's the more interesting part. So if you do have questions on the draft or how things work, you can actually read the draft or go back to earlier presentations I've made. So basically, MP-TE tries to capture the best of multipathing and TE, traffic engineering. And so, essentially, the way we do traffic engineering today, you get a single path from ingress to egress, but multipathing is an interesting idea. So can we actually get the best of both? The other thing is when you do ECMP or or multipathing in general, typically, you load balance equally across the next hops. But here, we actually compute end to end and say, if I were to do load balancing at this node, it looks like I have equal bandwidth on the next hop. But down the line, I might have less bandwidth. So we we talk about optimal load balancing at each node. So the base document captures the architecture and the general ideas. And there are a bunch of protocol documents that tell you how to do instantiate this with RCPTE, with BGP, with PCE, as well as with a Yang model so you can use it with any APIs that you wanna use. Okay. So if you did shortest path routing in this particular diagram, you go from r one to r 12. You can send a maximum of 400 gig from ingress to egress if you use a single shortest path. And if you use multiple shortest oops. If you use multiple shortest paths here, you can sell you can send 1,200 gig because I don't know if you can see it, but there are thinner lines which are 400 gig links and thicker lines which are 800 gig links. But at r two, because you're doing equal equally weighted load balancing, you're gonna send 400 gig on each link even though you have 800 gig available to r three. And so instead of taking full advantage of the bandwidth available in the network, you will only get 1,200 gig. If you try to send more, you'll congest the links to r nine and r seven. If you use conventional TE, you can actually use the full available 1,600 gig, but you'll have to set up four LSPs for that. And so either you can construct those manually or there are ways that different operating systems allow you to do this. But it is four times as much state in the network. Also, when you get on a particular node on a particular path, you're single path to the egress. So in particular, if I'm on the purple LSP, if I get to r four, I have to take the r five link. If I'm on the I don't know what these colors are, but there are two links. I mean, there are two paths at the bottom. At r four, either I will take one path or the other. It's not like I come to r four and make a decision there. In multipath TEE, we have a different way of doing things. So at we have this notion of a junction, which is a node in the DAG, in the directed acyclic graph that goes from ingress to egress. And at each node, you say, if I have multiple next hops, here's the ratio I want you to do the load balancing. So at r two, you say, send 25% to r 25% to r 50% to r three. At r four, you say fifty fifty. Actually, at r one, you also start off by saying fifty fifty across the two parallel links to r two. So this notion of a DAG, this notion of junctions, and the notion of optimal splits at each node is something that MP-TE brings. If you actually had and this is what I tried to mention at the beginning, between r 11 and R 12, you only had a 100 gig link or you had a 400 gig link that only had a 100 gig available, then you really don't wanna put 400 gig from R 2 to R 9 because just down the down the line, you'll get congestion. So you'll have these interesting splits instead of the 25, 25, 50 split. You'll have a one thirteenth I think it was 13 one thirteenth, four thirteenth, and eight thirteenth, some number, whatever. So so you do do the end to end computation and say, what is actually available so that at r two, you send the right amount of traffic to the next hops. If you have a link failure, what we do, for example, in this case, you have the failure of the link between r four and r six. You the the local action, the faster route action is to change the weights. If you have multiple next hops, you just change the weights on the existing next hops so that you accommodate the the failure. If you have a single next hop, you will need a backup or a detour path. But wherever you have multiple next hops, you can just use just change the weights. To reduce churn in the network, assuming that mostly when links go down, they come back up, you can leave the nodes and links that are no longer part of the DAG in the DAG so that all the label allocations you've made, all the programming you've done remains. The only thing you've done is change the weight to the fail link to be zero. So if the link comes back, you just change the weight back, and you're you're in business. So you reduce churn. There's also this notion. Once you sort of get out of your head that it has to be a single path, you can think about multiple ingresses and multiple egresses. So in this case, you have r 12 and r 15 are both egresses for the DAG. This is interesting in the case where you have iBGP multipath or you have dual homed CE that is dual homed to both r 12 and r 15. The nice thing about this is that the increase of state in the DAG is just very little. It's just the links that you see from r eleven, eight, five, and six to the new node, r 15. So the rest of the DAG stays intact. The control plane, typically, when you think TE often, especially if you're old like me, You think MPLS and you think RSVPTE. In this case, we are trying to be you know, put an idea forward, and it's control plane agnostic. The protocol documents layout different control planes for this. And so there's a companion document that describes how to do MP-TE with RCPTE, with BGP, with PSAP, and with Yang. And the Yang model is so that you can use APIs like OpenR or gRPC to to program your network. And so since this is no longer a simple path, we don't use EROs and this notion of here's my ERO and hop by hop, I carry it and pop off, you know, whichever node that have passed through. You instead have path messages that go from the ingress or the signaling source in general directly to each junction in the graph in the DAG. And it says, you're a member of the DAG. You have these b hops. You have these n hops, and this is the load balancing weights you should use. So we still call this a tunnel. That's a hangover from twenty seven zero two and thirty thirty two zero nine. But think of a tunnel. Think of a path through a mountain, you know, caves with multiple ingresses, multiple egresses, and you make your way through it. That's the kind of tunnel you should think of when you think of MP-TE. The data plane, this is why I mentioned to the previous speaker that the IPTE is interesting because we want to use MPLS. We want to use IP as well. The base document has some ways of doing IP tunnels and addresses maybe partially lose concern about if I want multiple DAGs to the same egress. How do I do that without using up a whole bunch of IP addresses? But it's a simpler solution to use multiple IP addresses if you have them available. I mentioned loose name and things just start well okay. There's a lot of interest in MP-TE, my coauthors. One is from Verizon. One is from Charter. It used to be Cox. One is from used to be at Oracle. Now we're at Arcus. This reflects interest in the notion of MP-TE from multiple service providers, cloud providers, and other vendors. I've also talked to many people about this, and they're looking forward to both standardization as well as implementation. So I should mention that we have started implementing this. We have a prototype that's focused on MPLS and RSVPTE. But as we start doing the IPTE stuff, we'll fold some of that in here. We also have a very early prototype with BGP. There's also a partial implementation of MP-TE with BGP in FRR. There's a workshop planned in October to provide SPs with a hands on lab where they can play with MP-TE. I think that's a good place where they can give us feedback on the ideas and as well as feedback on the CLI that we provide and and the telemetry we provide. There have been multiple side meetings as well as hackathons that focus on MP-TE. So there's been a lot of discussion about MP-TE, not necessarily on the list, but at the IETf. And and so we think the document is fairly mature. It's, of course, a long way to go. What we're asking at this point is to do a working group adoption and then take it from there. So I'm gonna stop there. We'll take questions at the end.
[00:39:21] Session Chair: Yeah. Okay. Also, we have apart from this, then we have the the draft for the solution with segment routing, and then we have an open time for discussions. I think this is when we can enter into the I now prefer also technical questions. If there are any, please ask.
[00:39:39] Pavan Beeram: Yeah. Let me do give a quick update on the RSVP signaling document and the young data model document. The signaling document has gone through five revisions. In the latest version, we just had mostly editorial updates. The signaling sequence examples that are there in the appendix, we cleaned up cleaned that up a bit and reflected what we actually have it in the implementation. There was a missing reference. We added that, and we also tightened some of the procedures to ensure that there isn't any ambiguity for implementers. The as for now, I mean, the big update is that we do have an implementation. We it's based on what's currently in the document. It's sufficiently baked, would say, for the working group to adopt it and refine it further. With the yang data model that we have, there are two modules. One is the MP-TE tunnel module, which is used at the tunnel originator, and there's a MP-TE junction module, which which is primarily for manipulating junction state at the junction nodes. The new revision we did I mean, based on our implementation and based on the conversations that we had when we demoed it, we have added a few knobs. The big the the interesting thing that we added is what we call DAG span constraints. So these would help you play with the shapes the various shapes of the DAG. You can specify how many junctions they need to be in the DAG, how many next stops they need to be at each junction. We have knobs that would help you play with the the slack. The based on the optimization objective, the metric margin options that you that are available would be different. We provide hop constraints like limiting the I mean, making sure that you pick only t links that have a certain amount of minimum available bandwidth be part of the DAG. We also have a compute only option where the operator can instantiate the DAG in a compute only mode, get comfortable with the shape of the DAG before it go going and signaling and provisioning it. Usual timers like optimized timer, retry timer, they're also part of the model. We also made sure that the groupings are consistently used across both the modules, and there were some based on some operator input. We also renamed some of the leaves. Again, like with the signaling document, this is sufficiently baked, when we have been revising it over a year now, and we do have an implementation that validates the model. So I would like to think that it's at the stage where the doc where the working group can embrace it and run with it. With that, let me ask Andrew to come over.
[00:42:47] Session Chair: So then let's go for the SR based solution, and then we will go into the general discussion of the topic.
[00:43:23] Andrew Stone: Alright. Good afternoon, everybody. So I'm here to talk about MPTE, you know. Fortunately, Creedy's already laid the groundwork, so I get to skip a bunch of stuff. I'm here to present this on behalf of the coauthors, and this is focused on segment routing. So Creedy just talked about what MPTE is. We have a proposal here about how can you achieve MPTE using segment routing. And, fortunately, if the mic if the there we
[00:43:46] Session Chair: go. Okay.
[00:43:47] Andrew Stone: So like I mentioned, it's achieving MPTE, except specifically how to do it with a controller. So the solution is oriented about solving MPTE using a controller and segment routing. So all of the behavior that Creedy was commenting about, eCMP, engineering, Slack, computing a DAG, signaling a jag DAG, the concept of a junction node realized with segment routing. So you're using a controller, and you're signaling down segment routing constructs with PCEP, BGP, NetConf, whatever you wanna use, the usual stuff you use today. And what it does is it introduces this concept of a junction segment. And so, really, a junction segment is deployed on a junction node. Right? So using that same kind of terminology within the segment running realm. So it has an incoming SID. That SID is a binding SID. And its outgoing SID less gives you the forwarding outside of that junction node. And so the outgoing SID list contains the path or the segment routed path between junction nodes plus a junction SID, which is just the binding SID of the next downstream junction node. And, of course, it can carry weight. So you can see on the the diagram that example, you know, I'm going from a to h and the the traffic at a, the ingress, it splits. Further downstream at c, splits again. All of that is weighted on each junction node. So the junction segment itself to actually signal this into the network, what the proposal is is to actually just reuse what's already been defined, which is an SR policy candidate path. So you realize the instruction of that junction segment on using an SR policy. So as we know, an SR policy has head point head end endpoint color. What the proposal basically is is that because a junction node naturally goes to multiple downstream nodes, the endpoint is a null endpoint. That's part of the architecture already. And the color actually maps to the junction ID or the MID, and that is actually tracked by the controller. So the end result is the a junction segment is really just a candidate path with the head end of that junction node, the color which is the mapping to the DAG, and then outgoing SID list and the binding SIDs. So there's an example here using MPLS. The draft itself is actually agnostic for most part about whether it's MPLS or SRV six because it's really just it's reusing and reimplementing what the SR policy architecture covers. So in this example on a, on the ingress, I would have two outgoing SID lists. For this example, they're weighted equal. So 50% goes to b, 50% goes to c. On node c, so the green box on the far right, is a junction node. On that junction node, I'm installing a junction segment. So it has a binding set. And then as well as outgoing set list. In this case, it's weighted. So 40, 60%, for example. So you notice the the label stack from a's perspective, its SID list is simply the segment routed path to reach the next downstream junction node or potentially an an egress and a binding SID, which is that replication SID. So the actual SID list on the ingress doesn't even realize it's actually part of a DAG. From its perspective, it's just forwarding the outgoing SID list. And from there, it might branch on. So because it's leveraging binding SIDs, one of the aspects of segment routing, obviously, is to reduce state in the network. So binding SIDS can become hierarchical. So if you compute a DAG, signal it in the network, that DAG can be reused by further upstream SR policies, for example, or segment routed tunnels, which they themselves may be DAGs. So if you really wanna go quite extreme, you could have a DAG that uses a DAG, which uses a DAG and so on. Right? It really depends how how crazy you wanna get with the computation. But for large scale intra area, intra domain topologies, this allows at least reuse between those. So some other properties that are that are really being inherited from SR is that, obviously, the protocol signaling. So I can mention BGP, PCEP, NetConf. So in the case of BGP, you could signal a BGP or policy to signal these junction nodes, PCEP, you know, PC initiated, for example. The other attribute, which I kinda commented, is between each junction node, because you have segment routing, you have the IGP, you don't need to necessarily signal hop by hop. So I gave this example if I go back. See in this picture on a, a going to h, you don't need to program any state on d or g. You can use a segment list along that bottom part of the topology. Protection, reuse TLFA. So TLFA here is not actually to protect the DAG or the n 10 DAG. It would be protecting the SID list between a junction node to another junction node. So really like a section of the DAG. Unfortunately, I don't have to explain the the multi egress. Right? Already mentioned that the loss of a single segment list doesn't necessarily mean that you lose traffic. So you can tolerate a junction node losing one segment list. Perhaps you need to rebalance for traffic and congestion and so on. But you've got that kind of built in protection if TLFA happens to, you know, time out or fail or whatever it might be. Multi egress supported because, again, the SR policy construct supports null endpoint. Multi ingress gets a little bit challenging or different because we don't really have signaling per se, for example, in piece up to say, you know, two head ends are part of the same, you know, mountain. So, you know, the same tunnel, the same mountain. But in theory, at least from a controller side, because the controller is in the picture, if you do wanna do multi ingress, you could essentially associate these things on a on a controller level. And then lastly, optimization. It it shares some, you know, similar behaviors of multicast I find, which is you got your local optimization and your global optimization. So the the document kinda just describes some kind of procedures, high level procedures on how you can deploy all these binding sits throughout the network and if you need to optimize, what kind of actions you might have to take. I'll try to go a little bit faster because we only got three minutes. So there's a section on liveness, how do you use SPFD. So it basically comments on run SPFD on every segment list. It's really the gist of it. And then for monitoring, if you wanna do ping and trace, very similarly, run ping and trace on every outgoing segment list, reaggregate on the controller, and kinda get a view of what is the worst case delay or the average delay that might happen throughout the tag. And, yeah, so the next steps are feedback discussions. So this work is taking place in spring. I wanted to bring this to the TEAS group just because, you know, MPTE, the architecture is being defined here just to share that this is, you know, one way to realize the tag and keeping in sync with that those concepts. So, yeah, thank you.
[00:50:31] Kireeti Kompella: Compeller. So two things. One is thank you for the draft because it actually captures the spirit of MPTE because you are doing with the binding sit and the junction said, you're doing hard I mean, load balancing at every node, not just at the ingress, which you could do
[00:50:48] Andrew Stone: Every node where you split.
[00:50:50] Kireeti Kompella: Yeah. Every node where you have a split. The second thing is your comment about hierarchy seems to fit very well with multi ingress. So don't know if you could just parlay that into multi ingress.
[00:51:03] Andrew Stone: So the the draft for multi ingress, the draft actually comments on that. I kinda skipped over some of the nitty gritty details that are really segment running specific. But in the SR policy architecture, SR policy has color. Right? That's your intent. That's your steering. That's kind of your implicit steering of service traffic. Sure. So the draft actually describes that the SR policy on ingress, that color value is actually unique to your dag color that you wanna use. That gives you two properties. One, you it helps with make before break global optimization. The other is if you have multiple ingress, the steering on the dag can be reused. So as long as your egress is common, your ingresses can leverage multiple DAGs. So in this diagram, for example, x might be an ingress PE in a in a simple area topology. X might be an ingress PE. Y might be a different ingress PE. A is a border router that they both have, and that's your entry point into the DAG. And by border, I mean, like, a ring border or something. Right? So as long as they're going to the same destination, those DAG reuse. That's the kind of the intention of it. Yeah. Cool. Thank you. Again, it's all up to the computation, really, is at the end of the day. But the the key thing is the signaling, however you wanna compute, use it, reuse it, and go from there.
[00:52:16] Kireeti Kompella: The computation is the fun part.
[00:52:18] Andrew Stone: Yes. Exact that's the fun part. Yeah.
[00:52:20] Session Chair: Thanks. Thank you. So any more questions for this specific draft for the out of segment routing? If not, then I think we can go to the general questions for MPT. So and what what even we can take? Lou no. You were in the for this it was for the for. Go ahead, Ben. We are now now we are in the general slot for general m MPT discussions.
[00:52:59] Lou Burger: Hi. Lou Burger, probably wearing a couple of hats. I I think this is really interesting work, and I think it will help us in DETNAT where we have the need for DAG signaling to support what's called RAW, radio aware radio aware of DATNET, where the architecture talks about DATNET, but we have no solution. So that aligns very nicely. The other thing that we have in NetNet, which this could help with, is support for pre auth where we do basically a form of one plus one protection. And we talked about this briefly in one of the earlier IETFs, one of the earlier presentations, is that if you allow for not single delivery at a junction but multiple replication, then you can support either one plus one or even one for n protection. And that is another thing we have in DETNET. And, obviously, in Ts in the past, we've did one plus one and one for one and one for n. So covering that would be interesting. I note that there is a protection section that's blank in at least one of the documents, so maybe that would will be will lead to it. But thanks.
[00:54:22] Session Chair: Saffar? Or do you want to reply, Kireeti or at or
[00:54:29] Kireeti Kompella: Kireeti replying to Lou, especially on the second part. There is something called MC-TE, multicast TE, which is not point to multipoint, but allows replication. So you have a segment and you can say or you have a junction at which you want to do not load balancing, but replication. And so that might help you with your I wanna send multiple packets and pick the right one when I get to the egress. So I will talk hopefully about multi MC-TE in a second, a couple of seconds, so you can come back and give us whether it fits or not at that point.
[00:55:14] Lou Burger: Sure. That sounds great. To be clear, I'm saying we look for you to provide solutions that help us at NetNet, not that I'm interested in doing the work. You know, I was thinking more of as a chair that it would help us in NetNet. So if you are looking for use cases or additional support, I think if you bring it into, say, this will support these dot net use cases, you'll get people saying, yes. We like that.
[00:55:41] Session Chair: Great. Thank you. So, Safar?
[00:55:44] Zafar Ali: Yeah. My comment is about the compiler tease MPTE. So thank you, Kriti, for the presentation. But the, problem and solution is fifteen year too late. It has been solved, implemented shipping using SRT policies. There is an RFC ninety two fifty six. You would like to take a look at that. It has detailed all of these aspects that you talked about here. And then, thanks to Andrew for, presenting that, how SR solved the problem for MPT. It's an informational draft which proved that, the construct already exists and people have been using and shipping. It's it's all shipping. I I don't have I mean, problem if if we want to document it, it's fine. You wanna generalize whether turning is fine, but this I'm mentioning the next part because the document does talk about s r v six tunneling in it. It has the content. So I find it a little bit challenging and difficult to read. When a document posed this problem for fifteen for fifteen years as something that had been invented today. It is how it's written. That's that's how I read it. Okay? So it was represented like this, and then it's referenced as r v six and does not even acknowledge its RFC 9256. Instead, s r v six reference, it's SRH, which is not relevant for this top for this discussion. So I don't know what is this, but but without acknowledgement for the proper work that is already done, I consider it as academic dishonesty. I I think I like authors to consider this that that at least reference the right thing, position it correctly. Thank you.
[00:57:47] Session Chair: You wanna reply?
[00:57:49] Kireeti Kompella: Yeah. I just wanna thank, Zafar for calling me academically dishonest. I'm I'm completely thrilled. Thank you.
[00:58:00] Session Chair: Okay. Janus disappeared from the list. So I don't know if you want still want to no? So if there are not any more questions, then I will start raising, first of all, the poll for interest on the MP-TE topic. So the very first question to ask is if this is a topic for the this working group. This is timely now. I have heard some voices saying that it comes a little bit late, but it is coming now. So K. So we are seeing a reasonable number of support. I mean, not as much as power aware traffic engineering that we reached 30 people, but here we are 18. We have three voices with the no. For the people that is saying that it is not an interest, is there any new argument different from the ones that we have already heard before that you wanna raise now? I mean, otherwise also, please, those arguments, voice them in the list also, please, so we are we can be aware of them. But here, I mean, it seems to me that there is a fairly reasonable number of support. As I say, not not as much as in the power of our traffic engineering, but but it's still it's still a good one. And then let us start at least first with the, let's say, more, I would say, agnostic document, which is the what? I would say this document that the document that presented for the architecture, if that was, it's a good starting point for the architecture itself. Okay? So it's, I would say, protocol independent, young model independent. Okay? These are we have seen there are RSVPTE based solutions. We have seen the Jamo that presented by him. We have seen the server routing solution, but this is the the general document. So we are about two two thirds even three three quarters even we are almost the same number as people have said that MP-TE was worth. He's saying, yes, there are still a few without opinions, so I guess they need to read the draft in more detail before pressing opinion. There are a couple of voices against it. If they are it's because they are like, the ones answering before that it was not MP-TE was not. But if not, if it's like, okay. Yes. You believe MP-TE is a good topic and the architecture here is something that you don't you don't think is a good starting point, please raise your voice now. I think we would like to hear those those opinions and and why not? Here is are just listening. This is not the discussions here are not personal. It's just technical, I guess. So please raise raise the voice because I think it's very it's very interesting hearing hearing all the opinions and all the views. And, also, if you don't want to stand up and show your face, just you can also use the list to to send it, please. But here, there are two voices. So okay. So seems almost the same number of people that said yes to the MPTE in general is good with the with architecture. And then I will go quickly through the through the the the other two. I mean, we'll take also the then later on the adoptions at each other time. K? But then we will go for the RSVP database. What? The RSVP or data. Yes. I will go for the I will start with the for the the data model, which is also more more generic. And then the more specific is the recipe. So we'll start with the with the data well that was presented by by Pavan. So here, for this data model, how how many do you think it's a good starting point? Of course, of those who you have read the draft and had seen it. So here, we have a good number of support. Of course, not as much of the architecture. I understand that. But we are in a very good numbers here. We are short of no opinions. I guess we need also more time to re go through them through the documents. And then finally, I would go for for the RSVPT base one. K? So here, also, if the for the document, how many of you consider that this is a good good starting point? Almost as the same as the even more than the the young model. But, also, we have a lot of no opinions here. So so I believe still the two documents, the signaling and the the JAM model, I mean, you can progress a little bit more. But I think that the architecture seems seems quite to have quite a quite a good support right now.
[01:04:59] Andrew Stone: Okay.
[01:05:00] Session Chair: So I think with with this, we can terminate the section on multipath traffic engineering. And then we can jump to the next part of or like the third part of the session, and we will start with the current 5,000,000 network size 95 in IP header for Qsurance. No? Multi press. Ah, on MC-TE. Okay. Sorry. Sorry. I just I bypassed your slot. Okay. So it's for.
[01:05:41] Kireeti Kompella: So I'm gonna go through this quickly. This is the first time this is being presented. Fundamentally, it says, let's use the junction concept from multicast multipath traffic engineering to have a more efficient forward doesn't work. To to to be able to signal point to multipoint LSVs more efficiently. And yeah. Here. So traffic engineering for multicast traffic has proved to be fairly interesting. We do have several deployments of this that we know of, and I'm sure there are more than that. So the thing is and and the people here that have more history on on the development of the point-to-multipoint LSP document. But as I said, this has turned out to be fairly important bandwidth reservations for multicast traffic, the ability to choose, you know, to do traffic entering over which links and nodes the multicast traffic will go, all of that has proved very interesting. And several service providers have deployed it. The thing that you had is in defining point to multipoint LSPs, there were multiple approaches that were considered. One of them was a tree ERO. One was I'm sure there were others. I'm looking at Lou because he probably has more history on this than I do. There's no prob probably with the probability of one. But, anyway, so the point is at the time we were fixated on an ERO. And once we sort of got away from that and came up with the junction idea, the idea that you use junctions and direct signaling from the signaling source to every node in the multicast tree, I think we can do a lot better. So that's basically the proposal. And so here, the really, really, really degenerate case of a point to multipoint LSP that Jennifer okay, that has one source, a lot of intermediate nodes, and many leaves. And so if you were to create a point to multipoint LSP using the sub LSP concept, which is where the the RFC ended up, you would create seven sub LSPs. It probably says here. So you'd have seven sub LSPs from the ingress to the one to each leaf. You'd have a lot of PSBs and RSVs across the network. And so if you add it all up, you get 91 PSBs, 91 RSVs across the network to support these seven leafs. If you use a junction notion, you end up with we we have this notion of a JSB, a junction state block, which is a combination of a PSB and an RSV. An And you would essentially have one junction state block in every node except the well, on basically, every node. The junction state block on the pre egress would essentially say, I have one p hop and seven n hops. The junction is essentially a multicast junction, not a load balancing junction. So the amount of state that you have here is way, way less than you would have by creating multiple sub LSPs from ingress to egress. So that's the high level idea of using the junction idea in point to multipoint LSPs. It doesn't add any new value. It just takes the state in the network down considerably. So the other thing that it does is if you actually remove an LSP sorry, remove a leaf or add a leaf. So in the case, at the top, you see a red node that is a new leaf. At the bottom, you see a a node that was a leaf that has been removed because it's, you know, the top leaf did a join, the bottom leaf did a leave. The churn in the network is very much smaller. Nothing changes across the the bulk of the LSP. The pre the penultimate hop essentially says, I have a new next hop, and then it says, I have a NextRob that's gone. So there's churn, of course, at the new leaf and the leaf that goes away, and there's churn at the p the PHP, but everything else remains the same. And there's no churn also in terms of bandwidth reservations and so on. So, again, it's not, you know, earth shaking. It's not new concepts, but it does allow you to create point to multipoint LSPs with a lot less state in them. So at this point, I just want to throw the idea out and have you guys sort of mull over it. At some point, we'll come back. Maybe we'll have a prototype implementation. We can do an apples to apples comparison between state using the junction concept versus state using multiple sub LSPs. The the example I gave was very degenerate, but I think in any topology, the junction concept will have less state than multiple sub LSPs. So that's pretty much all I want to say. At the next IETF, we'll come up with more details and maybe how to do some signaling of this using RSVP and maybe BGP as well since we're down that path. But at this point, I just want to, you know, make you guys aware of it.
[01:11:56] Session Chair: Okay. Andrew?
[01:11:59] Andrew Stone: I understand Nokia. Unfortunately, I won't make a segment writing version of this because it looks very, very similar to replication segment. So probably best to see how the replication segment's doing it. So especially in the BGP signaling, we actually there's there's a draft in p sub to do replication segment and point to point to policy already. So if you were to do, for example, a p sub signaling to me, where this gives you more than what the SR solution does, like, I I I would struggle with that. Same with the BGP signaling. The BGP already has it. You it essentially does junctions just the replication nodes. So I don't know now from an RSVP t signaling if that's what you wanna do. I mean, that's what you wanna do. But it it there's a lot of overlap there. So the other side is something to think about long term that actually gave us a lot of lot of work and text to figure out was optimization. And so doing optimization for the replication segments, global and local optimization, that that's not trivial. And I just wonder in a DAG design, if you're gonna do optimization on the DAG, obviously, you can tolerate things differently. You can reoptimize differently. Whereas in the multicast, it can loop really badly, really quickly. So I I struggle to see if the the DAG signaling concept, you know, with RSVP, how complex that optimization might get. So just a few comments to say that there's there's overlap here. There might be reuse. It's worth kind of exploring that whole hierarchy of replication segment.
[01:13:29] Kireeti Kompella: So Yeah. Thank you. It's a good comment. We will absorb it.
[01:13:37] Changzhou / Dan: Hi, Dan. So I guess following in from sort of the the optimization question, does this still consider things like Steiner versus non Steiner computation minimize cost of the overall tree versus shortest path, etcetera? And so would that sort of be part of the PSIP extensions?
[01:13:58] Kireeti Kompella: Like So the computation is not specified in any of these documents. I think you can do all of those different optimizations. So Steiner tree versus whatever else you wanna try. Having done that, now you want to signal and typically, these are trees. In principle, you could have a combination of replication junctions as well as load balancing junctions. You have to be really, really, really careful not to have packet replication at the end unless you really want it. In some cases, you do. But, again, the computation is orthogonal to this. Once you've decided what the shape of your tree is, assuming it's a tree, you can use this concept to signal it versus using multiple sub LSPs.
[01:14:57] Lou Burger: This is a long context switch. I mean, we're going back a lot of years to I can't remember. You might have been chair of the working group, the CCAP working group at the time we did this. It's that long ago. But you're making me remember some conversations we had with Rahul Agarwal, who is the one who came up with the sub LSP. Part of the reason that we ended up there is it allowed for different implementations to do different things. And if I have it wrong, Bhavan's done much more on the implementation side than I have, at least, particularly recently. So, Bhavan, you can correct me, but my memory is is that you could either signal each sub LSP individually or you could signal them as a group. And that if you signaled them as a group, you had the advantage of collapsing the state, while if you signaled them individually, you ended up with that
[01:15:51] Kireeti Kompella: Yes. Degenerate thing.
[01:15:53] Lou Burger: Degenerate case. Right. Yep. So my question back to you is, are you are the advantages more because of an implementation choice than a protocol design design choice? And that can you it may be that you can implement your junctions using the same sub LSP concept, but instead of doing them as signaling each individually, to do them as originally envisioned as a group. Or and, I I think it's a worthwhile analysis and to make sure we're just not coming, overcoming a implementation choice rather than a protocol design choice.
[01:16:33] Kireeti Kompella: So it's an excellent question. And I did go back over the the RFC, and I did notice that you have this. I think a couple of things. One is the implementation choice that we made is actual sub LSPs with lots of path messages. So the example I gave is more reflective of a particular implementation rather than the the choices offered in the document in the RFC. But there is a thing that in even in the in the RFC, it has this notion of a group, which means with a single message, I'm gonna send you multiple things
[01:17:12] Andrew Stone: Yeah.
[01:17:12] Kireeti Kompella: As far as I understand. So you're still gonna create a lot of PSBs.
[01:17:16] Lou Burger: No. It's a single PSP.
[01:17:18] Kireeti Kompella: It's
[01:17:18] Lou Burger: yeah. Single This was a compromise. And I know we're going back to ancient history. This was a compromise to allow a particular vendor, you know, to more quickly implement a solution. So it definitely was a the sub LSPs was definitely a compromise.
[01:17:33] Kireeti Kompella: Okay.
[01:17:34] Lou Burger: So I'm not gonna tell you it was optimal. It was a compromise on a standard group to allow different people to come to the table and say, I really wanna signal it with a single PSP, and someone else to say, I really wanna implement it fast. And it allows if but the individual sub PSPs allowed me to get there faster.
[01:17:54] Kireeti Kompella: Okay.
[01:17:55] Zafar Ali: So
[01:17:58] Lou Burger: I I think you're hitting an implementation choice and wanting to revisit that. I would just ask to go see if you can revisit it without changing with minimum change to the protocol.
[01:18:10] Session Chair: Okay. Okay. So please just we can continue the technical discussion later just because we have a couple of points. And, also, suggestion is, as also as you have done in the other MPET draft now with the multicast, it would be good also to have some operators, some carrier where you can also try to prototype it, and we can we can have also the data.
[01:18:31] Kireeti Kompella: Thanks for the questions.
[01:19:02] Andrew Stone: Okay.
[01:19:03] Changzhou / Dan: Okay. I will try making it faster. Okay. However, that's this is Changzhou from China Mobile. This is my first time to attend the Teams meeting. And today, I will present the draft of Carrie five g network slash identifiers in IP header beyond the the three d p manager domain on behalf of our co author, Jerry and Gong Yu. Let's start from the problem statement. And as we know, five g end to end network slicing is standard standardized by three g p p across run access network and transport network and code network. Units like unit identified by a 32 base slice ID called S-NSSAI. And so far, it is relatively mature in storage g p v manage managed domain standard device, search VP and ITF standards, respectively. But when the traffic, access the I p search VP management domain, while I u p f and enter the IP backbones, the slice ID will be no longer be visible to standard routers. As a result, IP routers will or can or cannot differentiate to the a per per slice traffic and cannot guarantee the correct or precise. This is a problem our draft is trying to address and clarify the relationship between our draft and existing ITF works. And, basically, we should say that the draft is complementary to current ITF works and existing ITF slashing works as a cover transport network identified by local identifier and our our drop to covers at the backbone network, which is outside of switch switch PP management network domain. And the solution our solution has major three major points. The first is a a boundary encoding, and the second is the encoding format, and the third is the the slides we are to us at the assurance. For the encore baudering encoding, the full uplink traffic ingress, you have embeds the sessions, slash ID into IP headers and for traffic, the service provider provider service just inject the slice into the downlink IP packets. And regarding the in in calling format, we just consider r p v four of option option hop hop options, And the IPU four is not in scope because I Tf no longer developers do IPU four extensions. And looking to the detail encoding, I shall say that we do not define quite refresh refresh new encoding for our solution, and we just leverage on coding networks in IETf-six man working group. And we're just following the format of network resource option defining draft of six man enhanced with with your waiting ID. And the two major fields, you can see that it contact type and natural resource ID can carry our option with a global unique S-NSSAI. And go through the procedure for QS assurance for control plane, the IP backbone management system just choose a precise parameters and then translate to the set SRS into the actionable QS policies, then process the policy to slash aware nodes. And the slash aware nodes for that play, that they can just check the slice option. And if the option exists, just following existing queues mechanism. And if not existed, and just forward the package as normal with best effort. From the deployment deployment perspective, I think our solution is quite highly practical since it it is worth incremental up upgrade of visibility. Only backbone edge routers and the interested intermediate nodes requires upgrade to pass the slice ID. And with pasta, the slice ID can leveraging the the nodes can just leverage a current Excel infrastructure and the mechanism. And the the solution is also easy to extend to and to external enterprise and the CDNs. Just to summarize, we proposed a nine according to g p p global byte size size ID directly into I p v six extension headers to guarantee to us over unmanaged IP IP byte modes. And the solution is backward compatible. And we just can just be with minimal nodes configuration. And going next, we welcome review comments and discussion from the this working group. And we will also coordinate with six man and with six ops work groups to ensure alignment on IPv6 hop by hop options with SASE. That's all. Thank you.
[01:25:01] Pavan Beeram: We were not planning on taking any questions. Nathan, if you can have a quick word. Go ahead. You have thirty seconds. Yeah.
[01:25:11] Nathan: Hi. Nathan from Google. Yeah. I just wanted to say that this feels like a very blunt sort of approach to the problem, and I I I'd like to understand what other things you've considered that don't involve adding 12 bytes to the the packet headers. And also, I'm curious about the practical implications of the slice ID. Whereas if it's really about QoS, it feels like the slice the slice type should be enough. So just Yeah.
[01:25:43] Pavan Beeram: If you can respond on the list. Great. Quan, you have five minutes. Quan, you have three documents in your slide deck. There's only one that's actually TEAS specific. If you can focus on that and just introduce the others, that would be useful.
[01:26:14] Quan: Hello, everyone. I'm from ZT. We have proposed some three new IDs to provide some young data models for HPC AI data. Their HPC AI did young data models can provide the HPC AI workflows, which are commonly managed by their work node managers and or chat with the sisters systems. So we define some schedule a drop metadata, and then we define our service intent to to send the service where requested, and their their scheduled drop can be inserted into their service intent. And we also finally define our ternary realization and to identify the natural resources to to be used to realize our surface intent. So this is the relationship between the three young data models. And the first one, the HPC AI schedule a drop method model, it it defines our schedule of facing metadata model for the HPC and AI. We define their schedule a drop metadata, the scheduler, and their their work note. And they're finally need a job to to to be as a as a scheduler, visible as as q execution object can be associated as associated with their work note. So this is the young model we have defined the trees. Second one is HPC AI surface intent model. Oh, sorry. Two models. The this document defines a common service intent model for the HPC AI work notes. So this we also define the service intent intent instance and their mission control admission state. The model allows their their work node managers and allchestrator platforms to express the end port, endpoint communication pattern, timing, performance, and date movement, and such as some other requirements for the network surfaces. And, finally, the the there's in did the self intent oh, sorry. This is the final turner realization model. It defines our internal realization model for the the the the the HPC and AI service model. It describes how our source intent can be associated with our network realization state. So this is the first presentation. If you are interested, we can discuss offline. Thank you.
[01:29:08] Pavan Beeram: Thank you. I mean, the first two models probably are not for teas, but yeah. I mean, you the third one where you are augmenting the t tunnels, maybe we may find a home here, but, yeah, make sure you socialize that in the. Thank you. That brings us to the end of both the t t sessions. See you all in San Francisco. We can always hope.