IETF 121 LSR Minutes

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/121/session/lsr

Thursday Session I 9:30 - 11:30, November 7, 2024

=============================================================
09:30
Meeting Administrivia and WG Update
Chairs (10 mins)

09:40
Advertising Infinity Links in OSPF
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-ls-link-infinity/
Liyan Gong (10 mins)

The authors think the draft is ready for WGLC.

• Tony P: Is overload (OSPF Stub Router) covered?
• Acee: Yes - Ketan brought this up and we have backward
  compatibility. The OSPF Host Bit RFC solves this problem.
• Acee: the reason to use the infinity link metric is because ISIS
  does so, and this is to be compatible with ISIS. The other is make
  the adoption easier because you don't need to support extended LSA
  in the base OSPF. This lowers the adoption barrier.

09:50
Flexible Algorithms Exclude Node
https://datatracker.ietf.org/doc/draft-gong-lsr-flex-algo-exclude-node/

Liyan Gong/ Changwang Lin (10 mins)

• Peter Psenak: Flex Algo participation can be used to exclude the
  node from an algorithm. The proposal is not needed.
• Liyan: This can be used to ease deployment when there are a lot of
  nodes to participate and only a few to exclude.
• Peter: I don't understand the configuration advantage. We don't want
  to have two different ways of doing that. Maybe you can post to the
  list of some details of why this needed.
• Liyan: It is a category of routers as opposed to individual routers.
• Acee: plese explain the use case on the list.
• Stephan Litkowski: I agree with Peter in that there is no
  operational advantage, same amount of work.

10:00
IS-IS Distributed Flooding Reduction
https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/
Tony P (10 mins)

• Les: My position is clear on list. Any discussion about how you
  enable the algorithm is independent of the algorithm. Do we agree?
• Tony P: There may be differences in the algorithm when there is a
  leader.
• Les: Suppose there is another algorithm. Is there any reason the
  control mechanism to enable it would have any difference?
• Tony P: Yes, seems like the algorithm will be different with a
  leader or without a leader. Shraddha may have more details.
• Les: If that's true, I don't see it. The discussions of enablement
  should be independent. Any discussion how an algorithm is enabled is
  logically separate from algorithm.
• Shraddha: This algorithm actually has a dependency on the framework
  that enables it. Please check the document. We can't make the
  independent assumption.
• Tony P: There is subtle difference.
• Peter: Any dependency between how the algorithm selected and the
  algorithm is a bad thing. The other solution has no dependency.
• Tony P: Nobody wants to run multiple algorithms except during
  migration. We need to ask the WG whether we need something
  leaderless?
• Acee: The basic requirement is to know whether a neighbor uses the
  same algorithm. But you can optimize much better if you know which
  algorithms your neighbor's neighbors are using. In the existing one,
  you will have see the algorithm the leader selected and assume
  everyone supporting the algorithm is running the algorithm. The
  leaderless is simpler.
• Tony P: Yes.
• Peter: In current solution, you don't need to know what any other
  nodes do.
• Tony Li: I don't agree with Peter. When there are multiple
  connections, you have to know what the other half of the graph is
  doing. Running multiple algorithms without understanding is bad.
• Peter: I agree. The point of leader is everybody agrees, so there is
  only one algorithm, no mix, otherwise full flood.
• Tony Li: Different versions are different algorithms.
• Gunter: Speaking as WG member. I like the leaderless solution, it's
  simple and elegant.
• Shraddha: This algorithm is derived from the algorithm that runs in
  it, and it's already deployed.
• Acee: Just to clarify, she's referring the OSPF Manet work that was
  done around 2005 to 2007.
• Les: The claims that with a leader-based enablement you got a
  terrible blast radius if you want to migrate from one algorithm to
  another is not correct. We can go through the details offline.
• Tony P: The question to the room is whether we should work on it or
  not.
• Acee: We can take this to the list.
• Tony P: If the WG wants to consider both control mechanism, we will
  consider next whether it's in the same or separate document.
• Tony P: I would a consensus call to whether "Should WG work on
  leaderless signaling for distributed flood reduction to allow for no
  configuration/minimal blast radius changes w/o flag days". Based on
  the result, the authors will determine the next steps.
• Acee: I will issue the consensus call.

10:10
Optional IS-IS Fragment Timestamping
https://datatracker.ietf.org/doc/draft-rigatoni-lsr-isis-fragment-timestamping/

Tony P (10 mins)

• Tony P: Requesting WG Adoption.
• Ketan: About a usecase with TE? Can you provide some reference?
• Tony P: Colby can elaborate the use case with determining the
  currency of the TE information. This is the machinery to do that.

10:20
IGP Flex Soft Dataplane
https://datatracker.ietf.org/doc/draft-ginsberg-lsr-flex-soft-dataplane/

Peter Psenak (15 mins)

• Sandy: This method is needed for multicast.
• Aijun: More examples are needed to explain why current algorithm
  encodings don't work.
• Peter: Existing encodings specify SR or IP dataplane.
• Aijun: Ok.

10:35
Source Prefix Advertisement for Intra-domain SAVNET
https://datatracker.ietf.org/doc/draft-li-savnet-source-prefix-advertisement/

https://datatracker.ietf.org/doc/draft-li-lsr-igp-based-intra-domain-savnet/

Lancheng Qin (10 mins)

• Xueyan: In the intra-domain architecture document, there is customer
  network as well, which may include many routers. On this slide
  (#10), only host networks are shown.
• Lancheng: The Host network is layer 2 only. Through some
  discussions, we found the connection to a customer network is
  through BGP, so an IGP doesn't apply.
• Xueyan: Is this method for IGP only?
• Tony Li: In the case of non-transitive network, why do we need more
  information. We should have all prefixes.
• Lancheng: In this case, router A doesn't learn all prefixes.
• Tony Li: I'm confused.
• Yingzhen: What prefixes are you advertising in the IGP?
• Lancheng: Router A advertises P1, Router B advertises P2.
• Peter Psenak: If router A and B are attached to the same subnet,
  they should both advertise the subnet. To me this is a
  misconfiguration.
• Tony Li: It's a misconfiguration. That interface may end up as a
  transit for the entire AS.
• Acee: The chairs decided that the requirement should be discussed in
  SAVNET. We need the use case better defined.
• Tony Li: Why is a tag needed?
• Lancheng: To avoid blocking valid traffic.
• Aijun: In SAVNET, the Intra-domain and Inter-domain architecture
  adoption calls have completed. Now discussing intra-domain
  solutions.
• Peter: We should NOT inject external prefixes into the IGP for
  SAVNET purposes. You can either use BGP or some other mechanism.

10:45
Intra-domain SAVNET Support via IGP
https://datatracker.ietf.org/doc/draft-cheng-lsr-adv-savnet-capbility/
https://datatracker.ietf.org/doc/draft-cheng-savnet-intra-domain-sav-igp/

Shengnan Yue

• Acee: Are intra-domain prefixes that aren't marked allowed as the
  RPF interface?
• Shengnan: No - they are filtered.
• Acee: Speaking as WG-Chair, we will not adopt this draft. This needs
  to be discussed in SAVNET.
• Yingzhen: We need to wait for the intra-domain architecture document
  to be stable before considering any IGP work in LSR.
• Peter: This is not needed on intermediate routers in IGP domain.
  There are other interfaces might be used, e.g. due to TE, you will
  need to solve this problem first.
• Shengnan: On the intermediate node, as long as there is reachability
  through an interface, it's included.
• Yingzhen: The RPF checking is very loose using a Breath-First search
  and allowing from any node with connectivity.
• Peter: What's the point of that?
• Yingzhen: You will need to explain the benefits of doing this.

• Weiqiang Cheng: This is useful in partial deployment.

• Yingzhen: These two presentations showed different problem scopes.
  We will need to wait for SAVNET to define the problem and scope
  first.

10:55
Open Discussions

=================================================================
Chat
Les Ginsberg
00:02:31

can other remote folks hear - I have no audio.

Jeffrey Haas
00:04:47

I can hear loud and clear

Yingzhen Qu
00:09:45

collective note taking: https://notes.ietf.org/notes-ietf-121-lsr

Shraddha Hegde
00:18:13

This can be done in RFC 9350 by not advertising algorithm TLV by the
node to be excluded

Ketan Talaulikar
00:21:56

+1 to Shraddha

Les Ginsberg
00:22:24

+2

Ketan Talaulikar
00:24:32

existing : enable/disable algo ... this new proposal : add/remove node
admin flag .... isn't that the same?

Liyan Gong
00:43:12

Thank you for your question. Let me try to explain, hold on a moment.

Liyan Gong
00:45:20

The advantage of using FAD is that We can exclude a category of nodes
that share the same attributes，
without having to specify each individual node.

Liyan Gong
00:46:18

For example, if we want to exclude all nodes in the network that have
not been upgraded, we can set the tag of these nodes to a specific
value. Then, by excluding that value, it will be OK.

Lou Berger
00:46:58

@les lost you

Jeffrey Haas
00:48:38

shraddha, your mic sounds like it's across the room

Christian Kuhtz
00:49:02

check which mic you're using on your machine.

Shraddha Hegde
00:49:25

I'll fix my headset. others can go

Ketan Talaulikar
00:51:31

@shraddha ... if nbr is running different algo then we just fallback for
normal flooding. It is the same for everyone?

Ketan Talaulikar
00:51:43

s/everyone/every algo

Les Ginsberg
00:55:55

This is why discussion of enablement method needs to be separate from
algorithm. There is a substantive discussion which needs to take place
which should be separate from whether a given alorithm is something we
should standardize. Please enable this discussion by separarting the two
discussions.

Shraddha Hegde
01:10:16

@ketan, My understanding is that what you describe is specific to
leaderless mode of operation. In area leader operation, the assumption
has to be that everyone runs same algo. Thats why algo will be slightly
different (very small nuance though) based on what framework it runs

Ketan Talaulikar
01:16:51

@Shraddha, I believe it is practically the same thing but I will double
check.

Les Ginsberg
01:20:28

@shraddha Leader based enablement guarantees that there is only one
optimized flooding algorithm being used in the network. Nodes can use
standard flooding - but they cannot use a different non-standard
algorithm. Unless you actually want to run multiple non-standard
algorithms at the same time - which I think is a VERY BAD IDEA - there
is no issue.

Mingqing(Michael) Huang
01:20:49

the two routers may has the prefixes, but the interface in FIB

Mingqing(Michael) Huang
01:21:02

might not be correct for uRPF strict mode

Mingqing(Michael) Huang
01:23:58

this is kind of the typical limitation of uRPF strict mode

Jeffrey Haas
01:32:34

From an overly simplified point of view, the SAV table contents for any
source prefix, S, will be the union of all shortest paths for all other
destinations that S can try to reach.

Exactly how that's different from reaching every part of the network is
part of the discussion as to whether this is a useful thing to do.

Jeffrey Haas
01:34:19

Additional hilarity ensues on a topology change and you have to deal
with a thundering herd of updates to the sav table entry in a scale far
greater than a destination based FIB update would have been.

Martin Horneffer
01:35:41

Is reprogramming filtering HW faster than reprogramming forwarding HW?
probably not ...

Jeffrey Haas
01:36:36

Depending on the hardware, possibly so. But in general, probably not.
Line card memory resources are different in fw vs. FIB entries in some
vendors with different programming latencies.

Jeffrey Haas
01:37:17

The savnet solution space permits mixes of fib-based behaviors and fw
based ones. However, they will not scale at the same rates.

Jeffrey Haas
01:37:40

the vrf-table based filtering is what many cases will devolve to, and
that's speed of fib programming.

Jeffrey Haas
01:45:50

Thank you, Peter P.