Internet Engineering Task Force 108, 28 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108-PCE-20200728-1410

Description

PCE meeting session at IETF108
2020/07/28 1410

https://datatracker.ietf.org/meeting/108/proceedings/

A

Okay, let's start hello, everyone. This is the past competition element working group station.

A

So today we have a tight agenda, so harry will take care of the minutes but feel free to help him on the god mid.

A

That's the new tool that is used for the itf meetings to gather everyone on the on the menu taking on you need a data tracker account to log in but feel free to, to use yours and to give a hand to harry so they're not well.

A

Everyone should be familiar with them, but we still need to make sure that everyone has a get some time to remind themselves.

A

Everything you say right share here is subject to ief ipr policy.

A

Okay, so uh this is the second day of this uh ietf meeting, I hope you're all familiar with the way medical is working, but in case you don't uh please be aware that there is a virtual cue to get to the mic. This is the the button, uh with the the hand on the mythico interface so use that one to get into the queue, knowing that the other one is supposed to be direct audio and travel. Myself may stop you in case.

A

You don't respect this protocol during the meeting itself as usual, the meeting is recorded, so please remind your name even if using metico, it's easier to see who's on the queue it's good to have it also recording in the audio and considering the tight agenda. We have pretty. Please try to stick to your time slot when presenting so the link towards the code made codemed is available in the slides, a quick reminder about the use of the mailing list.

A

This is the atf preferred tool to share about technical topics about internal draft, about the work the working group are handling.

A

Every open issues and conclusions should be shared on the list.

A

The description their stuff also as much as possible to make sure that everyone is involved or parents take part into them if applicable, would like also to see the new draft introduced to the working group using the mailing list before the meeting slots are requested.

A

People are sometimes eager to read drafts before preparing the to prepare the meeting. So this is very useful on the chair and is also to see the feedback from the working group on the mailing list to be able to judge on the consensus on draft on the decision, so remind we remind you that slots will be given in priority to draft that have been actively discussed on the mailing list.

A

um Also reminder about the working group process, especially during adoption calls on working group last calls try to send your feedback at those key times about document life within the atf.

A

The chairs also need that to make sure, there's consensus on the draft at every key step, try to share your concerns, support as much as possible, knowing that every working group archive can be looked at at some point by some other entities at the ietf head.

A

We obviously don't want to get into appeals processes, and so on, so make sure that everything you want to share is reflected on the mailing list that that's a guarantee for a further step in the life of the work.

A

Also try to review the ideas from others and consider that we are a community working as a group on working group as a whole.

A

The wiki we've been using the wiki for quite some time now. This is a very useful tool that allows easy updates to track all the documents that we have within the working group at various stages, it's available even between the meetings. So this is clearly the place where you want to look at if you want to know where are the? What is the document maturity on? What is an except for a given document and if you've submitted innovation or achieve a milestone, and so on? You may be also interested in updating the wiki page.

A

The link is right here, so feel free to use it on get involved into the wiki of the pc working group about a little poet allocation.

A

We remind you that in the etf there is a process to get early code point. If you have implementations that need to work together and you want to avoid modifying too much what is implemented, uh it may be relevant to consider hollywood point allocation.

A

The process is not that complex as soon as there is a specification stable enough on the consensus into requesting those early allocation, there is an easy way to get it. So if you really are involved into implementations on interworking, keep that in mind as much as possible.

A

So here would you reach the agenda? Does anyone want anyone want to bash the agenda?

A

We already have an overflow slot, so we'll see if we can reach it.

A

So, let's go into the working group status. We have 11 rfcs in ietf, 106., okay, that's two atf far away, but that's quite a figure. So let me thanks again all the chairs that have helped to achieve those.

A

John, dr adrian, because this is a collective work that I've been achieved there and we had a long list of backlogs in the the working group. So this is a significant step to achieve these 11 publications.

A

Also, we thank the author, the shepherd and every reviewers or ads. It is an etf, usual process and there are many people involved in the back ground, including ioni, erg, rfc, editor and so on. We have one document in the rfc detour queue.

A

I think it get out of 48 today, so the association diversity is progressing well, we have to draft with the isg the scheduling which has opened this cash discusses with the iig, but fuemo is working on resolving them, so this will be fixed in the near future and we have the flow spec id which faced recent revision due to the work, the parallel work that happened about the layer, 2 flow specification in the bgp flow spec.

A

There is another unassociated registry for bgp about layer two and we wanted to bring consistency within the psa prospect. So there is a new extension that has been added into the the draft drive published. I think it was last week a new revision we'd be happy to get the the working group feedback on this change. It doesn't modify the core specification of the draft, but there is a new option supported there to bring alignment with bgp, so feedback from everyone for everyone interested would be very welcome using the mailing list. As usual.

A

There is also an existing liquid point. Allocation about the association policy on is supposed to expire in may next year.

A

Beyond the working group, there are some existing erratas.

A

Several of them have been already progressed.

A

We have agreement on the way we should address them, so here it's mainly a matter of process between the chairs and the id to make sure that we properly resolve those and bring the correct status on those errata that have been embedded.

A

There are lessons with the itu-t study group 15, one that has been replied by scott mulfield's minfield in january, and there is an open one that I received on last feb.

A

A

A

It's on the list, as usual, so drive. If you want to take the hand from there.

B

Just one second, let me just share okay.

C

Hi everyone so I'll quickly go over the status of some of our key working group documents. So this is our working group last call queue. This is mainly for the notification for the working group to know that now is the last chance for you guys to review the order of our working group. Last few would be we will be doing the pcc uh document. First, uh the it has been stable for a while, mainly editorial changes. There was one ina request that was found to be missing so which has been added in the latest version.

C

uh The core specification is quite stable, so we would be moving this document to the working group last q. Next. After this, we have association policy. uh This one had the new implementation details added and also we have the early code point allocation for this one. So again, this is moving quite well, so this would be our next in our working group last call queue. And finally, we have a bi-direction association.

C

uh One clarification was added with plsp id usage and the b flag in srp object in the latest version. It was aligned with the sr bi-directional, which is also on the agenda today, so this would be the next one that we will take up, as as our working group last call, one document which is nearing working group last call, which is our pcep yang document.

C

The t dependencies are moving quite well in the teas working group. We have a dependency also with the netconf document called tls client server, uh which was stuck for a while. But in this meeting and I've discussed with the netconf chair as well that it's moving, uh they have an order. They have some dependency that they are getting out first, so three sets of document uh working group last call is already going on and next would be uh tls client, server, etc.

C

So, as this is moving uh in the in netcon working group, we could also start moving uh pcep yang after the first three documents that we saw. uh We did an early yang doctor review for this, so we were thinking. Maybe it's a time. We should get a final yank doctor review again and focusing on the changes that were made in the early version, and now uh there were some comments on the mailing list as well, which were handled in the latest version. So this is for your knowledge.

C

If, uh if you have any comments on this, please uh reach in the mailing list, uh some of the other uh working group documents uh we have the stateful uh gmpls, which was a merged document.

C

uh The key blocking point here is the implementation status is missing and if you remember our implementation policy, uh we need the implementation status section or at least a discussion about it. You can find our policy on the wiki page so until that gets handled, uh we will wait for uh progressing this.

C

There were changes in the next document, which is the native ip. The native ip document in teas is moving along. So this is the pc uh extension for it. uh There were some technical changes in the latest version. Some new fields, some encodings- were changed. So please look out uh for these changes as well. uh The other document we have enhanced error, the changes were mainly editorial and otherwise the document has been quite stable.

C

The flex grid document mainly editorial changes again, but it has not been discussed for some time in the working group, so authors could consider uh doing the next step for this. The document where we had uh uh some discussion and changes was the psap extension for srv6.

C

This document added one key clarification, especially since pcep uses the term lsp. We have lsp object, so it clarified that in the contest of srv6, the lsp refers to srv6 path, and this would be applicable for any future srv6 work within psep as well. There was some cleaning up with fields in srv6ero srv6rro.

C

So if you guys care about this work, please use our mailing list and provide comments on these document.

C

We have bindingsid. There were comments on the mailing list regarding the length field which was discussed and an update was made made to handle that. So that was the main change with the binding set uh with bn association, which was adopted around itf 105 uh main changes have been editorial and same is the case for sr path. Segment as well, then, this two documents are the recent working group documents that were adopted. The sr bi-directional is actually on the agenda, so we will discuss this document on that slot uh as well.

C

In fact, rakesh is presenting this next and recently we adopted the sr policy association document as well so which has not been updated since adoption.

C

So, finally, uh for working group adoption queue uh as per our wiki, you could see the next two documents which are in our adoption queue is the pcc sr and the stateful inter domain document. uh There are also a list of documents of all where uh the authors have requested us for uh uh uh for uh requested us, and we will get them in one by one uh order, so you can always look at our wiki for this information, and this is my last slide and we have lower in the queue oh laura.

C

Do you want to speak because you are sharing the screen instead of the microphone, if you want to speak click on the microphone link right now, you are giving me a request for screen share.

C

Perfect lower go.

C

C

Laura can you speak.

C

We are facing some difficulty so laura. Could you put it in the jabber if uh your question and we can get to it here- uh the audio doesn't seem to be working.

C

Are there any other questions for any working group status or any other documents that anybody would like to talk.

C

About okay, so then, let's move on to the next uh document in our agenda, which is sr bidirectional, so rakesh, would you like to join uh the queue.

C

D

Everyone you guys hear me.

C

D

uh Hi everyone- this is rakesh gandhi, from cisco systems, um presenting the draft on the bi-directional um sr parts on behalf of the authors listed next slide. Please.

D

So an agenda is requirement and scope that will look at the new association type for the bi-directional sr path. uh The psab object definitions.

D

So, as drew mentioned, this draft was adopted as a working group document after the last itf.

D

We received some pretty good comments from andrew and adrian, and there was a good discussions on the mailing list and the draft has been updated and they're representing uh the the updates uh for this drop. So next.

D

So uh uh it is uh the bi-directional sr path uh in packet, transport networks, uh co-routed or non-coded parts. The scope is the associated path. It could be pc, initiated or pcc initiated stateless pc as well not in the scope, is associating an sr path with an rcpt lsp next slide. Please.

D

So a new association type is defined. It's a it's a slightly different model than the two association types that we have for rsvpt lsp. uh If you recall for rsvpt lsp, there is single-sided bi-directional lsp and there is a double-sided bi-directional lsp and in this particular use case for segment grafting parts, it's a double-sided with reverse lsp.

D

Basically, the association happens at um a pc level for the forward and reverse path. So this is an example uh where both endpoints are given the forward and rewards part for their policy next slide. Please.

D

And in the pcc case, uh the pcc gives the information about the the forward. Lsp and pce would do the association with the reverse part, and then you know, inform the pcc about reverse path for it. So this is also the pcc initiated, supported with with this type next slide. Please.

D

So, as mentioned, a association type is defined uh for this particular use case, it's double-sided with the reverse uh path. um Basically, the procedure uses the same as other drafts. Analyses for the association object next slide. Please, error handling is also defined in other drafts and rfcs, and it's relevant uh here as well. That lsps must belong to the same tunnel or the uh it has to it. Has it can only be part of one bi-directional group and path? Setup in this case is ssr, so this error also apply in this association group as well.

D

Next slide, please.

D

So we welcome your review and comments um uh and suggestions uh for them all the changes uh that we made to address uh lots of good feedback on the waiting list.

D

I think this is my last slide. Yeah any comments, questions.

C

I thought it go ahead. Hello yeah, go ahead, tarek.

E

Oh hi hi: this is dark from with juniper networks. um Does this bi-directional support multiple segment lists or what would happen if uh multiple segment lists were in the sr path?.

D

Yeah, so it would be uh so. This is uh as you've seen it's. It says, sr path, so it doesn't really um say: is it a policy or the candidate path or segment list, um but yeah? uh The the ppc has the capability to handle the candidate path and segment list or when they are added, the corresponding association association group will be present in the object to associate them.

E

So, are you disallowing, um you know multiple segment lists an sr, a candidate path being instantiated with multiple segment lists for bidirectional.

D

So we are not disallowing it uh not clear what will be the use case, but if there is a use case and if there is a requirement, we can discuss and put relevant text in the draft. Okay. Thank you.

C

Just to continue on what tariq was saying, what I would suggest is we have to mention sr policy somewhere in this document, and we have to say that what is the relationship between this work and the sr policy work? So I think we can't leave that question open for interpretations. It would be good if you handle that.

D

Definitely yeah.

C

I remember there were some other comments as well, so I wanted to make sure that uh that those comments are handled in this new version, something which I think got missed was uh adding plsp id in the figures itself, because I think that was one comment uh where how to make that part a little easier to understand the idea that we could have multiple plsp id associated here, so just go back and other people who commented uh during the adoption.

C

Please recheck that whether your comments are handled or not, and if you would like to speak, we have some time right here as well.

D

Yeah do so we will add. uh Yes, I remember now that comment and yeah. We will add that in the figure.

C

uh One more question: do you think the rsvpd rsvpt document is ready to ship? Is there any uh dependency between this work? The sr bi-directional work and the rsvp one? Shall we ship rsvpt.

D

uh I think so um there was a small uh uh change that we had to make in march when we updated this sr path. uh But uh since then, um four months uh it's been a very stable and there is nothing outstanding. uh I don't see any intersection at this point.

C

Okay, thank you any other comments from anyone.

C

Okay, so let's move to the next presentation thanks rakesh.

D

C

C

uh Mike, could you uh ask again.

F

Yeah go ahead mike uh yeah hi everyone, so this is mike kodeshov from cisco I'll, be presenting p-step extensions for signaling multi-path information on behalf of the authors next slide, please the next slide thanks. uh uh It's an introduction right now. Yeah thanks, that's good!

F

uh So in the sr policy architecture, the unit of signaling in both psap and bgp is the candidate path.

F

So in bgp each update may contain multiple segment list sub tovs, but in psab we have this limitation of each update or report having only a single ero object. So this is obviously very limiting for the sr policy use case, because we cannot represent an sr candidate path that has more than one segment list.

F

So in this draft we propose a way for psap for pc to basically return uh multiple paths or multiple eros within a single uh within a single report or update, and even though this is meant to solve specifically the sr policy use case.

F

We keep the mechanism generic so that it applies to you know it's just a generic way to return multiple paths, it doesn't spec, it may be applicable to rsvp as well, and it is also applicable to stateless psap. So you can do a pc request and you can get a pc reply with a bunch of different. You know a bunch of ecmp paths next slide. Please.

F

So we have this kind of motivating example of splitting the bandwidth where the head end requests, 100 gigabits of bandwidth, but all the links have only 60 gigabits.

F

So in this case the pc would need to return at least two parallel paths in order to meet the 100 gigabits objective. So the pc has a choice to return.

F

It can return like two paths with 50 50 split or it can return three paths with 40, 30, 30, split and so on, and the head end doesn't know in advance that it's gonna get. You know multiple paths, it's up to the pc to decide that next slide piece.

F

So we just introduced this very simple, separator object, just so that you can encode multiple eros or rro's, and you can also carry kind of attributes and some basic information about each each ero or rro.

F

So today we just have the upper flag which, which tells of this particular path, is operationally up or down, and we have like a path id, which is just a numeric identifier for that ero in the optional tlvs. We allow to put the weight so that you can have an equal cost multipass. So you can have like uh you know: sixty percent of traffic on uh one euro and forty percent on the other arrow, and so on. Next slide.

F

Please, and we just have this capability negotiation, uh so it's mandatory in the open object to basically the head end says how many paths it is able to install uh and so that that's in the open up, object and there's also the same tlv can be put in the lsp object to override the um the number of multi-paths per lsp so that you can say that like for this particular tunnel, I don't want any ecmp.

F

So I just want one segment list or one path, and you would in that case you would include this tlv in the osp object and set the number of multipaths equals to one and then the pc. You would know that it has to return only one path. Next slide. Please.

F

So yeah, so that's it! um We would like to request word group adoption and uh leave some time for q. A thanks any.

C

C

uh Let me ask some questions by the time uh other people coming in uh there was a discussion uh on the list still about the use of sub-objects. So I wanted to make sure that within the working group we have an understanding that we will. We will be using a new object and not use the sub-object technique. So if anybody has any concerns on that, uh we have some time we can have a discussion, but it would be a good idea to close on uh close on that.

C

So that's one thing that uh I wanted to ask the working group as well so feel free to join the queue. If you have any thoughts on that, uh one comment to the uh to the authors would be that uh in the text we still uh uh mention uh scro and- and maybe there is a thought of using this work for p2mp as well. My suggestion would be to leave that out.

C

For now we have the other document, the sr replication p2mp, and maybe it will be better to do that kind of work uh along with that work and keep this uh pretty uh straightforward, focusing on the p2p case. So I wanted to hear from the authors: what do they think about that.

F

uh Yeah point taken: uh yeah we do plan, we did plan to use it for the three sid uh three set standards to basically.

F

Kind of program, multiple outgoing paths, so we will consider you know how to move some of the three set specific stuff into the three set drafts, so so that this one is kind of more uh you know targeted.

F

You know to a simpler use case.

C

Thanks mike uh any other question.

C

Go ahead andrew.

G

Hi this is andrew, stone, nokia, uh it's not really a question, it's just to comment on the sub-object versus not the sub-object and that whole discussion that we had on the list. um I'm still I raised my reply on the list. I think the way that it's structured down the draft is really the cleanest and tightest way to do it and follows a lot of the other patterns that were already put in place.

G

um So I agree like personally. I think we can keep it as is, but I don't know if anybody has any other feedback. That's all. I really got thanks.

C

F

Yeah, I agree, I mean. Definitely, you know like the the problem with putting something new in the ero object is that it's meant to be kind of carrying stuff from rsvpte, and you know it's not very.

F

So yeah, I think you know andrew's reply there on the list kind of summarized it very well, so quan go ahead.

C

With your question.

H

I have a question uh as well alone: there is a draft that defined the past segment. uh The past segment is used to I and uh sr pass, and your draft has defined a pass id, I think, is similar. So what's the difference between the path segment and pass id.

F

Well, like the path segment, is a label right? That's that's programmed on the tail end. I believe so path. Id is just it's not a label. It's just a numeric value, that's unique only within the context of this tunnel. So so basically, it would typically have a value like zero one yeah.

F

So I think, there's no similarity between them they're kind of very different things.

F

Maybe we can discuss this on the list.

H

Okay, thank you.

C

uh Mike I was just going through the document. uh Even the ina section uh needs some work, because we have some flak fields that we are defining so make sure that the ina section is also handled, and apart from that, I think the document is in a good condition. Thanks for working on it.

F

Cool thanks I'll look at the ins action for sure.

C

Okay, if there are no more questions, we'll move to the next presentation.

C

Quan, would you like to join the queue so that I can.

C

Approve, if any of you would like to share video, please feel free, but otherwise this is fine as well. Go ahead, go ahead with the presentation.

H

Okay, uh I'm wrong did uh my presentation is psab extension for srmps entropy label position next night. Please.

H

This draft has been presented in itf 106, and the comments are appreciated from stephen duff and tariq.

H

So, based on the comments we made some update, uh uh we made some clarification in in last in the update from last version. The first one is. We made some clarification for the background that the pc is used to configure the entropy label position.

H

It is because, in case of inter domain scenario, pc would be useful for computing, both sr paths and the position of the the entropy levels. Second, we made some clarifications for ingress capability, as defined in rfc 862.

H

Multiple er eli, el pals may be inserted in the srmps label stack. So the ingress must support the support their capability over inserting the pairs and it needs to be advertised in open message from pcc to pc. So we use the ebit to indicate the capability of inserting multiple, el el pails at pcc and and and at the meantime, it can be used to support the sr pass with erp from pc and so last slide.

H

H

Let's do the quick recap of the background. uh The rfc 86662 proposed is to apply the entropy labels to srmpls networks and provides under criteria to determine the best er ielts placement. So in conclusion, the draft has defined and that multiple eli el pals may be inserted in the sr npr's label stack.

H

So under wonder scenario is the sdn and the controller such as pc may perform their in the end to end past computation computation, as well as the entropy level position, including the numbers and the place of the el I els, especially in inter-domain scenarios.

H

So in this version we updated their uh scenarios uh the inter domain scenarios, as the figure show, uh for example, the the end-to-end surpass, is built across two domains. From a to y, there are some ecmp between a and b c and e x and j and k and l, um but the ingress a is in domain. One has no information such as msd er, ld of the domain ii, so the procession, a procession could be like that.

H

The pc2 computes the sr path and the in entropy level position of the domain 2 and send the result to the pc one and the pc one uh will compute the sr pass and the elp information of the domain one and uh send the end to sr pass and the elp to the ingress a so. The uh the ingress a has the end-to-end information, including the sr pass and the elp information.

H

So the label stack with the uh el I el is like the table, shows um it like uh the first, the top one is b and uh er. I l.

H

C

Lost, please give me a second: you can keep speaking.

H

Okay, so this is the uh example of the inter-domain scenario.

H

So, let's, let's slide.

H

So this is the precipitation over this draft. First, we extend the the open object in open message. We extend the e-bit to indicate uh it supports the sr path with erp configuration by. Meanwhile, it can be used to indicate the capability of inserting multiple eri, el pal at pcc and second, we extend the lcd object, the black field and we extend the e black to indicate the two computed sr pass with er erp information when the pcc will pass the pc to compute the snl parts.

H

uh Finally, we extend the ero object and the e-beat is used to indicate the position of the uh indicates the position to insert a el I el, in the srero.

H

So let's type this so this. This is order psap extension for the entropy label in sr into domain scenarios, so uh comments and the discussions are very welcome. Thank you.

C

Thanks for any comments.

C

Please join the queue if you have any comments on this document.

C

B

Yes, robin go ahead. Okay, so I have a doubt about this solution. So this is the this. The eri or the year, is uh calculated for sr paths or for specific traffic flow. I'm a little confused about this one.

H

Yeah there we just used the pc to compute the el. I el uh position, not the value of the eo, your eyes, because uh the real er and your eyes uh the value of the er eis and is computed at the ingress.

H

So we just uh we just to uh uh propose the uh the pc to uh compute the replacement, uh because the rfc 866 8662 proposes the uh criteria to determine the best er iel placement. So we think the placement is important and it can be computed in the pc, so pc just computes the placement and the value is computed after the ingress, egress ingress.

B

Mean I understand this is to compute the placement for the ingress, but I mean so for the ingress. We have this. The two entity one entity is the sr pass. Another user traffic flow may be identified five tubes, so I want her to know that when you calculate the position of the eri or the error is, it is a calculation for the for the sr path or for the or for the traffic flow identified by the five.

H

Tubes, I'm not sure, but I think the uh their sr pass is also computed for the traffic flow.

B

uh I think there's a different the granularity okay, maybe maybe we can have more discussion in the middle east.

C

Okay, thanks robin uh my understanding, my understanding of reading, the draft was that this is being uh put as a part of sr path.

C

So, especially after reading the document and looking at the encoding, that's what I feel so maybe you can continue to have this discussion on the list and clarify.

H

Okay, thank you.

C

uh I also sent a mail regarding the last uh itf. There was a discussion with stefan, so we wanted to make sure that we closed that discussion.

C

So if anybody else has any thoughts on that, the better uh the just a single bit is enough, from pcc's point of view to say that yes, multiple eli el pair can be uh put at pcc. So the current document says that a single bit is enough to show this capability and we had this discussion in the last meeting, whether something more is needed. So I would like for us to have a conclusion on this, so we can continue to do that in the mailing list.

H

Yeah welcome to discuss in the middle.

C

C

Okay, uh one more question: uh you have another presentation where we are talking about that in the lsp object. We have run out of flags, so I would suggest you to change this document and use the flags uh from the extended lsp flag. As you are already aware that there's a problem, we don't have uh flags available in lsp object, so better to use from extended lsp so make that change in your document as well.

H

Okay, thank you.

C

uh Any other comments.

C

Okay, let's move to the next presentation. Thank you.

C

Next, we have srv6 yank.

I

Hello, greece, yeah hello, drew.

C

Good evening, everyone, if you like to share your video, I can accept otherwise go ahead.

I

Okay, just hope. My connection is good.

C

Okay, uh stop stop anytime, if you feel the connection is going back, go ahead! Okay, thank you.

I

I am look for brazilian d4 from central african region precisely cameroon, I'm working for one of the leading operators in cameroon is antenna in cameroon and I'll be presenting to you a young data model for srv6 supporting pset on the behalf of microautos.

I

It's good to also precise that this is the first time I'm presiding in the iitfbc.

I

Please next time.

I

Okay, uh in this slide, uh we are trying to give some history about uh the latest developments that we have had on this subject for the pisa protocol.

I

On the left hand, side uh you have the protocol extensions, you have that for the sr mpls as defined in the rfc864, you have the protocol extension for srv6, which is uh an internet drive. Currently, when we go on the right hand side, we have the support uh for the sr mpls, which is near walking.

I

Which has been added to the basic young, and now we are focusing on the the uh draft for srv6 on the support on yam and that was released just the july. 8Th uh next slide, please, okay. On this slide, uh we are trying to provide the added capabilities that we had on the on on the pset, amongst which are the ability, the capability to compute and convey a service expert.

I

We have an added capability, srv6 or pc capability sub crv. We also have a new pad setup type. A new explicit, with object, record object for srv6.

I

uh We can refer to a draft as well for what was existing for the pc protocol for these different elements. uh Next slide, please.

I

uh It is important for us to present to you uh the basic, uh that's the added functionality for sr on the basic young.

I

We look on the right hand, side. We have the entity the pierre and also the session write it below, and the sr function capability added at the entity and the pl levels.

I

That was for the added functionality, the capability for the sr on the on the young. So next slide. Please.

I

Okay, now uh this is uh what has been done for the srv6 capability.

I

uh We have at the entity and the tier levels where you have an augmented capability for the srv6, and we also open the lsp container in the lsp database for the srp6 parts using the segment list. Exclave. Please.

I

Okay, we are requesting more reviews, uh especially from the uh implementers and the operators of srv6, and that this draft is in the pce work group and it's instead of stable condition and possible candidate for the workforce adoption.

I

Thank you. uh We help open for the q, a thank you febreze.

C

C

C

uh Fabrice, I I had not a question directly related to this document, but I was thinking that something that is missing would be for us to link the sit list with the sr policy yank uh as well- and this is something which I feel is missing for both srv6 as well as for sr mpls, so it would be worth exploring if we could put a reference to uh the sr policy yank as well and not just to the sid list. So that's something that would be worth exploring.

C

Okay. Thank you, joe.

I

That will be noted.

C

That is noted any other comments from anyone.

C

We do have time.

C

Okay, let's go ahead. Thank you.

J

Hello, everybody. Can you hear me?

J

Yes, go ahead uh yeah. This is the first time that we presented this draft in pc. So we want to extend the restart policy pcp to enable live feed for next.

J

Yeah the background and motivation for this work is that we want to combine the eye fit so instead of information telemetry together with dslr policy, if it.

J

Refers to all the network ram applications that apply data plane and particularly techniques in particular the most popular are in bangladesh.

J

On the other hand, policy is identified through the of the caller on the endpoint and uh another end may be, for more uh candidate part different way through configuration to pc and bgp in particular, in this graph, we want to define the extension to pc into distributor policies carrying, I think information.

J

This is the scope, so we we are talking about the pcp and you can look at the relevant draft adopted drafting next.

J

Yeah the main change from the 0 version to 0 2.

J

Main question about the ability was clarified, so the extension allows to signal vip capabilities together with the extra policy in terms of flexibility and dynamicity, of the electric attribution that is in charge, for example, a young model, and so on, um in any case for other function and controller and network nodes.

J

Another comment from drew was about generalization. This is still the discussion uh for now. The current version of the graph states that the effect attributes is described can also be generalized for other plds for other associations, but anyway, the suggestion from you was to use the lspa object. It makes sense to me, since normally associations are also used not only for policy association group, but also for other thing that is not very relevant for telemetry.

J

Anyway, we also reported the data plane documents. In particular, you can see the adopted document for inventory.

J

Yeah, the the main point of the draft is about the sr policy association group that is defined uh to extend the pc construction among candidate parts.

J

And we want to augment this by introducing lefty touchy built therapy.

J

So yeah this is the definition of the different pld that for people that is familiar with inventory, very simple, to recognize the relevant information that are considered so the uan trade option tlv the incremental presuption tld the direct export and edge to edge next.

J

This case we have the sr policy for alternate marking and the enhanced alternate mark in tlb that also in this case, this is referenced from the relevant document in six months.

J

Next, okay, I think that's all. I have five minutes time plot, so we want to basically to collect feedbacks. uh Do you get some useful input for the generalization uh yeah? Okay? In this version, we asked to evaluate working adoption considered everywhere anyway.

J

I think there is some discussion on that in particular, because if we want to generalize, we have to consider the relevant data plane that have to support the unbanned ram and alternate multimeter, so that is something that should be configured for for russia policies that are already natural world direction, but for other data playing technologies, welcome comments and.

E

E

Yeah hi: this is tariq from jennifer networks. uh My question is about the flow id uh it's coming from the pce. Is it a global id or is it scoped within the head end.

J

Do you mean the friday in this draft? Yes,.

H

J

Slide yeah now this is coming from the draft in six months of the alternate marking extension before for ipv6, where we define in the option error this pro monitoring identification that uses to identify the monitor.

E

Okay, so in that and that draft uh there is information about, is it global or scoped within the.

K

E

Okay, I'll take it. Thank.

J

You hello, go ahead.

K

Can you hear me now? Yes, yes, okay, so I have a question on flags.

K

K

It's quite deported, but we are kind of used to running out of black space. Have you any idea on how many.

K

Flags uh in a year or two, and if we do we have to add another legacy, will be with the uh 32 32 flags instead of just adding, maybe a couple in the protocol as we have it now,.

J

Yes, I this is a good point, so.

J

We should also evaluate some possible extensibility so but yeah, I understand your point, so you cannot establish many beats for flags we can use um earlier. But anyway for now yeah we made a proposal and we can consider this.

C

One question: uh are these flags coming from the data plane documents, so if this point actually makes sense, even in the data plane case? As far as I understood that these flags were coming from other documents and they were not defined uh in psep extension, but we are reusing these flags from other documents. Is that correct, yeah, yeah yeah?

C

So I think this is a global thing that even iom folks needs to consider.

C

All right uh robin I've added you in the queue go ahead.

B

uh I think that's a regarding the uh usually.

B

I I I don't think that's the flow iv global uh global uh idea. I think it's a. I think that you, if we use the global I mean.

B

That how to say I mean the user told me why the to me why the follow id I mean it's not a global flow idea. Yeah.

J

I mean I mean global. I mean global yeah, the domain. Why yeah global.

C

Thanks robin any other questions,.

C

Okay, let's move to the next thanks, giuseppe.

J

G

Thanks andrew go ahead, hi everybody! This is uh andrew stone from nokia today I'll be presenting local protection enforcement uh next screen. Please.

G

So there's been some changes since ietf 106., uh first there's two new co-authors, so that's good to see um the draft has actually been renamed. It used to be called path: protection enforcement. Now it's been renamed local protection enforcement more accurately reflects exactly what's being protected.

G

um There's been added text as well to the actual descriptions to cover different use cases and the comparisons between them, and there have also been implementations added. There are some changes, not yet posted. Most of it is just formatting. uh Dhruv has recently just commented on this just yesterday. Actually, so there will be an update coming for that uh looks like this draft will be updating, rfc50, 5440 and I'll probably be adding a section to comment on pc backwards. Compatibility next slide, please so just to rehash for those that haven't seen it or missed it.

G

The use case is really to cover two situations. One is the influence path, computation for expanded use case and the other one is to improve interoperability, so the expanded use cases are really today in igp. um Your adjacency sids are are advertised with a backup flag associated with it, which will indicate whether or not lfa is available for that segment id so using this backup flag, when pc actually goes to choose a path one, it can influence whether or not that that link is part of the path and as well.

G

There could be a deterministic selection of acid along a given path and when it comes to interoperability, this idea of influencing the path, calculation and influencing what's it is selected. Some vendors have treated as a hard constraint and some have treated it as a soft constraint based off of the previous language and the existing rfcs.

G

So really we're just trying to cover off the descriptions to make sure that we have better interop in the long term. Next slide. Please.

G

So this is really just the diagon trying to highlight the two different situ sorry, three different situations where, depending on whether or not you want to have lfa protection on local protection on all hops, in your path versus not wanting to have it versus not caring, right and so in the must-have and must not have you're really influencing the spf and the actual path that can be found, what feasible paths are available, whereas in the do not care case, you have a lot more feasible paths but of course, which shortest path gets chosen and the actual sids that are chosen in that path, whether or not they're backups selected or not one phones, the lfa.

G

So I'm not going to really cover all of the different examples. I think you can just kind of look at the diagram a little bit later, but this is basically just showing all the different combinations and what the outcome would be next slide. Please.

G

So the proposal to really achieve this is just using another bit. So today we've got the l flag for local protection uh desired and there's a new flag ebit for reinforcement between the combination of these two bits. It really gives you control over all of the different options.

G

And as well of course, the document itself talks about different wording and statements on how to actually achieve all of this next slide. Please.

G

So the implementation status at the moment, both nokia and cisco, have implementations on pcc and pc. If there's anybody else there that has implementations, please let me know next slide, please.

G

So the next step that we're hoping to do is one hopefully get working group adoption and, along with that, um the actual e-flag that obviously, that needs to be allocated by anna, so we're hoping to get early good point allocation for that. So that way that the implementations may proceed further and that's all I have thank you.

C

C

C

Anybody has any thoughts on updating, rfc 5440 is anything related to that and the usability of course, please feel free to speak up.

C

G

Let's go ahead and thanks andrew cool. Thank you um actually sorry just so. I assumed that I would just send a request to the chairs for the adoption bill.

C

Yes and uh you have to bear with us- there is a bit of a cue here so you'll get to it sounds good. Thank you. Thank you, update the implementation section in your document. Oh.

G

C

G

Thank you for sure.

C

C

C

H

Okay, um I'm trying from the t um my uh presentation is: uh lp object, flag, extension of state for uh pc press knife. Please.

H

um This draft has also been uh presented in itf uh 106 and the requirements and the consent are appreciated from durf attorneys, stephen and parven, and and this draft workforce being discounted in their main list and updated according to the suggestion from doof and adrian farrow. So based on the suggestion, uh I first moved this flag extension to an uh independent draft and we fixed the test based on the comments uh as the following show. First, uh we removed the list of the current currently assigned beats removed.

H

Their beat zero in the existing flags field, remove the description of update to rc8231 and we added the description of tre procession um and we define a an array of units of 32 bit for the length field.

H

And finally, we asked her- I uh I a n a for new tre type and a new registry to translate these in the joey. So let's snipe this, so this is the psap extension. First, we extend the xp lcp object. We uh because, as defined in rfc8231, the length of sp object flag field is 12 is but at the beat one two bit eleven has been assigned uh show on the right field, and but many other drafts would like to use the flag.

H

So this draft, this draft proposes to define lieu lsp extended black trov, for the lcp object that the figures show there. We extend the lcp extended flex field. This field contains an array of viewlets of 32-bit flags numbered from the most significant as beta0, and each bit represents one lsp capability or state.

H

It can be used and occupied by other drugs.

H

Last slide. Please, and we also extend the precept. Arrow object. The lcp extended flag to must be included in the lcp object when the bits of the the extended flat field need to be used. So if the tio is missing, the pc will generate generate an error with arrow type h6 and it means mentally object missing and the arrow value is to become uh to be added. uh It means the lsp, extended l flags, flag, till we're missing, and it must close the session.

H

So let's try it so. The p7 extension is simple and that's. uh This is just uh discussed uh in the mailing list, so um we want to get more feedback and comments, and discussions are very welcome. Thank you.

C

C

Julian- and I were talking about this document- we think that this is something which could is useful and we were considering maybe fast tracking this document. So if uh folks have any comments, please respond to the list or ask questions here. There is still some tightening up of language that is needed in the document, so I will work with the authors and provide my comments on the list.

C

C

C

Okay, let's move to the next one.

C

Shipping go ahead.

L

I'm going to introduce the psych extensions for past mtu next, please.

L

First about motivation and in the traditional amperage, the past mtu can be signaled about protocols like rsvpte and ldp. However, in the isr networks, there is no signaling to set up the sr path and there is currently no support on the sig uh negotiation mechanism of the past mtu.

L

So generally, in an isr network, the sr information is reported to the btprs and the pce will use those information to calculate the isr pass, and we know that when we start pushing the sales either label or ipv6 addresses into a packet. The package size is going to be increased.

L

Once the package size exceeds the past mtu, the packet will be dropped in ipv6 or fragmented and from the operators. We learned that when, using the at least a line over multi domains, the mtu needs to be learned to avoid the packet drops.

L

So this draft, we aim to specify the extensions to psap to carry the path mtu next piece.

L

So, basically- and this draft defines a new tab for the existing metric object for path mtu and the type value needs to be allocated by anna and the path mtu actually goes into the magic value to represent the minimum of the lincoln mtu of all the links along the path.

L

L

Here shows how to use the pass mtu for sr and the pce can be used to calculate the srte path, considering the various and constraints, and now the past mtu can be used as another metric for pce to consider. Well, it is calculating the path once the path is chosen and the pce can inform the pcc the srte path together with this pass mtu and now the srv6 is supported so for the new metric type for the pass mtu and that is applicable, applicable for the srte path, and it doesn't require any additional extensions.

L

L

So we can see that there is a need to convey the past mtu information over the psat and the draft that defines the the extensions to bgp to distribute the past mtu information within the sr policy has been progressed and now it's a working group draft in idr and this draft is the corresponding draft for pspsapp.

L

So we would like to ask for adoption for this draft. Thank you. That's all any questions.

E

From juniper networks, uh the mtu that you're going to uh signal from the pce is it uh mpls, mtu, ipmtu layer2mtu, which, which mtu? Is it.

L

That is depends on the data plan, so it's not limited.

E

uh So is it uh tied up with uh with the with the lsp?

E

Is that what you're trying to say.

L

uh Yes, so iosp is could also be, but this is for in the isr network.

E

Yeah, so if this is srv6, are you going to signal the ip.

L

Mtu uh for the I I p m t: u, what do you mean.

E

uh Excluding the l two.

B

uh There's a robin tarik, uh so I mean hello: kaioke, army, turric,.

D

B

Go ahead, yeah yeah, because I know that's the because this is for the sr policy, so I mean so. The sr policy is the under to underpass, so I mean so. This is the path mto for the sr policy, but you means which mtu is used to calculate the path mto, because this is important. This report, this information- maybe it's through the b2b, increased data in the bdb linux data. It means that you can collect the mps mto or something to the to you, but this user.

B

If the for the sr for the sr, I means for srv6 I'm using the definitely ipmq, but if the srm jars, maybe I think that this is the choice of the I'm charged mpo or the ipmto. Is it depending on the calculation options.

E

It's good to clarify it. I guess if it is not already in the draft, I agree robin.

B

Okay, yeah, okay,.

C

Thanks robin uh chen go.

M

Ahead, uh it's associated with a data plan. If we are calculating uh plus m2 for srv6 pass, then this is an iplayer mtu. If we are calculating an example's past, then it is the empirical layer mtu. That's it.

C

uh Pavon, I've.

C

N

Hey uh this is pawan from juniper, so the path mtu determination does, it take into account uh say say, say it's an mpls path. Does it take into account the number of labels in the stack at each hop or in the case of srv6 path? Does it take the header incoming header size at each hop of the path, or is it just a conservative estimate, or is it something that is out of the scope of this document.

L

uh It considers the the for the as imprs it can consider the labels. The label stacks for the srv6 is about the same list.

N

So is it the I mean say, uh say you have five hops and you're using adjacency sets. Are you just going to discount uh this label stack size for five labels, or is it taking into account? uh What would be the incoming label stack size at each hop? I mean this. Is I mean typically when you're in the case, when, if you're calculating a path mtu, you do discount for the label stack size or the header size and then determine uh what it does.

N

So I mean that I haven't read the red through the draft, but looking through the slides, you just seem to be saying that is just the minimum of the link mtu dude. Did I get that wrong.

C

Yeah, as far as I see in the document, the document describes as like minimum of the link mtu but I'll. Let chang and chopin answer you guys. Have your audio enabled go ahead.

M

Yeah so, first of all, we need to collect the minimal value of the link mtu alongside the pulse, but uh based on this, we need to minor some like overhead of, for example, tifa overhead. So so I I suppose that the uh plus m2 value will be the final uh value, which is the uh minimum length and cube minus the other over here.

I

M

The uh uh phosphate root overhead- something like this. So when we get when the pcc equals pcc get the power m2, then it will be used for the use it as the real mtu yep.

N

uh I I think it would result in a conservative estimate but yeah. I can send something to the list. Yeah.

G

Yeah yeah sure.

C

Any other comments.

C

Okay, thank you. uh We have one more comment, so let me.

O

Go ahead here, uh the when you say talk about path, empty and stuff like that right so like uh here uh we're going to consider the uh the repair paths uh mtu as well or right. So just the primary part.

L

This is currently it's not in the draft, so we could uh look at it in the future.

O

Okay, yeah thanks.

C

For the audio as well.

C

uh Jagan babu, can you say your name and uh information as well.

O

Hey uh I'm dragon babu, uh I'm working from cisco.

C

M

It I'm finished.

C

Okay, thank you. So, since we have time, uh let's, let's have our final.

C

P

Yes, so finally, we got the chance to present for many times so today, I'm going to talk about extension for pc for sr plus ingress production. So, let's.

P

Pick so basically, uh we have a pc for sr policy, so in this case the information for sr pass, such as the list will send it to the primary english nodes of sr pass.

P

So in order to provide protection for the failure of the increased load of p2p pass, we need information to be sent from a controller pce to the backup english node. So this information will be include the the seeds for the by-compass from the bicup english node to the equals node. In addition, we also need the information for protections.

P

For example, we what ingress node we're going to protect by the backup image. We need this information and then so what kind of traffic will be transported by the sr primary pass? So this information can also be included. Sometimes we also have service information, such as service label or service id in the chat in the package. So this information will also be needed, included in the information to be sent from the controller pc to the bicarb english node.

P

P

So basically, this uh the uh this is, the information will be included in this extension, so we need a capability negotiation and then we need uh for texting information to be included in the back hubble path. So this information include include primary universal ingress, node information and the traffic infusion and the surface information.

P

So because this one uh we already have several reverses, but uh we don't have a chance to present. So during this process uh we also get comments from uh from people and then they sing it with those downstream of the information is not needed, so we'll remove it from the from this current version.

P

So next page yeah, I think that's all for my presentation today. I think we would like to have comments.

C

Any questions from anyone.

B

Go ahead robin uh can you clarify this? The increased protection in the local protection or the under under protection.

P

Yeah good question, so this is the end on the protection uh here. We uh we require the controller such as pc to compute and entertain the past from bike company which loads to the inverse node, and then also we should have some kind of requirement for this class. For example, this class may have a minimum intersection with the parameter pass, and then we have the protection information to be sent to the bicarb university.

B

uh I'm a little confused if the failure of the pe1 you have a p1 happens. I mean that even there's another pce to synchronize this. The backup information c1 also can directly to considering the traffic to the to the back of the sr path.

B

J

B

The information should be synchronized between two pes.

P

Yes, yes, that's a good question. Yes, so there's a uh some details there, for example, uh in order to implement or achieve this protection. So we need uh some kind of behavior in the ce.

P

For example, ce may we may have different uh behaviors on the ce, so one one kind of behavior is that so p c one can multicast the traffic to both inverse node and backup inversions, there's one behavior, so another behavior is that c1 can detect the failure of p1 only after detecting the failure of p1 and then p1 to c1, which is going to traffic to was backup. So that's a. We have different uh behaviors there so for this kind of different behaviors, and then this can be.

P

Those information delivered to the bicarbonate node can help, for example, so in case for the behavior c1 send the traffic to both infrastructure and backup equations. So in this case, so the controller should notify the bicarbonate node, but even so, bicarbonate ingredient receives the traffic from c1. So this case, if a primary ingredient is active and then we just drop that package, so we so the controller should have delivered this information before backup engine of english node. So for another behavior. So if we see one only delivers structure to bicarbonate linguistics after their primary phase.

P

Path to the to the eagles mode, so that's a. We needed some kind of a control information to be delivered to the bicarbonate mode for protection of the primary inverse node.

B

C

Are there any more.

C

C

Thank you. That was our last presentation uh julian, any last thoughts, deborah anything before we end the session.

C

C

Just checking with me, okay uh thanks. Everyone thanks for attending pc session, enjoy your rest of the week and uh uh hope to see you guys in person sometime soon stay safe. Thank you. Thank you.

C