IETF 117 LSR

Chairs:

Acee Lindem (acee.ietf@gmail.com)
Chris Hopps (chopps@chopps.org)

Secretary:

#
WG Page: https://datatracker.ietf.org/group/lsr/about/
Materials: https://datatracker.ietf.org/meeting/117/session/lsr
Monday Session I 09:30 - 11:30, July 24, 2023

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

Multi-part TLVs in IS-IS

9:40
https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
Les Ginsberg (20mins)

Chris Hopps: As a WG member; As you know, I don't like this. If this
were a greenfield development this is not the solution we would come
up with, we would have done something better. I liked the big
container idea better, but you and most other people don't. Wide
metrics presented a similar solution so I am curious did you not
support wide metrics? (A bit of a trick question).
Les Ginsberg: Not quite the same thing, for wide metric, we just
started with two different ways to advertise the same information,
which is different. Problem here is that there is a bunch of
information that nodes already support and need. A single TLV can't
handle it.
Chris Hopps: But this is the equivalent of a metric that is too wide
for the narrow advertisement.
Les Ginsberg: I disagree.
Huaimo Chen: As Chris proposed, from a backward compatibility
perspective, combining capability and container TLV makes it
backward compatible. Chris explained this well on the mailing list.
Les Ginsberg: Chris and I had discussions on the list. Key thing is
that a new advertised element won't be processed by any existing
implementation, there is no backwards compatibility. The legacy
routers won't have this information. That's by definition, not
backward compatible.
Huaimo Chen: We support new features with capability, and new nodes
will be able to support it, and old nodes just ignore it. New nodes
know there are nodes that do not support it and won't use the new
information. That's backward compatible.
Les Ginsberg: What you're saying is when every node supports it,
everyone is happy. The problem is the legacy nodes need the
information, not just the first 255 bytes.
Huaimo Chen: That's an impossible mission.
Les Ginsberg: I'm happy to take this offline.
Tony Li: To Chris, absolutely, in a greenfield we'd do something
cleaner. This is a mess, we can acknowledge that, it's just the best
we can do in the situation we're in.
Acee Lindem: RFC 7770 defines OSPF informational capability. Could
we add an informational capability for diagnostic purposes?
Les Ginsberg: Yes, a discussion could be had about that diagnostic
feature, but that doesn't have any impact on the discussion at hand
on how to go beyond 255 bytes in a TLV.
Acee Lindem: Can the TLVs be spread across LSPs?
Les Ginsberg: Yes.
Chris Hopps: I would be happy with an informational bit at least, if
only to help the operator with diagnostics and debug of this sub-par
solution.
Les Ginsberg: There's a lot of input, not even the authors are 100%
in agreement. There is a lot to discuss. It goes beyond mutli-TLV.
Tony Li: We started the draft with capability, but the authors
argued about it offline a lot and decided not to include it. It's
very messy. There are points on both sides.

OSPF Adjacency Suppression

10:00 (originally 10:10, reordered ad-hoc)
https://datatracker.ietf.org/doc/draft-cheng-lsr-ospf-adjacency-suppress/

Liyan Gong/Weiqiang Cheng (10 mins)

Tony Przygienda: Points 1 & 2 are addressed in the alternate
approach, Point 3, I don't see how it can be addressed by this draft
either.
Les Ginsberg: The purpose is not to determine when everything has
been flooded network wide. The purpose is to suppress nodes with an
unpopulated control plane.
David Lamparter: The loopback address problem in the presentation
seems a rather poor example to illustrate the protocol feature, is
there a better scenario to illustrate this?
Liyan: It's just an example. Other LSA types have the same issue.

Improved OSPF Database Exchange Procedure

10:10 (originally 10:00, reordered ad-hoc)
https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/
Shraddha Hegde / Tony P (10 mins)

Les Ginsberg: Make clear this does not apply to Graceful Restart.
Les Ginsberg: The advantage is that this only requires a change on
restarting node, unlike the previous draft which requires changes on
both routers. However, the previous one is better in synchronizing
with the actual forwarding plane coming up. Suggest that the two
drafts should, in fact, be merged.
Liyan Gong: This draft recognizes the problem, which is valuable.
After router C sends seq X, router B will generate LSBadReq. Also it
doesn't work well with remote routers because the sequence of
flooding can't be controlled precisely. In general, I agree with Les
to discuss merging the two drafts.
Tony Przygienda: Responding to Les, it's a valid consideration. How
long do you want to hold down the adjacency? Some things seem
trivial, until you get into high load and it's not anymore. Might
also be to some degree implementation specific.
Peter Psenak: Agree with everything. Q: For the proposed solutions,
is there a case where the restarting router doesn't in fact want
some of the LSAs to be regenerated? How is that handled? Feels like
a solvable problem.
Acee Lindem: ACK, trying to think through how and where this can
cause problems. If you don't use the stale router LSA, it should
prevent other stale LSAs from being used.
Peter Psenak: Ordering issues in what is flushed when, if things are
updated in the wrong order, breakage may result.
Tony Przygienda: Yes, there's a window.

IGP Unreachable Prefix Announcement

10:20
https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-ureach-prefix-announce/

Peter Psenak (10 mins)

Dan Voyer, Les Ginsberg, David Lamparter: Would like to move this
forward.
Les Ginsberg: The "other" draft doing the same-ish thing is broken.
Chris Hopps: We'll do an adoption call on the list later.

IGP extensions for Advertising Offset for Flex-Algorithm

10:30
https://datatracker.ietf.org/doc/draft-chan-lsr-igp-adv-offset/
Louis Chan (15 mins)

Acee Lindem: Clarification - once the implicit range is specified,
it must be supported everywhere? It looks liek there can't be holes.
For every adjacency, you have to support everything. Virtual
Flexible Algorithm is a horrible term.
Louis Chan: Yes, look at example in FA129, the hole would be very
small. After garbage collection, holes can be reused.
Les Ginsberg: There are discussions in the TEAS WG on extensions in
this space; this is premature and should await the outcome of that.
Liyan Gong: From China Mobile SRv6 deployment, I think this solution
is valuable.
Ketan Talaulikar: There are other propositions in TEAS to address
this, I do not see the need for the approach presented in this
draft. Same as above, we should await for TEAS WG outcome.
Tarek Saad: What's the alternative for lose SIDs? What's the
alternative for achieving the same thing without IGP extensions?
Jie Dong: VFA may not be the right term for this. I'm not sure this
can work with existing SR mapping algorithm.
Louis: We're not talking about resource reservation.
Acee: Please start a discussion on the list.

Updates to Anycast Property advertisement for OSPF

10:55
https://datatracker.ietf.org/doc/draft-chen-lsr-anycast-flag/
Ran Chen (5 mins)

Acee Lindem: It exists for IS-IS, so this is kind of a maintenance
draft. Draft says it's useful for routers to know if something is an
anycast address, could you clarify those use cases and put the in
the draft? The IS-IS draft skipped over the rationale since was it
was a minor addition to the IS-IS SRv6 document, RFC 9352. The use
cases should be included here since this draft is exclusively about
anycast.
Ran Chen: Ack.
Shradda Hedge: Similarly, how are routers going to use this
information? May also want clarification on what happens when this
is incrementally rolled out.

IGP for Temporal Links

11:00
https://datatracker.ietf.org/doc/draft-chen-lsr-tl/
Huaimo Chen (10 mins)

David Lamparter: How does this relate to the work being done in TVR?
Huaimo Chen: Might be related.
Acee Lindem: The schedule YANG model and how to use it in IGP are
separate problems.
Tony Li: As TVR chair, the TVR WG seems to be addressing exactly
this problem. Without TVR hat, this seems overly specific and not a
great solution. A lot of attributes (e.g. latency) are going to
change. Shouldn't there be a more general mechanism to address this?
TVR is trying to create that mechanism in a sensible way.
Huaimo: I agree there will be lots of changes, and this is focusing
on only one aspect.
Tony Li: In TVR, we use YANG model to define time variant
attributes. You know this beforehand and may do precalculation. You
don't need to change the IGP.
Chris Hopps: Similar comment, this is a specific and complex
solution, would benefit from simplicity and generality.
Acee Lindem: OSPF does not have a metric for a link that is down,
you have to signal it. IS-IS does have a link down metric. There are
different ways to do this, this way of doing it, having all routers
act independently, is more fragile. All the clocks need to be
strictly synchronized, and the clocks can become a security
vulnerability.
Huaimo: Agree with you.
Louis Chan: Cost needs to be synchronized, and source routing might
be needed to avoid loops from this. But if source routing is used,
the packet might then be dropped in the middle.
Huaimo Chen: Attempt is to get all the routers to the same state to
begin with.
Chris Hopps: There are a bunch of interesting, but abandoned ideas
that required synchronized clocks, but since we decided we could not
count on that the ideas were not taken up.

Purge Originator Identification for OSPF

11:15 (originally 10:45, remote presenter could not be reached)
https://datatracker.ietf.org/doc/draft-li-lsr-ospf-purge-originator/
Zhenqiang Li & Changwang lin (10 mins)

Acee Lindem: The medicine/solution is worse than the problem;
Consider the case where someone is spoofing a purge from someone
else, would it send another LSA to identify itself? Also consider
the propagation delays, this will amplifying the LSA purge.
Peter Psenak: Agreeing with Acee; trying to solve a valid problem
but the solution is creating more problems than it is solving.
Changwang: We can limit the potential performance impact by only
allowing intra-area LSAs. We have run into this problem, and want to
identify the source of the purge LSA.
Chris Hopps: Please continue the discussion to the list.