Minutes IETF113: lsr
minutes-113-lsr-01

IETF 113 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/113/session/lsr

1. Meeting Administrivia and WG Update
   Chairs     (10 mins)

2. Update to OSPF Terminology
   Acee Lindem (10 mins)
   https://datatracker.ietf.org/doc/draft-fox-lsr-ospf-terminology/

Acee:     2328 is already an Internet standard.
Chris H:  To me, this is a better way.
Acee:     I’d look at the product documentation, not the standard.
John:     There are lots of RFC impacted, I do see the value of
          publishing one short doc with all the updates. But I would
          hope subsequently we may actually take care of all the
          changes, better to have it in the spec itself.

Notes from HedgeDoc:
Chris H.: would be nice if we could bis the base with errata, maybe
will be easier later with this doc
John S.: I had similar though as Chris, would be nice to rev the doc,
but then saw the long list of impacted docs and thought there was some
value to a small single update doc

3. Node Liveness Protocol
   Tony Li   (15 mins)
   https://datatracker.ietf.org/doc/draft-li-lsr-liveness/

Aijun:    First there are existing pub-sub mechanics, why do we need a
          new one? Second why IGP WG? Third for ABR, it must keep
          registration table, will stress the ABR. You can find other
          nodes to do the work.
Tony Li:  Buffer overrun. For your first question, I haven’t see any
          pub-sub protocol in IETF, if you know any please let me know.
          Can you repeat other questions?
Aijun :   Maybe a new WG for this work? It belongs to more than IGP.
Tony:     I agree it could go outside of LSR. Just we started here
          because of LSR problem, the problem was raise here. if the WG
          thinks it’s interesting and want to take it somewhere.
Linda:    Do you do registration for client node or all nodes?
Tony:     Currently the registration is for prefixes.
Linda:    Isn’t that the same as LSA?
Tony:     We’re not advertising anything. This is a request.
Himanshu: Have you considered multi-hop BFD?
Tony:     A is going to get notification from B, C and D.
Les:      You’re inventing a new application, which operators will need
          to config. Do you have any feedback from operators whether
          they like it?
Tony:     Some feedback from operator, but I won’t speak for him.
          Routers have lots of subsystems, I agree it’s a pain. But I
          think it’s better than overloading IGP.
Les:      I’m interested in whether people want to deploy.
Acee:     Thanks for a very readable draft. I don’t think advertising
          a few thousands loopbacks is that many in OSPF, they’re really
          small LSAs. How did you come up with “ONN”?
Tony:     that’s Old and New. The reason to allow aggregation is to
          reduce the number of registrations.
Chris:    the notification is at host level, correct?
Tony:     yes
Jeff Zhang: This reminds me of BGP route-target mechanism.
Tony:     Not consciously mirroring it.
Gyan:     Are there concerns for overhead?
Tony:     I’m not concerned. it doesn’t have to be on the router, it can
          be hosted on a server.

Notes from HedgeDoc:
Aijun: lots of pub sub why invent new one, why in LSR WG? 2nd.
Tony: I have not seen similar pub/sub in IETF, happy to reuse.
Tony: problem was raised here so we started here and solving problem
here, but happy to move to wherever
Linda: clarification: who does registeration?
Tony: register for all lection
Himanshau: Have you considered ____
Tony: yes A registered for all (B and C).
Les: Doesn’t like, but not, but you are inventing something that Ops
will need to manage, deploy, etc… have you heard any feedback from
Operators on this?
Tony: I’ve heard from 1 op who is in the room, other than that no,
routers already have multiple apps, one more is better than overloading
the routing protocol.
Acee:
Jeffery: the one area to another reminds me of BGP route target
registration
Gyan: any concerns with overhead between the different component
Tony: no not a lot of data, doesn’t even ahave to be ABR based.

4. IGP Extensions for Scalable Segment Routing based Enhanced VPN
   Jie Dong/Zhibo Hu (10 mins)
  https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/

Chris:    We're looking at a standard-track protocol extension based
          on informational draft in TEAS. It's a little early for
          adoption in this WG. we need to move at the right order.
Jie:      which doc in TEAS?
Chris:    There is an informational and an individual  draft, you
          might know better.
Tarek:    I have similar proposal in LSR, we presented at IETF 110. I
          agree with Chris, it’s too early for adoption.
Vishnu Pavan:   The guidance from TEAS chairs is to use term NRP.

Notes from HedgeDoc:
Tarek: still other documents work
Pavan: Use NRP-ID to refer to this not VPN+

5. LSR for SR Proxy Forwarding
   Huaimo Chen  (15 mins)
   https://datatracker.ietf.org/doc/draft-hc-lsr-sr-proxy-fw/

Chris:    Is the proxy draft adopted in SPRING?
Huaimo:   There is an adoption call, waiting for outcome.
Chris:    We’ll wait for the base document to progress first.
Bruno:    I believe the result was sent. There is already mirror-sid
          in ISIS, so the question is why we need similar function? I
          don't think we made progress since then.
Huaimo:   One option is to reuse mirror SID, another is for extension
          of capability. Binding segment would be nice to have.
Acee:     I think the document Bruno brought up could be more clear.
          It should specify exactly when the capability should be
          advertised and for how long, those need to be added to the
          draft.
Stephane: There are still work to be done in SRPING before anything in
          LSR.
Chris:    The work needs to be done in SPRING first.

Notes from HedgeDoc:
Bruno: SPRING thought that IS-IS extension were not needed, already
functionally there.
Chris H: so is this an end-run around that?
Huaimo: true, but one capability bit is missing
Acee: could be a lot clearer about when things happen
Stephane: We need to clarify the use case first in SPRING before

6. IGP Flexible Algorithm with Deterministic Routing
   Shaofu Peng    (10 mins)
   https://datatracker.ietf.org/doc/draft-peng-lsr-flex-algo-deterministic-routing/

Jeff      The measurements don't match. the advertisement is per
Tantsura: topology, per adj, the delay is per traffic class, you can't
          advertise one per traffic class. there are huge differences
          between how traffic classes are defined. I'm not sure you
          can do it.
Shaofu:   is your question about measurement of traffic class?
Jeff T:   you have different traffic classes going to the same topo.
Xuesong:  Stable paths are important, we should be careful when choosing
          distributed path calculation. We need have more discussions
          whether to go down this way.
Acee:     We should get input from the DETNET WG. One thing we need
          discussion on is how often you change them, for scaling etc.,
          this needs to be in the draft.

Notes from HedgeDoc:
Jeff: delay is per traffic class, how does this work?
Xeusong: stable path is very important for deterministic latency,
which is called explicit route in DetNet. But With distributed routing
computation, it is difficult to keep the path unchanged. things like
delay and jitter will change accordingly. So we should be careful if
we choose a distributd method for DetNet, for example Flex-algo.
Acee: Need to hear from DetNet WG and the advertisement frequency
should also be considered

7. Advertisement of Dedicated Metric for Flexible Algorithm in IGP
   Mengxiao Chen (10 mins)
   https://datatracker.ietf.org/doc/draft-lin-lsr-flex-algo-metric/

Tony Li:  This is already available in generic metric proposal. This is
          redundant.
Mengxiao: This is different, it's algorithm based. Using multiple user
          defined metrics is another solution, but may bring more
          complexity.
Chenxi Li: If there are routers that do not support this mechanism,
          what will happen? The existing flex algo can solve this?
Jie Dong: This is more similar to multi-topology, not original
          design of flex-algo.

Notes from HedgeDoc:
Tony: Already in Generic (mentioned by Shradda on the list). Please
look again.
Chenxi Li: How does this work with existing routers (ones that don’t
support??)
Jie Dong: This makes Flex-Algo more and more Similar to MT, while
diverge from the design of Flex-Algo.
Peter P: [no time cut off queue, come back if time]

8. The Application Specific Link Attribute (ASLA) Any Application Bit
   Shraddha Hegde (10 mins)

   https://datatracker.ietf.org/doc/draft-hegde-lsr-asla-any-app/

Les:      I've sent an email to the list with details. The conclusion
          is that there is not justification of moving forward with
          this proposal. This will cause lots of implementation and
          deployment complexity, and we're not getting any benefit for.
          So my opinion is there's no justification for this going
          forward.
Shraddha: You mentioned encoding efficiency, but these are just
          examples. If you have more attributes have to be repeated,
          the efficiency is better.
Les:      I went through 3 examples, one with some savings, the other
          two with no savings. The quantity of benefit is not worth
          the complexity.
Chris:    Les's examples are pretty convincing. It's coming down
          whether you need it, do you have any example this is needed?
          Are you just imagining it? Do you have real examples?
Shraddha: If ASLA going forward, it should be flexible. We need to
          think future, how easy to extend it.
Chris:    We have IS-IS extended space, but never really used it.
Shraddha: The TLV space gets used up is coming.
Martin    This is a general comment about ASLA. The fact that
Horneffer:          We're having a discussion here about ASLA shows that it's
          too complex, and don't know who really needs it. I hope we
          resolve this issue ASAP.
Acee:     speaking as chair, please read through emails and comment on
          this. Response to Martin, we did have operators request ASLA.

Notes from HedgeDoc:
Les: long email sent, there’s really no justification for moving
forward on this when you look at the realistic deployments, lots of
cost not lots benefit.
Chris H (wg member): is there an example of running out of space, do
we need this right now.
Shraddha: we do have other use cases
Martin: things already complex enough let’s get this resolved.
Acee: please read through the mail thread on this

9. OSPF Monitor Node
   Alvaro Retana (10 mins)
   https://datatracker.ietf.org/doc/html/draft-retana-lsr-ospf-monitor-node

Acee:     I was saying that on the list that this was the worst way
          to do it, we had to change code to get rid of adj. I read this
          again, I think one thing you can't do is to get rid of adj and
          any flapping of it on the side of non-monitor node. You put th
          e burden on the monitoring node and you get the best backward
          compatibility even when the non-monitoring node doesn't support
          the extension. For example, you can use DR priority 0 to prevent
          the monitoring node from becoming DR. You just need to know the
          node you're connecting to and put these options in his LSA. It
          might be good to have a formal mechanism.
Alvaro:   It makes me nervous if you put everything on the new node.

Notes from HedgeDoc:
Acee: Most of this can be done with unchanged protocol, maybe limit to
just what can’t be done

10. Anycast Affiliation Advertisement
    Jeffrey Zhang  (10 mins)
    https://datatracker.ietf.org/doc/draft-zzhang-lsr-anycast-affiliation/

Linda:    A good draft. We had the 5G edge draft we did it a slight
          different way, and we used flex-algo to identify the topology
          where this info is applicable. Finding anycast affiliation
          doesn't need to be known by any node.
Jeffrey:  Let's follow up offline.
Acee:     The idea is the ingress will use the anycast to find the
          service and then unicast to load balance, correct?
Jeffrey:  That's one of the use cases. In theory, there could be more.
          But you don't want to change back and forth, that may get
          into routing loop.
Les:      IGPs already have mechanism to identify anycast and the
          source of it. I don't think we need any extension. I don't
          understand why we need to mapping of anycast and unicast?
Jeffrey:  IS-IS N-flag is not enough.
Les:      We have A-flat as well.
Jeffrey   I'll look into that.
Acee:     That's a proposed draft, right?
Les:      We'll get there.

&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
&         Chat History
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

Tony Przygienda
so quiet and nice ;-)
06:22:11
Ueber allen Gipfeln Ist Ruh', In allen Wipfeln Spürest Du Kaum einen Hauch; Die
Vögelein schweigen im Walde. Warte nur! Balde Ruhest du auch. 06:22:14 Jeff may
be the first guy who can claim having chaired _every_ group in IETF ;-)
06:27:08 Jeff Tantsura Yes, we can! 06:27:37 Tony Przygienda yes, we need
controversy! make ospf great again vs. is - is = 0 or something ! 06:30:25
Boris Khasanov Indeed :) 06:30:35 Tony Przygienda let's squat port 179 on TCP
and start flooding that way ! oops ... 06:31:03 John Scudder 😆 06:31:14 Gee,
who is this "AD review" who's holding things up? :-( 06:33:22 But seriously,
it's moving, it's moving. 06:33:49 Tony Przygienda routing ADs are like car
repair men now IME. Just don't ask for costs or dates ... 06:34:12 Jeff
Tantsura as long as it is moving in the right direction ;-) 06:34:14 Jeffrey
Haas Slow yang module revision processes were discussed in netmod. 06:34:16
Aijun Wang every routing related group 06:38:28 Russ White that's an empty room
you have there, Jeff 06:40:48 Jeffrey Haas More people than mpls had 06:41:24
Joel Halpern We had a modest number of people in the room for the savnet BoF
(15 or so). 06:44:03 Jeff Tantsura @russ - IGPs are soooo yesterday ;-)
06:45:32 John Scudder I think I forgot to say at the mic, thanks for doing
this. 06:47:22 Russ White that should have been a picture of bgp ... since we
just throw anything we can think of at it :-) 06:49:20 Robert Raszuk @russ ..
was just going to say the same .. let's save this picture for reuse ! 06:49:48
Jeff Tantsura yea, I expected some hidden BGP message on the truck 06:49:51
John Scudder https://www.constbgp.com 06:51:43 Robert Raszuk :) 06:52:12
Jeffrey Haas <3 06:52:18 "BGP is a Swiss army knife. Actually, it's all
knives." 06:52:35 John Scudder I remember that but not who said it. Was it prz?
Stefano? 06:53:11 Jeffrey Haas prz 06:53:18 John Scudder probably more
manageable to ask questions one at a time and let the speaker respond one at a
time, if you actually want answers 06:54:15 Stefano Previdi @john. My memory
archive doesn't go that far...;-) 06:54:57 John Scudder :-) 06:55:03 Robert
Raszuk @Stefano ... your memory is just FIFO 06:55:44 Stefano Previdi @Robert:
qualify "memory"... 06:56:14 Russ White maybe this should go in rtgwg -- @jeff?
06:56:16 John Scudder no matter what group it's in, jeff will be chairing
06:56:35 Jeff Tantsura @john as ct/car discussion proved - answers don't matter
;-) 06:56:44 John Scudder 😢 06:57:22 Jeffrey Haas Whereas I regularly have
conversations with people that want to reduce protocol count in their
ecosystems. 07:01:16 Russ White @tli -- I completely agree with this ... more
smaller protocols rather than keep stuffing things into the protocols we have
07:01:20 Jeff Tantsura some have deployed kafka connectors... 07:05:16 Aijun
Wang @tony. Additional questions that are not answered on the mic are here: 1)
The pressure on ABR is not only the sessions number, but the registration
prefixes. 2) Only the ABR can act such role. other internal IGP nodes can't
accomplish this task 07:06:25 Jeff Tantsura meetecho 07:06:47 SoS 07:06:59
Meetecho What's the issue? 07:07:08 Jeff Tantsura no audio 07:07:13 Zhibo Hu
@Russ White Dealing with coupling between multiple protocols can be a disaster.
07:07:28 Jeff Tantsura Jie - we can't hear you 07:07:30 Jeffrey Haas I can hear
jie 07:07:30 Jeff Tantsura can't 07:07:35 Meetecho Jie is not audible in the
room? 07:07:51 Jeff Tantsura let's wait for meetecho 07:07:52 no 07:07:56
Gunter Van de Velde yes, i can hear you 07:07:59 Louis Chan i can hear 07:08:02
Jeff Tantsura neither chris 07:08:02 Meetecho We can hear on Meetecho 07:08:03
Hao Li can hear 07:08:11 Jeff Tantsura not in the room 07:08:12 Meetecho
Checking 07:08:19 Gunter Van de Velde (oh, but i am remote) 07:08:19 Tony
Przygienda e'one remote. jeff can go drink a beer and we continue ;-) 07:08:37
John Scudder can ppl in the room join from personal laptops while the room
audio is being debugged 07:09:17 Acee Lindem Please join on laptop 07:09:21
John Scudder so that we can continue the meeting pls? 07:09:22 Meetecho Sending
someone over 07:09:35 But are all remote participants not audible? 07:09:48 Or
ust Jie? 07:09:51 Christian Hopps Everytone remote can hear 07:10:01 Jeff
Tantsura all 07:10:02 Christian Hopps it's only the in room 07:10:04 John
Scudder all remote ppl can hear one another 07:10:06 Jeff Tantsura I use audio
from my laptop into the mike 07:10:15 Meetecho Can remote participants hear
audio from the room' 07:10:18 John Scudder thanks jeff 07:10:22 we do not hear
audio comign from the room but then again I don't know if anyone is talking
07:10:35 Christian Hopps that'll be fun when it gets fixed :) 07:10:39 Meetecho
Ack, found the issue 07:10:41 Fixing it, just a sec 07:10:45 Wim Henderickx we
can hear in the meeting 07:10:50 Eduard V It is more reliable to be remote. The
world virtualized. 07:10:54 Jeff Tantsura we are back 07:11:03 thanks meetecho!
07:11:09 Aijun Wang broken 07:11:10 Meetecho Should be working now, can you
confirm? 07:11:22 Jeff Tantsura yes 07:11:26 confirmed 07:11:35 Tony Li @Aijun:
1) There is only one registration prefix assuming you're willing to put all
loopbacks into that prefix. 07:11:41 2) No, it doesn't need to be the ABR. Any
node that sees the area LSDB can provide liveness. The capability TLVs allow
the ABRs to designate proxies for the NLP service within their area. 07:12:48
Aijun Wang how the node in one area finds the proxies in another area? 07:13:46
Tony Li Capability in the L2 LSDB. 07:14:02 Jeff Tantsura @tony: from
implementation prospective, would you have RIB registration and invalidation
based on the state? 07:14:56 Les Ginsberg @Tony: Non-ABR nodes providing the
service have to have access to L1 and L2 LSPDB - otherwise they do not know
what is being summarized. Unless you want to allow the service notifications to
be completely redundant. 07:14:57 Tony Li Ok, the proxy probably needs to be an
L1L2 node. 07:15:00 Jeff Tantsura +1 les 07:15:23 Tony Li @Jeff This has
nothing to do with the RIB. It's just data propagation. Do with the data as you
will... 07:15:41 Aijun Wang regarding to point 1), if there are 1000 nodes in
one area, there will be 1000 loopback address registration, even these 1000
loopbacks are allocated under one prefixes 07:16:15 Tony Li You're assuming
that the registration database is /32 or /128. It doesn't need to be. 07:16:47
Boris Khasanov @Tony, sorry I didn't get: what is the fundamental difference
between liveness signaling via push/subs vs. existing IGP LSP? Speed,
resilience, less resources consumption or what? Why should we trust
registration more, for example? 07:17:42 Tony Li The point is to take the
burden off of the IGP. 07:18:05 Aijun Wang the ABR can summary the
registration. But for the first ABR, it must register the specific /32 or /128
address 07:18:07 Tony Li The first ABR can see summaries advertised by other
ABRs. 07:18:28 Jeff Tantsura tony: of course, not directly, but the end
consumer uses this to resolve (or invalidate) routes behind some next-hops
07:18:32 Tony Li It registers with each ABR for the prefix that the ABR
advertised. 07:18:42 @Jeff, correct. 07:19:04 Jeff Tantsura @tony - similarly
to BFD registrations 07:20:45 Tony Li Except that we don't need to send packets
every 10ms 07:21:07 Jeff Tantsura sure, but the end result is exactly the same
07:21:45 Tony Li There are many things that people seem to think are
'equivalent' PUA solutions. 07:22:36 Aijun Wang @tony. The ABR should advertise
the register the liveness of another loopback address, not the summary address
07:23:48 Ketan Talaulikar @ Jie, it would be good if the authors can clearly
identify and segregate the info that IGPs are actually going to use (i.e. for
route calc, programming into fwd, etc.) and stuff that IGPs are simply flooding
for someone else to consume. For the later set, some justification for why this
needs to be in the IGPs would be good to add. 07:24:01 Tony Li @Aijun Not in my
proposal. 07:24:15 That approach would scale poorly. 07:24:34 Jie Dong @Ketan,
thanks for your suggestion, will clarify the usage 07:25:51 Aijun Wang @tony,
then, if only one of node within the prefix failed, but others are alive. how
you notify the register via the summary prefix 07:32:10 Tony Li Registrations
are prefixes. Notifications are hosts within those prefixes. 07:32:40 Aijun
Wang OK, I know. but it sound a little strange. because the prefixes are
reachable 07:34:39 Tony Li This has nothing to do with reachability. 07:35:12
Aijun Wang the prefixes are live 07:36:13 Tony Li It's pretty simple. Suppose
loopbacks are in 10/8 network wide. 07:36:13 Area 1 has loopbacks in 10.1/16,
area 2 has them in 10.2/16, etc. 07:36:29 Now node A registers for 10/8. Node B
registers with node C for 10.2/16. Node D fails and node C generates a
notification for 10.2.1.1/32. 07:37:24 Aijun Wang No, I think there are problem
on your assumption here. 07:38:14 node A may tunnel with 10.2.1.2 07:38:55 when
it receives the summary notification, will it switchover? 07:39:25 Tony Li
There are no summary notifications. 07:39:36 It gets a notification for
10.2.1.2/32 07:39:53 Aijun Wang So, registration summary, but notification is
specific? 07:40:02 Tony Li Yes! 07:40:09 Jeff Tantsura :) 07:40:16 Louis Chan
@Tony, you might consider notifications with all-alive-but, or all-dead-but.
07:40:23 Tony Li Now you're just making things complicated for fun. 😄 07:40:50
Boris Khasanov @Tony, if we want to use other than ABRs routers for the
registration, how that role will be assigned? Any thoughts? 07:41:47 Andrew
Stone Tony: might want to just describe the registration message as basically a
filter for notifications on a per-prefix level (note i didnt read the doc
yet...) 07:42:23 by per prefix level, i mean, the filter is applied but end
consumer receives notifs per prefix 07:42:59 Tony Li @Boris As noted above, it
would need to be an L1L2 router so that it sees both databases. Set the
overload bit so that it doesn't carry traffic. 07:43:04 @Andrew There are many
ways to do it. 07:43:41 Robert Raszuk @Tony - Does it need to really be a
router ? How about just node listening passively to both L1 and L2 areas ?
07:44:48 Tony Li That suffices. 07:45:00 Jeff Tantsura i think we have a
presentation on IGP monitor later today? 07:45:22 Boris Khasanov @Tony, I
thought about using some centralized way of assignments, via controller for
example. 07:45:34 Aijun Wang @boris, yes, this is the normal PUB/SUB procedures
07:46:54 Tony Li @Boris We know that global controllers don't scale and we end
up with hierarchical controllers. Which is not very different than this.
07:48:13 I will wait until the end. 07:50:36 Tony Przygienda unless you really,
really absolutely max. speed reaction time here (which is Tony's solution) an
IETF free, cheap solution consists of a passive session to an ABR, bitsy code
and a kafka bus or 0MQ ;-) But hey, where's the fun in that, nothing new to
invent, no new stuff to hack into IGPs, no operational crisis when another
obscure sideways hack takes the whole network down ;-) 07:52:04 Zhibo Hu Would
PUB/SUB be a disaster if all nodes needed to know the reachability of all
nodes? 07:53:39 Jeff Tantsura I'd argue that "on change" streaming notification
into kafka/similar bus would have rather similar (speed wise) characteristics
07:54:19 Tony Przygienda @Zhibo: chicken and egg. how will a node know how to
get to the bus/server if there's no forwarding yet? ;-) 07:54:40 Robert Raszuk
@Zhibo - no. Today all nodes in IGP do know how to reach other nodes. Here we
are taking about liveness. 07:54:57 Tony Przygienda people always think IGPs
are superfluous until they stand there with a packet in their hands and say
"eeehe, how do I get there"? 07:55:21 John Scudder 😆 07:56:23 Tony Li @Zhibo
The nice thing about PUB/SUB is that it can go slowly if necessary. Sure, under
stress, convergence time may suck, but that's far better than collapsing.
07:56:42 Aijun Wang IGP has the existing mechanism to do the notification,
which is no burden to the router(no SPF involved) 07:57:13 Tony Li Except that
you're adding arbitrary stuff to the LSDB. 07:58:14 Zhibo Hu If any-to-any
PUB/SUB is used, IGP is more efficient. 07:58:22 Tony Li Which is why it's
hierarchical. 07:58:50 Jeff Tantsura @zhibo - no 07:59:20 Tony Przygienda
@Zhibo: you may be underestimating flooding & SPF speeds and overestimate
seriously how fast pub/sub systems can go, especially with slow receivers
(building a serious BGP is very educational in this respect if you didn't
implement other buses along Kafka lines ;-) RFC1925 #4 ;-) 07:59:33 Jeff
Tantsura +1 prz 07:59:51 Zhibo Hu In addition, we have a document MFI that is
trying to isolate the impact of different IGP flooding instances, and I think
it would be better to resolve it within the protocol than to create a new
protocol. 08:00:05 Tony Przygienda lots of that has to do with fact that you
cannot compare a modern 64cores memory loaded server hacked in hugely parallel
fashion going fast and dying on bugs in nice regular fashion to a box that you
drop into a basement double caged sitting there ideally for 15 years without
being touched except cabling changes 08:00:44 Jeff Tantsura there's a reason we
do BMP and streaming telemetry in general 08:00:48 Robert Raszuk If anything I
would like to get clarity on key requirement - some folks claim that the
mechanism (regardless which one) is needed to signal remote PE (service) node
liveness across areas. Yet another group of folks claim that we also need to
signal segment endpoints (possibly each P router) across areas. So do we have
any agreement that both requirements are sound and we need to address them ?
08:03:26 Zhibo Hu Node liveness is not a common occurrence. I don't think IGP
advertising node liveness will lead to flooding crashes. 08:03:48 Boris
Khasanov @Tony P. RFC1925 has also #6 :) 08:04:12 Robert Raszuk @Zhibo - then
do not summarize node loopbacks and we are done. 08:04:31 Tony Przygienda
@Boris, yeah, #6 leads to people trying to dump truck IGPs as "broadcast bus"
since they existed instead of building a proper solution in their own layer
08:05:40 Zhibo Hu Summary is mandatory. Summary is used to reduce information
about live nodes. Most nodes are in the live state. 08:05:43 Tony Li So then we
don't need PUA. 08:06:25 Robert Raszuk stable information (as you claim it is
such) do not hurt IGP scaling 08:06:30 Tony Przygienda in simple words: routing
protocols do reachability, what "liveliness" is is service access point
availability and it is NOT a routing protocol problem/space. If people insist
to dumptruck the protocol the best we can do is what Tony suggests, give them
PUB/SUB service endpoints ideally and if they're too lazy to build their
pub/sub provide simplest pub/sub possible 08:06:47 Boris Khasanov Very good
discussion! 08:07:54 Jeff Tantsura along this lines - if your org is ops heavy,
out of band solution might be better choice (building scalable and reliable
collector infra ta scale is somewhat black magic), otherwise what tony proposed
might fit better 08:09:18 Zhibo Hu In fact, the IGP itself needs the node
liveness status to select the correct ABR. One ABR notifies the node liveness
status, and the other ABR notifies the node liveness status. 08:10:57 In fact,
the IGP itself needs the node liveness status to select the correct ABR. One
ABR notifies the node live status, and the other ABR notifies the node liveness
status. 08:11:40 Robert Raszuk Nope .. ABRs are local to the area ... no
livness is needed to select correct ABR 08:12:35 Jeff Tantsura yep 08:12:42
Christian Hopps @meetecho is there a way to increase the volume on the in-room
mic in the remote mix? 08:13:11 John Scudder the gain control in the lower
right helps a little 08:13:37 Zhibo Hu Other areas node select appropriate ABRs
08:13:49 Christian Hopps yeah just found that, better, with all volume levels
maxd though 08:14:01 Zhibo Hu We will list some other cases in PUA. In fact,
BGP does not only benefit from the node liveness status. 08:14:51 Christian
Hopps fwiw this has been a problem in every WG i've attended.. so maybe htis is
a site-wide thing that could be fixed next time 08:14:52 Acee Lindem Pardon my
queue squatting... 08:15:20 Tony Przygienda to be frank, there is a lot of
naive parties here pushing for stuff (service liveliness) they vastly
underestimate in terms of difficulty, even providing a good, reliable
notification. Imagine what happens if you registers @ 2 ABRs and one of them
sets overload bit. Theoretically it should notify you e'thing behind it is
_dead_ but guess what, you either on getting both notifications need to
coallesce those (hello, massive async FSMs) or the ABRs need compute from point
of view of _other_ ABRs. Now what about registration coming from left and right
and you that right a guy in the middle set overload. Now do you send a down
notification on the right interface only? I can come up with examples like that
for a long time, what you ask graph theory wise is a very complex problem to
put into a topology protocol, your best guess is to say "if both parties can
reach a common point (pub/sub) then the service is up". Enjoy parsing it ;-)
08:16:13 Robert Raszuk #Tony - I asked that on the list. Les responded that
overload or max-age would not be a trigger in any case. 08:17:27 Meetecho
Christian: the speaker mic sounds fine, not sure about the in-room mic one as
no one is speaking there. Speaking closer to the mic may help. We'd rather not
touch the mic levels as we risk causing echo when remote speakers talk 08:17:34
Tony Przygienda right, we can make all kind of wonderful assumptions and end up
with 1925 #7 08:17:58 Christian Hopps Well I would question "sounds fine" I
have all volumes maxed to barely hear the speaker, so when someone remote talks
it will blast my eardrum.. having attended too many loud rock shows this causes
pain :) 08:18:47 Meetecho You're talking to a metalhead so I can relate :D
08:19:17 We'll try to better balance the levels when we do our sound checks
tomorrow morning 08:19:47 Christian Hopps thanks :) 08:20:20 Tony Przygienda
yeah, getting a good passive monitoring solution would be a great workitem
here. it may even get rid of the bgp-ls wart in long term ;-) 08:25:00 Wim
Henderickx @tony, was just going to ask can we not use bgp-ls, but seems i know
your answer :-) 08:25:38 Christian Hopps I like acee's comment about usign the
protocol where we can and just add what's missing. 08:25:45 if you trust the
monitor node enough to let them onto your network you can trust them not to
advertise LSAs too I guess 08:26:11 Tony Przygienda you can, I'm fighting the
warts every day. Don't get me started ... BGP-LS _almost_ does the IGP database
and it _almost_ reflects flooding 08:26:19 Robert Raszuk @Wim - if you recall I
proposed how to use BGP for this notification. And no need to go into LU .. any
SAFI and recursion works fine. 08:26:33 Tony Przygienda the _almost_ at scale
in high reliability deployments are what makes me loose sleep at night
regularly ... 08:26:46 Jeff Tantsura I don't see realistic alternative to
BGP-LS is the next 3 or so years 08:27:26 Boris Khasanov +1 to Jeff. We still
need BGP-LS in mid-term perspective (it is supported by the majority of vendors
in some level) 08:27:45 Tony Przygienda the BGP-LS guys were warned about the
sins they're committing but they just ploughed ahead ... having BGP being a
conduit would have been fine, having done it right would have been fine (like
keeping seqnr#) but the way it's done it's a fine toy until you really, really
want equivalent of "what is IGP seeing" ... 08:28:20 Aijun Wang BGP-LS has far
scope than the IGP based solution 0

Tony Przygienda
so if you _really_ want to know what IGP is seeing passive monitoring cannot be
beat. And effort to parse packets is vastly exaggerated. But yes, I know I
likely talk scale & timings & reliability asked by very demanding customers
which is not reality for vast majority of folks ... 08:29:55 Wim Henderickx
would it not be useful to do a generic monitor mechanism which is protocol
agnostic. Like the pub/sub proposal Toni has for liveness. Rather than
overloading the protocol have extendability for these use cases. 08:30:07 Ketan
Talaulikar @Tony +1 - BGP-LS does not provide the real IGP machinery view ...
its only a topology view

Jeff Tantsura
@prz, in general - there's enough data to be actionable (icw with some other
things) 08:31:03 Boris Khasanov ccvktdvudlfdigiuknegcjukctteghfbjuitiihn
08:31:15 Tony Przygienda @Wim yes, it's thinkable. but I fear we devolve very
quickly into generic query language if you want to know certain "closures" on
link state database notified/published 08:31:16 Tony Li BGP-LS could have
simply done a bcopy of the LSP/LSA as it was updated. That would have been
simpler and more extensible. 08:31:21 Tony Przygienda @Tony: yepp, that's the
conduit thing. They were being told that over and over again ...

Boris Khasanov
Sorry. @Wim - what customers should do while this new protocol is not available
at least on 2 major vendors boxes? 08:32:02 Jeff Tantsura they = you ;-)
08:32:03 Ketan Talaulikar but then we would need practically an OSPF or ISIS
implementation to parse and also figure out what is "usable" Tony Li Which is
now common. Next problem? A passive node on the end of a tunnel is a simple
solution to all of it.

Tony Przygienda
+1 and that's the root of my comment, yes, let's provide a good passive
monitoring solution on IGP adjacency so people stop hacking stuff like not
going FULL in OSPF Robert Raszuk Parsing LS is not an issue. I was always told
that reason to trash BGP was requirement for BGP-LS to do intelligent NNI
across domains hence need to understand the content 11. Meeting Closure
   Chairs (5 mins)