IETF 117 LSR

Chairs:

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

Secretary:

Yingzhen Qu (yingzhen.ietf@gmail.com)

#
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.