Internet Engineering Task Force 110, 10 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF110-IDR-20210310-1430

Description

IDR meeting session at IETF110
2021/03/10 1430

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

A

B

Giuseppe, could you try my.

B

C

C

Starting to feel like we caught everybody, you know stepping away from the computer just before the session started.

C

uh So, since giuseppe hasn't responded yali could you also uh do a microphone check? Please.

D

Could you hear me well.

C

We can hear you thank you.

D

E

Can you hear me.

C

Giuseppe you're, a little bit quiet.

E

C

It sounds like you're talking to an open air mic.

E

E

C

And hello linda, if you could do a microphone check while we're waiting to start that'd, be great.

D

Can you hear me.

C

Loud and clear, thank you.

D

D

F

All right we're two minutes into the session. So do you want to kick it off or jeff? You want to kick it off.

B

I'll go ahead and kick it off today go to the folks. Welcome to the wednesday session of idea, we've got an hour if you've not read the note. Well, please do that care. Will you show the next slide, which is the agenda.

B

Our agenda is close for an hour, so folks, uh please be tight uh if we get some more time at the end, we'll open it up to question, if not waymo you're first go ahead.

G

Hello: everyone today, I'm going to present the hd bgp flute spec for airsoft v6 next page just give a quick review about the document. So for ipv6 a packet head for an sr package. It has special structures. For example, its destination is a segment id which consists of locate located field, auctions, field and arguments.

G

So for this special structure, we define two new component types, so one of the type can consist at least or for operators with values to define matching conditions on this special field, such as locator field, function, field or arguments field.

G

G

So which, for this latest version, we just made some editorial changes next page.

G

So we would like a welcome comment and also we would like a request for adoptions.

G

Yeah, that's all for for me today. Thank you.

H

Cool joel you're on the mic. Thank you.

I

I had apparently not looking sufficiently closely at this draft if you're trying to point explicitly at the lock field and not encoding the length of the lock field in this spec.

I

Then interpretation of this piece of flow spec requires processing and using other routing information to know how long the lock field is.

G

Yeah good question, uh since uh so in fact, because these are actually just just a very brief review and we have uh uh for each operator, we have a value, so those uh lens for locator and a function is encoded in the lens in in the value of in the in the value field, in the variable. So can you go to previous slides.

G

Previous one, that picture here, we just give details about the operator. In fact, where operator has associated with a value, so those length field is given in data value. We have.

I

Structure, okay, yeah yeah! Thank you so the length the the length well, it's not in the field type is in the value. That's good enough! Thank you. Yeah.

G

Yeah, yes, yes,.

F

C

Weibo uh my question to you is: uh this is obviously targeted for current srv6 related stuff. How do you foresee this interacting, perhaps with the work ongoing in spring, for you know the more compact uh formats? Are you expecting this to be a logical format that you're expecting to carry to the new compact formats, or do you think that you will need a new flow spec for each of those.

G

Yeah, that's a good question. I think uh uh these are because we talked about uncompressed. I think for compressed one, because that structure may be a uh have. More information will have additional information for comprehension. So in that case we need a virtual extension for compressed seats right.

C

I that is my question and one of the possible outcomes. I I think the input I would give as an individual contributor rather than a chair, is that uh one of the things we know about the sr related stuff is that the differing formats are going to be a big challenge, and I think we should understand what we're looking to get out of flow spec for the different formats before we go. Choose any specific draft towards it.

C

uh Not so much that your draft doesn't solve the srv6 problem more that we may want to solve the more general problem.

G

Yeah, I think the first step is a focus on the uncompressed one because for a compressed one they're still working in progress, because there are a number of proposals for compressing the seats, so different uh solution or proposal for compression they may have different information attached or added into the destination or c's, or some of them just put will update the header, some fields, open field and flags views.

H

That is it. Thank you, joel you're.

H

I

Oh sorry, I pulled back up the draft and looked while I get how the length in the value type works for the lock. How do you find you? You actually want to be able to explicitly test the funk, and actually there are multiple problems with explicitly testing func separate from lock among them that it is not actually required that they have meaning that the encoding is the is constant across things. That's not what's required by network programming, and you don't know where the lock is.

I

The length of the value field won't tell you where, in this thing the lock is- and it is not required that it be at a constant offset for all sids used in a given domain, even within srv6.

I

It could be, but it's not yeah, that's yeah.

G

That's a good question. I don't think this works uh this, uh because uh we just provide a this kind of component and then- and they use this one.

G

The user or application will define, define those operators, and then the user, user or application will have more information about the size of locator, because for some of the because those applications were used were targeted for some some fluids traffic flows and then for those traffic flows they will know they have more information about the the locator and the function, the interest you can't.

I

You can't process this without specific information from elsewhere in the routing system, not just general config information, I wouldn't care if it required general config information, but you need to actually know for this lock. I look at this funny bits to see that that's the funk. If, if I have this prefix on this segment on the sid, then I look at this many bits and that's just not the way even floatback has lots of problems, but but I don't think you can do what you're trying to do here. The way you've laid it out.

I

I think you need to go.

H

Back again at the rfc.

I

On network programming and on the encodings for how things actually get transferred? Remember that, for example, the standards for the values of of funk are not actually standards for the values in the packet. They are only standards for the values that get encoded in the routing protocol. That tell you what the meaning of the sid is.

I

So if you don't even know what the meanings of the funk bits are, unless you've looked in routing for the specific lock and it's encoded separately for individual locks, so I think that the srv6 network programming is much harder to filter.

I

If you want to separate filters, if you just do it as a prefix on the sid sure it works, I can't argue with that, and the length of the value will tell you how many bits to test works, but if you want to separate out the funk or the args and test them, it's not even clear. It's meaningful as a test, and it's not findable as written.

B

Joel and lama, I think.

I

B

Great, I think this is a great thing to actually detail on the list. Joel waymo, it might be a really good thing to have a discussion on this and confirm it before you ask for working group last call for working group. Adoption would would you would that be okay, because we're going to run. I.

G

Know you've got the time.

B

No problem: okay,.

G

Okay, okay, yeah yeah, yeah.

B

And also joellen jolin waymo. I think that I think that the discussion would also be valuable either on idr list, uh because we're looking at the limitations of flow spec, you may find that flow, spec, v1 or just proposal for expanding flow spec v1 may take us into v2, which may provide us additional aid. So I really would like to see this on the list because I think it's beneficial for our general flow spec.

B

Thank you both if we have additional time at the end, we'll open this up, uh joel and and waymo will come back to this.

F

C

F

Much thank you. Emma um next presenter, uh linda you've got two sessions.

D

Okay, so um here I'm going to uh introduce a new nlri address family for the 5g edge computing services. Our next slide.

D

Please so um we presented this in 109. There were quite a few questions on the list and and also during the discussion. So I just want to recap what we discussed.

D

So basically, there was a assumption that all those edge computing servers they are in the local data network, close to the 5g core network and the multiple servers for one application and the application prefer to use any cache address simply because make it easier for deployment, so they don't have to readjust addresses for the application when they want to move a service from one server location to another, with any cache address the network itself being leveraged to distribute the traffic to different um edge nodes.

D

So um the the thing about in our network itself, we, a network network itself, has been very good in using the routing distance to compute the best path to select to the the best pass, and we also have te traffic engineering taking bandwidth into consideration.

D

However, for this kind of environment, the the bandwidth information and the routing distance might be similar, so there's another attribute being introduced, which is the running environment that load information.

D

The those applications themselves are registered application services, not just every any service attached to the network, only the ones, the application that needs network to further optimize, the distribution among different locations.

D

And so we introduced a new um um mri and subtle v to carry those information, so that can help the ingress node to choose the uh the optimal path to the egress router next page. Please.

D

Okay, so um during the 109 and the mailing list discussion, there were three issues being raised.

D

Three major issues being erased right, so uh first one is how to select the optimal egress router, um based on the information received. um Second, one is um how the english node keep the packet up from one flow to the same server.

D

Third, one is: when the ue moved from one cell tower to another cell tower and being anchored to a different session pdu session, or they called, which is part of the upf user plan function, then they will go through a different ingress node. How that flow can be stick to the the original server okay. So next page please so this meeting just want to clarify those issues. So, first of all, um for the past selection uh there's assumption here right so only for the register services.

D

There's the application controller, um which is identified in the 3gpp 748 project. The application controller will tell the network which services they are interested for network to optimize. The forwarding with those information appropriate acls, can be created on the ingress, node and other on the egress node, uh which service to collect and there's a bgp compute plugin that can compute the optimal path or best path with the information about the running status.

D

In addition to the routing distance and the bandwidth information, if te is considered, so that's the assumption um so this for the past selection. That's basically we'll be able to take the application metadata um input into consideration so that um when a destination has three next hubs, r1r2 r3 and they can choose to the the optimal optimal one and in terms of forwarding um the forwarding the on the bgp compute download the voting table to the contract to the forwarding plan, the forwarding plan will use the existing. The flow affirmative feature.

D

Affinity feature to support to be able to make one flow goes through the same path. This feature is supported by most commercial routers and when the ue moves to a new uh sale size and then the the traffic will ingress from a different ingress router, we have a draft in six man to show how do we use ipv6 to stick to the same english, egress router and also if the ldn is hrv6 based?

D

That approach has been um described very clearly in the six-man apn 6 to show how the srv6 is used to stick to the original path? um Okay, next page, please.

D

So in the for the app metadata information- propagation, it's not to be distributed to every node and the scope of the propagation can be using.

D

We can use the ifc 4684 to constrain the distribution, um but there could be application servers many of the services needed, so this could also be statically configured the application server id, which is the anycast address and then with the interested routers next page, please so so here um those are the main um subtleties we propose uh once the ri has attributes for the application metadata, and today we only specify the four sub-tlvs.

D

One is the load measurements and one is the capacity another one is the preference those information um can be either actually um downloaded or exchanged between application controller to the egress router or computed by the egress router. So those are out of the scope how the egress router uh get this derive those information, but those are the roi needed to carry those information in the future. Maybe more application.

D

Relevant data can be included here, but for now we are asking for working group adoption just for those proposed roi and subjects. That's it. Thank you very much.

F

We've got a little any questions for.

F

F

Linda you're, on to your next.

D

F

D

Okay, um so this is the sd1 edge discovery. This actually will be a very short presentation. um Thank you very much to the working group for the valuable feedback and we have cleaned up the draft, and so I just want to give you an update next page. Please.

D

So this is what we discussed in ietf109.

D

Basically, we took the tunnel in cap draft the mechanism described in the tunnel in cap draft and now it's probably on the q2ifc now using the separating the the underlay um underlay tunnel property advertisement from the client, so the client um basically use the extended community to describe the tunnel type and also use the color to coordinate correlate with the underlay property. So um there will be two update. Two types of update right: one is the client one is the underlay um next page. Please.

D

um So we cleaned up a little bit here. uh Basically, if um ipsec um has been ipsec, security association has been pre-established, so, instead of attaching all the ipsec related parameters, um we just include the ipsec ids and those ids are pre-established, and if those uh episode has a certain uh inner encapsulation we'll attach the proper tunnel encapsulation subtle beach, which is already described in the tunnel in cab drive.

D

So we I presented this on monday to the ipsec me just make sure those kind of configuration and those kind of method of carrying the information doesn't cause any problems with episag me group and people over there think this. This is good approach.

D

This is slightly different from the traditional ipsec configuration, which is always pairwise. You always have two end endnotes and you have to establish authentication.

D

You have to establish all the related like traffic, selectors admission and routing information between the two peer nodes with bgp with the route reflector, it's scaled much much better than the pairwise when you have, especially when you have a large network and also that with bgp, you have a raw reflector, already connected to all the edge node through secure channel. So the authentication is already done before, even this being established it this before this message to be exchanged.

D

So that's that's a good news from the episode and e group um next page, please so, um but for the um secure ipsec security association.

D

If it is needed to be exchanged through a bgp update, they can also include it here with detailed information like the key sub trvs nouns and proposals that transform all the detailed attributes needed by ipsec. They can also be included as a subtle v in the tunnel exchange next page. Please.

D

So, um with a hybrid hybrid tunnel, which can include both nprs paths and episode path, um this roi is introduced um basically include the color uh include the site type because for hd1 deployment some sites can be far away. It's not like controlled, uh like mpls. Everything is within the within the wall, so the site type can have be a simpler. uh Just the node id itself be able to identify the precise location.

D

There could be in a more diverse at your geographic location that you need to include the geolocation information septuali to indicate accurate. Besides your location, and we have color to correlate with the client update next page, please.

D

So I we think that this draft is clean enough and answer many questions from the working group and we are ready for working group adoption.

F

Super any questions for.

F

F

Thank you so much linda great, thank you and we got four minutes.

F

F

In our next presentation, uh giuseppe.

E

Hello, everybody. Can you hear me, okay,.

F

Yes, we can hear you fine, okay,.

E

Yeah, this is an update about the bgtsr police extension for I fit the graph that's been adopted during its 109. So next slide.

E

Yeah just a few words about background and motivation um if it refers to data plane on path telemetry in particular in c2rm and alternate marking, and you can see the document the relevant documents for these two methodologies.

E

On the other end, we we know that an add-in may be informed about a graduate part about by using bgp and you. You can also see the relevant document by combining these two bot on part telemetry methodology and using the this bgp capabilities. We this document times to define a new extension to digitally, to distribute.

E

I fit information together together with the sr policy. This way, the telemetry methods can be automatically enabled so next life.

E

Yeah in this, in this slide, we report all the changes after the working group adoption. In particular, we received some comments on list during the adoption call, firstly from drew we, he suggests to add more text about the error, rambling actions, the ifit procedures to start stop, update the different type features and also the backward compatibility that need to be guaranteed.

E

Another comment from katan was more about the types of steering that would be possible to be used for sr policies and how this is handled by the srpm.

E

Another comment from gun was about the alignment with the sar policy and tunnel encapsulation attribute according to the idr segment, drawing fee policy graph.

E

Another comment from mike was common to the companion draft in pc regarding the possibility to consider different effect methods for each segment list, and we also added some consideration about that and in the end, we added the new new fields in the alternate mapping mode to indicate if the measurement is up by operant. One next slide.

E

In this slide, we summarize the changes in the main changes in the zero one version. uh The first one is about the specification of how happened is speeding into a nasa policy. Basically, it is the same as specifying in the spring, in the spring document on segment routing policy.

E

So once the airfit attributes are similar to bgp when the packet arrives at the at the head and it may get steered into the sr policy according to the procedure, they find spring document.

E

And I think methods can be applied, of course, if they are similar regarding the all the possible cases of I feat we adopt and in the draft a conservative strategy. So this means that in case of empty I feed wheels or more than one instance of the same subjects or if there are two conflicting iom subtle these.

E

uh If it is not activated, so it's better to have the conservative approach if this is an optional functionality, the regarding the validation as specified in the spring document. This can be treated as all the other tlv, so the validation can be added by the srtr.

E

The backward compatibility can be also guaranteed, because if there is an implementation that does not understand, if it subjects v, it can be simply more and the same applies for error. Rendering actions, because, as described in segment routing t policy draft in spring, a bgp speaker must perform the syntactic validation of the mli and can determine if it is good. If it is not formal, and if there is an error. Tritas withdraw is a good strategy to apply, and these, of course apply also to a heat treat.

E

E

Now this is a quick recap about the draft. We updated the sr policy, encoding structure and the effect attribute. You can see that we draft added the effect attributes after the gate at the candidate part 11 as the subtleties on the right. You can see the format of the general life. It's subtle these and the the detail of the different options of the video currently defined data file.

E

E

Yeah in this slide, we have the detail of the situation sub tld, so the top four for the pre-allocated race option, the incremental presuption directly export option and edge to edge option. All the fields, of course, are aligned with the incident graph in ippn and next.

E

Yeah this is the the other subject related to the alternate marking.

E

As I said, we added two new fields, the two flags uh h and e about that indicated that the measurement is up by operand one, and this is also aligned with the rail around drafting in ipv6 on data plane about alternate map next slide.

E

E

Yeah, we added some more consideration about the operations uh we defeat attribute for sr policy.

E

Basically, we referenced all the operations of segment routing key policy draft in idr, so we just updated some added some consideration, but the basic operations are the same uh since a fit attribute. Subject are optional: they can be considered in the mli by a bgp speaker, but of course the implementation may unsupported subtleties.

E

Once the mlris have been accepted have been considered acceptable, including.

F

E

Information, this can be propagated regarding the error, rambling and the validation. This must be performed to determine if they are formed or imbibed, but this is done by the srpm has also stated in the segment browsing through policy draft. So next that's like this is the final slide, so we are working. This work is in progress to make the draft table. Of course, we welcome questions, comment to improve it and to go to glide.

E

F

Any questions for giuseppe.

F

Super. Thank you. Okay. Thank you.

F

And I believe we still have one presentation more.

F

F

I'm trying to get hold of the slides.

D

Okay, thank you.

F

Give me a second please.

D

D

B

Grab this presentation I have them hold on.

F

Yeah, can I give you the screen yep.

F

So you got the screen.

B

B

B

This should be ellie. Do I have the right presentation.

D

Yes, but I cannot see the slide, make sure the screen sure is being started.

B

uh I see never mind give me a moment.

D

B

Back to the screen, sharing give it a.

B

Second excuse the few moments of fiddling with.

B

B

Okay, just a minute you'll get the big screen.

D

Yeah, I can't see.

B

I'll get you a full screen mode. Can you go ahead any time you want.

D

Okay, thank you, uh hello, everybody. My name is uh yali wang from huawei, so I'll talk about the draft to propose to define the bgp extension for advertising ipad capability next slide. Please.

B

Do you see ellie.

D

Yes, yeah, I think maybe a little bit delay yeah. Thank you. So, first I am going to describe requirement and goals of this uh proposal and then I'll introduce the definition of iphase capability and two optional extensions.

D

B

Please your next slide is showing.

D

Yes, I see it so yeah. First of all, uh england uh ifit refers to a family of data plan on paths techniques, including the in-situ oem and alternate marking, and I need to indicate that the iphone capability of the devices can be manually configured one by one. So hence the deployment efficiency is low and menu. Configuration may be incorrect so and when the I think, the capability of the network devices it changes.

D

For example, uh the devices change from the supported eye feet uh to uh non-supported the high feed capability, so the physical configuration on this device need to be modified.

D

So, based on this uh crashing and issues here, we propose a extension to bgp to advertise the tail nodes iphase capability.

D

So in this one we propose two optional methods: one is to extend to ipv, 4 or v6, address specific, extended community and another one is to extend to the bgp network capability.

D

So here I want to answer the question why we propose list to option optional extensions, as I, uh as I mentioned before, we need to prevent the information leakage, which means that we we need to avoid the iv8 data leak outside of the ipad domain, which may cause complete and errors, and another reason is that we need to determine uh whether I particular I fade option types can be uh supported by the tail nodes.

D

It means that uh depends on the information I can decide, which kind of the iv option to be in encapsulated in the english node uh yeah. This is the reason next page, please.

D

So here we firstly define the ifit capability format, assuming the figure is formed as the 16-bit bitmap and right now we give the five flags uh used to indicate different kind of option. Types include the ion and alternate marking yeah next.

D

Okay, here uh this is the first option extension and this is extension to bgp extended community. So uh here we give. The uh true scenario: firstly, is for uh the ipv 4 network, so let's just define a new type of btp extended community called ipv4 address specific if a tail community, so it means this, it can be used by the I feed the capsulation node to notify the iphat capability to is its partner. uh I mean they. I think it's encapsulation note uh it because it is a uh traditive extended uh unity.

D

So we here we requests to be allotted the subtype code number and this another one is for the ipv6 network. I think it's a seminary.

D

I mean the seminary matter to to extend the ipv6 uh address. Specific, I think tail community, yeah and uh as shown in the figures or original address, is, are defined as the ipv's i4 address of the f8 capsulation node and another one is, is a ipv6 address of I fit the capsulation node next, please please.

D

Okay, this is the second optional extensions to a bgp next hub capability, and so here a the bgp next hop capability attribute uh is an uh is a non-traditive bgp attribute, so here we it is modified or deleted. When the network may change it here, we define to reflect the capability of the next hall, the hub of the iphat capability.

D

So here the capability codes we defined as a two oct octet are signed by uh uh binary intake, lim integral, which indicates the type of network capability uh uh advertised and to identify an individual capability, and here we request to uh less code as the I fit. Next I face next hub capability, and here we also um to define the original ip address uh as the iphas the calculation node address, so so uh at defined.

D

Here we can see that a pdp speaker that can send an update with this bgp next hope capability attribute, uh including the ifit network capability, so the increasing of the iphone x hub capability with the network layer, reachability information in the bdp updates indicate that the bdp next club can act as the iphat decaf solution node and it can process the specific eye fit package.

D

Yeah, this is the second one, next page piece.

D

Okay yeah: this is all the content defined english swaps and any comments suggestion questions for. Let's draft, uh please let us know- and we also request work group to evaluate this draft and consider it be adopted. Thank you. That's.

D

B

Okay or you will need to ask for questions and manage the money.

F

For sure uh any questions, uh folks for yali's presentation.

F

F

C

Am I off mute now? Yes, thank you, sorry about that ali. Thank you for presentation, and this, I think, is a more general question, uh more applicable to your draft than the one that giuseppe has presented.

C

um I have many concerns about the security considerations and some of the protocol behaviors for this draft, not that the problem is not worth solving, but I, I think, there's two things that are sort of clear from looking at the initial presentation.

C

The first one is that the ifit domains have considerations as to how widely this information can propagate, and since these things are attached as extended communities, you know they're very likely to get far away from where you want them to so some discussion about that needs to happen in the draft.

C

The second item I see is an immediate concern is when you're trying to actually say that the next hop is able to carry out certain behaviors you're, making assumptions that the next hop is potentially not being reset on a different spot of the network than where the community was originally attached. So I think that also raises concerns.

D

Yeah, thank you. Thank you. Your comments and suggestions and uh for your first question I think you mean the uh the I think uh uh domain right, how widely the fatal man is and how widely the information can be transmitted and because I think the definition of life domain has been defined in I mean another drop and I think we can make it aids the jobs as a reference and make sure the domain of diabetes but, uh as I know, the ipad domain dependence and bounty dance, the I face ingress node and the egress note.

D

So um after uh I mean when, when the package had I fit, uh I mean I fit a header in the package so before before the package transmitted to the e-grades nodes, uh as shoe the header I think had should be removed from the package. So let's try to make sure the uh the security uh in the trans uh I think domain. I think, but I think it should be a problem to to consider it. It's a.

C

Right, the the specific concern is that the communities that you're attaching to bgp will leave the ifit domain. So let us say that isp a is a ifit domain and it's part of you know autonomous system number one when the routes are sent for destinations inside of that autonomous system to autonomous system 2., if the ifit capabilities are not stripped.

C

I believe this gives information that suggests that as2 is capable of doing ifit operations with as1. I don't think the expectation for ifit is that that should work, but the capability propagating tells it that maybe it.

D

Should yeah, uh I think, yeah I I think I will uh considering your suggestion and uh if, if you don't mind, we we can discuss this in the main list.

C

Yes, I'll take it to the mailing list.

D

Thank you very much. Thank you. Thank you.

F

Boris you're next.

J

Oh, thank you yeah very short comment. Not question would be very good to see implementation status in the.

D

Draft uh you mean worth the time.

J

It would be very good.

D

Okay, okay, I I think I will add the part in a new version.

D

Thank you for your comments.

K

Tony hi, a follow-up question to jeff's comment, given that this is local and we really don't want it propagating, wouldn't this be better served being in the management plane and not in bgp.

D

Whatsoever, oh I'm sorry! I I I don't catch your opponent. Sorry.

K

So why is this information in bgp? It seems like this is information that should be provided via open, config.

D

Oh okay, this is from it's from the motivation, I think from the motivation of this uh proposal. We designed because we consider to take advantage of the btp protocol to dynamically trans uh dynamic, dynamically detect the devices capability, so we consider using the uh the control plan protocol, not the management plan.

D

This is our uh motivation here.

D

Because, uh here we we, I think, a previous slide. We have mentioned that we we're considering, uh if we devices dynamically change this its uh capability uh to support the iphat uh application right, so we need uh need have a matter to dynamically detect its capability.

D

So here we we give a uh a matter to taking advantage of the bdp protocol to to catch its capability information yeah. This is our consideration here.

K

Yes, you are protocol. I understand that why you stick it in routing. This has nothing to do with routing.

D

Okay, you mean it relates relationship to the routing right. So here I think, um because the you mean, uh you know that I feed uh the I fade. Application can be inserted into the package, the the traffic packet.

D

So if we want to measure the performance matrix using the iphage, I mean the iom or the alternate marking matter to to get the performance matrix. So the devices need to support the capability to proce close process, the iphage package.

D

So when we enter the ingress nodes, when we decide uh which which, for example, which powers a path or the which flow, uh we need to use the iphat application to measure the performance matrix, we need to know.

D

These devices along the path can support this capability. I mean the supposed the eye fit capability, so you can affect the uh affect application. On the other hand, if you want to calculate a path, can be used, the ifit application to to measure the performance matrix to make sure the soa of list parts.

D

So you need to know uh how which devices cannot support or which device can support the iphat application along the path. So.

B

um Kelly, this is sue, um I think you might. I I think you might need before working group adoption to uh carefully consider tony's question and uh provide some pros and cons uh on this. I don't think at this point, perhaps due to the fact you've just heard tony's question that you've given a uh response that doesn't point back to the management plane. So I may I kindly suggest that you consider this question with your co-authors and provide some additional details.

B

If you'd like some feedback on an initial presentation before you send it to the list, you are welcome to send it to the chairs, but I think it would be wise to consider and give pros and cons before you go for a working group adoption. Otherwise, I think we're going to go through this discussion again. Would that be okay, ellie.

D

Yeah sure I want to discuss more details with that with yours.

B

Yeah or you can, I encourage you that this discussion should be come to uh should occur, will need to occur on the list before working group adoption.

B

But if you are unclear on the question or the import of the question, you can of course send the chairs some some clarification, but you will need to discuss why this is important to put in routing on the list before we go working a group adoption. Otherwise I'm afraid it will just repeat during working group adoption.

B

Do you understand what I'm saying? If not you can ask me in email.

D

Yeah, I think I got your point.

B

D

B

Thank you again for your time and for your presentation.

B

I think we're out of time care. It's your call.

F

Yep, no, we. Why don't? We take uh your questions robin and kissabi um on the mailing list uh and uh close the presentation at this point?

F

Sorry- and thank you so that was the last presentation and we will see you again at ietf 111 in three months. Thank you.

F