Session Date/Time: 22 Jul 2026 07:00
[00:00:06] Joel Halpern: IDR could do a good job of making this one feel like there were a decent number of people in that small room, it probably was.
[00:00:23] Bruno Decraene: So welcome to Spring Working Group. We are on time and we have a full agenda, so we're to start. This is not well, so you should not well not wait. You should read it because you already comply agreed to comply with it. If you have any question, you can ask a question to the chair of your heady. This is the meeting tips. Nothing really new. But again, if you're in the room, you still need to join with the remote tool, especially if you plan to make a comment, but even if you don't plan to make a comment. And for remote participants, please unmute yourself if you don't plan to speak to avoid the background noises. Thank you. Again, minutes are collaborative, so you're welcome to at least check and help, especially if you make a comment. It's good to double check that your comments were appropriately recorded. In term of document status, we have adopted two working group since IETF-one hundred twenty five. One is validity of SR policy candidate pass and second one is flexible candidate path selection of SR policy. So it's now working on documents. So everyone is welcome to review and help progress the documents. So if you have time in your way back on the plane, you're welcome to look at the document and the changes. We have an adoption call running currently for three weeks. So we had an extra week to account for this meeting week. And the adoption ran until end of July. The draft is on the agenda today. And we have two last call. One is the SRv6 for Redundancy Protection. A new version has just been published this week with some significant editorial change. Again, it's at the agenda. The second last call is segmenting IPv6 secondurity consideration. It's the second last call for that document. Authors have just published Version 14, so thank you for the Authors. To address the comments received during the last call, We have received some positive acknowledgment saying that the comments have been received, especially from Jean Michel Combe for security considerations. Thank you, security directorate. But we're still missing two. Other than that, we believe the document is ready for publication, except anyone disagree. And finally, we've submitted a document to ISG. It's not under AD evaluation. It's under ISG evaluation. It's introducing resource awareness to SR segments. The IDE has just been revised. And it currently has four discusses, so some work still in progress. On the agenda today, we have a topic about handling ICMP for SRv6 VPNs. There are two short solutions being proposed. And to summarize and also to save time on the agenda, we have asked the authors to make a shared presentation with a shared description of the problem space, a shared network topology, and then the two presentation of their solutions. And others agreed, so thank you to the others. We believe the solution space is for six man, but at least the requirement is in scope of premium. This is the agenda for today. Again, it's full. Any comment? Any agenda bashing? So if not, we are starting with spring working documents. And the first one is Sr-six for redundancy protection.
[00:06:06] Balazs Varga: Okay. Good morning, everyone. My name is Balázs Varga. And on behalf of the co authors, I represent the status of the redundancy protection draft. Just a a small recap. So this is a a draft which is providing a generalized protection mechanism in order to achieve high availability in segment routing networks. The draft defines a new seed. This is the redundancy seed, the r seed, and that is the seed which is used to point to the redundancy functionality of the node. If you are defining an r seed, then there is also a related redundancy policy. This is defining which flows are served by that redundancy functionality, but configuration take effect on the flow, whether it is doing replication, elimination on the specific node, and if it is doing so with what parameters it is done. We have to note that the the concrete algorithms used for the elimination functionality, this is out of out of scope in the draft. And we have also appendix which defines a complex network scenario, how to use this RC and the redundancy functionality. There is also a DetNet related draft that the draft in the DetNet world describes how to use the RC for the DetNet service sublayer functionality. So so the draft is covering wider use wider range of use cases and protection topologies including but not limited to the DetNet scenarios. So many other use cases are also mentioned in the draft. So it is a a very general tool for a service six networks. The current version of the draft is version eight. There were lot of changes in the document. They have not affected the technical solution. They were made in order to make much more clear and easy to read the document. We have received a lot of comments during the working group last call. We have received also very focused and detailed comments from Alvaro regarding how to improve the document. There were many things which were implicit there in the document, but we have decided with the update to spare them out explicitly in order to make more easy to understand how this RC should be operated and work. I have listed here also the major changes in the document. So we have somewhat restructured it, and section three is now where all the building blocks which are used by the redundancy functionality are described in detail. Including the redundancy policy, this is where we have improved the document and and that subsection as well to to have all the detailed information, but have to be contained in the redundancy policy in order to being able to to implement it properly. There were two new sections added to the document. One is related to the implementation. We have also announced on the list that there are two open source implementation which are implemented this RCs and also implemented related algorithms, how to do the elimination even if these are not part of the of the draft itself. And there was also a section on operational consideration just to highlight when you design such a network, when you design your usage, what you should consider in order to to have a proper network update. And we have also received comments on security. So here, the security specific aspects were also updated, extended. There were also some minor clarification in the in the security section. So this is where we are currently. And, also, we have received yesterday list of comments from a early review from the routing directorate from from Andy Smith. These comments related very much to the fact that this is the first time that we are adding not only one, but two arguments to a seed. And these arguments can have various sizes depending on your network topology, number of flows you have in your network, and the use cases. So that is something that that we intend to address in the next version of the document in order to make that aspects even more clear. And as because this is the first time that two arguments are defined with some variables in the document, we understand that this is something to be improved in the document. So this is where we are currently. Any questions, comments?
[00:11:37] Bruno Decraene: Any question? What's the the roadmap for the next version?
[00:11:43] Balazs Varga: We we plan to have it until the end of the summer. It will be version nine. Yep. That is the plan.
[00:11:52] Bruno Decraene: Okay.
[00:11:53] Balazs Varga: We understand that we we start vacation period for many people, So that that is the plan that end of the summer, we will definitely have it.
[00:12:02] Bruno Decraene: We would likely do another last call after after the the new versions.
[00:12:08] Joel Halpern: Given the restructure restructuring that seems to make sense.
[00:12:12] Bruno Decraene: So we see we see with the new version, but maybe we'll do another last call given the size of the changes and the technical technical point with the two arguments. Yeah.
[00:12:24] Balazs Varga: Yeah. So all all the intention was to make it clear the text. We don't think that there are any technical changes, but let's double check it. Yeah. Okay. Thank you.
[00:12:34] Bruno Decraene: Thank you. So next is segment routing policy extension for network resource partition. You have a comment?
[00:13:47] Ran Chen: Morning, everyone. I'm from China Mobile. The title is the segment routing policy, the exterior for network resource partition. We recapped the draft. As our policy is a set of candidate passage consisting of a one more segment list and the associated information, and the- the NRP is a collection of network resource located in the network. So this draft defines the experience to the SR Policy architecture for associating SR Policy with RRP. And we have made the updates since WG adoption. We clarified the NRP-ID's rule based on AD's review. NRP ID is used in candidate pass validation. v08 does not participate in candidate pass selection, and we separated the terminology. The NRP ID is used for control management plan, and the the NRP selector ID is used for data plan encapsulation. So we made some editorial changes. We add a new terminology session with NRP, NRP ID, NRP selector ID, and it refers to the r I've seen the the drafts, and we up to date the references. So the since the technical connect is stable, we ask for the WG last call. Thank you.
[00:16:00] Bruno Decraene: Any comment?
[00:16:09] Zafar Ali: The first list is Christopher. I had a comment on this draft, and this is about being able to change the an RPAD as a forwarding construct as you go from one, one CP to another CP. I'm sorry. I'm I was just rushing through. So I like to hear from people about the data model. I think an RP is an intent. It is a policy level attribute. And for data plane to be able to change this on the fly on a credit report level is an issue. I read this during adoption call. That comment. I'd like to see some discussion on that from the working group as well, authors.
[00:17:16] Ran Chen: Yeah. Candidate passed level.
[00:17:21] Junxin Han: Many
[00:17:24] Ran Chen: the candidate pass level is the unit of many protocol like BCEP or e GDP as a policy exterior. And and the candidate passed level have the the several segment list
[00:17:57] Joel Halpern: to all
[00:17:57] Ran Chen: the the second list is for load balancing. So we think the candidate path level is more suitable.
[00:18:06] Zafar Ali: I understand the candidate project, the level of signaling or but is the forwarding plane construct and you can there are many attributes that are actually policy level attribute, but you carry them in candidate part level in signaling or control plane. But you just use the always the same same value at at each current part. Intent color is is one example. Right? So that does not itself makes the difference.
[00:18:46] Jie Dong: From Huawei. I I'd like to reply to the first question. I think this is in this draft, I I think we mentioned that it is valid to have different an RPID associated with different candidate parts of a as a policy. Just if you have a consistent intent associated with one service, maybe you would like to have a all the candidate pass with as a policy associated with the same NRPID to make the binding with the between the service and the NRP consistent. So that is the maybe the typical cases of this usage. But from the architecture, it is allowed for different can it pass through a server with a different than RPID. I guess this is what you ask.
[00:19:41] Zafar Ali: Yeah. I I did notice that you have this thing is that it could be same or different. But my question is for this is that what is different? It's a very difficult thing for hardware to switch an RPID on the fly when you go from candidate part one to candidate part two. And so that clarification and because of the overload of an RP construct for in control plane and data plane and all, there's a lot of complication that has come in. So as implementer implements it, the the draft should be very clear on that. And I can I can follow-up for the on the mailing list? This is a yeah. This is a comment that I sent earlier as well.
[00:20:25] Joel Halpern: Zafar, I'd like to ask a clarifying thing before the authors respond. Are you asking about different NRP IDs or are you asking about different NRP selector IDs, the data plane construct? Because I think I understand why one would want different NRP selector IDs. But are you asking for that or are you asking for actual different NRP IDs?
[00:20:51] Zafar Ali: I'm asking for the data plane construct.
[00:20:54] Joel Halpern: The selector ID.
[00:20:56] Zafar Ali: Okay. So so think of it this way. Today, you have DSCP for a treatment, differentiated treatment. We don't take candidate part one at DSCP one and candidate part two at DSCP two. It's at this policy level. So some description of that when it's used as a within the construct of forwarding, candidate path level is not distributed at the policy level. Or add a policy will attribute and do two copies of this under the candidate path. So it's clear that people who want to use it at the policy level will use it at the policy level and copy it to each candidate path or there's another odd.
[00:21:41] Jie Dong: So are you suggesting to make it a a policy level attribute?
[00:21:48] Zafar Ali: Yes. Like adding adding this hardware selector ID or the ID that carries the hardware at the policy level. We can discuss more offline as well if you like. I can send the email from the original email that I I send this comment.
[00:22:06] Jie Dong: Yeah. We can discuss more on this architecture. But for the control plane, the signaling is mostly at the candidate pass level. That is something still will be at that.
[00:22:21] Zafar Ali: Yeah. Yeah. I mean, I understand the signaling, it is at candidate path level. Okay.
[00:22:29] Jie Dong: Okay. We can discuss about this in how to describe this in this architecture draft.
[00:22:36] Bruno Decraene: Okay.
[00:22:39] Zafar Ali: We can take it offline. Thank you.
[00:22:54] Bruno Decraene: So next on the agenda is Hamed.
[00:23:31] Hamed Assarpour: Good morning. So this is an update on the draft-ietf- spring-srv6-service-programming. Okay. So just a quick reminder of of the draft and the context and the scope of this draft. So it defines the data plane functionality to implement service chaining with with s r v six and and also s r MPLS where each service is associated with a seed. And we can include those SIDs in an SR policy to steer the traffic in in through the the the services. And that provides a way to do integrated overlay, underlay, and and service programming. Some of the concept that is defined in this draft, what is a service segment, and how the assignment of a service segment either in a case of sr aware services or sr unaware, also the definition of an s r v s r service policy. Also, in this draft, we define some of the proxy behavior for the s r unaware service, including the static dynamic shared memory and masquerading. One of the things and what is outside the scope of this draft is the control plane component for the service programming. A bit of update on what has been happening since the last IETf. So the authors of this of the draft had a discussion and and on the remaining work to close the draft and and and move forward. And based on this this discussion, the work group concluded the split of the draft into two drafts, one to address the s r v six and one to address s r MPLS as an appropriate path forward for this, specifically because they have requirement on different data plane mechanism. As a working group chair have sent an email asking for a feedback on on the split, and based on the outcome of the pull, we have the chair has asked us to basically go ahead with the split. We have submitted revision zero of the s r v six programming draft just before the cutoff for IATf, and we will be submitting the s r m p l s draft. An update on what has been a change it for in this draft. So we we try to keep the changes minimal in this draft just to keep the history of the draft. And from there, we we move forward. So the first thing that we did, we basically removed the MPLS part from that draft, and it will be in the in the other draft for SR MPLS. Based on the feedback also from the working group chair, we reduced the authors to to five. All of the other authors has been already notified and and in agreement with that. And here is the link for all of the diffs that we added into this draft. As part of that work, we identified few things that needs to be updated in the upcoming revisions of the draft. First, that the draft is missing some of the deployment reports that it has been publicly published already. So that's something that we're going to include in the upcoming revision and also to how to handle the s r v six microsid in in the data plane. As a next step, we welcome the review from from the working group. We already sent an email on this on the on the mailer. So we welcome any question and and feedback, and we will be publishing the SRMPLS drafts. And we will send an email to the working group asking also for feedback. Thank you. Any questions?
[00:27:25] Jim Guichard: No. Not a question, but just a comment to the working group. Please pay attention to this draft. We have a set of dominoes that this draft unlocks the yang models that unlocks other yang models in other working groups. So we need to start pushing those over. So please pay attention to this draft, review it, and and provide, you know, all the comments you can. Thanks.
[00:28:03] Bruno Decraene: Next is Feng for see the source address in Srv6.
[00:28:22] Feng Yang: Yeah. Can you hear me? I'm I'm remotely.
[00:28:29] Bruno Decraene: We do
[00:28:29] Feng Yang: have meeting. Yeah. Can I start? I can't see the slide. Yes. This is this is from China Mobile, and I will present this source address as IP s R6 on behalf of from Src. So the base basically, in this in this revision, first, we have several updates. First, we make more generic c including non VPN suitcase is added for for the source address. Second, seat selection for the source is added. And there is a discussion on per route suitcase. We will respond later on. And last, I p SMP handling implementation and consideration are added. Quick recap quick recap. When s r v six traffic pass through stateful firewalls, a problem may occur. Stateful firewall identify a session based on the firewall post. However, in s r six case, the problem is the address in the forward and the reverse direction are not symmetric, which blocks s s r six traffic. The solution we propose is using the as source address for the I p srv6 packet. By doing that, the IP address will be symmetrical in both of the forward and the reverse direction. No additional encapsulation or modification to s r v six forwarding behavior, and that will be compatible with existing IPv6 forwarding infrastructure as well. So so so the first part of update is the in in the user user traffic, both of the user traffic and SMT traffic. The one man for the user traffic, major update is the extension of the source scenarios. Previously, the draft mainly focused on the VPN scenarios. The latest version expands the scopes to both of the s r v six VPN and the global IP over f s r six. And one thing we need to mention is this especially for the VPN scenario, Multiple SID granularities may exist, like per v p per per VIF, per AC, and per prefix. The draft recommend a selection per principle. Choose the most specific seat as a source address whenever possible. This is feasible at least by the manual manual manual configuration. Another update is the SMP handling use section two dot two. First, for for s for SRv6 ping, the NSAID may be used as a source address. This is useful when we want to check the reachability of the locator on the return return direction. The second for the ICMP errors generated by the transit nodes, the SID that triggers the error can be used as a source address. This allows the header head head node to identify the problem directly. Otherwise, using the the you use a global node address will require an extra step to map support to the. So the the second part of update is is on the on the the firstly, second since section for the use SID compression compression case, we suggest that's the last segment uncompressed. So the firewall does not need to support the compressed SAID. That simplifies the firewall's implementation. For implementation status status, as H3C that has already supported as the feature about some mention in this this in this proposal. And for security considerations, not a space of the because the the the source address is changing from the load back to the SID. So the space of the source address will will expand quite a lot. That may impair the traceability mechanism relying on the source address validation. So, also, for the potential for the firewall, because of the because of source source source address space expand quite a lot. Potential may impact the firewalls sessionable. So so so the recommendation is considering s r v six must be deployed within the limited domain with strict operational control. And this and this feature also also also can require strict operation control. It will mitigate the aforementioned security impacts. Last page is we are already initiated adoption call. So we have received a couple of comments in The Middle East new list. So so we still want to have more feedback, and and we'll refine this document in in the future. Thank you.
[00:35:18] Daniel Bernier: So then the HPE, thank you for this. I think I'll probably connect with you offline. There's actually a few other use cases. You could leverage this using this modifying the source address, r p f being one if you do like SFC. And there's also optimization on the forwarding return path, but I will connect you with the list and offline. Thank you.
[00:35:45] Feng Yang: Thank you.
[00:35:54] Bruno Decraene: Any any user comment? No? Okay. Thank you for the updates. Next is Andrew from HCPaaS, Traffic Engineering for segment routing.
[00:36:20] Andrew Stone: Never been up on a stage before, so this is overview on everybody. This is good. Okay. So good morning, everybody. I'm here to talk about multipath traffic engineering for segment writing on behalf of my coauthors. You'll see since last time I presented, the list has grown. So we have a few more new coauthors here. Thank you guys for joining. Let's talk about it. So just a quick recap. So what multipath traffic engineering is, there's a draft in TEAS calls TEAS MPTE. And effectively, we're no longer talking about signaling a path. The whole concept is essentially signaling a DAG, a directed acyclic graph. And so rather than signaling individual paths that, you know, you can spread out throughout the topology, you essentially program instructions to these things called junction nodes. And those junction nodes essentially do branching. So they do hashing. And specifically, that hashing is weighted ECNP. Of course, in segment routing, we have weighted ECNP on an SR policy as, you know, as part of a SID list. It's very similar except rather than just doing it at the ingress, you do this downstream in the DAG. And so the beauty the beauty of this is effectively you can do ECMP, right, traditional native ECMP that we do today. You can do TE, traffic engineering, along the DAG. And then also introduces this concept of Slack, which is you're taking your shortest path eCMP and going beyond it. So for example, if you have a path, you know, your normal SPF, your path is a 100. You have another path that's available in the topology, that's a hundred and five milliseconds. You can probably use it. So by including those other possible paths into the DAG, you compute the DAG, the graph, you signal that to topology. And you can kinda see my example here where the traffic originates on a, gets split on the ingress, reaches c, gets split again. And more importantly, you can see the traffic on a makes its way to g. That's been originated from a, split on c, and then actually rejoins back again on g. And so for each one of these branching points or the junction nodes, you can control the weighted hash of the actual traffic flow. So your bandwidth tuning along the DAG is actually tunable every time it branches. So what this draft is really doing is it's taking that architecture concept, and it's saying, okay. Well, we can do this with segment routing. So specifically, the document talks about the concept of a junction segment that gets deployed throughout the DAG. Now, all a junction segment is, it has an incoming binding SID and outgoing SID list. So in the SR architecture, we already have this. Right? This is an SR policy with a single candidate path. So effectively, the draft says, okay, we're gonna use the junction nodes. We're gonna program junction SIDs. The way that we're gonna do that is use an SR policy candidate path. And then the end result is you can achieve a DAG. So by using a controller, you push this down, you know, PSEP, BGP, Netconf, whatever your protocol flavor would be, you'd program these SR policies throughout the DAG. So there's an example here for s s r m p l s. The draft actually doesn't talk about SRMPLs or SRv6 SRv6 specifics because at the end of the day, it's just an SR policy. So, for example, on the ingress on router a, you would encode two outgoing SID lists. That SID list essentially would contain the path to reach either your leaf or your egress or potentially another junction node downstream. So the junction node in this case, c, was directly connected. It could be multiple hops away. But effectively, the SID list is just the path to reach that next downstream node and a binding SID. So on, for example, on node c, if you go to the far right side, node c, you deploy your SR policy candidate path as a binding SID. Has an outgoing weighted ECMP SID list. The traffic would get essentially hashed and distributed across the path. So again, this is an example for SrMPLs. But in concept, the same thing would achieve with Serving-six as well. So since the draft initial version zero zero compared to zero one, I did an update, I think, two ITFs ago. Now we're on zero two. It's been changed to informational. So because there's actually no new signaling and no new semantics to the constructs, it's really just talking about how you can use what we already have to achieve MPT. Like I mentioned, there was new coauthors. Some of the text has been simplified, which is basically a refactor of the document. Some content's been removed, moved to the appendix, try to make it a little bit easier to read and follow. In terms of new content, the new content that's been added has been about manageability. So how do you actually make sure that, for example, SPFD works on a DAG? How do you do ping? How do you do trace? So the text that's in there right now kind of slowly tries to introduce the implications of those doing those two things. So, for example, to run SPFD, you're on a. You wanna make sure that you know, the packets that you send make it to your egress nodes. So as a side effect of the DAG, right, your packets are being hashed and being hashed again and being distributed, effectively, the document discusses that to do SPFD, there's a general guideline that just says, you need to run SPFD on your ingress, of course, and on every junction node that you program and on every outgoing SID list. So using that same topology before on the left, right, that's how the DAG gets provisioned. Well, on the right side, your SPFD, you have essentially multiple sessions running. So, yes, this means your egress node is gonna get essentially bombed with SPFD packets, right, in order to cover every possible hashed path that you might have in the DAG. But it seems like for hardware, that shouldn't be much of a concern. But it is, again, a guideline to kinda recommend that in order to cover all of these paths, you essentially need to make sure you exercise not only the outgoing path to your next downstream junction node, you but also wanna guarantee the processing on the downstream junction node in order to be able to draw a a bad SID list. Likewise, it gets a little bit more messy with, you know, ping and trace. So you could add ingress, for example, generate pings with enough entropy to essentially try to cover every possible path. That could be a lot of entropy because one of the values of the DAG is this can produce a lot of paths. Right? That's the beauty of it. So rather than trying to tackle the entropy problem, effectively, the document just kinda recommends, well, you have a controller already running. If you run your pings or you run your traces on a given upstream node, you're only gonna see a subset, a strand of that DAG. So if you really wanna get full coverage to understand what is my, for example, worst case delay that the that the tree is taking or is the tree being able to take every single path, effectively, recommends, well, you have to run that trace or that ping along every single segment list in the DAG, so every single junction node. So the controller, in theory, can initiate this, collect all that data up, you know, and essentially build a picture of the DAG. Now, of course, this is not gonna be accurate because you're going be doing these collections at different times. You're going to have to essentially estimate what do you think is your worst case delay traversing the DAG, what do you think your average delay is, and so on. And so the document just kind of talks about that, but it doesn't really introduce anything new. It's just trying to say, here's are some techniques to kind of approach the DAG problem, essentially, from a segment running perspective. So the next step's basically looking for, again, more feedback, more input, more reviews. There's experimental implementations going on. Right? The nice thing is we can reuse our existing protocols to do this. That discussion about ping and trace, there is an explicit text in the draft that says SRv6 specifics still need to be discussed. There's some topics there that need to be covered. And in general, we're seeking working group adoption. So the MPT architecture draft is being presented in TEAS. My understanding is that's going to be approached for adoption as well. So we'd like to bring this into the loop with that. And thanks. Any questions?
[00:44:27] Bruno Decraene: Yes. Clarification question. Do you foresee any extension for pset or BGP or nothing new?
[00:44:34] Andrew Stone: In at the very moment, there shouldn't need to be any protocol extensions. So from a BGP PISA perspective so for example, I did an experiment with BGP and be able to deploy the DAG without any changes to the BGP stack. Again, that's right now. We'll see as, you know, things evolve.
[00:44:53] Speaker 12: Clarification question? I guess there is some clarification question from somebody else also. I don't know. Anyway, if you have a fault on a from the junction box Yep. How does it ahead and know? How does it
[00:45:10] Andrew Stone: So take, for example, this picture. So imagine from, let's say, c to f. Is that a good example? Mhmm. So in this picture, one of the values of using segment routing is you can use a a sit list from c to h. So you actually don't have anything on f. So that SID list from c to h, you would run SBFD on to detect the fact that c to h, that direct strand, isn't actually forwarding. That SID list would go invalid. The SID list would essentially get withdrawn. Now at that point, there's actually no packet loss necessarily in this picture because c is still gonna hash on your incoming packets and use the alternative links out of that junction. Mhmm. You might run into congestion, right, because there's probably a reason why you split the traffic up. At that point, you know, the controller would have to come in and play with some weights or readjust things. But a doesn't actually need to know that that strand from c to h has failed. Now once all of those strands have failed, let's say all of the outgoing SID lists on c have failed, that's why from a on that segment list that goes to c, you would also be running SBFD. So a to c, that SID list, would also now go invalid. So you can kinda see this cascading effect where you essentially downstream, you're running SPFD to detect, you know, a subset of your SID list would fail or all of them. And then upstream, you're still running SPFD to test to make sure that when you enter into the junction node, that junction node is still processing that packet that you sent.
[00:46:38] Speaker 12: Right. I okay. So in this example, from c to h, you're running the SBFD from c to h on different parts.
[00:46:48] Andrew Stone: On every segment list that's egressing a? Yeah. Yep.
[00:46:53] Speaker 12: Now if there's a fault on the c that c detects Yep.
[00:46:57] Christian Martin: How would a know and not send the traffic to c? If if the fault happens on c and c
[00:47:03] Speaker 12: Downstream to c.
[00:47:04] Andrew Stone: And downstream to c? Yeah. C has additional paths available Yes. For that binding SID. Yeah. Now, once those additional paths disappear, because it's a hard fault, let's say, c is gonna stop processing that binding SID. So the SBFD that's originating on a is gonna detect the fact that c has stopped forwarding that binding SID. Okay. So it's each junction node and the ingress effectively independently detect that their downstream junction node is failing to them, and that cascades back.
[00:47:34] Speaker 12: Okay. So if there is a I mean, all the pods disappear, until then, it will continue to send the traffic in a load balance fashion to the c and other nodes, but c will not be able to Correct.
[00:47:46] Andrew Stone: So you get built in protection in terms of SID list going down if you've got multiple outgoing SID list. TLFA is still applicable here. You still have all those mechanisms. It's just at some point, yeah, a junction node can start blackholing. So that's why upstream, you would still be doing your detection and make sure that your next junction node is not blackholing. Okay. Thank you. Thanks. It's okay?
[00:48:11] Bruno Decraene: So so so okay.
[00:48:15] Christian Martin: Alvaro, what's the problem? It's Chris Martin, Cisco. Just a question here. When I look at this this rendering here, the the the path or the, I guess, the traffic that's showing emanating from a is rendered in blue, and then what's branching at c is rendered in red. Is that the way to to see this?
[00:48:34] Andrew Stone: Yeah. So the it's hard to render these things. The the red color is to try to symbolize in this picture the the SBFD that's originating on c Okay. For each of its outgoing set list.
[00:48:45] Christian Martin: Oh, just the BFD part, not
[00:48:46] Andrew Stone: the Correct.
[00:48:47] Christian Martin: The why I was asking is it looked like a was representing this blue line from a to h was representing, like, additional traffic.
[00:48:55] Andrew Stone: Oh, yeah. No. No. It's yeah. It's essentially each each junction node. So in this case, you have the ingress on a, and the junction node is only on c. Each of those for each of their outgoing sub list have to originate an SPFD test, basically. Thanks. Thanks.
[00:49:09] Joel Halpern: You're up next. But reminder to everybody else, please put yourself on the queue.
[00:49:17] Greg Mirsky: Hi. We're working on the PFD strict mode additions. It would be good, and I don't have to take working group time to make sure that we're aligned with the state changes so we get the state changes that then will feed into the routing state changes, BGP stuff. So just just a note to make sure it and a note, I'm sure you do it. I just put it in the discussion here so that it'll get captured, and we can follow-up. Thank you. Sounds good. Thanks.
[00:50:00] Speaker 15: Pirav Shenak, Cisco. So I'm just thinking, instead of without the scalability issue. Sorry. The mic is
[00:50:20] Andrew Stone: a little muffled. Could you
[00:50:21] Speaker 15: So you can enable the UCNP, right, on the boxes itself. They would compute all the path, install them with the weights and everything. You don't need to do this centrally or from the head end. You can let just all of the nodes compute their own UCNP path and then put a seed list. It will be nicely load balanced.
[00:50:40] Andrew Stone: Sure. There is also the use cases of going beyond the UCNP, right, that are covered in this. So by invoking the traffic engineering rules in here, you can't really do that. And on
[00:50:50] Speaker 15: the You can combine it with FlexAlgo and UCNP. You almost get that, and it scales pretty well. And just a thought.
[00:50:56] Andrew Stone: Yeah. And the the other thing to consider that's really hard to represent on, you know, simple topology is that this grows very quickly in the number of unique paths, especially when you go beyond the CMP. That if you were to take a simple topology and just ran ECNP, I've got lab topologies, right, where between two given nodes, there's no there's only a single path. There's only just a simple SPF. And so doing doing any form of bandwidth distribution to spread your traffic load out kinda have to bring in off the shortest path. And so by doing that, you essentially bring in more paths, which which the SID list on the ingress, yeah, you can add multiple SID lists. There are situations where you can start talking about having, for example, twelve, eighteen, 32, 300, 60,000 unique paths. Right? The graph it it's you're getting off of when you get off the shortest path, right, the anybody that's implemented, you know, graph algorithms, the amount of paths that you can find explodes, right, very quickly. And so you wouldn't be able to really represent this only on the ingress. You essentially need to encode the sheer volume of paths by distributing that across the network. So the only the upstream
[00:52:05] Speaker 15: It's just the scale and the number of paths you need to compute, it's going to be huge.
[00:52:10] Andrew Stone: And It could be huge on some topologies. But it's it's actually not that expensive to compute to get a lot of paths. And then because you're essentially compressing the amount of paths in a DAG form, the amount of state that these junction nodes actually get programmed for to create that volume of paths is actually quite significantly compressed. It's a lot less paths.
[00:52:28] Alexander Vainshtein: Alright.
[00:52:28] Andrew Stone: So but, no, it's a it's a fair point that there is weighted ECP. Right? And I do wanna mention, if, for example, a given computation, you can represent a DAG using four Sydlas, five Sydlas. Yeah. You can just do that on the ingress. It's really when you wanna go beyond just four or five unique paths and you really wanna create a significant volume of paths. Any other questions?
[00:53:00] Bruno Decraene: No, thank you. In terms of adoption, we'll probably wait for T's working group to progress the architecture.
[00:53:06] Andrew Stone: Yep, sounds good. Thanks.
[00:53:13] Bruno Decraene: So next is Balaz, I guess. And it's for ICMP, our only in the service six based VPN on Zafar.
[00:53:37] Balazs Varga: Okay. So as it was also asked by the chairs, we've we sit together the authors of the two draft, and this is a combined presentation about the two drafts. Both is working dealing with scenario where there is an SRv6 VPN, and it is about how to handle with ICMP error. The first slide is just showing the problem space. So we have a s r v six network, and the c nodes are connected using a VPN service over that s r v six network. And it is assumed that the provider network hops, they are allowed to made visible end to end. So that means that provider network deploys the uniform model. The c nodes here can be I p v six or I p v I p v four data planes. Both are allowed. And despite the similar problems problem space, the drafts are focusing on different aspects. The first draft is focusing on troubleshooting. The second is more on observability. This is on very high level, how you can just imagine that. So when we sit together and there were also many discussions on the six man and the spring list on about these drafts, So we think that the two drafts are not really competing solutions. They are providing complementary solutions. But let's look to the details and the and the solution what the two draft is is providing. If we have ICMP error processing in a VPN scenario, the major challenge is that the p node is not VPN aware. So it does not know what to do with VPN specific ICMP error messages. Furthermore, if we are in a SRV six network, the p nodes may be IPV six only. So they may not be supporting IPv4 at all. Draft varhal is focusing on on troubleshooting. If you have a connectivity issue inside the network and you would like to check that connectivity, you would like to be able to point the latest point, which is before your problem in the network. So this is this is what it is targeting. This is why I said that it is more a troubleshooting related solution. And the proposed solution is that the ingress p is changed only. So that is the only no no where the behaviors are changed. There are two set of changes. The first is related to the. Encapsulation. So when a is sending a packet to b, on the ingress p node, you do the s r v six encapsulation. And what we have changed here is that in that encapsulation, a VPN specific information is also encoded. This is encoded in the source IP address, and it is using a VPN specific seed. So this is how the traffic is sent towards the network. The p nodes are working according to the standard forty four forty three operation. There are no changes at all on the p nodes in this in this scenario. When the p nodes sending or generating the ICMP error message, it will send it directly back to the ingress p node. So it is using the error free part of the of the network in order to to send the ICMP error message. And here is the second change in the ingress p node because if it received this ICMP error message, the processing was changed based on this VPN specific information. It will be able to identify in which VPN context the the node a is reachable and send translate the ISAM pair or message and send it to to node a. So that means practically that from the p nodes nodes in the downstream direction, including the egress p node, they are not involved in the ICMP error processing stuff. And this is quite reasonable because we are looking where there is a failure towards the USB node. So we don't want to involve that part of the network. And I would like to hand over to to Zafar to speak about the other.
[00:58:19] Zafar Ali: Thank you. So, yeah, so we we started this work as the same thing like as as been mentioned is that there were customers that are willing to or or they run their c c e nodes in close trust with the provider network. So they were okay in propagating the internals of their core to the c a customer. So when so so like what mentioned before, this is VPN scenario. So the states for forwarding are at the p nodes. And p node doesn't have any v pin states. And in the second one in draft- ali, it's also remained this way. There is no state addition to the p node. Now what in draft- ali was done is that is if you recall, how did we solve this problem for MPLS? Packet is coming to a p node and p node doesn't have the VPN state, it doesn't know how to forward. So instead of doing any, what it can do is it can forward the packets, make the packet, the ICMP error. It it it it hit an ICMP error on p one node. In NPIs, we did the same thing. Is that it uses the actual packet forwarding part to send up the ICMP error towards the CE. So it actually takes the packet where it was going and it was going to PE, and the VPN said that it was going with. It take the packet with that VPN said. So it actually uses Egress PE forwarding plane to send the packet because the state exists on egress p back to the c. So if we have a node which is capable of doing this for s r v six, then that node perform this operation. It doesn't ink I would like to be very crystal clear. We're not introducing any VPN state. It's just like MPLS. We are taking the the forwarding part information and we let the e c m p error follow the path of the forwarding traffic. Now the other method that we're gonna just went over is you add a context at the English PE which is the source address. That is that give can give you the context. Now, obviously there are two cases. P one is capable of doing this forwarding. So it has software that can actually look into the packet and basically say where it was going, I have VCNP error, where the packet was going, I let me prepare a packet. Header matching where the packet was going and ship it forward and it looked back. Second question is that this is not capable, it's not software, not upgraded on it and is a is is a brown IPv6 node. In that case, the packet will be sent to p e one, which is go back to the source where it's wrong. But we do the same technique as p nodes was doing. It did now p e node will look into and try to forward the packet towards the p two and then back to the source. So in in a, the the draft cover both cases. Now, let's go into a bit of comparison. And we are both here for any questions or So we went to where this, this table is done together. So first of all, in in the draft early, because we are operating at the ICMP, so any type of ICMP error that is generated, like in MPLS network is worked the same way. That whenever there's an ICIP exception, that exception is handled regardless of type of ICMP error. So it could be MTU issue with packet too big, and then you forward the packet forward. In the draft-varhal is that the it is mostly related with traceroute. Time exceeded a use case because then you have yeah. You're using a specific source address and and the packet goes back to the to the source PE and then get forwarded based on the context, those address context. Second thing is, which is important also to understand, is that because the draft- Ali uses the forwarding construct to loop it back using the forwarding, it does assume that the forward part is working of that LSP. So for anything issue with VPN, is within a provider network, it assumed that the provider is doing a trace route within the PE or within the VPN context. And it finds the any kind of broken error that way. Not a customer doing a trace route and finding there's an issue on that link. Okay? So it assumed that the forwarding path is intact because it relies on that forwarding path. However, the other draft is actually does is able to find the issue as the customer is tracing the network. It is it can find the issue. The the next thing is about the topology. Because in the draft-ali, what happened is that we rely on the forwarding plane. We just take the packet where it was going, just just copy the content and make it forwarding. So it become transparent and applicable to many sample topology and also encoding. So it had no dependency that you have to preserve the the outer header with that source address that was put in by the English PE. So so if you have lesser cases like TLFA or or or multiple encoding on the packet, the packet would still get delivered because it is relying on the forwarding table that are installed and and not not on the specific address context context in the address. So this this this this does bring into some some of these things that that the the applicability and aspect. So so, like, as mentioned, there are different use cases, like, for for both, whether you want to find the issue or you want to be more generic across all all, the topology. So so the draft-ray can support, let's say, carrier supporting carrier inter, AS option a b c. It can also do s r v six to s r m p l s or m p l s interworking because the both method are using the data plane construct. So once you have the ACMP error, you can use the data plane construct that is set up. So that's that's really easy. Major sort of a philosophy for this trend whether you use a source address which is give you the context for VPN for the ingress p or you defaulting that is already installed in the network. That's really it. So we find it complementary. So we we discuss. We say it's it's fine. It's for for finding an issue from a CE within the provider code, that's that's that's completely a valid solution. So we agreed to merge the two drafts to progress them together. So that is the next step for authors to produce a merged version of the document. We're looking for feedback. You would like to add anything?
[01:06:28] Balazs Varga: Maybe just what is also on the slide that I think it would agree to to agree on that that this is the way we would like to cope with the ICMP error handling. This is the the the the scope, the network scenario, and we think that both draft is working on that. So if we would like to have a single document dealing with ICMP error scenarios in in VPN, then it is definitely a good way to to merge the two draft and and in a comprehensive solution provides provide provide the the view on that.
[01:07:07] Bruno Decraene: So at this point, we we are going to assume that the work is mainly for six man because the first reaction in the p node, which is a regular IP six forwarding. So we want to discuss the requirements, but not not too much details on the solution. Oh. Sasha?
[01:07:26] Alexander Vainshtein: Sasha, Suppose for the moment that your you run another IP VPN service between the two p's, but alert to the and the VPN service. And the pinout detects a problem like MTU exceeded or time exceeded. In this case, how would it understand even after that it is it deals with the layer two VPN service. And in this case, sending something to the EgressP would be useless because it wouldn't be able to do anything about that.
[01:08:17] Zafar Ali: No. That's an excellent comment, So the the way that it detects is is from when a packet hits an ICM three exception at the p node, it goes to the slow part. And the slow part then look at the content of packet and that determination. And there's a full section
[01:08:39] Andrew Stone: of
[01:08:39] Zafar Ali: this based on the local policy and other means. By looking at the packet, it determines where the packet was supposed to go, what the action is supposed to have.
[01:08:52] Alexander Vainshtein: Okay. I'll look it up in the draft. Thank you.
[01:08:55] Zafar Ali: Thank you.
[01:09:00] Bruno Decraene: Any other comment?
[01:09:04] Zafar Ali: One comment. So so we did present this draft in six men. This draft does not change anything for ICMP. So so there's no new error code or anything. There's no changes. So I think six men may be okay if spring takes this draft, but let you guys but there was a discussion with with in six men in that regard as well. Joel was there, I'll let him comment.
[01:09:37] Joel Halpern: I think speaking mostly as a coauthor, but also as a cochair here, but I'm I'm recused on the cochair role. But as a coauthor, I think we need to get agreement on this adopted merge on this merged approach. And then we can work out what things are interoperability issues that need to be addressed by six man or int area versus what things are just architectural documents that can be handled purely here in Spring. I don't think there's any need to prejudge that. The important thing is to first get agreement on this merged approach.
[01:10:12] Zafar Ali: Okay. Thank you.
[01:10:15] Bruno Decraene: But anyway, thank you to the others to to have agreed to have a common presentation and to have progressed on the solution. So next is Yao-srv6 b seed with notification message relay.
[01:10:48] Yao Liu: Hi. I'm Yao Liu from ZT, and this draft is about binding site with notification message relay. And as we know, the s r v six binding site or the End.B6.Encaps behavior, It says that the node sets a source address of the newly encapsulated outer I p v six header to an to an I p v six address that belongs to itself. And messages generated by nodes inside panel, typically the ICMP messages, may need to be delivered to the head of the upstream pass. So we can look at the figure at this page. But first, node s as a source node, it sends s r v six packet with a source address such as itself. And it this set list contains binding set on node b. So when this packet arrives at node b, it will it will node b will encapsulate another outer I p v six and s r six header. And with source address set to its local address, which is in red, the we said s a equals b. And then node b, we are forward a packet along the binance set turner when it arrives at node b two. And node b two generates an ICMP arrow and as defined in the existing RFCs. So the ICMPv6 arrow will have a outer I p v six header with a destination address set as the original outer source address, which is a node based address. And in some cases and this I c m p v six arrow need to be relayed from the node b to node s. And there are existing relay relay solutions in RFC twenty four seventy three, which is defined for generic solution for the I c m p v arrow generated inside the I p v six tunnel. And the solution is the I c m p v six the I c m p the I c m p six error message is first to send node b based on the out assay, as we said before. And then node b exact exaggerates in working packet from the I c m p message to get the upstream source address, which is inside the packet. It's a node s address. Then it relates to a new ICMPV error message to node s, which they sent to us. And there are some shortcomings of the solution. The first is m two constraints. So the inner I p v six source address may be truncate in the message payload, so making relay infeasible. And the second problem is a passing complexity. Because for s r v six and we we have variable lens headers. So in this case, it makes a deep header passing inefficient to some for some devices. So compared with this deep DCI based Relay solution. And in this document, we defined a mapping based Relay solution. And so we defined a new set. So it's called the End.B6.Encaps.Relay. Now it's a variation of the original by s r v six binding suite behavior. So we call it relay set for short. And it has an argument part. And the argument serves as a dynamically allocated identifier that you need identifies the this each encapsulation, the source address. So there are two branches of this relay behavior. So the first branch in branch in the left is when the argument part is zero. It's a normal it's a forwarding procedure. And you you first when you receive related to its arguments equals zero, and you first record the original essay of the inner of the of the the current I p v six header. And if there's no mapping exists of this source address, then allocate a new argument and creating a mapping table between this new argument and the original source address. And then you just for what behave behave like the original binding set. You encapsulate an outer I p v six and I s r v six header. But the now the SA, so it's addressed of the outer header is set to the relay set, which carry the new argument. And a branch of the right is when is a relay reverse relay procedure. So when argument is not zero, then the nodes will look up the argument in the mapping table. Then you get the then to to find the original source address. Then you relay it this message with original so with the destination address set with as original source address. So here's an example. So the upper figure is normal for word procedures first. And note b receives and relates it with argument equals zero. And then the step two, not be allocates an argument x for the original source address and creating a mapping entry. And the step three, not being in caps outer I p v six headers with as outer source address sets to release it b with argument x. And for the for for the figure, lower figure, and then about the relay procedure, that when the node b two inside the binding set turner generates an I c m p v six arrow, and its behavior is not changed. It just sets the destination address as the outer source address and send it to node b. And this but this time, the outer source address is relay set with argument equals x. And when the node b receives this packet, it's now it's locally relay set, and it looks after mapping table with the argument and guess original source address. Then it relays message I c m p v six message to the node s. And that's all. Welcome feedback and comments.
[01:18:50] Joel Halpern: I have a question as a participant. When if you can go back one slide. When b relays the ICMPV six, the content there, I think, if I'm reading the slide right and if I remember the draft correctly, the I c m p v six will include the s r h or I p v six header that be put on the packet as a result of the binding operation. And if I've understood that correctly, that means that s will receive an I c m p v six packet with a header on it that it didn't put on. Is that the intended behavior?
[01:19:41] Yao Liu: The the the the packet encapsulation is not changed. Yes. When the the node b, we are received is I c m p v six error message and with the outer I p v six header just like what we are doing now.
[01:20:08] Bruno Decraene: Zafar, you have a comment? Or
[01:20:13] Zafar Ali: Yeah. Zafar, this is the system. So the draft that was draft early just was in the last slot was addressing this without introduce introducing any of the new release dates. Because the forwarding is already set up. So you can use the forwarding table that are already set up on the PEs to to send this packet to the to the CE or to the original place. So I think there is something that we can discuss offline, but I believe this problem is solved using the draft in the previous presentation.
[01:20:53] Yao Liu: Okay. Thank you. And this draft is not only relate to the I c m p v six VPN arrow, which will be sent back to c. And it also includes the the the scenarios where where for example, the p itself generates and ping or trace, and it's need just need to be sent back to p. So it's just a proposed generic relay behavior. So which only covers the the function that you just relay the message back to the head at or the upper of the upstream pass. So I think let let's discuss offline. Yeah.
[01:21:43] Zafar Ali: Sure. Let's discuss.
[01:21:48] Daniel Bernier: Dan, BHP. I understand what you're trying to achieve. What I'm wondering is, shouldn't this not be kind of a, like, flavor or, a use case of the the source addressing draft and saying how can you what in what kind of use cases do you wanna modify the source address of a transit packet? So if you wanna modify the source from a VPN to be able to add the end function as a as part of the source address in the previous draft, could this not be one of the flavors in case of you're doing a binding set operation and you just you wanna, like, like, a source address on change or a source address translation, those that that's what I'm trying to figure out. Like, not necessarily creating yet another draft, but, basically, this is adding it as merged to the other one around some of the use cases. You see? You understand what I mean?
[01:22:42] Yao Liu: Sorry. There's a little bit echo.
[01:22:44] Daniel Bernier: So the logic is, like, you're trying to modify based on character or, like, on on some use cases or conditions, the source address of a of a of a packet. My my logic is if you're already trying to do it on another draft around the source addressing of the SID, can did that just be added to, like, as an explanation or use case instead of, like, creating another independent work stream?
[01:23:09] Yao Liu: Yes. I think this solution can be combined with the previous solution, which said the set as source address. Because if you look at this this figure and finally, where we we are relay the the the the ICMP message based on the inner source address s. And we it's whether it's VPN set or anything else.
[01:23:40] Daniel Bernier: So That's why I'm saying it should couldn't that be merged in the other work stream and just keep one and just optimize, like, augment the use cases or the the patterns of for forwarding. But maybe we can we can discuss this offline or to the list. Thank you.
[01:23:55] Yao Liu: Thank you.
[01:23:57] Bruno Decraene: So far, are you still in the queue? Or no. Okay. Thank you. So next is Feng for SRv6 pass verification.
[01:24:26] Feng Yang: Yeah. This is a fully functional mobile presenting the s r v six pass verification on behalf of the co authors. Actually, we have a I have per presented on the last ITF meeting and received some some feedback from from Joe and from people who who are familiar with service chain. So the main update of this this proposal has has two. One is we propose two back algorithms and introduce sequence number. The two is algorithm selection, operational consideration, and the backward compatibility are added as well. So the basically basically, we have go through most of almost all of the algorithms that's proposed by the different of the standard bodies and find the the two algorithms are feasible. A quick recap of the problem. The the the path carried in the s r h is the intended path, but the actual forward path may be different. That's that's that's cause a problem problem. If the packet is forwarded through an unexpected node, the operator may not be able to detect it. So this this kind of problem may be triggered by some of the configuration errors and or nature's path injection. So the basic idea is is is authentication tag is updated hop by hop. Each SSS now contributes its own part in the iterative way. So we a new is is introduced in SRH to do the authentication. This number is added here for replay attack. The calculation method is shown in the formula on the right side. On each node, it need to on each node, the it need to have the local key and the input from packet, include including the authentication tag, destination address, and the number to generate a new authentication tag. So finally, on the tail node, the tail node will verify the complete authentication chain. There are two algorithms are proposed. One is HMAC SHA and one is ESC MAC. This reason we propose these two algorithms are because they are suggested both of them are suggested by ETF, and they can be accelerated by the hardware. We also have some basic analyze an an analyze on the computation cost. The total of total input size about the about the the is 384 bits. That's that's the include the includes authentication tab. Doesn't destination address, access number, which each has 128 bits, respectively. On every s r v six node, each packet need is two SHA operations or three ES operations for the HMAC SHA and ESC MAC, respectively. Both algorithms are able to reach the 400 g line rate with hardware encryption engine in H3C router. The the only the only router we invested today. So we also need some feedback from the WG if that says feasible or not feasible on your router. It it looks like the HMX SHA is better, but the the SHA requires 512 bits box size, while EES only 128 bits. Thus, the three EES would be faster than the two operations. That means EES based router both are manageable with the language forwarding. But the SIP CPU based router, EES CMAC, is recommended. The other part of the update is added as operational consideration. The two things are added. One is a single single algorithm is recommended within one s r v six domain. The other is a number are recommended recommended to prevent replicates. And the backward compatibility suggests that if verification do not do not support it, then please ignore it. If a path contain unsupported node, path verification should not be enabled on that path. Some of the security consideration, like a key should be rotated rotated pure periodically, and some consideration on the sequence number space. So we we would like to have the WGP feedback on that, including if we if the hardware can support the two algorithms in what kind of the rate. Thank you. That's all.
[01:31:18] Bruno Decraene: Any comment? Thank you for your presentation. And next on the agenda is the SRV6 behavior extension for flow control in one sensing.
[01:31:56] Junxin Han: Good morning. I'm Junxin Han from China Unicom. Today, I'm going to present our work on s r v six behavior extension for cross hope flow control in that area network. Previously, this draft was discussed on the mailing list, and we have received some comments. And there was a concerns that defining a new s r v six behavior is a preferred approach. Well, let's start with the background. The emerging AI framework has brought a new demand for the cross domain collaboration. Scenarios like collaborative training and distributed inference are becoming popular, breaking the physical boundaries of a single data centers. There is a gap between DC and the wide area network. It is critical to making cross data center interaction as efficient, say, the and controllable as within a single data center. The much low lossless mechanism within the DC such as the PFC need to be extended to the one. So why not just apply the PFC into one? We have faced two problems. First, PFC used the whole backhaul bad pressure. So do we need to upgrade our Intel network to support the PFC? It's unfeasible. That's too costly and complex. So bad pressure signals have to pass through the legacy non PFC devices to reach upstream PFC capable devices. There is no standard solutions. Second, PFC based hot level back pressures, but it's true cause for the one. The multiple ten eight shelled links, there is a risk for congestion spreading. So we need fine grained flow control delivered to specific subinterface or slice queues for tenant traffic isolation. Our solution is aimed to extending the data center lossless network into one view SRV6 by defining the new s r v six behavior and x PFC behavior. It extends the index, maintains the interface forwarding, and enables PFC trigger to reverse tunneling. That marks and identifies the PFC capable devices and interface along the path and serve as a destination segment made in SRH for reverse back pressure tunnels. And for the behavior distribution and discovery, the End.X.PFC behavior is flooded within the domain view IGP and will report to the compo controller via BGP LS. The PFC capable device encapsulates the PFC frames into a reverse SRV six tunnel. The final segment in the SRH is the End.X.PFC seed of the target upstream interface. How do the End.X.PFC enables the precise cross hold back pressure? As we can see in the figures, there are two data centers interconnected via the VPN over SRV6 policy. Using SRV6 using SRV6 to steer the back pressure frames across non PFC legacy devices to the exact upstream PFC capable device interface. In the forward traffic segment list, the End.X.PFC indicates the PFC capable interfaces. And based on the network topology, the controller of the PFC capable node can provision a reverse SRV6 tunnel, like from, for example, from the e to c and then c back to a ahead of the congestion events. When e is congested, it will send the PFC frames of bills that reverse as a v six tunnel. And the LIGO SIN node b and d will just do the standard as a v six forwarding. Only the node with End.X.PFC behaviors will end the tunnel and execute the PFC actions to stop or reduce the traffic. As for the data plan logic, this page shows the pseudocode for End.X.PFC behavior with two phases. Phase one follows the standardized side processing. Once all side segments are proceed, then move to the phase two, the upper layer processing where we merely add the PFC logic. When the packet arrive at a PFC capable node, it checked if it's Ethernet frame. Yes. It will remove outer IPv6 and SRH header. And if the inner frame is PFC, the specific inter interface executes a preset flow control. Otherwise, it will just process a packet following the IFC eight nine eight six. For next step, we are asking for more reviews and comments from the working group and welcome interested individuals and operators to join us for future work. And if you are interested in the draft or have any suggestion or any feedback, please contact us. Thanks for your attention.
[01:38:17] Bruno Decraene: Thank you. Any comment? Okay, thank you very much. Next and final is for Srv6-four-srv6-four-PPPOETransport.
[01:38:44] Shengbin Xiong: Yes, I'm here. Can you hear me?
[01:38:47] Bruno Decraene: Yes. Okay. Sharing.
[01:38:57] Shengbin Xiong: Okay. Hello, everyone. I'm from China Telecom. Next, I will introduce the draft to s r v six for p p o s r v s r v six transport for p p o e. It is divided into the following sections. Next slide, please.
[01:39:15] Bruno Decraene: You have you have controller.
[01:39:18] Yao Liu: Okay.
[01:39:26] Shengbin Xiong: It doesn't move. Oh, okay. It is divided into the following sections. So first one, why we we need to keep the OE over SRv6? The capsulations, behavioral design rationale, behavioral definition, pros procedural code, and finally, the current port deployment at the vendor support. The data intensive workload transmission is frequently deployed in scenarios such as scientific computing and the inter site AI model placement. Such services exhibit characteristics such as periodic generation, massive volume, significant impact on Internet access services, and extremely high cost among others. From a solution perspective, we can first examine the third feature, the great impact to the Internet access services. It indicates that the that different services must be carried by separate net network planes. For example, different network slices are still two distinct anchors. And this associated technical realization requires a first step for Internet access service to the BRAS and the second step step for intensive data transmission to another network anchor. Here is the third feature, the relation technology. And though then we will go back to the first two, the periodic pure periodic and massive volume. They imply that there is no need to release long term private lines. Instead, the AC for Internet access should be reused and adjusted to carry joint traffic volumes within the a dedicated time scope. The the fourth one, the extremely expensive feature, it means that charging should not be monthly based. Rather, it should it must be metered in minutes or final grad granularity. So PPOE is a very good option due to its advantages in authentication, charging, and the service keep taking a live and settle. So, therefore, PPOE for the second app is needed. However, the network anchor, for example, the PPOE server may not be within the same layer two domain as the PPOE client. Therefore, the PoE over IP is needed to break the restriction of the layer two. Meanwhile, compared with IP, the s f f six is has the advantages of network network programmability. So SFS6 is a better underlying solution. In conclusion, the PPOE over SFS6 is needed for intensive data transmission services. So this slide presented the encapsulation of four p o e over Srv6. The p o e encapsulation will fully complies with the RFC twenty five sixteen. And I will spend a little more time explain explaining the design rationale of of the endpoint behavior. The PPOE is roughly divided into two phases, the discovery phase and the the session phase. These two phases transport distinct characteristic ki types of messages. So depending on the functional role of the transmitted messages, different endpoint behavior design approaches must be adopted. For discovery phase, this signaling messages exist solely between the PPOE client and the and the server. So there is no need for onward transmission to a subsequent network segment. For example, no requirement for intensive data transfer. So consequently, deterministic network guarantee, such as the network slicing or curios, are not required. So we should use the end and the d x two should be used directly. And for the session phase, especially for the data transfer phase, The plain user data packet need to be still to the value.
[01:44:45] Bruno Decraene: We are not hearing you anymore. So we'll wait a couple of minutes for you to reconnect if if needed.
[01:45:05] Shengbin Xiong: Can you hear me?
[01:45:06] Bruno Decraene: Yes. Just now. Yes. Thank you.
[01:45:12] Shengbin Xiong: The slash ID a should need to be inserted into the IP header for the purpose of the network slash steering. So if only the in this case, if only we just use the end d x two, the PBOE packet of the remains in remains intact, and there's no opportunity to program to program the value added service steering behavior into the end behavior for the plain user data packet. So a new endpoint behavior should be defined for data transmission of PPOE over s f a six. Here, we use here, we use the slice I network slice ID instead of an IP selection ID for the purpose of end to end cross domain network slice implementation. And the and we have to apologize that in the now the the the current version of the draft, the SID format, which is defined in section eight in the older version of the draft, and it should be deleted. We will update the o o o one version as soon as possible to correct this mistake.
[01:46:36] Bruno Decraene: Next.
[01:46:39] Shengbin Xiong: Next is the we define two behaviors, the end d at a slice p p o e and and the d at d s p p o e. It should be noted that the term decapsulation here as used in this in as used in this document differs from that which is specified in f c eighty nine eighty six. In that, it means that in in addition to remove to remove the to to the removal of the outer IPv6 header and its extension headers, PBOE headers should also be removed. Here is the protocol for behavior. We can see that when we when the node received a packet, we should check the upper layer header eight eight six four, and we know that it is the KPOE session phase. And we will remove the Ethernet header and KPOE session header. And then when we find that the the upper layer header is o o 21 or o o five fifty seven, we will remove the PoE header and add a slash ID value to the IP header. It means that it is the plan planned IPv6 or IPv for a customer user data. So next one. It's the current deployment on the vendor support. The POE over over SRv6 has been deployed across 11 provisional level administrative regions within China, and more than twin 220 dedicated lines have been provisioned. And a provisional revenue of is over about 6,200,000 CNY has been generated in 2025. And about and the ZT, h three c, and the have already support the TPO over over IPv6, and the Huawei is is a work in progress. So here is brief introduction of my draft. Thank you. And any questions?
[01:49:09] Bruno Decraene: Thank you. Yes. Yeah. Questions?
[01:49:12] Daniel Bernier: Yeah. Dan BHP again. So I'm trying to understand what is the use case around is it because if it's you're trying to get a way out of layer two, you're still using PPPoE. So there would be an option of saying, can I just run PPP over s r v six and avoid the Ethernet header shim? Second thing is, have you thought about going to broadband forum about this? Because this is really, like, an the behavior of a traffic of a subscriber session steering. How do you wanna be able to modify the behavior based on the subscriber? So it's either going towards optimizing right now, it's working text four seven four around subscriber session orientation or steering. So I'm trying basically to understand what is the b view you wanna achieve, avoid Ethernet for PPPoE session or PPP session or being able to anchor a traffic pattern after the the a B RAS or BNG. Still trying to understand it, though. Sorry about that.
[01:50:22] Shengbin Xiong: I will may I have your question again? Repeat it. Yeah.
[01:50:28] Daniel Bernier: So first one is your so you first one, you're saying you wanna be able to why do we need so PPPoE over s r v six can already be done. So you can go to a tunnel of Ethernet using p and tunnel PPP UE over an s r v six tunnel, whether it's to the wired end termination with EVPN or a pure d x two. So removing Ethernet would be, I wanna just do PPP over s r v six and avoid the Ethernet issue. If the other problem is how do I wanna be able to have a steering path after the BRAF session, then it again goes into how do you wanna be able to do the BRAF functionality, and I would go to BBF for this. So that's what I'm trying to see. Is it is it just removing the Ethernet SIM, or do you wanna, like, create something based on a service six? And for that, I'd be happy to help you to go to BBF around modifying the way they think about broadband steering using only Ethernet and VPN. I would be more than happy about that.
[01:51:33] Andrew Stone: But
[01:51:34] Daniel Bernier: if you want me, I can clarify on text and email list because maybe my it's kind of confusing if I talk over the mic. So thank you.
[01:51:42] Bruno Decraene: Thank you, Denise.
[01:51:43] Shengbin Xiong: Okay. Thank you, chair. Maybe I will answer your second question. Why we we don't go to the BBF? Yes. We can go to BBF, but BBF cannot define the new s r v six behavior be endpoint behavior. It just give just give the requirement and the use cases to the BBF to route the vendors to support our to support our service. So I think the IATf is the right place to identify the to define the seed, new seed here. Maybe we will give you give you a clear answer to the mailing list. Yes.
[01:52:37] Alexander Vainshtein: Can you please move to the switch to the slide when your behavior has been described? Endpoint behavior has been described?
[01:52:50] Shengbin Xiong: Behavior. Here.
[01:52:52] Yao Liu: Oh, yeah.
[01:52:54] Alexander Vainshtein: Next. Next. Next. Yes. Oh. I think that there is it may be a typo, it may be a mistake, but the upper layer header type in the third line cannot be the upper header Their header type in a service six can be ethernet, but the service six doesn't recap recognize specifically PPP over ethernet or things like in different in different phases. These are not upper header types. These are ether types in the Ethernet frame that encapsulates a p t p packet.
[01:53:36] Bruno Decraene: So I
[01:53:36] Joel Halpern: think that
[01:53:37] Alexander Vainshtein: something here something in this description is wrong. And that's one comment. Another comment is that to the best of my recollection, I believe PPP over Ethernet has been successfully carried over MPLS pseudo wires for at least twenty years, and nobody has ever requested a dedicated pseudo wire type for that or something like that. So I really don't understand why you need a new behavior at all. From my point of view, srv6 is a fine thing, but it is not a silver bullet to to address all the problems of all the layers. Whatever we want to do with the PPP or Ethernet packet after it has been delivered or a service six shouldn't involve a service six at all. Thank you.
[01:54:37] Shengbin Xiong: Oh, okay. Thank you for your two question. The first question, you mean that we have some run header type? Actually, for the Ethernet chapter, which is equal to 143, we have we have just list here s or one here. So we're just missing it. I didn't I didn't type it in red because I because it is the it's the same as the other as the d DX2. So I just marked the new new new part into the red. And the second question that you have said that the PoE or PPU have already worldwide deployed for over twenty years. I I mean so your answer so your your answer is that we have no need to define a new end behavior in ITF. Is that right?
[01:55:41] Alexander Vainshtein: Correct. I think that
[01:55:43] Shengbin Xiong: Yeah.
[01:55:43] Alexander Vainshtein: Whatever you do, you deliver Ethernet effectively and from the PPOA client or the PPOA server. Whatever happens after that is after the PPOA server. You don't which if it wants, for instance, to deliver IP over a service six to your data center, this should be done there. And there are ways to say to push it to the the case. It's policy and things like that, but this is entirely for the or if it is the session establishment phase, it would terminate this function and all that. But it is not in a service six function thing. It is something that it is it tends at the service six delivers that is is a pipe. It doesn't it it isn't involved normally. It shouldn't be involved with what happens under the Ethernet from my point.
[01:56:48] Shengbin Xiong: I think it is the I think it is it is the same reason why various end behaviors exist. For example, the end d s two or end d t six four is already as is also already deployed worldwide for twenty years. Can actually so can actually be composed through the that they are composed by through the static configuration combination of the various functional modules in the router. And I believe that if this combined functions cannot be packed into the s f v six native behavior, there's no way to advertise this combined functions to other nodes via BGP notifications. And then the controller cannot select based on the node capabilities, And thus network programming is impossible. And the network programming is is actually the meaning of the SR. So therefore, defining a standard standard endpoint behavior is not for the sake of can for something that can be done, but for something that can be some function that can be done at scale with interoperability and network programming. So I think it is very necessary to package a whole set of actions into a new s r v six native endpoint behavior. And and I will and I will and I thank you for your question, and I will answer your question in the mailing list. And I will write down more clearly if my expression is not very clear on this on the line.
[01:58:45] Joel Halpern: Nobody can hear you, Sasha. It's okay. Okay. This is Joel Halpern speaking as a co chair here. I want to bring up one procedural point. When talking about proposals, talking about potential deployment or actual deployment is really good. We love to know that this matters for networks, but please do not discuss revenue, cost, profit. Those are things we do not engage in here. Please.
[01:59:17] Shengbin Xiong: Okay. You mean that the cost to the revenue is not should not be a parameter to this to to to to design a solution in IETf, just technical.
[01:59:36] Bruno Decraene: Okay. Thank you. We are just on time. So see you in
[01:59:40] Shengbin Xiong: Thank you.
[01:59:41] Bruno Decraene: San Francisco, and have a good day. Thank you.
[01:59:47] Shengbin Xiong: Thank you.