Internet Engineering Task Force 106, 18 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF106-IDR-20191118-1810

Description

IDR meeting session at IETF106
2019/11/18 1810

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

A

We're about to start it's true, hello, everybody! This is IDR we're getting started, so please find your seats or find the door or you know, stand up and back at the peanut gallery or whatever su is going to put a note well on the screen any moment so that you can have seen it. But I bet some people in here have seen it but I think yeah. Here we go.

A

It is our note. Well, it is the ietf policy. You did agree to this thing when you registered to come to the IETF. If you don't know what it says, you probably should acquaint yourself with it enough said we're gonna try to cut the whole comments from the chairs thing well short, because we would rather spend our limited time on other stuff, especially because sue has been doing a bang-up job of sending out periodic status updates.

A

So it would be kind of redundant to spend our time here and now sending out status updates, but I realized I should walk around and get these blue sheets moving, please sign into the blue sheet and whenever they get to the back of the room, please someone bring them forward, and so they don't get lost. It's always a pain to have to find the blue sheets at the end of the meeting.

A

Do you want to so here.

A

So this is sort of the last minute thing that I put together because.

A

Essentially, I noticed that you know I, guess I didn't just notice, but we have a lot of flowspec related drafts. They continue to come in every meeting. I think we've talked about this before, but as a reminder, if you go and look at flowspec flowspec does its thing using NLRA, the NLRA contains flowspec components. Flowspec components are structured as type value pairs. They are not structured as type length values just type value.

A

What does that mean? That means you can't write a generic flowspec parser. You know, unlike unknown path, attributes that we can just skip over and keep going and everything's good. You get an unknown flow, spec component and game over.

A

This isn't really good for flowspec extensibility there's an exception, which is, if you're, defining flowspec over a new a few Safi. That's fine because you've got a demultiplexer up. You know that you do know how to find that either. You know you either you exchange that fe Safi in your MP bgp capability, in which case you'll, will know how to parse the components or you don't, in which case you won't get the component. So that's fine, but you just get one shot.

A

You know once you've defined your your new, a fe Safi with your new components in it. That's it forget about extending it. Later.

A

Some years ago we had a flow spec v2 proposal that, among other things, represented components as type length values. So obviously they wouldn't have this problem, but instead we have not worked on that actively because we have taken, you know, did the quick thing of doing the bist document. First, with all quick things, it wasn't quick.

A

So the thing that I would like to put out for you know, potentially a couple minutes of discussion right now and I will also follow this up to the list, of course, is just it seems to me, as as the co-chair, that it doesn't really make sense for us to advance documents that define component types that can be expected to make.

A

Peirong sessions fall over if you actually transmit them across the session, so that kind of implies that either we stop extending flowspec or we get back to work on some kind of follow on whether it's you know resuscitating the v2 draft or doing something else is up for discussion.

A

We have a few minutes for discussion if anyone wants to make a comment. Otherwise we can talk on the on the list later.

B

Chaired much Akamai makes sense to me that we should fix the TLV oversight. What which method doesn't matter to me?

B

Jeff has spent a lot of time in the last year, actually working on flowspec code and some of the reason why you have the some of this stuff 255, something like this number one piece F actually picked up our format and was going to stick it in their protocol. They received this morning. They did the same thing, except for their components, actually include link fields, so they do not suffer from this problem, so we have at least one existence, proof of change.

B

The format makes it happy thing number two: we should gate these new things, I believe and something that has a TLV I. Think that if low spec v2 makes sense, I think the scoping of the faux spec fee to proposal may need to rediscover.

B

Feet in place make it TLV. Flowspec v2 also try to advance it in terms of like firewall rule ordering have to decide. If we still want that.

A

Thank you thank.

C

You go fishing skiing, Verizon, Media, Yahoo edge, cast absolutely agree with Mike.

D

C

Agree with what both Jeff and Jared have said, we, the current mechanism of we, really cannot extend folks, but because it will make routers fall over and govt is just an oversight and let's bite the bullet and fix it. Thank.

A

You, let seems like consensus in the room so anyway we'll we'll discuss it further on the list, but I think that will be the you know. Even though I'm standing up here, I'm I do have a chairs hat on right now, I I think that's going to be the position of the chairs going forward. Is you know you can you can discuss your your extension draft, but I think that we are going to want to prioritize the groups time on getting the the TLV thing done so that we can actually roll out those extension drafts.

A

E

As the author of the previous one, I, really don't care just as long as we fix the TLB problems, so open proposals are are okay on this we have an a flow spec in working group. Last call the chairs wanted to make sure we knew what we, if we had any sense for the room again we'll send more of this out to the mail list but seems like it would be a whole lot better to fix it.

E

So, speaking of flow specs, are we ready for Donald yep.

E

And he's using a different, a piece, a FISA, which is why we wanted to I think I've got it. It should be dance.

D

Okay hi, so after that, oh that's not quite right! So I'm gonna talk about two drafts in only 10 minutes.

E

D

With some time for discussion, so I'll be moving along here, pretty quickly, layer, 2 VPN and the tunnels, so the l2 VPN flowspec draft has a number of changes from version 11, particularly clarifying that it applies to efi 25 Safi 134 included some stuff about validation.

D

So you can tell it if flowspec is coming from a source authorized to send that it has a very minor extension for the drop eligible indicator bit, which is a bit in VLAN tags as I can be checked, and so it basically defines new component types for l2 and those now have TBD values rather than fixed numbers, which used to be in the previous version and there, of course, there are various editorial cages, so I'd like to resolve questions at the end, because I want to make sure I get through the expository text on the drafts.

D

But the question arose on the mailing list with expert on whether this can use Saffy 134. So a fee 25 is defined as the a fee for l2, VPN and Savi 34. Currently, in the IANA registry, says VPN v4 dissemination of photo spec rules. The ipv6 draft is going to expand that to be l3, but ie, then this staff proposes a change change it to VPN dissemination because you can tell from the a fee whether it's VPN, ipv4 or ipv6 or lastly, in this case level, layer 2.

D

So why do you need to use a new different Safi from 134, because the a fee tells you what's going on and you also might be able want to apply? What's in this draft to non VPN cases and there's a convenient a fee for that you can use fe6 and Safie 133 an ambiguously from the definition of that affiant a fee would clearly make what case it was appliable too obvious to anybody getting that. So that's the question people can think about it while I go over the other draft.

D

Is there a good reason to have another Safi, which I think is a burns one for no particularly good reason for this ultra VPM, so the other draft, the file name, is unchanged and has n vo 3, but the revision to the draft I've that's been made from zero version. Zero. Six digital seven makes it really not nvo three specific, the oh six focused there. It didn't really say anything about sad. It wasn't really clear: what's a feat was being used or anything it's a matter too good.

D

A draft in that regard was I had lots of other good stuff in it. It only supported VX land and envy GRE, and it worked by having a delimiter component, which marked boundary, so it sort of was like adding a component which is we found least currently doesn't work at all and may not be the probably the best way to do it in this case anyway. So the new draft of the sex 7 changes this quite a bit. It's really a general tunneling or encapsulation kind of flow spec.

D

It proposes to use a new Safi, you've just TPD, and it has in it details about the ex lam, not just vehicle and env GRE, but also l2tp, v3, IP @ IP, jerry etc, and has a new NLRA structure which can contain one or optionally also a second flow spec. So what applies to the outer header- and that applies to the nested inner header, which you would need frequently, but not always so this is what things look like. This shows the overall attribute at the higher level.

D

Is the multi-protocol BGP attribute where it is a naffy Safi next hop information, then there's the ml or I, and it begins in this draft with a tunnel type, so the hole type actually acts sort of as an additional thing. If you don't understand the tunnel type, you can skip over the hole, the hole attribute, so we, you could add things for specific tunneling headers later, even with the same, a few Safi as long as they had a different tunnel type.

D

Okay, then there's some flags regarding discriminator and a second flow spec flag and some reserved Flags routing discriminator field and then the then there's the outer flow spec, which is always there. That's the next to the last box here and that essentially parsed or whatever, based on the a fee, that's at the top of the attribute, and if the second flowspec flag is on, then there is another a fee and the inner flow spec net inner a fee applies to the inner, let's back, of course, so there's also this Rodney discriminator bit.

D

So if this is the VPN case, you need a routing discriminator to tell what VPN vrf the stuff is in that you're trying to look for and right it might not be so that's an optional thing. This way that you only meet once a fee rather than two different Saffy's for the VPN, an on VPN case. You could do with two Saffy's, but it seems cheaper to use a bit which determines whether the routing discriminator is present. So this just blows up, the NLRA gives more detail, shows the link fields and so forth.

D

This draft also has more components that defines because of the other kinds of tunneling it covers previously only was fee excellent, NB GRE and only had added the tunneling header components for those it extends the flow spec ordering rules. So you can tell what precedence is if you have a tunneling and a non tunneling flowspec that both match or something like that includes validations based on entirely on the outer flow spec. So whether the source of the flow spec is authoritative.

D

So here's two examples. The first one is IP and IP, so you could have in this case you would almost always have an outer and inner flows back, because it's not worthwhile doing really for IP to simple IP and IP intersect, which can match the the inner IP address and the outer one matches the outer one and in case of l2 VPN there might be Mac stuff there, which case you need to use a appropriate a fee, and you can have l2 stuff as well.

D

This is VX lamb, so this is a little more complex, but over at the right side it shows what would be covered by the outer flow spec. They, let us say the flow spec. That's always present. That applies to the outer header and what would be out of the inner flow spec so, but he can either. One of them can contain components that match on VX, LAN content fields and in both cases there be a difference. The tunnelling flow specs a fee would be there, so you could. You would only get to code.

D

That knows how to parse this additional field, and you also would have to have match the tunnel type.

D

So I don't know, I go over these different fields, but I'm not sure. There's too much here, that's obscure or anything. So for once. That's always what particular would like to have some indication whether the working group thinks we actually need to use a brand new Safi for the l2 VPM or whether we can use a fee 25, just l2, VPN and Safie 134 for flowspec, and I'm hoping to get to early allocation of the code points for that.

D

But he needed to resolve that question to a more Reb of the draft for the N via 3 full spec, which I could change the name or something. If people like don't like that file name, because it's no longer fully specific to n vo 3 I'd like people to look at the latest version of the draft and provide feedback. I do think it needs another pass to polish things and improve it, and the goal is to get Kol points, they're also on a goal.

D

The code points, of course, is to get implementations and see what we don't. We do that and.

E

So I want to underline that the the the purpose right here is to see if this is ready for lis allocation of code points, so they can try out some of the ideas and make sure they're ready for having an implementation. We are looking for feedback at that point.

B

Jeff has so one of the reasons that a different efi Safiye pairing is a good idea, no matter what is your changing flowspec precedence rules, so the problem would be like. Let's say that you just stuck this into what are the existing efi Saffy's as just a new component type. You want the evaluation to be a different order than what's actually in there and that's the whole point of an athlete Safi. The route selection is consistent across the entire domain.

B

So if you want to actually break that rule by changing, and so your full spec rule adds slightly different comparison steps, you discover that the prior slide well, this is okay, so.

D

That, in the end, vo 3, what everyoe, 3 unquote flowspec rule yeah. It does extend the precedence rule for multiple matches, but that uses a new safiya TBD and.

B

That's my point: there's one to have it.

D

Happy for that got yeah but yeah. My question really is for the for the l2 VPN one where I think we can us use 134, 25 134 for a fee Safi, and it has been asserted by at least one person that that's terrible and we have to have a noose a fee. There I, don't I, think that's unambiguous and it's well define so well. I knew Safi Ford. The tunnel. Aspec I completely agree with you and.

B

The only reason that wait is sort of for the reason that we were talking about if you stuck this into the existing a fee, a fee type stuff regardless, whether the evaluation is correct, a lot of implementations say: I, don't know what this component is and drop the peering session. So your gated behind the v2 work or you go with a different Africa's having yeah.

D

Well, I would claim that it, wouldn't it needs to will need to have specified the anafi with this noose a fee for the tunneled one, and if it did that, then it would understand that there was a tunneling type there and if it accepted the tunneling type but understand the components associated with that tunneling type.

A

Hello working group, member John Scudder, in my opinion, you're perfectly fine we're using the existing Safi. As you say, both a fee and Safie provide context. So sincere, you know contextualizing it with the ABI as well. Great, don't burn the extra code. Point fine sounds.

E

Good to me, okay, okay, one of the things that again because John presented at first hopefully you're thinking about is: should this go in a in a B to fixing the type length order. My suggestion is to give him code points, even if we make it to v2 decisions so that we can get experimentation going as soon as possible, and so.

A

Just to add I think that, in the case of this pair of drafts, in fact, I had a bullet on my my one slide that but I think covered your dress, which said that if you're defining flowspec over a new a piece a fee pair, you're, okay, because it's it's fully defined and I- think that's the point. Jeff was making it the mic to you. So I don't see there any impediment! You know on that basis to you know, moving forward with these two drafts right.

B

It's actually the pairwise of the Fe and the Safi together. That is the important piece the you know. You could reuse the same magic number in Safiye. If the fe is different, the code is different, so that's, okay. One other thing I'd point out is that looking at the Safi registry, 241 up to like 254 is reserved for private use. You could just grab that and start playing with it. Okay for temporarily Cumbria's yeah.

A

But don't be shipping, it I.

D

Don't ship anything.

F

I'm going to talk about the BGP yang model to begin with, if we have a new author edition and Jeff has a agreed to join it and be an author on the draft and for thanks for his contributions, I'm not going to go through the status you can go through it look at it. The tips are, of course there. If you have any questions, feel free to post on the mailing list.

F

So I'm going to talk about five issues that we are tracking they're being tracked and github at that particular location, feel free to comment on any of the issues there. If you or on the mailing list either one is fine, I'm gonna go through each one of them and if I don't hear any objections and by also posting on the mailing list, if I don't hear any objections, I'm going to zoom it's okay to proceed and implement them all right, so the first is: should Confederation be a peer type.

F

Currently we have three internal external and Confederation, which was probably not the correct way to do it. So the new two new additions are the Confederation internal and Confederation external. It's any comments.

F

Okay, none so noted, we'll take you to the mailing list. Also.

F

Jeff so I think the question is: would you differentiate Jeff.

B

As the question from Randy Bushwood to differentiate it, yes, so the motivation is hearing sessions are internal and external, and are you appearing with your Confederation, yes or no from upstate? You know, we've always shown its internal or external, and we need the show if it's Confederation, because the rules differ, but.

G

They're orthogonal, so you could have internal Confederation external Confederation. You've got four right.

B

So our two choices for modelling this was to have no enum for internal external and then have a boolean, that's Confederate, which is sort of what you have, but when you're trying to reflect the actual state of the session for what each EP rule you do, you basically have to say which of these four things it is, is the cross product.

B

So we're not saying it's no, the best one. We were the other. You know that I said there is a second option in there. Please take a look at the model and see which one, you think makes sense.

H

mmm Differently, one question to you: we're talking here about operational state or configuration state. This is strictly for operational state.

B

Maybe that was not clear. Okay thank.

H

F

F

The second issue that we are tracking is the list of s bad segments, so s path will always be maintained as a four byte. If riders started that are not four byte capable route update should consist of either year strands value. The magic number is two by.

F

Comments questions I, see really good.

I

We got for Church telecom I think this is my standard comment and remark for something like fifteen years. Are we expecting that the young modeling is going to happen on Reuters that do not have 4-byte asn.

J

That was my say: AC Linda I, don't think you're gonna find somebody implementing the yang model that doesn't support for by a SS I mean what it's it's it's. It's would be there. How many implementations are there of this yang model? I mean I, know, there's a few open camp 8, but this yang model so.

A

I would interpret both of those comments as supporting choice. Number one allows people to keep their comments brief, just because we have a lot of material.

B

To cover yeah, just a clarification comments they for bite capable in this case is not the this. Is you at 32 data structure? This is supporting our C 48 93 for 4 by TSS, okay,.

F

The third issue that we're tracking is the a spat, Lent container ill ill, contain the calculated s padlet, four routes per 42, seven rules- and this is mainly for the user to see the number that serves as input to the BGP route selection are in odd state. Yes, okay, comments, support for authentication, so currently we are tracking supporting authentication either over IPSec TCP md5 and TCP AO, with the idea that we'll probably try to achieve this using IDF keychain model that they see and others have locked on. Ac is this work for you.

E

We're looking to use the cheat keychain model, a.

J

Selenium ha I believe we have everything you need. If you look at the algorithms and the key.

F

J

Or know the key rollers is there ok.

F

Here's an example.

J

How you would do hitless key role over the implementation just have to support it? Even we've been doing it in the co, not not the egg model, but the CLI version for ages. It's just that. Not all protocols support key change with the key rollover.

G

Randy Bush is the key role over 40. 808.

G

Sorry is the key role over 40 808, well I'm in trouble with care.

J

I'd have to get back to you on that I. Don't know what for it I don't know the details of 40 808 I.

G

Was asking you know says.

F

It supports key.

G

J

40 RFC 48, oh yeah,.

G

It's real simple, so.

B

If I was Randy, Mahesh does not know the details. This is us reusing existing models. So if the exam, a ttle that is being defined by a C's yang module supports it, then we'll support it by inheritance. That's the idea: okay, yeah.

F

If that was the question.

H

Yeah Stephanie kievsky are gathering CP md5. Do we need to support it if we want people to move to display? Oh, oh great,.

F

B

So you want to make sure that this can support existing routers and existing deployments, even if this is not something that we would recommend is security, a.

J

Solanum, cisco systems, so for IPSec as far as I know, there's no native IP set for TCP you'd have to define a an IPSec tunnel that uses that as the top as the selector. So this is orthogonal to this model. You wouldn't include IPSec in this model.

B

So tier point AC our implementation, juniper and at least couple of your flavors over at Cisco have direct integration into the BGP configuration for IPSec aesthetics associations. That's what's being done here is to allow the keying of the session to be tied into the BGP configuration I.

J

I don't know if the existing keychain model supports every algorithm, because the keychain model supports both key and algorithm agility for the rollover. Ok,.

F

J

I don't know if we have every algorithm that you might want to use the.

E

Question AC is not whether you have every algorithm, but can we express what you're doing in most of the current vendors? If this time, if you think that's to be true, then we'll go on? We.

J

Looked at both TCP al and TCP md5, while we were doing the key chain, mod right can.

A

I suggest that you know a few of you that have all the details in your brand sit down together sometime this week and just thrash it out and make sure it all works right.

B

So that the meta here is that we don't want to invent this ourselves. This is something that I ATF is trying them standardize and if they don't have a standardized, we want them to help standardize talk.

A

Among yourselves,.

K

Ok, quick North capital R cos the the King mechanism that is described here that sees his trough supports us, as he said, for md5 nao for IPSec. You probably want to look at something which was discussed in carp working group- that's close, but you need a king mechanism or a key material to be exchanged.

F

Okay and final issue is features and attributes that, like references, there's a list of them, our su in particular to see this.

E

Is this is where the chair I take off my co-author hat and put on the chair had this is essentially in order to get to be effective within the yang committee. We need to actually define these so we'll need to put together a description. There are two option in a chair model, separate draft or this draft. My suggestion is to make that clear and and easy for everybody to debate on.

E

We put it in a separate draft if you're from a vendor- and you implement some of these features- I'm interested in talking to getting a small cadre of people to push this quickly.

J

Very quick very quickly, a sealant of what we did for the IGP models. Is we put a lot line and we said no more features in them and then these features are going to have to come in in augmentations, okay,.

E

Put this particular model. One of the thing was we wanted the common features that this has the inheritance from some of the open, config work where we have the common features. These are as far as we've been, although.

J

Yeah, these are old as the hills yeah okay, so this is part of the base. Alright,.

F

This is part of the base model, we believe they're widely implemented, but they're like references I.

L

Have a question now for the model: how to arise to implemented for multi public instance? Not for we are all behind for I mean that if I have money for PDP incidence, both wrong, we came before or other adjust by then I have some way of instance. It's also wrong P P for P to ze, but L 1, for example. 1 we have 1 I want to use the PDP instance the one to advertise beginning for roles and the reacted to I have a for another excellent.

E

Point, but not the focus of this particular model. This particular model is just the base. If did I misunderstand he's coming and Jeff go ahead and answer.

A

One other thing: I, don't think you said your name. Can you please give your name for the minutes.

L

Standard male Meli's, aha.

L

B

Is hypo yang, yeah.

B

Okay go ahead and we, the partial discussion that we had was the nmda battle for the Rick instancing gives him a portion of what he is looking for. We need to close the loop and the last piece of the component that he was discussing. I think I. Remember the thread in question: okay,.

F

So, just to completely complete on this slide, so these are individually will be surrounded by individual feature statements so that make them optional to implement. Just wanted to make that so.

M

A question about anything so you're saying you're going to document what these features, how these features operate somewhere else.

E

Question Mahesh gave us a pre look at what the anchors might say that that these would need to have some documentation. They can point you yes,.

M

And I love references and I'd love to see what this actually means. The question is again: the intent is to have a draft a separate draft one or more standards track draft the documents. These features in.

E

In this case that we're all I'm treating it in my chair hat as a case where you have a document and for clarity's sake, you break the document into multiple documents. No.

M

That's that's fine, so the observations that ever make is that we know how long the process can take for each one of these documents and if it's not one, if it's multiple one, six right, maybe consider if there are features that you can define in there I don't know advertising active routes. That sounds like a true sentence thing that you, where you can describe what that is. Maybe that is something you could just put in the draft right, this. It's not normative or anywhere else. Maybe something you want to do.

M

You want to put there just.

E

Surely the current discussion among the authors is a separate draft of arrow. If you have more input, please let us know a.

J

Celinda m--, so maybe not for some of these, it seems like you could just put them in the description in the egg model and that'd be enough. I'm not saying that applies to every one of them, but like always, compare met. That seems like that would be a paragraph like this and you could completely.

A

Describe okay in interest of time, I'd like to cut off further discussion, even though I have some comments, I would like to make about it, I'm not going to make them, so we can continue later.

E

Thank you very much working group for active discussion here.

E

Trying to do hey, Percy.

N

Hi everyone today I'm watching okay-y much hang on the future way today, I'm going to talk about the PGP for ite allocation.

N

So basically we have adoption call from April. Then we we have a number of comments. I think the major one is that some people don't like using PGP LS for SIDS and also suggested that using a new epistatic and then the other are commands.

N

So in this draft I, we addressed all the comments. So it's basically the first one, the first of the important one. So some people don't like this kind of extension to PGP lr s for s ID, so we just get a raved get rid of that one. And then we use the suggestions. So we use ur new at the NS, a v4 s ID as suggested, and then for those are other comments. For example, people says why you use a BGP. Why not? It is a young and then those are stuff.

N

So we give more detailed explanations for those. Why and why not in the draft, and also some people mentioned, that we're missing something we straw if we want to withdraw these SIDS and we need to put something so we also addressed of the one in addition to that, we ad the cap with the negotiations, so any other comments regarding for this new version, I.

E

Encourage discussion on the list as well.

E

It's sense. If it we made a Lunt option, call and they've tried to address it. It would be helpful if, if there's something you think still broken or still needs to be worked on. Ok, thank you. We'll go on to next. Okay,.

N

E

N

I also go quickly: yes, go ahead so another. Why is a fruit spec or as rv6, so basically with very small extensions so for existing flow spec is for traditional IPS, so we eat. We extend that much infield to the I. Si D is in the s rh. So just two component type.

N

So in last version we've already talked about it. These two new types, so one type, is for margin, conditions to a whole si D, so another type is for matching conditions, so focus on the some part of that IDs such as a locator and the function or arguments.

N

So basically we the fact that the format of this one this is similar to the existing rules back, so each one will contain at least of all OP and values. So these at least will define the match conditions. So has this much condition are satisfied, so action will happen, so both axes are at same as the existing one.

N

So the format of for the opportunity for in this version is that we just give more detail specific format or the second component type, which is a week. We would like to focus on some part of SIDS such a locator function and arguments.

N

So any comments for this one. So.

E

We recently improved the v6 flowspec by releasing it and making it, and this thing had co-author on the v6. Have you taken a look at it? I realize we just made the deadline, so maybe you didn't it might if you haven't, if you I forgot to mention that yesterday, that if you're looking for the v6, if you're only SR, v6.

E

That that may not be as germane, but if you're, if you're looking at regular v6- and you need to harmonize so I it does. The SR v6 need to be harmonized with the regular v6. Oh yeah,.

N

A little bit different because radius.

E

N

Of physics is also focus on those kind of traditional IPS.

G

N

For this one, we extend this kind of a match domain inside those.

O

Are SRH? It's.

E

O

Two different app apples.

E

And oranges, that's what I had initially thought, but, as you were presenting I I wanted to listen. Is there any other comments? How is the sr6 work coming? Are we progressed enough to look at flow specs.

J

Easy later, I just have a comment on all these flow specs and the idea of getting a flow spec for every end cap is the ID. Is there a framework for what you're gonna do? If this is, it seems like you're doing open flow with flowspec right is our? Is there some document that describes the requirement and what you're doing of this? Or is it just just because if there's an MP and that end cap exists, we'll do a flowspec.

E

Okay, see John's first slide. Our first thing is, we think we oughta as chairs again chair hat on. We have to go back and fix the basics of TLV then as to the rest, that would be an appropriate time to say what, if you think, we should narrow our scope. At the original definition of flowspec, there was a very targeted audience and a very targeted focus. The addition requests have indicated that the same denial of service attack work is concerned.

E

We haven't done when I presented, the original v2 I had called for a thought. Your exact question of harmonization, the working group asked to put it off till we got the Bissau. So your comment is germane and I think the working group should reconsider all these things. The reason I asked about the SR v6. This is a new type of caring planter that seems to take the v6 control plane. I, don't know enough personally as to the deployment. So that was a question. I guess: yeah.

J

Ac Lindemann, it seems it seems, like the header document, is at least done. I don't know about, you, know locator. It.

E

J

There's only there's only a couple ways you could do it so so.

E

We have some time to discuss the v2 and to talk about this limitations.

A

Go ahead and make your comments, please keep them brief. If you can line is closed after you guys, because when, though, still has one more thing to go through care was up. First, go ahead: Capitol.

K

Artists, I think I think we should hold this work till we have the flow spec v2 hashed out, and you could then use this as a capability or new TLB and carried having once a fee would be a much better choice from an implementation perspective. Then to get a Sofia explosion within flows back yeah.

E

That's good feedback.

B

Jeffires, as far as the applicability goes, the motivation that all these different authors have for trying to drill into the contents of various tunneled packets. His flowspec is being used for two big cases right now, the first one for dealing with standard, DDoS type things at various number gauges which may be under some types of tunnels. As an example, you know if, for example, if I would pick a topic near and you're like Linda's heart fit, so that's the UN type of implementation.

B

You may need to be able to do a flowspec filter, targeting a specific port for a specific encapsulation and still do all the firewall type things that flow spec is good for. So that's one motivation. The second motivation and I suspect from some of the people in the participants is that they're using the flowspec filters to be able to be used for traffic engineering purposes,.

E

N

One Mia is about a extension to BGP for SR pass ingress protection. So right now we already have SR policy draft is invoking, is walking walking with document. So as our policy well sender, s are passed to the ingress node of data pass and English, not West set up that pass, but when that humid in Lhasa fails so in order to prove in order to provide protection for the failure of that English node, so we needed to also send up another by car, pass through a backpack, Harper English note.

N

So the path back a path will be from that back by coupling with note to the equals note unity so that we may have some kind of informations will for protections.

N

So basically, in the previous version, we already talked about these kind of extensions, so the extension is the first small and then we just made stop. At least this opportunity contains the information for the protections and then, in this version we just make made a little bit change a damn war description as a subsidiary which described the traffic that a backup as well well we'll transport.

N

So this is the sapaterre of the details, yeah. That's all any comments.

E

So, on all of this a couple of times, I've queried these bring chairs on some of the policy. I also ask if you're working toward using this spring policy, that you at least give me a heads up operationally what what this is being used for on the are pd acceptance as a draft. I also call for operator input.

P

Hi, andrew here from liquid telecom, we are using s or policy a fair amount of it primarily for steering traffic around places that how do I put this certain customers do not want to root over certain locations of a certain hardware, etc, etc, and so we give them the option to steer around far away patch. That is all done with s or policy injection, and it's a big deal for us.

P

Looking at this I I will admit that I have not read the drafts. This proposal before this meeting my bad, but my question here would be, if I'm going to send a backup off at the moment over the SR stuff. Why am I not just going to send two separate paths using two separate communities to dictate which route or accepts them and send it like that?

P

Rather than complexified, my policy saying to the Ruta create another part when I can simply inject the two paths: do all the calculations on the back end and then set the communities to determine which route or accepts to me. That seems like a lot simpler option and it leaves the control, in my controller, to calculate all of those paths. That would be my comment on this I.

E

Would appreciate if that type of comment also went toward the spring chairs, with the reference to this there there you know some of this is refreshment and that's very good feedback and questions. Okay,.

A

Alright, so I think we're up to Europe and we're we're almost running on time. I will ask people's indulgence to say just a few extra minutes so that he can have his is full ten minutes, but we're we're darn close to being on time anyway. So if.

Q

Almost on time you mean I have to go slow or fast.

R

Q

Do I have a clicker.

Q

Job Snyder's entity I want to provide a small update on some work that was presented in ITF 104 in the Gros working group, and my hope is that this work and transition to the ID, our working group, which is why I'm here, but some of you have already seen parts of this presentation.

Q

The topic at hand is bgp maximum prefix limits, HB maximum prefix limits are a very popular mechanism in the operator world to dampen the negative effects of mostly full table route leaks. So it's a very crude mechanism or it helps against very common occurrence that we see in internet in the internet routing system.

Q

If you look at the core BGP specification, there is which introduced BGP maximum prefix limits. There is no notion of whether those prefix limits are applied.

Q

Pre, import policy or post import policy and I've created an image where on the x axis, we see a progression over time and the y axis is the amount of prefixes that one network is sending to the other network and when a leak occurs, the amount of routes advertised to the adjacent network goes up until it hits a certain threshold where the common operational procedure is to configure the device so that it tears down the BGP session and from that moment on, even though maybe bgp session is destructed, both networks are in a safer state than they would be if the leak persists.

Q

Now this is what happens. Pre policy well can occur if a maximum prefix limit is applied. Post policy is that between an e BGP, prefix based filter, that derive from say, IR data or or in case RPI based HP origin validation is applied that so many parts are rejected in the policy that the amount of routes that make it through the policy does not exceed the trash hold, in which case, even though you have a full routing, League full table route leak.

Q

If you have high quality filters, the a part of the leak still makes it through, and the session does not tear down because the thresholds are not reached.

Q

This is discovery we've made in the real worlds, where at some point we in NTT realized hey. We were contributing to a route leak that lasted for multiple hours. How come? Why do we even observe this behavior?

Q

There are benefits to both pre policy, maximum prefix limits and post policy, maximum prefix limits, the pre policy limit feature is very effective against full table route leaks, and it is also very effective to protect against memory exhaustion in case a BGP implementation is operating with a fully populated adjacent grip in the advantages of a post policy limit could be to protect against rip or fit exhaustion or to enforce contractual agreements between parties.

Q

An example of this could be that as part of a layer 3 VPN service, only X amount of routes are allowed in into that that VPN.

Q

The illustration here is that that both use cases exist in a world and I think they're. There they're valid use cases. Now, if we go take a look at what is available to operators these days, it appears there's a wealth myriad of interpretations of the particular sections of the core BGP spec on how to do maximum prefix limits, specifically on iOS XR + XE. The concept of pre policy limits does not exist at all and then on other platforms, for instance, OpenBSD is open.

Q

Beach PD, the post policy variance, does not exist and I believe that the is this inconsistency between HP implementations.

Q

A result of the lack of mentioning that pre policy and post policy limits could exist in the original BGP specification.

Q

My hope is that by specifying that both exists and how they should how they should behave, that we can encourage vendors to consider implementing both types of limits and I believe this will have positive impact on operational community.

Q

A second aspect of the draft we would like to work on is the notion of outbound maximum prefix limits, very, very crude character, stationed a character. That's a difficult word from the concept of entities perspective being a simple internet transit provider.

Q

The general case is that we will either announce a full routing table to appear or a subset of that full routing table say half of the full routing table and in the instance where to the piers, where we only intend to announce our customer routes, which is half if we would exceed a threshold of say, 400 500,000 routes, whatever is happening is wrong and we would be better off if we self-destruct our sessions on that particular ebgp neighbor.

Q

So this the concept of maximum of outbound maximum prefix limits serves to to facilitate situations where maybe the peer did not configure any limits, but we have expectations of what we expect to announce to the specific adjacent network and that we can opt to shoot ourselves in the head. Should we shoot certain high-water marks be reached now only birth as an implementation supports this today and I. If a battle of open Beach PD to to consider for testing I am aware that there are a number of complexities related to this feature.

Q

We should this be adopted. As a working group, we will need to identify those complexities and see if we can resolve them. So this I'm not passing this off as a trivial feature, but I think it is worth attempting to specify this so compared to ITF 104.

Q

I've come to an important insight in that grow meeting back then, and there I advocated that's only a cease notification.

Q

Should be applied if maximum prefix limits are met, reasoning from the perspective of internet routing, we're tearing down the session is a more desirable state of being compared to keeping the session up, but stopping stop accepting new advertisements. However, upon rereading the core BGP specification, it became clear to me that already today, in the course back, we have two options of dealing with hitting the maximum prefix limits. One is keep the session of block new extra announcements.

Q

I want us to go through the motions of tearing out the session, so we will need to rework the draft to provide compatibility with what already exists, even though, as an internet operator, it is not my favorite option. I do not wish to alter that part. I want to my goal is to to revise and clarify and not take things away.

Q

Sue has been very kind in providing a extensive review of our first step at this draft and she also provided the primary notes fish and who moved the word from grow to idea, as she was able to articulate with some patience to us that these things can only materialize. If we do this as a update to for 2001 in doing so, I've come to realize that there is a fair bit of spaghetti to untangle, because the concept of maximum prefix limits is mentioned in numerous sections and well.

Q

It is a very exciting puzzle and and yeah III. We we would benefit from from help in how to not only articulate what we want to accomplish, because I think a natural language.

Q

The notion of pre policy versus post policy is fairly easy to explain from from one person to another, but we should also be very careful in not making the current text that we want to update worse and and foremost in this effort is to drive consistency across multiple BGP implementations and provides users of BGP implementations with a reference which they can maybe consider in their RF piece.

Q

So the next step is to go through another round of cleanup to see if we can improve the language and undo some of the spaghetti, and then I would like to move forward with asking for working group adoption and work on this jointly. Thank.

A

You I would like to say: let's not have questions at the mic because we're at two minutes over our three minutes over so now we're five minutes over and I, don't you know I've seen people filtering out so I think it's. You know, sort of. Let's respect the group's time, if you have points to make by all means, please make them on the list or you know where to find job.

A

Thank you again. Thank you.