IETF 112 LSR Agenda Chairs: Acee Lindem (acee@cisco.com) Chris Hopps (chopps@chopps.org) Secretary: Yingzhen Qu (yingzhen.ietf@gmail.com) WG Page: http://tools.ietf.org/wg/lsr/ Materials: https://datatracker.ietf.org/meeting/112/session/lsr 1. Meeting Administrivia and WG Update Chairs (10 mins) Chris: For flooding reduction drafts, for any of the experimental drafts, are they deployed? 2. Flooding Speed Les Ginsberg / Bruno Decraene (5 mins) https://datatracker.ietf.org/doc/draft-decraeneginsberg-lsr-isis-fast-flooding/ Acee: Giving the interest, the number of meetings and discussions on this topic, we're going to do WG adoption immediately. Whether experimental or standard, we'll discuss more during the process. I'll probably have more comments, but editorial. 3. IS-IS Flood Reflection Tony Przygienda (10 mins) https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-flood-reflection/ Chris H: As a contributor, I reread the draft. The tunnel between L2 and L1 for forwarding, have you considered automatic set up without signaling? Once they join a reflector. Tony: That's what the discovery TLV is there for. Chris: I didn't get that, there wasn't anything saying you don't have to signal this. Tony: Depends what you think of a signaling. But basically what happens is you send these discovery sub-TLVs, which tell the others what the roles are, and you can optionally add to that sub-sub-TLVs, which describes the tunnel endpoint and say, look, this is the tunnel endpoint for the flood reflector adjacency or for a shortcut. And then there is basically a simple explanation, what's the tie-breaker and who is initiating. And based on that the tunnels can be automatically set up, but something has to set up for the tunnels unless you support the university statically pre provision tunnels which will also supported. I don't see much more to be done there. Chris: If you know the other client, you can automatically as the receiver set up a tunnel. Tony: Yeah, but that's what's happening. So in L1, you will see all the other guys and they will show up as clients even same cluster ID and they will show up the shortcut endpoint, so you can set up tunnels to them automatically. Chris: That's what I meant you don't have to signal. Tony: You have to know what type of tunnel is supported and what is the endpoint address of the other guy. Chris: What I was getting at is that upfront, rather than signaling tunnels, just saying what type of tunnel and then everyone is just setup with tunnels, just a thought. Tony: You talk to 4 customers, what type of tunnel they prefer, you get 5 to 6 answers. We tried to steer them towards GRE, and the most advanced customers end up to prefer no tunnel option, that's why we worked on that stuff more extensively. We suggested the whole thing a while ago, and the most sophisticated people actually reject the tunnel option, lots of reasons, operational, silicon reasons, and so on. Chris: Follow up questions on the tunnels, in the draft, did you get the TTZ comparison? TTZ gives you a full mesh of adjs and you're cutting down, that's the main advantage. Did TTZ require tunnels between L1 and L2 edge? Tony: They have underneath the full mesh of tunnel. It's hidden. what is drastically different is the no tunnel option. But this is far more sophisticated to deploy. Huaimo: TTZ doesn't use tunnels, but uses shortest path through TTZ. Chris: You advertise all the outside reachability into the TTZ, that's why. Tony: I remember TTZ differently, but it's a while since I read it. Anyway, the draft is very detailed, and is up to implementation. Acee: Speaking as a WG chair, I think it's ready for LC. For those IS-IS developers, would you please read and comment? Chris: We'll put a WGLC on the list. 4. The Application Specific Link Attribute (ASLA) Any Application Bit Shraddha Hegde (10 mins) https://datatracker.ietf.org/doc/draft-hegde-lsr-asla-any-app/ Acee: if you have A-bit and other bits set, you're going to use whatever advertised in that attribute. What's the advantage of A-bit over zero length SABM? Shraddha: if you have designed one attribute, let's say admin group in an application-independent way. So in your network, so red color means one Gig link, and that means any application can use this red color, this admin group. So admin group is an attribute which is designed in the network to be used by any application. So now you can advertise it under A-bit. And there are some other applications, some other attributes that you want to design it in an application-specific way. For example, you want to raise some bandwidth related attribute that you want to design it and advertise it in an application-specific way, so different for SRTE, different for flex algo. and so on, so you can do that. You can advertise that the bandwidth one with the application-specific bit set, and the admin group with A-bit set. So, whereas, if you advertise the admin group under SABM, with all SABM with length zero, for flex algo and SRTE, you have advertised bandwidth. Now you cannot use the admin group for SRTEs, because they have the application bit set. So, basically, it's giving you opportunity to advertise attributes in an application-independent way on a per attribute basis. Chris H: I understand why you did this, because the zero length can't be used the minute you use a non-zero length, that's what you're saying. To me, that's a flaw in the original design. Why don't we fix that? Les: We've had extensive discussion about the technical issues on the list, including the points that Acee and Chris are asking about, I don't want to go into that here. I don't think we have the time to go back and forth. The point I want to make is kind of a much larger point. The function of the IETF, the function of our working group is to produce a standard that supports interoperability. We have done that with the RFCs 8919 and 8920. The authors of this document have decided that a certain portion of the way to support all applications or any application if you will, is not to their liking. And so they've proposed an alternate form of advertising this. The two definitions, the definition of the zero-length definition that exists in the RFCs, and the A-bit that's defined here, are not compatible. Despite what Shraddha has presented, in a real deployment, all of the nodes that are operating in the network, have to advertise things the same way in order to understand each other or they have to advertise things both ways in order to make sure that, with the nodes supporting one strategy versus another, that everything is understood. This now puts us in the position of instead of having a standard which everybody can use to support interoperability, we now have multiple published solutions, some of which are favored by one set of people and some of which are favored by another set of people. This introduces a lot of interoperability issues. It requires vendors to do multiple implementations of the same functionality, not because one of the solutions is deficient, but simply because some folks have decided we prefer to do it this way. And this to me does not serve the industry. Chris: We haven't published two competing standards. But but we're not like breaking the Internet. What you're saying is they're proposing a solution and it's not compatible. That's what the working group does, right? I mean, no, we don't want to publish two things that compete with each other or cause problems. So that's a great point. But you know, let's not take that too far. Because this is just a draft, right? So that's a reason not to go with it. In your opinion. Les: Correct. Chris: Okay, great. So we're out of time on this. The question that I was asking is why the zero length can't be fixed. It sounds broken. But all we can do that on the list and we are out of time. Shraddha: With respect to Les's observation, I think it's not right that the two solutions are not inter-operatable. How they can inter-operate was discussed in the previous slide. If it's not clear we can discuss again, but I do think this inter-operates with what's defined in 8919 and 8920. it's just gives another option. Chris: Let's take it to the list. Showing something doesn't interoperate is pretty easy, right? We can all technically look at that and look at the example, usually can show an example right? So if Les is right, he'll throw an example out. And we are go: Les is right. And if Les cannot come up with an example, then you're right. That's easy enough, Right? Acee: Yeah, we'll take it to the list. This stuck out in my mind. It said when everybody is upgraded, and there was nothing in the protocol to do that. It seemed like it was an operational interoperability and not a protocol interoperability. 5. Updates for PUA and Passive Interface Attributes  Gyan Mishra/Aijun Wang (15 mins) https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/ https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/ Les: The comment I want to make, I think the discussion on the list highlighted the fact that there's an open question, independent of whether we use the prefix unreachable draft or the Event Notification draft, as to whether this problem should be solved by the IGP or whether it should be solved by BGP, or in some other way. And I think the logical way to proceed on this is to get the consensus of the working group as to whether an IGP solution is desired first, then after we reach consensus on that, then we can start talking about which approach is the better approach. Which one should be adopted? Chris H: Chair hat on. You've been asking for adoption for a while. The event notification draft is new. I agree with Les that in a perfect world that would be the case, but asking for adoption is one way to answer the question. It may be not the perfect way to answer that question, but it is one way. I agree without my chair hat on, I'm not sure we need this, but it's not for me to say by fiat. Acee did put something out on the list to try to engage people again. And I don't think a lot got said. Acee: I didn't see much support other than from the authors. I saw one non-author support on the event notification. Chris: Everyone has a right to ask for an adoption. Everyone has a right to say we shouldn't adopt this and there are the reasons. We've let people to express opinions, without seeing a lot of negative opinions it's hard not to just grant the adoption call. Tony P: I think this is all making a trash can out of the IGP. One possible solution is to ban or encouraged maybe everyone with these kind of suggestions to go towards the service instance stuff or whatever we call it, which I think is a good idea. Just run a power line up and much lower priority. Don't trash the main protocol that holds the whole thing together. Chris: Great comment for the adoption call. As a WG member, I agree. 6. Flex Algo Extension for 5G Edge Computing Service Linda Dunbar (10 mins) https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute/ Shraddha: You have multiple application severs, and you want to load balance on servers using anycast address. Metric is not the right way, the moment you change the metric based on load or preference, or whatever, you get oscillation. You have more UEs connecting to a server because of the lower metric. What you really want to do is to use the factors that you have described like the lower preference and site cost, etc, to compute the balance and load and use it as a load-balancing mechanism, basically an equal load balancing on ECMP and custom prefix. Chris: Linda wants to use the network/routing function to load balance. How do you do that without using the metric? Shraddha: It appears to be a load-balancing problem, and changing metric doesn't really solve the problem. There are other ways of doing it. For IGP, load0balancing is done on next hop. Chris: Using routing for load-balancing is sort of novel. Acee: You forgot to remove sections 8 and 9. Linda: I haven't got a chance to update the draft. Acee: Another commentis, if you're not using the raw metrics, if you're just using an aggregated metric, you can do that today, irrespective of all the problems of load-balancing using routing, you can do it with base OSPF, making the anycast address an external route using a Type 2 metric. But if you're going to use the raw metrics, that would be a different matter. 7. IGP Extensions for Path MTU Xing Xi (10 mins) https://datatracker.ietf.org/doc/draft-hu-lsr-igp-path-mtu/ Chris: After reading it, I think the tie-breaker should just be lowest MTU and forget all that other stuff. Jeff Haas:My criticisms is not specifically targeting how do we carry this insight into the protocol mechanism. My comment to you is that the general issue that we seem to run into in the real world is that we can't believe what the protocols are telling us in a lot of cases. So I know that you want to carry this stuff in the IGP that signal to some front end, here's what my path should actually be. Whether you believe it or not, it's actually tricky. It was having the graph of the individual MTU so the links will give you roughly the same type of information. My suggestion to you is, please take a look at the contents of the very simple BFD draft that's exposed here can be carried in things like BFD. The general problem that you're going to have is you're told the Path MTU is x, but some component link that may be part of that path, part of the backup link, part of a fast reroute scenario. Pick any number of scenarios, the Path MTU is not going to be what you actually are told that it is and it's important to not press that. That's my comment. Thank you Les: I shared Jeff's concerns. I have a limited enthusiasm for this draft. But my comment is in regards to IS-IS. If the working group decides to move forward with this draft, there are already two code points that potentially can be used to advertise this. One of them, particularly the per-link advertisement was defined by TRILL. It would require a bit of adaptation to be used in this context, but I think it's quite feasible. So I'd like us not to allocate yet another code point if we decide to move forward with this for IS-IS. Thanks. Acee: We've got along without this for a long time. Are we just bringing this in bnow ecause it can be done. I looked at the use case of SR, what I could typically do is to take the lowest MTU in the whole domain and use that as my sending MTU, so I can use any path in the domian. Chris: I think that's what they're kind of doing. Acee: Then you can just use a capability, do it on a node basis instead of link basis. Chris: There are lots of tunnels, and it's getting worse. Let's have the discussion on the list. 8. Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth Using IGP and BGP-LS Xiao Min (10 mins) https://datatracker.ietf.org/doc/draft-xzc-lsr-mpls-flc-flrd/ Chris H: If it doesn't have to do with routing, it should not be in the IGP. Unless the FLC is affecting forwarding, it's a management thing. As a working group contributor, just like IFIT came into the working group, and they wanted to do things that didn't have to do with forwarding, they wanted to signal capabilities that didn't have to do with forwarding. I think that violates what an IGP should be advertising. Xiao: I understand your point. it's used for performance measurement, not for forwarding. Acee: RFC 9088/9089 has it at node level, but you have it at prefix level. It should have a similar form and structure to those two RFCs as opposed to prefix. I can take it to the list. Les: I agree with Chris's point about this not necessarily being appropriate for the IGP. I think the mystery about why you've chosen prefix reachability is you've been misled by the entropy drafts because we had a special case there where we wanted to advertise entropy capability for external routes. And so we needed to use a prefix reachability advertisement to do it, but it's really a node property. And what you're talking about here is also a node property. So if we were to advertise it, it should go into router capabilities. But, again, I agree with Chris's comment that this may not be appropriate for the IGP. thanks. 9. Updates to Anycast Property advertisement for OSPF Ran Chen (10 mins) https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/ Acee: Speaking as member, the first question is what is the use case for anycast? I thought the whole idea was that it was transparent. The routers didn't ned to know the prefix was anycast. And the second comment I have you say that you would not have to use the former flags field if you use this variable-length advertisement. That's not the case because you still have to, you still should set it for the existing flags for backward compatibility. Because it's part of the prefix encoding in both cases, in both 7684 and the OSPFv3 8362 or whatever it is, the prefix options in the case of OSPFv3 and the flags field in the case of OSPFv2 extended prefix are part of the same encoding that has the address so you really have to include it. You can't not use it. Chris: When I read the transition on the last slide, to me it sounds wrong. Preferring the new advertisement over the old one is almost always wrong, because people that don't understand it would pick something different. Either case, this needs a review on the list. Acee: It says you could omit it, you cannot pmit it because the flag is there. You might as well set it correctly and have that in the draft. 10. IS-IS Extensions for Link Bit Error Ratio Chenxi Li (10 mins) https://datatracker.ietf.org/doc/draft-li-lsr-isis-link-ber/ Chris H: What bit error rate is this? Before correction or after correction? Chenxi: Before correction. Chris: This is hard. I know what you're going for here is basically link quality or a different measurement of link quality. My experience is with the operator I've worked for, Deutsche Telekom. So it was way up high on the pecking order, and we worked on a new network and for us, any non-zero post-FEC bit error rate and you took the link out of service, there was no percentage. Any pre-FEC bit error rate unless it was immediately spiking, just meant the thing was working. If you have a zero bit error rate post-FEC, you have no packet loss due to bit errors. And if you have a post-FEC bit error rate that at least the operator I worked for, you just stop using that link all together. Now on all the routers there's alarms and different things that can watch this stuff. I'm just not sure how useful this is. I'm interested in hearing from other people specifically other operators, there also maybe does this have some kind of application in lossier networks. I don't know but I'm worried that this is too fine of a grain to be looking at on the routing level. Acee: Speaking as WG member, the encoding looks fine. It's similar to the other TE metrics that we spent lots of time on years ago. I'm wondering what BER offers you above packet loss? It seems basically at high-level to be link quality. And it seems like packet loss is a more important metric than the low-level BER at the physical layer. I don't see the advantage of it, and I'd like to hear from the operators. Chris: Randy agreed with me in the chat. If you see post=FEC bit errors, you just take it out of service. This is also echoing what Acee just said. We'll take it to the list, but BER may not be that useful. Too much information. 11. Stub Link Attributes https://datatracker.ietf.org/doc/draft-wang-lsr-passive-interface-attribute/ Linda: This draft looks like we can use for distributing aggregate cost as well. What's a stub link? What's the difference from prefix LSA? Is stub link always for prefix? Aijun: No, stub link can be used to connect many prefixes. It's a link located on the boundary of one AS. Chris: That's an interesting case. We're run out of time. I'd encourage people to discuss on the list. As a contributor, I don't see why this draft is needed. I'd like to see more discussions on the list, especially people have ideas how to identify stub links without this. Anyway, more on the list. Acee: The encoding now is fine for its original purpose which was for inter-AS TE. The question is whether people, other than the authors, think this additional link type and information is useful for TE. Chat History Bruno Decraene it's a 6MAN doc (not SPRING)04:03:38 (SRv6 OAM)04:05:19 Jeff Tantsura It’s ok04:12:05 Jeffrey Haas Author limit: https://datatracker.ietf.org/doc/html/rfc732204:13:48 Christian Hopps wow my audio is totally broken04:15:52 John Scudder Typical troubleshooting steps are change browser, change device, change ISP.04:16:18 Jeff Tantsura Try closing the tab/window04:16:38 Ketan Talaulikar @ John ... didn't you miss the all power reboot/restart somewhere in there?04:17:11 Jeff Tantsura Changing house/country:)04:17:55 John Scudder True true. "Did you turn it off and on again?"04:18:00 Jie Dong and try turn off the video?04:20:29 Christian Hopps reboot required04:21:35 safari produces clicks for audio04:21:55 I'll blame apple04:22:07 John Scudder Oh Safari. I've given up using it with Meetecho.04:22:48 Christian Hopps yeah I was in chrome safari was an expirment before reboot04:23:06 chrome was heavily scratchy audio04:23:22 Jeffrey Haas My experience is that it's browser roulette for what works or is broken that IETF cycle. Last cycle I had to use safari.04:23:25 Huaimo Chen TTZ does not use tunnels04:32:24 It uses shortest paths for edges connects.04:32:55 Stefano Previdi Hi guys...04:35:18 John Scudder :-o04:35:26 Eduard V Probably, I need to read the draft (I am guilty). But I have not understood the use case for the Application attribute.04:43:04 Boris Khasanov Looks like App specific Flex-Algo, IMO04:44:33 Ketan Talaulikar @ Eduard - please check RFC8919/2004:45:07 Ron Bonica I'm not sure that I am hearing an answer to Chris' question04:48:36 Peter Psenak Ron, there are existing ways to address the problem that the draft is trying to solve and it has been pointed out on the list already04:49:55 T A-bit is clearly redundant04:50:12 it looks to me some people try to limit its ASLA support to minimum and invent things that would help them to do so04:51:02 Shraddha Hegde @Peter A-bit was a result of discussion on the list where operational issues were extensively being discussed04:52:40 Peter Psenak there is no operational issue here04:53:00 existing ASLA provides ways to encode any combination of apps and attrubutes 04:53:37 all you propose is a different encoding04:53:45 I see no reason for it, as you can encode what you talk about in a different way and achieve the same result04:54:24 Les Ginsberg RFC 8919/8920 are fully functional in this regard. Authors of A-bit draft just don;t like the ASLA solution and prefer the A-bit. But introducingtwo different ways of supporting the same functionality imposes a burden on all implementations to support two different flavors and on network operators to configure which mode implementations are in. There is no need for this.04:56:47 Christian Hopps The A bit appears to be being proposed b/c the zero-length option seems broken in that one application can cancel the use of the zero-length "all" by another 04:56:47 Peter Psenak no, that is not the case04:57:03 Christian Hopps ATTR A 0-len everyone use, ATTR-B is advertised for App-X and now the ATTR-A can't be used04:57:27 Peter Psenak all you need is to encode the same attribute in the ASLA with the application bit04:57:28 Les Ginsberg @Chris - read the RFC - read the thread on the list please. :-)04:57:32 Christian Hopps "All you neeed to do is replace the zero-lengfth with set-all bits" that isn't the same thing04:57:56 but ok04:58:02 Peter Psenak no, that's not what I said04:58:15 Christian Hopps right, let's discuss later I need to pay attention to current presenter ;)04:58:30 Peter Psenak you can use SAMB 0 together with SABM with bit X04:58:34 all you need to do is to put the common attribute in both04:59:07 that's one way, there are others04:59:15 so we have several ways to do it already 04:59:26 Shraddha Hegde @Peter you are OK with several ways of doing it then why are you objecting to this one?04:59:59 Christian Hopps b/c it's a new specification that's not needed if you can do it with what exists05:00:24 Peter Psenak because we don't need yet another one05:00:25 Christian Hopps i'm just wondering if it can be done.. I will look again later.05:00:44 Shraddha Hegde @Peter, @Chris, the existing ones are operationally very complex for the network evolution05:00:57 What is being proposed is to simplify it05:01:09 Peter Psenak that is part that we would likely never agree05:01:21 Shraddha Hegde having to set the bit on attribute on every link is not easy operationally05:01:38 Tony Przygienda neither is the event nor this (this much less) a good idea to stick into IGP05:02:01 Peter Psenak I don't see a difference to be honest, it's just an encoding05:02:09 Tony Przygienda usual trash-canning IGP as "generic broadcast mechanism"05:02:19 if you need something like this go to the "service instant" architecture05:02:39 Jeffrey Haas Every protocol becomes a "dump truck" to quote one of my protocol elders.05:02:49 Jeff Tantsura @JH - to Tony’ point - at least we could put it into a separate truck05:04:56 Tony Przygienda the propensity of people to look for free lunch does not make it a good idea or one that should be encouraged ;-)05:05:20 Jeffrey Haas I've made some arguments over the years that running parallel tracks of state distribution is FINE, as long as you have a common useful way to key into that state.05:05:47 I'm personally fond of doing so in something like bgp-ls05:05:58 Jeff Tantsura +105:06:14 Jeffrey Haas The remaining challenge is congruency of state distribution.05:06:32 Tony Przygienda yepp, and make it a slow, low priority hauler, de facto an out-of-band thingy ... nothing wrong with that. IGPs have been built & tuned as racing cars of convergence and you do not transport IKEA dressers in ferraris (well, in silicon valley maybe you do ;-)05:06:36 Jeffrey Haas So, there's there's a good desire to want it in the native protocol05:06:46 but much like bfd considerations, don't make the core thing messy... it slows down the core use case05:07:15 John Scudder Maybe hold the general philosophizing for the bar? Oh, no bar. :-( 05:07:28 Tony Przygienda but if you insist to put a SUV body on a ferrari suspension, all cool. will be an expensive, fragile thing to maintain despite the initial quick "success"05:07:39 Randy Bush low bar05:07:43 Les Ginsberg I am absolutely anti-dump truck. But as this issue is associated w the summary address already advertised by the IGP I think a case can be made the addressing issues associated with the summary is a valid use case for the main IGP instance. Let's discuss more on the list.05:07:56 Tony Przygienda @John in bar we had alcohol, that stopped too extensive ruminations. Here we all sober and angry, hence unforgiving and full of verbiage ;-)05:08:27 Boris Khasanov @Tony, there are people who would argue that BGP is suitable truck for that either ;)05:08:27 Peter Psenak @Tony, I don't see the truck comparison fair for the 'event' based notification idea05:08:41 the amount of data is way lower compared to traditional IGP data05:09:11 Les Ginsberg @Tony - how do you know we are all sober? :-)05:09:18 Christian Hopps heh05:09:23 Tony Przygienda 'event' is slightly better (don't ask me what I think of this "negative" thing which seems to have no orthogonal or even loop-free algebra to it) but it's still "signalling of something else in IGP"05:09:27 @Les I know what timezone you in ;-)05:09:39 Les Ginsberg @Tony - sadly true.05:09:59 Christian Hopps Perhaps @les is a fan of bloody mary's and irish coffees :)05:10:08 Peter Psenak it's directly related to what IGP advertise already and the volume is very low05:10:11 and we can have the discussion about the loop free algebra next :)05:10:42 Tony Przygienda @Peter, no, it's not ;-) really AFAIS and "but it's small" is a weird argument when you argue about whether something belongs into an architecture or not ...05:10:44 Peter Psenak just reacting to truck analogy05:11:11 Tony Przygienda 'event' in this respect is benign, I give you that and I stand accused myself, KV in RIFT finds good amount of pretty cool use cases ;-)05:11:29 anyway, heading to the bar (actually no, reading more of the "usual company" DoS draft attack on BIER WG ;-)05:12:05 Jeff Tantsura Talking about trucks…05:17:16 Jeffrey Haas Context for my upcoming comment: https://datatracker.ietf.org/doc/draft-ietf-bfd-large-packets/05:21:21 Christian Hopps FWIW, as contributor: I remain skeptical about the load balancing using routing; however, I'm trying to keep an open mind b/c it's intriguing.05:22:17 Jeff Tantsura @Chris - as long as it is weight of the metric (additional metadata) but not the metric self05:24:22 Peter Psenak we can call it whatever we like05:25:04 Christian Hopps @peter *nod*05:25:49 Jeff Tantsura BW community is quite though05:25:49 quite useful05:26:07 Zheng Zhang To Jeff Tantsura, which rfc/draft contains BW community?05:26:54 Jeff Tantsura draft-ietf-idr-link-bandwidt05:27:43 Zheng Zhang Got it. Thank you Jeff!05:28:02 Jeffrey Haas Please note there's discussions about link-bw being problematic. People don't like 32-bit floating points. :-)05:29:36 Zheng Zhang oh, is there any conclusion for the 32-bit floating points?05:32:25 Randy Bush @jeff: floating point / integer issues once caused ibm to have to replace microcode (which was stored in expensive hardware) on all shipped systems.05:32:58 Jeffrey Haas The discussion about 32-bit floating point is just beginning. Please see last presentation in idr yesterday05:33:22 Randy Bush these are all lessons we learned in the '60s05:33:23 Shraddha Hegde @Jeff, I also think the loadbalancing can be easily solved with link-bw community05:34:10 Tony Przygienda Chris just bought Rivian IPO I think ;-)05:34:54 Jeffrey Haas bgp link-bw provides a modestly reasonable way to do load balancing and is well deployed.05:34:56 Shraddha Hegde or something similar to link-bw community that is used for load balancing05:35:14 Jeffrey Haas But since it lives in an element that has to deal with "policy", it's tricky in a few contexts05:35:20 Tony Przygienda me to IETF: please do not blame itself by thinking you can standardize a better IEEE754 ...05:36:48 Randy Bush @tony: +100005:38:04 Jeffrey Haas IMO, the conversation is same as writing any code: using floats is inappropriate for many cases where the user's sense of granularity might not fit into the type. Users get confused when they enter some integer number and it's not returned to them as the same number.05:40:47 John Scudder (the spec does indeed call for IEEE format, specifying an invented-here float is not part of the problem)05:41:57 Jeff Tantsura but apart from encoding semantics, the idea is to provide additional information about a route, not changing its main characteristics05:44:21 Christian Hopps Didn't I see randy in here? :)05:55:44 Randy Bush @chris: agree take circuit out on ber alerts 05:56:07 Christian Hopps yeah, ok.05:56:16 Randy Bush interplanitary links?05:56:47 Wim Henderickx in my view if people really need it collect it via the controller and avoid abusing the IGP for this05:57:08 John Scudder Acee, your dog is more patient than mine. No dancing, no accusatory staring.05:57:34 Reshad Rahman +1 to Wim's comment05:58:13 John Scudder Running over is not ideal since people do plan for how to use their break, just like IRL.06:02:01