Chairs:
Acee Lindem (acee.ietf@gmail.com)
Chris Hopps (chopps@chopps.org)
Yingzhen Qu (yingzhen.ietf@gmail.com)
WG Page: https://datatracker.ietf.org/group/lsr/about/
Materials: https://datatracker.ietf.org/meeting/122/session/lsr
##
##
09:30
Meeting Administrivia and WG Update
Chairs (10 mins)
09:40
Flooding Reduction Algorithms Framework
https://datatracker.ietf.org/doc/draft-prz-lsr-interop-flood-reduction-architecture/
Shraddha Hegde (15 mins)
Tony Li: I originally proposed leader-based election. However
operators don't really want leader-based flooding election. We have
to accept this is market reality. Having only one algorithm per area
is a problem. We may not have the algorithm right. Being able to
transition between algorithms is a big-win operationally. The
leader-based transition scares people. Same level of neighbor trust
with leader-based and leaderless since you are dependent on your
neighbor listening to leader and having a correct algo as well.
Changing the algo with leader-based is binary for the area. About
test, there is not test across algorithms. In leaderless, you have
routers running algo 1 and others running algo 2, the links between
them are running full flooding. That means the algo needs to work
within its own subgraph. you don't have real problems here. As to
blast radius, this again goes to transition. Let's way we want to
transition from version 1 to version 2, ver 2 is tested in lab. with
leader based, we need a maintenance window and switch to version 2,
whether it works or not is binary to the entire area.
Les: Node knows that neighbors are either running the leader
selected algo or isn't. Only two choices. I agree that transitions
are difficult, but nobody today is running two algorithms. With
leaderless, you can enable 2nd algorithm node by node, but risk is
that you can't test it.
Tony Li: You get to operaate one node a time and let it soak.
Operators want to be able to change algos incrementally.
Tony P: I acknowledge your perspective here. We had quite some
discussions on the list. Main thing is that is consensus to work on
leaderless but I look forward to second part of the presentation
where you look at improving leaderless. An important part is we have
to address the market with whatever we standardize here.
Marin Horneffer: Selecting a leader does add complexity to a
protocol. We did have a problem and outage with a different protocol
with a similar leader-based semantic. I don't think we'll change
algos often but want just one algo that is better than no pruning.
Shraddha: Testing flooding is not unbounded. When testing flooding
being able to introduce new algo incrementally decreases risk. Even
flooding testing today is difficult. Be able to slow introduce a new
algo is to reduce risks.
Les: Test matrix is unbounded - where are touch points and what are
the scenarios for combinations of algos.
Shraddha: If you say we have to test different flooding topologies
and the test is unbounded, that's true even for today's flooding.
Acee: In MANET, there are lots of flooding reductions. Those can be
tested in isolation and flood all the time on interfaces that
connect them different algorithms. As long as flooding domains are
tested in isolation and flooding is not filtered between domains,
there shouldn't be any problem. I'm not worrying about multiple
algorithms.
Peter: Martin mentioned complexity. To me, the complexity and bugs
probably not in selecting the algorithms but in the flooding itself.
Tony Li: There are a infinite number of graphs to test a single
algo. However there are limited types of graph to test with. You can
will always have full flooding between to algo tested in algorithms.
Both algo 1 and algo 2 need to be fully tested, but you don't have
interoperation between algo1 and algo2.
Les: This strikes me as a problem of theory and practice. In theory,
we fully agree. In practice, not so much. We have seen flooding
problems after long deployment.
Tony Li: we have not seen problems when different flooding
algorithms interoperate.
Les: Sure, as we've not deployed it yet.
Second part of presentation:
Tony Li: Version is useful as well as algo. Nodes shouldn't
advertise both flooding algo TLV (RFC 9667) and leaderless draft
TLV.
Tony P: Try to come with final encodings can't be done at the mike.
Assumption is that new draft will supersede the distributed flooding
algo.
Tony Li: Loves CSNPs and wouldn't go away from them. However, would
be happy to look at a further level of reduction by digesting the
CSNP especially for large LSDB, which will be very helpful. On mesh
group, I disagree that we need an algo number for it.
Les: Not true for leader-based, where only leader advertises the
algo in use while others don't.
Tony Li: Yes.
Les: as far as the 2nd level CSNP, we need to do something about it.
10:10
IGP Reverse Prefix Metric
https://datatracker.ietf.org/doc/draft-li-lsr-igp-reverse-prefix-metric/
Changwang Lin (10 mins)
Peter Psenak: There is already a reverse path calculation with Flex
Algo. I'm not sure whether we need a solution for algo 0.
Changwang: This applies to non flex-algo.
Libin Liu: There are usecases outside of Flex Algo, such as for
strict rpf or traffic engineering.
Acee: This reverse metric is for inter-area reverse SPF calculation.
Flex Algo is for intra-area reverse path.
Peter: Flex Algo reverse path works for inter-area as well. We can
take it offline.
10:20
IS-IS Extensions for Load Balancing Alternates
https://datatracker.ietf.org/doc/html/draft-dong-lsr-load-balancing-alternate-00
Jie Dong (10 mins)
Tony Li: Are you going to update link metric every 10 seconds?
You're going to be reflooding entire LSDB every 10 seconds.
Jie: It may not trigger SPF. You could tune it but it needs to be
reactive to address congestion.
Tony Li: Not reactive to the congestion is useless. There is another
draft on tactical TE using SRTE.
https://datatracker.ietf.org/doc/draft-li-rtgwg-tte/
Jeff Tansura: If you wait too long, congestion information is of no
use and flooding will actually make matters worse. Also recommends
looking at tactical TE draft where you don't need to flood.
Peter Psenak: How do you avoid loops with a path that has loose
paths?
Jie: Must be hop-by-hop to avoid loops.
Peter: How does it scale?
Jie: It depends on the network.
10:40
Flexible Algorithms for Energy Efficiency
https://datatracker.ietf.org/doc/draft-li-lsr-flex-algo-energy-efficiency/
Jinming Li (10 mins)
Tony Li: Advertising information about links that is static. Why use
flex algo as opposed to optimize all paths?
Jinming: We want to exclude links and nodes that do not meet energy
consumption level.
Tony Li: Could an operator use energy efficient on all links?
Acee: A global optimization should be defined. Need to define use
cases for using metrics and constraints. Speaking as chair, we need
more people to review this.
Jinming: we will specify the use cases.
Peter: Are all the metrics dynamic?
Yingzhen Qu
00:02:14
Good Morning! Please join the notes taking:
https://notes.ietf.org/notes-ietf-122-lsr?both
Jeff Tantsura
00:07:42
pretty empty :(
Tony Przygienda
00:20:42
we looked at mesh groups and because the coverage of the full mesh is
guaranteed it looks like it will work fine but as Shraddha says, needs
discussing trhough
Ketan Talaulikar
00:21:30
Agree.
Yingzhen Qu
00:24:39
Please make sure your comments are captured. Please help with the note
taking: https://notes.ietf.org/notes-ietf-122-lsr?both
Tony Przygienda
00:25:30
in terms of practical deployment every deployed scenario with mesh
groups was working fine on deployment of disttopo w/o the need by the
mesh group to advertise anything. Of course it's a limited point of view
but of practical importance
Tony Przygienda
00:26:51
MANET has been around for 20 years or so and quite deployed ;-)
Tony Przygienda
00:37:36
actually you have to know whether your neighbor is running hte same algo
in distributed algos
Tony Przygienda
00:37:45
please look up the trinagle example I provided on the mailing list
Tony Przygienda
00:37:51
it's minor observation though
Tony Przygienda
00:48:02
sorry, the test matrix is a red herring. should yu end up running two
algorithms for some reason (only real one is really migration if ever
happens) then it's two distrinct graphs connected by full flooding
Tony Przygienda
00:48:39
it's like claiming that you have to test whole internet because ASes
peer to each other and some run ISIS and some OSPF (it's imperfect
analogy)
Tony Przygienda
00:49:28
Acee, I cannot toast, it's 4AM here and I don't drink before lunch!
Boris Khasanov
00:55:43
\:)
Joel Halpern
01:03:07
If we assume that different versions of the same flooding optimization
algorithm are compatible, then is the purpose of sending the version so
that an operator can better tell what the various devices are doing?
(That seems an understandable value if that is the point.)
Tony Przygienda
01:03:49
yeah, and I agree now as well with Tony Li having disagreed with himself
within same session (a new one AFAIK ;-)
Tony Przygienda
01:10:54
2nd level CSNP is good idea though obviously bits complex, easy
implementation technique is caching CSNPs (assuming obviously that it's
not link BW that's limiting it). But yeah, also interested in
contributing if we start to talk about it
Tony Li
01:12:58
Perhaps I was unclear. Let me try again: I do not think that two
versions of the same algorithm are going to be backward compatible. It's
simpler and cleaner to have the two versions be treated as completely
independent algorithms.
I am happy, however, to have the version number in place as it gives us
15 bits of namespace to play with instead of only 7.
Les Ginsberg
01:14:14
So when is a new version warranted vs a new algorithm number - seems
very arbitrary.
Tony Li
01:15:06
Caching CSNPs is a given and doesn't really change the link bandwidth
issue. Doing a second level of summarization, making things
hierarchical, allows CSNPs to scale effectively indefinitely for fixed
transmission costs. Yes, obviously processing costs are linear with the
size of the
LSDB.
Tony Li
01:16:02
Les Ginsberg said:
So when is a new version warranted vs a new algorithm number - seems
very arbitrary.
True, but I don't see that as an issue.
Tony Przygienda
01:20:17
as Joel said, at minimum it's a good thing operationally to understand
what's on the network so there's value there.
Yingzhen Qu
01:23:06
please point the camera to the presenter
Yingzhen Qu
01:23:28
@meetecho
Shraddha Hegde
01:26:31
https://datatracker.ietf.org/doc/draft-li-rtgwg-tte/ has a mechanism to
solve the congestion problem. It doesnt need any protocol extension.
doesnt flood any extra info in IGP. much scalable solution
Tony Li
01:32:01
Tony Przygienda said:
as Joel said, at minimum it's a good thing operationally to understand
what's on the network so there's value there.
Documenting what's deployed is certainly valuable, but if we don't need
it operationally, then it should be in the management plane.
Tony Przygienda
01:32:09
Did Jeff just admit to have blown up a couple of networks ?
Jeff Tantsura
01:32:43
I was merely observing it :)
Les Ginsberg
01:33:11
1 To Tony P.
Documenting what's deployed is certainly valuable, but if we don't need
it operationally, then it should be in the management plane.
Jie Dong
01:38:37
@Shraddha thanks for the pointer, will take a look
Vishnu Beeram
01:46:48
@Jie -- TTE is a shipping feature for us, and as Shraddha mentioned, it
does not need any protocol extensions. Besides its applicability to SR
paths, the draft also discusses how TTE can be leveraged in networks
that use RSVP-TE for path placement.
Vishnu Beeram
01:56:25
I would like to draw your attention to a data model draft that defines
the notion of a power-group as a topology attribute --
https://datatracker.ietf.org/doc/html/draft-barth-teas-yang-pg-aware-topo-00
Joel Halpern
01:57:09
With regard to distribute flooding control algorithm identification, if
we want a bigger algorithm ID, lets define the field with the size we
want. If version ins't useful, don't have it.
Vishnu Beeram
01:57:13
Pointer to a newer version --
https://datatracker.ietf.org/doc/html/draft-barth-teas-yang-pg-aware-topo-01