Internet Engineering Task Force Interim Meetings, 21 Sep 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-MPLS-20230921-1400

Description

MPLS interim meeting session
2023/09/21 1400

https://datatracker.ietf.org/group/mpls/meetings/

A

B

Got some uh good uh feedback from Carlos we're converging and they will only few remaining uh items that I responded. I think I sent yesterday um yeah.

A

So something yeah.

B

A

B

I hope that we will converge might be by end of this week early next week and I'll upload. The new version.

A

Ah That's good thanks sure.

C

C

Hello, hi hi, hello, hi, everyone.

A

So we have six people, that's still a little bit low yeah. We didn't send out a reminder this time. Is that the reason.

C

I didn't see that you sent a reminder.

A

No I didn't I can't be kind of busy, so.

C

Okay, let's see, let's give it some more time then yeah.

A

I'm waiting, at least for Nick and um I, know that Matthew is not coming. So that's, oh.

D

So is my: is my audio okay I'm getting some fairly rough audio from other people? Do I need to reconnect? No I can hear you well.

A

E

There's a little.

A

Bit Echo somewhere.

D

No I'm going to reconnect I'm going to change, ISP and reconnect okay.

A

F

C

We can hear you.

G

By the way, I haven't seen my slides from the medical machine materials so uh do I have to share my own screens later.

C

Hi yo, your slides, are on the session material. uh The link I'll paste it but I'll be sharing.

F

C

I'll give you the control: okay, okay,.

C

Let's do the link in the chat.

D

So I'm sorry I was muted, uh lower and Tony. I responded to g with my personal view on some of his comments. Some of the I think some of his comments, or we should respect me discard, but I think others have substance I'm doing a personal sort of last look through it I'm wondering whether we might want to have um a voice call amongst the authors at some stage just to go through them.

H

uh Sure, if you think that's necessary.

D

I was talking why don't I just send it around to the authors and then, um um if, if they're, all accepted great, if they're, um if there's any need for discussion, it might be quicker to do it with a voice call rather than lots of people I'll send them out to you. First anyway,.

A

Okay, that's fine. um We can take a meeting. It's often quicker. Do it that way, but.

A

Yeah, whichever way we want to do it.

D

All right, I'll send out uh my view of the changes um in the um uh to the author team first and then we can share it with the rest of the the working group.

A

D

Indeed, we may have a lot of difference, my responses to uh Dong's comments. So again we should discuss.

A

A

Greg, do you know if the Joel will join the meeting.

E

B

So, as you know, we have uh two proposals for uh supporting IAM with m a um I think that would be good to have a discussion uh about uh working group adapting a solution.

A

Okay, so the plans for next week is to discuss use cases. We can do it the week after.

B

F

It makes sense because.

B

I am, is one of the use cases and uh I believe that there is interest in uh finding out uh what would be the solution, because um it seems it will help uh overall discussion of uh ISD and PhD.

A

A

So it's Rakesh is one of them and who's. The other is that it's is it that are you talking about the direct export.

F

A

Okay, fine look, I, don't know.

A

The Tariq do you want to continue waiting.

A

We are eight at the moment.

C

Yeah I'm just wondering if I mean it's it's, it's still good audience. We have eight, but uh do you think we we should proceed with uh um with this little attendance or what's your thoughts.

A

I think yeah we need to. We need to have the discussion. um If we identify that we miss some input. We need to correct that some way, uh probably through mail or something but yeah I, think we need the discussion. I had that hope that we should have some LSR.

A

People with an LSR hat on but I, don't think we have.

C

C

Okay, I'm going to progress on this in you know.

D

There are, there is some in LSR expertise on this call.

A

Oh yeah I know that there's no one with an LSR working group candles strong profile. Is it.

E

C

um All right um shall we um I guess we will get started. This is uh anemone interim and for the usual attendees they will know. This is a collaboration between the three working groups and um we will note all the this session is being recorded and the material is being made available. Publicly links will be provided on the subsequent slide. uh This is the note 12 um that governs the ietf contributions as well as policies and again a little bit of pointers, administrative pointers.

C

Here um we have the the meet echoed session there um and the agenda can be accessed from one of the bullets I'm sharing.

C

um Today's agenda is short. We will review the action items and then I'll give the ball to uh Yao, so she can talk about signaling, uh rld and then we'll close off. If and no one else has any other business to talk.

A

About sorry, I have one thing at the end and that's the announcement of the next week's meeting I will send out the mail yesterday closes this meeting off. So just talk a little bit about the window sounds.

C

Good I'll remember to bring it up after.

C

Anyone else has anything to add to the agenda.

C

Okay, so we will get started by reviewing the action items. Outstanding.

C

I have one action item that I'm tracking. It's open and I. Don't see the authors of the m a header solution draft, but it was to address all the comments that we we had this uh this draft. The open issues in that draft was presented. Last time we met in the interim and the the authors were supposed to take some action on outstanding comments and we are tracking, so they were supposed to work with Joel as well, and a couple of other comments, including the rld MSD discussion that we will have today.

C

uh uh I am not sure if anyone can give me an update on the status of these discussions. Anyone attending now, but.

B

C

Free, if anyone has any input.

A

I think there were some discussion on the mailing list.

C

A

C

It so any closure. You noticed.

B

A

There is some there is some, let's see if we can push put it in the chat.

A

um I got the new version of Thunderbirds. Things is not working as it used to do. um Where do I have the shot there? No.

A

B

A

Try to fill out the message was like this, but it said maybe two weeks ago one week.

A

A

It was sent now it's August, okay. Now it's probably not the right thing, um but.

C

I thought I thought.

A

I thought you will send a message to the authors, yeah and.

C

It's suggesting text, yeah I,.

A

Can look at that.

C

A nod from the authors that they're consuming that uh whatever was sent I, don't want to record it as closed I. Don't want to close that uh with this uh okay.

A

That's fine with.

C

Me it might be, you know the text need to be consumed still like okay, um that's the only open uh action item I have in with this uh um I'll pass the ball to yeah, to talk about rld and possible, renaming that as well. So, let's see.

C

Now, let me see if I can give you control as well. Okay, yeah! You should be able to flip slides as well. If you want.

G

Oh yes, I can do it now. Thank you, hello, good morning and good afternoon and good evening, everyone um as we know there are many discussions around IOD recently and I've proposed an area star draft on secondary signaling IOD via rgp before so I'm gonna introduce the draft and kick the discussion on IOD, as required by the chairs and sorry I didn't put the name of the draft here and but I put the link in the chat. Please interrupt me if you have any questions or something else to discuss.

G

uh Here's the agenda.

G

Although the areas are drafted, doesn't Define the IOD but I suppose that women want to discuss about it. So I put put it here and the m a framework defines the concept of IOD. It is the number of lsds, starting from the top of the draft that a router can easily read in the incoming amperes package by the word easily. As for my understanding, it roughly means that a router can.

F

Read the areases.

G

Without or recycling so to make it more accurate, there is an alternative descriptions provided in the list in our item list. All of them here here are some opportunities, but with no processors, no performance impact, a perfect process that language line rate, processing or processes for forwarding rate- and it seems it seems like with no performance impact- has the most suitcase for now.

G

Here's the definition, part and and comments.

A

G

A

Think we kind of um agreed on one of them, but I, don't remember which one Tony do you remember.

H

F

We've gone back and.

H

Forth right now, with no performance impact is what I have down.

A

That's I think I think we can go with that for the time being and change if, if necessary, when we go to working group last call for the framework, so I think we can put. We can pose with no with no performance impact in the text and then we can revisit at working group lost course.

E

A

C

Have a question please: so we are different. We know of readable label depth, but routers in practice uh have something called readable depth. They actually go beyond the label stack and uh why are we not defining readable depth uh in bytes, for example, or you know uh in going beyond the the just the mpls header or or is it defined? Basically, my question readable depth.

E

E

C

In practice, Tony and thanks for answering it, the the routers are actually inspecting, sometimes the payload of mpls to do some, uh some smart decision based on the payload or first nibble, and so on and I'm not clear why we only track rlb, then yeah, so that was I'm, not sure about that.

H

I I'm trying not to Define terms that nobody references.

C

Agreed: okay, let's see the other, what others have to say: okay,.

D

Is readable label that the same as writable label depth.

H

A

Wait keep to it again, though. It's Greg.

C

Hey Greg go ahead you're at the top of the cube with your question.

B

So uh tarek, if I understood your question correctly, um uh it caused uh ethernet sudaware a lot of pain uh when uh control word made an optional because Transit notes uh what we have found at the transit nodes are trying to do: load, balancing guessing the payload and without uh control word at the bottom of the stack. uh There were uh cases where they interpreted the payload as uh IP traffic.

C

Yep, that was that could be one case. Greg I agree. So do we have such a term readable depth so that anyone can assert.

B

uh We we have a readable label, depth entropy and uh what it says that uh it's very close to what we are coming for Rod, but it says that uh this uh stack of labels may be used for load balancing. So um that's an excessive. That's not what we want to uh convey in the in this. So uh this definition uh seems to be more aimed specifically to the case of um just.

I

B

um And analyzing the content of this substack.

C

Okay, thank you.

C

Jimmy I think you're next.

C

It takes a little time to the mic to come up. Can you hear us Jimmy.

C

Your mic is green, but we cannot hear you.

C

We still cannot hear you.

E

Hello, hello, yeah.

C

Now I can hear you.

E

Okay, yeah I think that is a good question. Actually previously, we only think about the label depths well, should we have the scenery uh there may be PSD in the packet also, so maybe we can have a more generic term to cover both I stand against the, and the question is whether, if we call it the readable doubts whether it is uh still belonging to it, it belongs to the smoking or it's a more generic thing, not only for mprs.

C

Correct in yeah indeed, and could be a a GRE header that we're trying to read- and we don't know the capability of the router and that's correct and yeah.

D

So I I think there is a big difference between readable label, depth and readable, stack depths and um I. Don't know whether we need both parameters or not but readable label depth has got um certain. um You know. Subtle is associated with it, such as Hardware, detecting bottom of stack and all those things.

D

um But there was another comment: I had we've spent most of it. We spend most of our time talking.

F

D

Readable labeled that, but for m a we may well need writable versions of these and I'm, not con I'm, not sure that those parameters are the same value.

F

C

Do we need to Signal, you think uh the writable I mean I think? Are you asking specific yeah.

D

I mean I went to the side note at this point, I suppose, but yeah. If we are Mna is somewhere where we may.

D

D

D

And the writing characteristics may be different.

D

For example, Reed just appears as a cache piece of data. Doesn't it.

D

um I'm not sure what happens with writing.

D

Probably very Hardware dependent, but we are planning to write in the stack.

D

G

Oh I'm. Writing. uh Sorry. My writing is the basic MPS imposing MSD can have this function because it it represents the maximum number and those can impose on on the package.

D

G

D

Sorry I'm sorry.

G

Oh yeah I all I almost finished it, so it is it uh the base, MPS impulsion, MSC kind of the right or labor gaps. So we already have something like that.

D

So yes, so um there's the imposition depth.

D

There is the readable which applies just at the Ingress there's the readable depth, which has to apply along the LSP to make sure that you can see certain parameters that have been popping imposed in this in the stack, but previously mainly Elli, but in that, in this case the m, a information but the I mean, but, unlike anything else, we've ever done to the stack before the m. A information may contain writable parameters.

D

May it not, and the writable parameters um are I, don't know whether the hardware will be able to write as deep as it can um read. I have no idea.

D

G

Classical yeah, that's another capability.

D

Exactly I mean classical sort of implementations, it's probably the same, but in the highly cached Hardware assisted world. We live in in high-speed forwarders that someone needs to tell me whether it's the same.

H

So I can't speak for all Hardware, but from the hardware that I have seen. Yes, they are the same.

A

Got it, we have how you, in the queue Wilson.

C

Sorry, yeah I the mic took a while. uh Why uh why you please go ahead.

C

I

uh Are you yes, um uh sorry, yeah, I'm, late and um I just see this. uh This slice and uh uh I'd like to give my comments on that. Actually uh in the email discussion. I have said that um in this slides, I think the easily uh should be removed. It's a kind of subjective here. It's um some revealed through much information and actually, from the hardware perspective, there are two kinds of situations. One kind of Hardware is um um kind of Asic based is has a fixed the functionality and cannot be changed.

I

Then, therefore, it has a harder limitation for the readable labor depths, which means you cannot do more than that. It's basically impossible to do that because of the hardware is designed to not support that. Another situation is some kind of a natural processor based device which is programmable, and it has also has a readable, labor. Depths means it can can do that with the acceptable performance trade-off, which means, under certain assumptions of the package size, a minimum package size and the current feature set.

I

It can somehow realize a wire speed forwarding, and but if you want to read beyond that, that will require a significant. uh You know reloads package package data into the uh into the memory buffer to do that. That will incur significant performance penalty, so um we should avoid that so I think this is the two different uh situations. uh That's why we have this readable label depth. uh We call that readable. It doesn't mean it's only readable, which actually means it can be parsed and processed at the same time.

I

um So that's a in my opinion. It's a very the same thing.

C

But the lower you want to comment back.

A

A

How are you what we said before you came online? Was that for the time being we put The Window performance impact in the framework, and then we say that it's open to re revisit all the time up to closing the working group last call if we need to add packs to the framework yeah, please help us and do that foreign.

I

E

G

A

G

Should I continue? Oh okay for.

C

Now please yeah, we don't have anyone else in the queue go ahead.

G

Okay, uh the next page is about the advertising scope and the protocol must support both the link and the note advertisement for ild and Tony and Gian provide good use cases in the mailing list for requirement. So the link advertisement.

G

So the first is the modular node consisted of a number of different line cards which are based on different forwarding engines, and the second is a virtualized virtualization case for virtual routine instances on the same device owning different virtual supports. They may have different capabilities yld uh and, of course, we could advertise iot node, which is the smallest IOD. On a note, and if there's any there's, not any questions, I will continue to the next page.

G

And about in the advertising protocols, while the concept MSDS first introduced for Sim peers to indicate the maximum number of six is applicable for in Long smps case a while, the MSD defines the maximum maximum level depth and igp already have the mechanism for signaling different types of MC. So the protest protocol extension for igp is simple. Just a New igp MSD type for ild direct place.

C

Yes, yeah sorry I wanted to ask a question about the previous slide: um you're defining link and the node uh scope rld. What's the relationship between the two like what then you know the per node be the minimum of all the links, for example,.

G

Oh yeah, the penult. uh The panels already would be the smallest audio.

F

G

Okay and yeah, and it has already defined in the m- a form framework that both polinkamp nodes could be signaled at the at the same time, and we should choose pulling uh first.

C

Okay, thanks I lowered my head and lower. You go ahead next.

A

Yeah, we have two terms that are kind of similar. We talked about per platform labels per interface labels. What are the relationships here?.

G

A

F

A

Per platform would be very similar to per node, and per interface would be very similar per link right.

G

We didn't measure ment per platform here.

A

I agree: you haven't done that, but why? Why not uh go back and use terms that are we haven't already used.

G

um Oh I didn't check the purple platform uh terminology in fact, I didn't know well that and the reason why we use Berlin camper no because for yesterday they already use this so just use the same link.

G

E

Of course, okay and.

A

I think we, but.

G

I can go back to chapter platform, technology yeah.

A

That would be great.

C

Tony is at the head of the queue, um so please go ahead.

H

Hi so tarek to answer your question. um The my intent here was to allow a node to advertise per node level rld if it has a single rld value and then, in addition, if there are multiple different rlds on specific interfaces, then they could also advertise per link, or it could also just advertise per link. So basically per node becomes a default for the Box.

C

Okay, I got it. Thank you.

C

Okay, there's boom.

G

C

Still have one, you know one one hand raised and then lower.

A

All right, Tony said is not exactly what's on the slide.

A

You use the per node. If you have the same for all interfaces and if you have different on the different interfaces, you need to announce the per link right.

H

Correct, if you, uh the slide, is not exactly what I intended or have written. um If you want per node and there well.

E

If there's variable.

H

Rld on the Node, you can and should specify them using per node and per link. So you can be accurate. You don't have to lie to people and using a smallest rld, probably not optimal,.

A

Could you could you help us with the text and work with the Jiao to get get it somewhere, where we actually most of us, agree on it.

H

uh The text in the framework document has already been reviewed and everyone thought that was acceptable.

A

Okay to Point Joe to that to that text.

H

It's in the framework craft as published.

G

Yeah I go back to check that.

C

Please proceed here.

E

G

And we'll continue with the advertising protocols, as we said before in the political extension for igp is simple: we just need a new igp MSD type for ild and in the centralized scenario, the controller or PC needs to be aware of the iot of each intermediate area model.

G

For BCPS there's no extension and your model needs a small update after the igp extension being accepted, so the yacht model is not included in the draft, um they have their own draft and the question is since the protocol extension for igp is simple. Well, we do we request for the New igp MSD time in the framework draft or in the separate airsr draft, because currently both drafts have done this.

C

Hey yo I have a question if you are ready to take it now,.

G

C

Okay, why are you talking about segments? We started with labels and now you're talking about SIDS in Sr and uh I. Don't know what brought in SIDS to the discussion.

C

um It could be that since our mpls or non-mpls in segment routing, so just calling it maximum Sid depth is, is confusing uh to the least.

C

So that's that's about the maximum sit depth naming but altogether I think we should stick. You know not bring in segment routing yet so keep it to label. Why are we talking about SIDS.

G

Because uh because the concept MSD is originally come, let come from, and- uh and it is also mentioned that although the MSD is called maximum set depth, it can be used in the noun Sr scenario.

G

In this case, the MSD represents the maximum label dams, so determine MSD. Its originally means maximum set depths, not maximum labeled, apps phones, right.

C

Yeah I'm not debating the maximum set depth, that's already defined, but I think we should not. We were not defining another set depth, so we are defining.

F

C

Label depth: oh.

G

C

um And then you.

G

C

That's what I mean I, don't think we should overload that term at all.

H

The problem is that the existing mechanisms already are defined in terms of an erld MSD.

C

So you're saying that the protocol extensions are defined already for in or are we defining new protocol extensions.

H

The code points are defined in terms of MSD.

C

Okay, maybe we should take that offline of it. I I still think that we should have a genetic label.

B

C

B

Right if I may uh so what um y'all and Tony uh referring to um we have Ariana already Ayana registry for MSD types. So uh we can uh assume that uh the new.

B

F

C

So so one question I'm I'm going to raise my hand, so we are going to use that igp MSD type, so we're looking a new type from igp MSD type, not.

B

C

That's the plan.

B

Yes, it probably because we'll get a new uh MSD type.

B

It will be uh it.

E

B

Advertised in igp.

E

H

I've put a link in the chat to the Ayanna MSD allocation.

C

Yeah, thank you. Thank you. Tony I, just clicked on it uh and I'm still Mike was on yes uh and I, see it's all segment, routing specific, um so I I, that's my concern again, but I'll I'm happy to take it offline and see if I'm mistaken, anywhere.

H

um It is yes, it's defined in terms of segment uh SIDS, but it is not actually SIDS, it really is label depth, and so it's a terminology problem that was created when this concept was introduced and nobody caught it.

H

And so, if we want to use different terminology, we're going to have to replicate all these mechanisms, which seems extremely wasteful.

E

C

E

C

Right thanks, I'll take I'll, take a look offline, no problem.

C

Okay, uh Loa! Please go ahead.

A

um I engraving Tony that we shouldn't produce duplicate. So what already is in Diana? We might want to have a text explaining the situation that arising with the with m a uh and where we should put that I. Don't know really, maybe an update to the document that actually Define the register, but we need to give a look and see what we want to do, but I think it's kind of clear what Yao want to do with respect to the registered list.

A

C

Okay, y'all, please proceed.

G

Okay and uh I'll continue that the discussion about uh where we do. We put this registration because, as I mentioned before, um currently uh both the framework draft in the arrest object, I have done that have both requests for a New, igp MSD type for IOD and uh in in my opinion, in the currently in the m. A framework by saying IOD is advertised by a igp MSC type. Is it? Is there an assumption that igp is the only advertising protocol for m a maybe in the future?

G

There are other existing or new protocols need to be defined and it needs to be extended to support their money. So um so is it better to in the framework to say that the ild value can be advised advertised via protocols and less than examples like IDP, and here are some basic iot advertising and processing rules. So no matter what token needs to support M, A or IOD, it can be extended following the instruction in the m a framework.

G

So that's my point of view. One please.

H

If there are new protocol.

H

Advertiser rld I don't see, we need to say anything.

G

So um so, to be honest, I have Android too many framework drives, but as much for my understanding, normally in the framework specifies some general rules, so I'm sure is it.

G

uh Is it a usual way to define the protocol extensions in the framework draft.

G

A story at 20 I can't hear you.

C

uh Please progress further I, don't see anyone in the queue yeah.

G

I believe uh Tony was speaking, but I can hear him.

C

Okay, I, don't see him in the queue now.

C

So I'll go, we can go with the assumption that uh he will come back.

C

Okay, I think he went offline. To be honest, he got disconnected.

G

F

G

uh Here's some okay.

C

Tony, if you can hear us- and you want to speak, just raise your hand and we can interrupt you out thanks.

C

G

Okay, uh yours um related to work.

G

uh Currently, there were two types of IDP MSD for MPS. One is based appearance in potion. Msd It prepares a number of labels that can be imposed on the now the link, so it is not related with IOD.

G

Another is Eid MSD for entropy level, readable depth, and it is related with the router's ability to process EOS if a router is capable of reading um labels, but not using any or located within those own labels in crd is zero, so reality is not a review, so yeah I already MSD, is not reused for IOD, and another observation is that there's there's other work action, there's other network actions specified.ld and the amperes in band PM encapsulation draft defines the flow ID, readable label depth similar to yellowd and with ildmst to this MSD need to be defined further uh for my personal understanding, possibly not a node can signal social network action capability and the iodmd to indicate that it can process this network action within the IOD and how to process and when both iot and network action specified ideas received and in the areas they have Sr draft.

G

We didn't talk about that and leave the decision to implementation and a comments.

C

uh Yes, hi, uh I I think the capability of a network action is independent of the readable label, depth so being able to read yes and, and it doesn't it's not, you know tightly coupled with uh people being capable and I think we need a separate. You know way to advertise capability of a network action from a node uh and I. Don't.

G

C

In the same track,.

G

Yes, that uh what what I mean is that uh we, if we take Eid as an example because the file is defined, is defined, is defined three examples by erity and so um yeah. What do you mean? Yeah I mean ER. Ld has two meanings. First, we can read and labels a second. We can process uh the entropy label located within those labels, so ERD itself means uh it has that it has the ability to process the entryway label.

G

But in fact we have the advertisement of eiod as well as the advertisement of ERC, which is the algebra label capability. So what I mean? Is that uh tell this MSD related to the Network action only to be defined further, because uh if we have IOD MSD advertisement and when we Define a new network capability, we advertise it both the network, action capability and IOD and it can present, but it can present the node- is able to process the network within the IOD.

G

So it seems like we in the future. We don't need the network actions specified. Iods like similar to reality. That's my point of view.

C

Okay, so just to understand you are going back to erld and the way it was defined and that's fine we're not changing that. But you.

G

C

Rld is something not it's not ER, release something different and I, don't think it's tied to any capability or action rld.

C

So just you know this is how far I can read and that's it. But this is my opinion. Let me know what do you think.

H

So the intent in the framework draft is that rld is general and in fact it's not even specific to m a.

C

Yeah yeah, that's in line with what time yeah.

G

Yes, uh I I, I I totally understand that, and what I mean is that with IOD in the future network action specified iods seems it seems like they don't don't need to be defined. For example, the F flow ID readable depths MSD because we just need the IOD. That is enough, am I right.

C

um So again, I think I'm. You know I think the capability of an action regardless, if it being m a action or a flow ID uh you're, referring to which I think is still possible to do it in m a it's still on the plate, but going back to m a, I think the capability of an action uh will have to be advertised somehow and it's not yet defined so and that's separately to be not separate. Now, okay, yeah.

G

H

My opinion, the fact that erld overloads both its capability and its rld into the same value was a bug and that should have been fixed. This should never have been allowed. This is why we have to go.

G

Ahead, yes, that's what I mean.

H

Right so this is why we're General defining a general rld now we're fixing that problem, and we should not repeat that mistake, so we should not have an m a specific or even flow ID, specific rld. That does not reflect how the hardware works.

E

G

Okay, uh that's that's all for the slides and uh and I think when we talk about where to put this igb extensions, um Tony put and link on it, so it where to put in the igb extensions I think is the first first point: we need to decide so do we need a separate uh igp draft or we just put all this in the framework draft, so.

H

What's in the future right now, what's in the framework draft right now, Define crld and requests the code point and we already have existing igp drafts for how to advertise MSD, erld MSD, but allocating the new code. Point allows us to just reuse those mechanisms.

H

So I'm not aware of any need to allocate new mechanisms in the igp.

G

Oh yes, it was so so. My point is similar so because in the protocol extension for igp is simple. We just need a new idpm state type. So if we put the IDP uh MSD requests in the framework draft, we don't need and separate rsr draft, but it's all best basic too. The working group's decision- I'm okay, with both.

C

I I think this um yeah that Ayana is managed by the LSR working group um so um either way we have to engage them to tell them we're we're intending to allocate this new type.

C

For this purpose, um the draft I'm I think we need to. uh um We need to decide to keep this Ayala location in the framework or uh or have a short draft just to do this new type allocation, um I'm, okay, either way, but.

G

Yes uh type allocation and to mention that on the igp MSD said via pgb OS. So that's the main point of the IDP drafted now.

C

If you want to Signal it in bgpls, then at that time you have to.

G

There's no extension.

C

Yeah right, my understanding is bgpls will carry those dlvs, as is um you know, igp defined ones, um you're not going to redefine igp ones right in bgp.

G

Yes, so I mean currently in the high GP drive to just mentioned that we can advertise this New MSD uh type via BJP, just like it is.

C

Okay, so I think you need to work with the framework authors draft to see. If um you know this, uh the the this allocation needs to be done in LSR, working group and pgp uh working. You know and the IDR depending on, if you want to do it in bgpls or not, but that's my my take what do you? What do you think lawa and others I'm, not sure about keeping the MSD type, the igp MSD type allocation and framework draft I'm having mixed feeling on that?

C

A

So since you're asking me, I was kind of rather comfortable with us in the in the framework, but so what? Where would we put it? If we don't put it in the framework foreign.

C

I think I think the definition uh of your rld can definitely stay. You know, and they you know utility of it and to to M A on others can stay in within mpls, but we need the type uh in a sub. You know that's my opinion and a separate draft with LSR working group for igp and I'm gonna stop right there. Maybe someone else has their perspective different.

H

I agree that we need LSR approval, but having a separate draft just allocate a code, Point seems excessive.

C

F

A

Yeah, that's how we've done it before earlier and we have been assigning code points from other working groups. Registers and other working group has been assigned to now registers and that hasn't been a problem. It never had been required to actually write a a specific draft. We asked for the allocation, even though I think we've done it one at one one time, but that were other reasons.

C

A

Well, if we are located in the framework and allocate from an LSR manage registry, we need to tell the LSR group what we're doing concerning the allocation and they need to approve that.

A

That's the process we used before.

C

Right, that's through and I need to double check, and you know that um it needs to become a standard strike document rather than informational. If it is not already.

A

uh Are you saying that the LSR the registry says that code points are.

E

C

Allocating a type right uh you don't want to make it. The document will become. The framework draft document will be standards track right, I kind of I need to check Kevin. You know if it is not already.

A

um I, don't think so, but the.

C

It is not, in fact, it is informational at the moment.

A

But the the allocations procedure from the IDP MSD types are expert review, so I. If I remember correctly, expert review does not require a um standard tracks document.

C

um Okay I mean, with my limited uh knowledge, I think if you're allocating that pipe can be informational, well, Stuart.

A

Do you remember what the requirements, because you were on the ISD at that time when that was decided? Do you remember what the requirement for expert review are.

D

uh Expert review is just that the experts agree to it. I, don't think that's a current one. Is it, but anyway, experts just require the experts to to review it. They don't require even a specification.

A

D

Can have an external.

A

Document yeah, that's what you're saying I think that's true, but the Google would also allow a informational document and if an informational, RFC right.

D

Well, hang on a second, it depends on the register. What we've! Actually we talk about? What exactly.

A

You're talking about igb, MSD types, assessor registration procedures, expert review and nothing else.

D

Well, that means just the experts have to agree. They don't even you don't even need a written specification available to anyone else.

D

It's a very, very loose one. You just have to get the experts to agree. Okay, I see, okay will likely want something written down. Of course,.

A

Yeah they normally they need a document, but um who.

D

Are the experts.

A

It's Jeff and Uma.

D

D

Well, you to get an expert review code point you just have to convince the experts.

C

Okay, Lord go ahead, you're still raising your hand.

A

uh Well, that's because I haven't taken down. Thank you. I will do that.

C

uh Are we converging on uh a an action plan to uh you know, keep it in the framework? It seems that it's loose requirement that that registry, um so it doesn't require standard strike document.

C

Are we saying that this is the the plan forward, I'm I'm, trying to help out Yao here to see what is the next step.

C

F

C

G

C

I think what what I'm trying to ask is uh you know you're presenting this draft in the LSR working group. Is that what your intention is.

G

um Yeah, so if if the decision is to put the registration in the framework craft, so I think there's no need to uh to this IDP draft, so.

G

So it's based on the working group decision, whether to where to put the registration.

C

Okay, there were things that I wasn't aware. You know like the the idea of the framework remaining informational and still allocating, uh so given that I don't see that uh we strictly have to uh have a draft to just allocate a type and- uh and maybe we can rely on the framework to do this. Allocation and Loa will is.

A

Yeah, the I I think that a week we as the mpls shares can say that we are willing to have the allocation done by the m a framework, and if the anyone has a different opinion, we need we need to discuss. That is that.

A

Reasonable summary of our discussion.

E

C

G

C

Yeah, okay, all right, uh okay, I think we have to present then whatever we presenting now as uh on the behalf of the framework graph to LSR working group, so we have to tell them. This is the rld definition, and this is what we intend to do and uh is that the plan?

C

uh Do you want to work with uh with the framework or or maybe the framework uh authors will uh so I'm asking this question in the context of the framework draft now and being it ready for a working group last call we are putting a requirement now to engage the LSR working group and I want to see that uh engagement before we progress the document further, so I want to hear from the authors of the framework draft now.

A

Yeah I'm, finally, without saying but actually Tony is the editor and he might might have more information, but I thought that Tony was okay. With this.

H

I will be happy to reach out to LSR.

A

Okay, fine, then we say that the author of the framework draft will reach out to LSR and tell them what we are planning.

A

Tarek you, okay with that. Yes,.

C

I'm fine with that, we can. Okay, summarize it like that, no problem, okay, anything else you want to add.

C

You are clear on the next steps.

G

C

Okay, great, thank you uh going back to the agenda. I think we're done for today. Unless someone else wants to bring up I.

A

Had an oh any other business, do you remember.

C

You did go ahead: okay,.

A

uh That's just an announcement. The meeting next week we'll discuss the m a use cases and I'm preparing a mail telling the authors to uh prepare outstanding issues and questions to the working group and I'm, asking the participants to review the document and participate in the discussion.

A

So I have the mail more or less ready and we'll send it out within an hour but use cases for discussion next week.

C

Okay, thank you all right with this. Thank you so much whoever attended and we look forward to seeing you next week on Thursday have a good day.

A

Okay, thank you. Bye-Bye.

E