Minutes IETF112: lsr
minutes-112-lsr-00

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