Internet Engineering Task Force IETF 115, 8 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF115-MPLS-20221108-1630

Description

MPLS meeting session at IETF115
2022/11/08 1630

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

A

Every case well, this would this would work.

B

um Less than a minute to start time,.

C

A

We recorded yet yep, okay.

C

So, let's start uh welcome to IHS 150.. This is the MPS working group.

C

Please make sure that you wear your mask unless you are speaking and please scan this can be quote in order to be on the blue sheets, um so we will be a distributed session if we have three time zones. So the chairs are sitting three different time zones and see what is going to support me here.

C

A

C

The minutes? Oh yes, that's uh that's Max yeah. So we need a minute tracker and we need uh JavaScript. I guess.

C

Anyone in Mac online.

B

I don't know I volunteered to minute taking but I don't mind help from the audience as well. Okay,.

C

Yeah that you're monitoring the Java I.

D

E

C

So node well yeah about known I, guess.

C

Yeah, so blue cheats Java is minute. Taking we have a minute taker. The agenda is also online and updated. um What else is fine I guess? So we have four presentations today.

C

D

C

We have four presentations today, I think two are here on site and two are remote: um 10 minutes per presentation and all together uh one hour.

C

Yes, it's light so working group status, Lower for you or shall I continue.

D

I just talked to tarek and he volunteered to take it. Oh.

C

C

B

Yeah this uh this Errata, we have an Errata that was reported against um RFC 8960 um I as one of the uh co-authors of this draft. um We acknowledge this is a uh a Miss in the RFC and the the the the suggestion um will work, so we will be following up uh with uh with the ad on uh closing this matter.

B

um It seems that there is a duplicate errata um on this and we will look into that.

B

Okay, do you want me to continue Nick on uh yes,.

C

B

Okay sure um so in terms of uh Liaisons, we have none uh egressing from mpls working group. We have one that came in uh back in March and uh it came to multiple working groups and we will be uh looking looking into that.

B

um There was a session uh today, um maybe not in the slides, but about the network. Slicing uh identity. um um It was with liaison with three gpp I could not attend remotely, but not sure. If Loa or Nick have you attended.

C

um I had the same problem, so I think we have to check afterwards that.

F

C

Today, at around noon, I guess the session yeah.

B

It was earlier today, but we could not.

E

B

In so that's one thing on that: Navy will provide an update to the working group uh on subsequent, maybe um subsequent sessions or via email, and so next slide. Please, uh we have no other new rfcs this time. We thank all the working group members and and authors for diligently working on their on the working group documents and we encourage them to continue to work and delivering those um you know um uh to become rfcs.

B

We have one document in iesg and uh and we recently adopted a uh a document- that's on the agenda today. This is the MSD yang document.

B

Next slide, please so in terms of the existing working group documents, uh uh the first one here, egress tlv nilfac, um the the early Court allocation, expired, and we had to renew that.

B

um We have a couple of m e documents uh that are listed here, their existing mpls documents, but we will talk about them in more details in the joint session.

B

um We are missing couple of uh reports on some of the documents that you don't have note next to them. So, hopefully the authors are present and they can provide the chairs with an update. Later on um the the we have. We have the RFC 6374 Sr document. The authors have declared this is stable and ready for working group last call. The chairs were recorded this and we'll take the next steps uh as needed.

B

um The next one below it as well. Srep-O-Am is a candidate for working group. Last call and uh the last one here there was a mpls BFD directed.

B

um There was a upload, a new revision that was posted and in it they changed the status to experimental um and the plan is to progress less. The working group last call um I.

B

um We have one also that's ready for working working group last call, which is the ri RSVP frr and uh just to let the working group know that we are tracking these okay. So next slide, please so in terms of individual documents, a couple of them are on the agenda either on this session or the joint session. I will not go into details of each one of them, um so maybe we'll skip the update to individual ones.

B

Next slide, please.

B

Next, okay, so this is the mpls working group session and I wanted to bring up the that you know we have a design team, that's been working on uh M, A and M A solution uh um activities, and we we wanted to um uh bring to your attention that uh we were weekly meeting to discuss, uh M A activities and we may need to revisit the frequency and.

B

um The the recurrence of the meetings- uh so this is something that's up uh for for the members to discuss. uh There was the recent uh topic that brought uh that was brought up uh and um in terms of non-ipp loads and the interactions with M A packets.

B

um So that's something that the design team will have to look at, and um you know we will we'll see. If we we will keep the the the periodic meeting and the same frequency uh so that with that um that you know, I will close and I'm done with my uh status update I'm happy to answer any questions uh that anyone would have on this.

A

uh Just before we go there, Stuart um can I do a mask reminder please, or everyone have masks please thank you.

C

So no no question so far. Okay, so.

B

Let's continue.

C

B

C

Continue with the next presentation, I think it's uh yes tell.

B

Me uh yeah right. Okay, thank you. So uh this is a an update to the working group on uh Wiki migration. That's happening in ietf.

B

um uh It's informative, plus some actions that um you know we're asking either the the members or the chairs will take on. So let me start with the plan on the next slide and we'll go through the actions after so there is a new uh there. There is, there are plans to migrate from the old um uh Wiki to a new Wiki, and uh the plan is to uh turn off the old Wiki. uh That's tracked on track.ietf.org sometime in November, right after IDF 115., and um so that the uh you know we we don't.

B

Users or visitors, are looking for uh content, don't hit any stale content or the search engines. Don't reveal information, that's not up to date, so uh they we will not keep two copies of the information and the old copy will will disconnect from the web.

B

um uh All content that that's that was on the old Wiki will continue to live and, and it will be archived uh but pulling it out- will not be a straightforward process. There's a Docker image that people would have to download and and run on their machine to extract it.

B

So in terms of actions for the working group we want, we need to migrate anything, that's so valuable uh value to the working group to the new Wiki.

B

um We already have a new Wiki with minimal content on it. um I think the lower Hutt set it up, but we will need to populate it with the relevant content. There is a guide to individuals contributing to Wiki. It's uh it's a very well documented guide, so I encourage people to go through it.

B

People can directly edit the page or use git to commit the changes. There's also a zulip channel. That's was set up for helping raising questions and discussions and there's a support, email as well that people want to use use it for if they run into issues next slide, please. So the ask for from the working group is for volunteers.

B

If you can to help in sorry to help in migrating the content from the old Wiki to the new Wiki, so we will be doing that there you know as as much as possible, but this will be a uh you know. We have a limited time to migrate as much as possible before uh the wiki will. The old Wiki will be turned off uh so and in terms of using the wikis for um meetings that we do as well as tracking um updates to documents.

B

We will have to use the new Wiki from now and on so that's uh that's about it. It was a heads up on migrating, uh our wikis to the new uh placeholder, um so I hope people are aware of it. Now.

B

I think that was the last slide on this and I'm happy to answer any questions. If people have any.

C

None no questions.

B

Okay, thank you.

C

C

So next is MSD young update.

G

um Hello, everyone, my name, is I'm going to present an update uh of the young data model for mprs MSD on behalf of all the co-authors. Next slide, please so on. This draft has recently been adopted as a working group document.

G

um So just a bit history, um MSD stands for maximal, say depths and is defined in RFC, 8476 and 8491.

G

So this data model was originally part of the segment routing data model, which is already published as RFC 1920., and it was suggested by the ISC during the last call to separate this part from the segment routing data model, because it's part of a small mprs characteristics.

G

um This model, augmented the base mprs model- that's defined the RFC 8960.

G

next slide, please. So um thanks for thanks careful review during the adoption call, so um we made some editorial changes. I did some references also updated. The security consideration during the adoption call next slide. Please. So this page shows the trade diagram of the entire data model. So you can see it's a very small one.

G

Basically, it has two parts. The node MSD is a list of the node. I must be based on iMac types. Also, the link I might see which augments the mpis interface with the Lincoln MSD same as node MSC, is based on the MSD tags.

G

um So this data model has the common definition of MSD type and both the ospf and the Isis msdi extension.

G

How indeed, how dependency on this model, so we sure hope we can progress this model fast next slide, please so next step, um because this is a really simple, straightforward data model, and now it's a working group document. We hope we can progress this soon and we like it to request the young doctor last call review and routing Direct Read last call review, and after that we hope we can do a working group last call. So if anyone has any comments or questions, please let us know.

G

That's yes, yeah any question. There's one question: yeah.

G

A

Hi can I do it.

C

A

I do another mask reminder, please thank you.

E

I had a question, sorry yeah, uh so the MSC types that are defined today are not all mpls specific. uh There are some MSG types defined for srv6. uh How is that going to be handled.

G

So this one so far is now considering isra6 I I. Think israel6 has its own data model. So it's up to the sra6 authors to to decide how to what to do with it. Only.

E

Okay, but the number space uh for MSD types uh that you had in the previous slide is common.

G

E

Yes, there is, there is.

G

I suppose you can either augment this one or if I can talk with the sra6, also as if it's really necessary, we can split it into a separate and a model. Foreign.

E

Yeah so I'm I'm, perhaps I was I'm not aware. I missed that uh thing, but uh Sid or segment depth was Sr. Indeed Sr specific, so uh yeah.

G

E

Not sure why that is.

G

F

If you read the Japanese from Microsoft, if you read the ISS rfcs that Define cmsd, the language is that we explicitly defined type number one which is in PLS specific, the rest will be defined in the future. So for me, this split wasn't really obvious and that's why we did it initially as kind of part of common model, but since working group decided to split it, I would assume we'll do the same for services even so you're completely right. The MSD scope is larger than Justin BLS.

C

B

Question to Ying Zen but I see she is left, maybe I'll take it offline, then. If uh okay, all right.

C

B

C

B

Okay, I I. My question is related to what ketan started to talk about and also related to a comment uh that we got during adoption.

B

um It was a um a suggestion to go with an Ayana module for documenting the MSD types uh rather than defining them in your module. um Is that something that you will pursue? Or uh what are your plans.

G

I think uh just like the discussion, just we just had with skating, is if it's necessary. If I start with six um authors, don't want to augment this module, then we can split it otherwise, I think I. Don't think it's really that necessary to split it because um I don't expect the msv type will increase that much.

G

H

G

Yeah we can work with the sra6 authors together.

G

um If we can progress this draft fast, we we are now going to cause any dependencies for them, so I think that's, okay, otherwise it's gonna be a problem, might take for everybody.

E

Yeah I I think we should not rush this. uh There is. There is an issue here, but we can take it on the list.

F

So the base protocol model is dependent on this. If we expanded the interdependency will kick in and I really don't again, as I said, I, don't necessarily understand why we had to take it out of base model in a service six. We could either build single models that address same as this or do and follow work as we did here and have MSD for a service 6 as a separate model. If again working group, you.

G

Wish to do so now, after the SRA 6 young authors.

C

G

Thanks any more questions or comments.

C

She was empty, so yeah. Thank you. Thank you. So who is next.

D

C

Yes, that's correct.

C

I

um Next slide, please!

I

So um what is the simple two-way active measurement protocol? uh uh It is a performance measurement. um The two-way means that uh we have uh uh one um actor that originates test packets- that is, this actor, is identified as a session sender and transmitting to their um uh peer session. Reflector session reflector um performs some processing on a test packet and reflects it back to the session sender. So thus um uh we, um this protocol enables uh one way, um delay measurement.

I

uh It can measure one-way packet to us also to detect uh packet reordering and packet duplication.

I

um So so far uh at uh ippm working group, we published uh two RCS, the Baseline specification, RFC 8762 and extensions 8172 extensions include extra padding, direct loss measurement uh time, Source reporting that uh intended to help to evaluate the accuracy of the timestamp so to differentiate with the timestamp uh acquired using the hardware assistance uh or it's a software based and follow-up Telemetry.

I

uh So this particular case might be interesting for a virtualized environment, um so that um uh packet, that is reflected uh in virtualized environment in a server um it's uh using the software-based, the packet. So if it's in and a three timestamp uh the packet will experience unpredictable um uh delay in queuing.

I

So but many systems can report back to the sender uh their actual um walk, lock value when the packet was physically transmitted, so that value uh then can be used in a consecutive test packet so that uh to uh get more precise, more accurate uh delay measurement.

I

um So uh the mechanism is similar to Echo request a reply and um it's um format is a symmetric packet size, but uh with the additional using the Yang based model, which is uh in um um working group status document, uh it can be modified uh to do asymmetric uh measurements next slide, please.

I

So um uh the base specifications uh are not um Network specific and uh in a discussion at ippm working group, uh so there was uh brought attention and proposed the mechanism. uh This uses um stamp um extensions uh to communicate. For example, uh the return path uh for the reflected packet uh also um stamp supports a simplified demultiplexing of uh sessions using a stamp session ID.

I

So uh with all that, uh it uh appeared that uh using the approach similar to bootstrapping BFD session over mpls LSP, uh it could be a useful option uh to use and to extend lspp being to bootstrap step um test session.

I

So in here you see, uh they're captured, proposed um format of the Tov stem tlv that includes session identifier, destination. Port number and um So currently um stamp can use UDP Port 862, but at the same time it can use a port number from ephemeral range.

I

So this field can be used to signal to the reflector on which Port it uh should expect a test stem test packet uh from the sender and optional uh extension for specification of the reflected path, um reflected packet path, so which can reuse um faculty of these and non-fac defined in uh earlier in previous extensions to lspp next slide. Please so.

I

This is pretty simple and uh welcome your comments, uh questions, suggestions and well, at some point, we'll ask for working group adoption. Thank you.

C

That's correct solo, quick.

D

Question I read the draft, it seems to be in a pretty good way. Are we already working with adoption kind of immediately.

I

uh Well, um thank you very much Laura for your consideration. uh Yes,.

D

What are you waiting for? Why are you not? Why are you do you have the question mark on the on your slide.

I

I I try to be um polite. Humble.

D

A

I

I'm not always but I'm trying.

A

No, this sounds like the lower has to pick an action up.

C

A

C

Charlie is next yeah.

B

Don't skim through the draft and it's a good uh starting point. I think I just have a clarification question, so we have an mpls. We published RFC 7876, which allows you to do uh uh performance, monitoring and measurement for with mpls with ipudp, um and it doesn't require bootstrapping um for the session ID I'm wondering if you you know, can highlight the advantages of this approach versus what we have already yeah.

I

um I I like their ideology of Roc 6374, uh because it resembles ideology of ethernet, OEM and uh even goes uh more flexible because it allows combination of uh packet delay packet to us measurement in one packet.

I

um So um we've got quite a lot of interest in the stamp and I'm aware of a number of implementations uh being worked on and being prototyped, so I believe that stamp and again so, let me start probably from a little bit far um stamp allows for uh interrupt working uh with the T1 white, but unfortunately the state of the T1 white. It's not standard uh in the way it was uh defined in RFC 5357 as appendix so it doesn't have the standard, uh richness and fullness. So it's not fully defined.

I

So that's in my experience, working with the T1 polite we experienced quite a lot of problems of interworking, with the different implementations, so stamp is attempt to bring to the industry standard-based solution for the simple uh measurement that allows not only um delay and packet to us measurement, but detection of reordering and packet duplication and, at the same time, can work together in an environment where the T1 white is deployed because uh their characteristics and principles of stamp can allow it to interwork with the T1 white in unauthenticated mode.

I

So uh if you want I can go into more the specifics of a stem, but uh I just want to mention. You know really concentrate on discussion of bootstrapping mechanism.

H

um Are you intending to use um LSP ping for session maintenance as well like with you, cameras.

I

And that's that's a great question. So, yes, um um I might be not really clearly articulated in this version, but intention is a little bit different from DFD bootstrapping, because in DB DVD bootstrapping, the assumption is that uh only single uh packet with BFD discriminator Tov is used.

I

So uh in talking to people implementing that uh the assumption is that all our consecutive will be uh rejected. So in this case um and I will clear I'll make sure it's clear uh explicitly stated uh for the same session ID. There might be a number of or sequence of uh things that change the return path because, for example, you want to change the return path. Okay,.

H

Just make sure that the the recommend making sure that the text is really clear on how it should be.

I

Used right, yes, um it's a good point. Thank.

H

You yeah, there were quite a few interrupt issues that came up in the industry in general with LS3 PFT, because the text is in that RFC is a bit vague as to whether it's mandatory to do this yeah.

I

And I agree that assumption is that for 5884 that only one uh uh DFD discriminator of the same value can will be accepted.

A

J

uh Hi uh Greg, um so uh we we may have uh touched upon this offline, but um if you can also add some tax on the uh stamp reflector, that's a state full kind of thing. um That would be useful as well.

I

Yes, indeed, and um yes um so um uh Rakesh and footer, um so we we talked about it and I I really appreciate uh uh discussion with them because well they were inspiration to this work.

I

um Yes, and uh we recently talked and uh that need to be uh clearly explained so um their uh feature of uh stamp protocol is that it a reflector, might have uh to um modes um stateful and stateless uh stateless. It does not allow one-way packet to us measurement because uh it's not expected uh to count packets, it uh send uh to the sender so thus it effectively what it does.

I

It takes the sequence number from receive packet copies in reflected packet, so the sender would cannot measure one way uh packet to us, because always it will be the same as it said um so and yes, I would clarify I will make it explicitly uh mentioned and clarify it in the next version of the document. Thank you.

A

Thank you. Thank you.

C

So next is spp.

K

Hi, can you hear me? Yes, okay, hello, everyone! uh It's xiaomi speaking! This presentation is on lspp Church roots of enabled easy to OEM capabilities. This.

D

B

A zero zero.

K

Version of individual draft- yes,.

K

This is the background of this job, which of the iitf ippm iom state defines a general method of iom capabilities discovery, including iom capabilities formats.

K

In that job, the actual request reply is used for ion capabilities discovery through which the ioa and encapsulating now can discover the iom capabilities of each iom, Transit and the decapsulating nodes along the LSP.

K

This chapter is a campaigning document. That's ippm document. uh Specifically. uh This chapter defines the SPD trace route extensions to achieve iof capabilities discovery in nprc, Networks, necessary.

K

This page shows the newly defined two SVP cubes one for Echo request another for Apple reply. uh The other figure is, the format of the iron capability is very POV, using algorithm test the value field of these trvs and this stuff namespace IDs.

K

The lower figure is the format of the iom capabilities response tov using Echo reply. The value field of this POV is a list of capabilities objects, and each object represents one type of iom capabilities in one namespace ID.

K

Besides this job to define the new return code no match the namespace ID, which indicates the responder found the Clarity of it doesn't include any Nemesis ID or none of the received namespace IDs is recognized or none of the received Nemesis IDs is enabled by the local policy next slide. Yes,.

K

uh For the iom capabilities response to the six iom capabilities, sub TVs are defined, they are I, am pre-allocated tracing capabilities. Subdiv I am incremental. Chasing capabilities of gov. I am proof of Transit capabilities from tov. I am age to age, capabilities.

K

Imdx capabilities, sub, POV and iom end of the main subdue next track is.

K

This page shows an example of iron.

F

K

F

K

And responsibility in this example, the iOS capabilities of two namespace IDs, our Courage by the standard and the responder replies with the all the IM capabilities, corresponding to the two namespace IDs, enabled by the local policy.

K

Next slide. Please.

K

Next steps uh for this job to review our comments and a collaboration always welcome, will revise this structure to improve it and then ask for working group adoption. That's all thank you.

C

Thank you, sultanic.

B

C

Tariq is a.

B

Participant thanks for the draft update, um usually or more commonly the the capabilities, um it's desirable to be known even prior to establishing the LSP.

B

um There is a dependency here that you have the LSP um with your approach. You have to have the LSP present and then your discover you're, discovering uh capabilities uh um using this LSP trace or ping.

B

um So there there is this uh shortcoming. I would say that you cannot discover the capability before the LSP is set up um and and even if you change the LSP path, um how is that you know going to affect the capabilities that you you've discovered before, so you have to re-trigger again every time the path changes for the LSB.

K

Yes, I think uh if the SBP changed then Discovery have updates Discovery need to be triggered again. Yes, do you know any uh any uh protocols or mechanisms that can discover capabilities before or uh before the spp yeah.

J

K

B

Igp capability advertisement, so usually you would flooded in igp and any any head end or any in you know, anyone setting up the LSP would know it in advance.

K

uh Yes, I I think uh the authors can compare this method described in the instructor.

E

K

Igp uh method and uh report to the working group is that okay.

C

Thank you. No more questions, okay and I. Think.

A

Declare it closed. Yes, we'll resume tomorrow with the joint session right. What time is it uh first thing? Is it 9 30.

C

9 30, then I guess yeah first session, so see you either tomorrow or in Yokohama. Thank you. Thank you.

I

I

I

I

I, don't know you know for us.

I

I

G

Right up, I just decided yes,.

G

Thank you. That's wrong.

F

To change I mean the capability.