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

##

Friday Session I 9:30 - 11:30, July 26, 2024

##

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

2. 09:40

   IS-IS Distributed Flooding Reduction

   https://datatracker.ietf.org/doc/draft-ietf-lsr-distoptflood/history/

   Tony P (10 mins)

• Les Ginsberg: Two parts to the draft, flooding algorithm and new
  control mechanism to determine which algorithms are enabled. Should
  be two drafts for independent idea
• Tony: Doesn't see the value since the requirements are for both.
• Les: Is there an existing control mechanism that can enable dist
  flood?
• Tony: There is nothing preventing you from doing that.
• Les: These two are logically independent. I should be able to use
  any control mechanism to enable any flooding algorithms.
• Tony: This is from customer's requirement. They're happy with
  default algorithm. They don't want seven vendors having 12 different
  algorithms.
• Les: I don't think where the market where go about the control
  mechanism. My second comment is about the control mechanism. It
  allows several optimized algorithms to be enabled in the network at
  the same time. For someone has to debug the network, it's difficult
  enough for one algorithm, we're already making it more difficult by
  allowing one optimized algorithm run together with legacy nodes. I
  don't want to deal networks running multiple flooding algorithms.
• Tony: I agree with you . But this gives you the opportunity to
  improve or correct the existing algorithm seamlessly. I don't
  recommend running multiple algorithms.
• Les: I support the flood reduction algorithm, but not the new
  control mechanism.
• Tony: This was partially based on your comments. No technical
  comments so far, we are running with that and it works. I have all
  customer requirements fulfilled.
• Yingzhen: The scope has changed.
• Tony: There is not scope at the adoption call. If you look at 100
  drafts that had a huge creep on what you call scope.
• Chris: I think people have a valid point that the scope of the draft
  has changed.
• Tony: New requirements are incorporated into drafts all the time.
• Chris: Are you saying you can add new stuff to a WG doc and no one
  can question it? Let's make sure WG agrees with the new requirement.
  This is valid question to ask so let's at least talk it through.
• Les: I think that's a legitimate process question. The WG needs to
  resolve it. My objection is technical. The control algorithm and the
  flooding algorithm should be independent.
• Tony: You can reference the flooding algorithm without splitting the
  algorithm.
• Don Voyer: Is it possible to articulate the argument on the list.
• Gunter: Routing AD hat on - I want to reiterate that the document is
  WG document and we need to form consistency.
• Tony: I've never seen a new draft fulfilling a new requirement, and
  let's do a consensus call. There is no RFC talking about this stuff.
• Acee: It hasn't happened a lot in LSR, but if you follow IDR,
  there's been a lot of forced break ups of drafts. We should do a
  consensus call. My personal opinion.
• Gunter: Couldn't agree more. Same thing happened in PIM.
• Tony Li: Speaking as MPLS chair. If there is a change in MPLS, we go
  back to the WG for consensus, even for editorial changes.
• Chris: The chairs will have to make a consensus call on whether the
  WG is ok with it. Let's not reject that right out of hand.
• Yingzhen: Consensus call show of hands.
• Dan Voyer: Harder to follow when things are put in different drafts.
• Chris: Please note a show of hands isn't a result - just gives the
  chairs an idea.
• Acee: Is the a problem in using the LSPs in getting all the 2-Hop
  neighbors for all of your neighbors?
• Tony: No problems with IS-IS after the 3-Way exchange finished and
  if something is missed, it will be discovered with PSNP.

1. 09:50
   ### Optional IS-IS Fragment Timestamping {#optional-is-is-fragment-timestamping}

   https://datatracker.ietf.org/doc/draft-rigatoni-lsr-isis-fragment-timestamping/

   Tony P (10 mins)

• Tony Li: I understand what you are doing, but think you should use
  something standard like Linux timestamp.
• Tony P: Need fractions of a second.
• Tony Li: Could use Linux timestamp with both seconds and
  nanoseconds.
• Tony Li: Somebody is going to use this timestamp for something other
  than debugging.
• Tony P: Fair point - will add text to say that is shouldn't be used
  for anything else.
• Les: Need to clarify the use cases on the router.
• Tony P: Controller can get it from the LSDB of routers in domain.
• Les: Don't see the use cases.
• Tony P: Used to see if flooding is backed in a part of the IS-IS.
• Chris: Controller could talk to all the routers and use NETCONFs to
  retrieve timestamps and LSPs from each node.
• Tony P: Controller - would be too slow with NETCONF to every router
  in domain.
• Chris: Let's just use 64 bit timestamps as Linux does.
• Tony P: Will consider resolution and indicate not to use it to
  influence IS-IS behavior.
• Jeff Haas: RFC 8877 has format.
• David Lamparter: No capability to check if the PTP clock is
  configured correctly.
• Tony P: Not needed - just an offset.

1. 10:00
   ### Improved OSPF Database Exchange Procedure {#improved-ospf-database-exchange-procedure}

   https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/
   Acee Lindem (10 mins)

• Enke Chen: Although I haven't really followed the discussion, this
  reminds me of BGP GR. When a BGP speaker restarts, it's in receiving
  mode. When there are multiple routers restarting, there is a
  potential of deadlock. We had to introduce a bit to indicate that
  you're restarting, so we don't wait for you. This could be something
  similar.
• Acee: It could, but we don't need signaling. Better just do it your
  self.
• Enke Chen: I feel the initial holding pattern is similar.
• Acee: We shouldn't be relegated to the inefficiencies of other
  protocols.
• Enke Chen: just want to make sure it's taken care of.
• Acee: Let's take this to the list. We've been talking about
  end-of-rib on another draft, bgp-spf.
• Enke Chen: There are two things. One is whether the router is
  restarting, the second is end-of-rib. they work together in BGP GR.
• Liyan: Thank you for the discussion on the list. I see two
  improvements in your slides, the LSA type and the forwarding plane
  problem. slide #5, I'd like to confirm this solution doesn't need to
  be deployed on all neighbors of the restarting router?
• Acee: If you weren't previously adjacent to it, you can't have stale
  links even if it's adjacent with other routers.
• Liyan: In this situation, we must maintain a list of previous full
  neighbor.
• Acee: this is optional. Thinking it more, I wouldn't do it if I were
  to implement it.
• Liyan: This is a bit complicated. Slide #6, for reason #2, I think
  this is normal situation. There might be a scenario, the stale LSA
  is MaxAge, as describbed in RFC 2328, this LSA won't be added to the
  DBD packet, but to the retransmission list.
• Acee: I didn't really follow you. If you're getting rid of these
  stale LSAs that are in the domain, the restarting router is either
  going to update or purge these LSAs if it becomes DR again, it won't
  advertise adjacencies with any one else until it has updated or
  purged the stale LSAs.
• Liyan: This is normal flow. The problem will happen as this was
  described in section 10.3 of 2328.
• Acee: Can you put that scenario in the list?
• Liyan: yes.
• Liyan: slides #7, About the forwarding plane, we will have to
  control the neighbor state machine of the restarting router, am I
  right?
• Tony P: No.
• Acee: OSPF requires both LSAs have bidirectional connectivity. As
  long as the restricting router delays announcing the adjacency until
  it has updated its data plane, everything is fine.
• Liyan: You're missing special cases. I'll send it to the list.
• Les: slides #5, For the first optimization, I think you've talked
  yourself out of it. I don't think it applies because the scenarios
  you're trying to address are not restricted to these cases where the
  neighbors still haven't timed out their adjanceny, the LSAs in OSPF
  by default last for an hour. It's quite possible your adj has come
  down and you don't have any memory of it but you still want to use
  these procedures. You don't need this.
• Acee: I tend to agree.

1. 10:10
   ### OSPF Adjacency Suppression {#ospf-adjacency-suppression}

   https://datatracker.ietf.org/doc/draft-cheng-lsr-ospf-adjacency-suppress/

   Liyan Gong/Changwang Lin

• Acee: OSPF flooding is deterministic and there won't be neighbor
  deadlock.
• Liyan: OSPF is very complex and high risk to modify neighbor state.
• Tony P: Since OSPF has point of database synchronization in
  adjacency formation, the need for End-of-RIB doesn't
  apply.

1. 10:20
   ### IGP-based Source Address Validation in Intra-domain Networks {#igp-based-source-address-validation-in-intra-domain-networks}

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

   Lancheng Qin

• Acee: Are you going to advertise a color corresponding to the
  prefix tag?
• Lancheng: Will look at this.
• Tony: Don't really see how to practically use this in the
  IGPs. Also, BGP will also be advertising information
  for prefixes available and can conflict.
• Les: We don't need a new SAVNET tag.

1. 10:30
   ### IGP Reverse Metric Algorithm {#igp-reverse-metric-algorithm}

   https://datatracker.ietf.org/doc/draft-ppsenak-lsr-igp-reverse-spf-algo/

   Les Ginsberg

• David Lamparter: You don't need a continuous algorithm for
• Les: Disagree.
• Sandy: Need more discussion on how this interacts with PIM.
• Acee: Wouldn't you want to do this for every prefix in the
  IGP domain rather than signaling it in Flex Algo
  for specific prefixes?
• Les: That is one usecases but there are others for
  specific prefixes. Still thinking about how to
  position these.

1. 10:40
   ### IGP Extensions for Optimized SRv6 SID Advertisement {#igp-extensions-for-optimized-srv6-sid-advertisement}

   https://datatracker.ietf.org/doc/draft-cheng-lsr-extension-opt-srv6-sid-adv/

   Liyan Gong/Weiqiang Cheng

• Acee: Isn't this very complex for operators? And won't it require an
  IGP capability?
• Liyan: Relatively simple and may not need to use capability.

• Peter Psenak: Would like to see real use case to advertise hundreds

  of End SIDs.
  * Liyan: Draft contains a use case.
  * Peter: Not sufficiently specified to demonstrate a real
  requirement.

1. 10:50
   ### IGP Color-Aware Shortcut {#igp-color-aware-shortcut}

   https://datatracker.ietf.org/doc/html/draft-cheng-lsr-igp-shortcut-enhancement-04

   Changwang Lin

   • Peter: Nothing needs to be standardized here. Implementations
     are pointed out here.
   • Changwang: Need to update RFC 3906 shortcut SPF needs to be
     updated.
   • Liyan: Existing document needs to be updated to cover the
     color.

Chat History:

Jeffrey Haas
00:04:25

Yingzhen is quiet at the speaker mic. Is that mic actually on?

Christian Hopps
00:05:46

I can hear OK, quieter than Acee, but still audible for me

Jeffrey Haas
00:06:06

Either the gain is turned down too low, or she's being picked up by the
chairs' mic.

Jeffrey Haas
00:06:14

@meetecho could you check

Christian Hopps
00:06:31

definitely sounds different for me

Christian Hopps
00:06:48

sounds like she's talking directly into the mic in front of her for me

Lorenzo Miniero
00:07:09

We've raised the gain a bit, is it better?

Christian Hopps
00:07:17

maybe the mic isn't getting mixed into all the right channels?

Jeffrey Haas
00:09:12

not really much better. given how close they are to the mic, I think
it's simply off.

Christian Hopps
00:09:22

It's definitely not off

Christian Hopps
00:09:33

I'm hearing it just fine Jeff, and I'm remote :)

Yingzhen Qu
00:09:49

the mic is on

Yingzhen Qu
00:09:56

how about now?

Christian Hopps
00:10:06

It's still fin Yingzhen

Christian Hopps
00:10:48

Something is wrong with the audio going to Jeff's setup or on his setup
\:)

Jeffrey Haas
00:11:01

I'm similarly remote. chair mic is a blast, tony is only ok.

Jeffrey Haas
00:11:27

it's audible, just not as loud as I'd expect. so consider me an outlier.

Dan Voyer
00:31:26

I'm told that the audio is not that great, did we raise this somewhere ?

Padma Pillay-Esnault
00:33:20

FYI Yingzhen you are barely audible at the back of the room

David Lamparter
00:34:06

coin flip >_<

Yingzhen Qu
00:35:24

@Padma thanks, I'll try to be louder.

Henk Smit
00:40:19

Timestamps might seem a bit useful. But you can just as well get the
timestamp via Netconf/Yang from the originating router. Imho, we
shouldn't put unnecessary cruft in the protocol when not necessary.
Henk Smit
00:40:30

https://www.rfc-editor.org/rfc/rfc1925.html
Rule 12. (My favorite rule).

Ketan Talaulikar
00:41:52

+1 for "less funky timestamp"

Christian Hopps
00:42:01

Like Acting on forwardign to try and synchronize

Bruno Decraene
00:43:31

like anti-replay for auth?

Ketan Talaulikar
00:47:00

This is not something to push into BGP-LS. We don't push LSP/LSA
refreshes (w/o any changes) into BGP-LS.

Jeffrey Haas
00:48:11

I've not studied the draft, but fundamentally something like bgp-ls can
put a second timestamp in to its announcement that "this is when I got
the received tlv". The best you can do is display the stamp shipped, the
local received stamp and let something do the subtraction math.

Jeffrey Haas
00:49:57

Stick to rfc 8877. Just stick to 64 bits.

David Lamparter
00:51:15

i meant the TAI-UTC offset...

David Lamparter
00:52:31

(if the IERS makes good on their promise to abolish leap seconds it
won't matter)

Tony Przygienda
01:27:19

You cannot q”just add something” on receival in link state

Tony Przygienda
01:28:07

The TA-UTC is interesting discussion

Jeffrey Haas
01:39:10

To Les's point, do you really want to contaminate the general purpose
tag type with an application specific (that needs to be coordinated)
value?

Alvaro Retana
01:41:04

A couple of observations on the last presentation (SAV): (1) some/all
(?) of the information that would go in the new tag can be inferred/is
already available in the LSDB (no need to duplicate); (2) the blocklists
at the border should also consider internal-to-the-AS interfaces
(subnets), even if transit-only.

Jeffrey Haas
01:42:27

IMO, the major thing that needs to be flagged is "ownership" for the
subnet. As I noted to Les in a hallway conversation, there's nothing
similar to the rpki used by bgp to be used by the igp to declare the
"truth" of such tagging of ownership.

Jeffrey Haas
01:42:48

Similarly as discussed with Les, there's nothing an igp could really do
about this being wrong.

Jeffrey Haas
01:43:00

The threat model is going to heavily impact the deployment model.

Jie Dong
01:43:53

which data plane would be used for Flex-Algo with this calc type?

Liyan Gong
01:43:55

3）This implies that the stale LSA updates or purges have been flooded by
the restarting neighbor prior to the Router-LSA or Network-LSA
containing a link to the restarting router.
---to Acee, if the stale lsas on the neighbor router are maxage, they
will not be added into retransmit list instead of DD（10.3 of RFC2328）.
So the start router have the chance to refresh the stale lsas throuth
flooding flow instead of request flow, so the order your slides
mentioned can not be assured. This optimization will cause the solution
not to take effect.

Alvaro Retana
01:45:26

Jeffrey Haas said:

IMO, the major thing that needs to be flagged is "ownership" for the
subnet. As I noted to Les in a hallway conversation, there's nothing
similar to the rpki used by bgp to be used by the igp to declare the
"truth" of such tagging of ownership.

https://datatracker.ietf.org/doc/html/rfc2154

Jeffrey Haas
01:49:23

I was unaware of that. Thanks, Alvaro.

Based on a quick flip through, it's fine for signing, but only covers
the public keying in the general sense rather than the rooted form we
see in RPKI. I'm unclear on a quick read whether there's enough here
that can be leveraged for RPKI and would love to hear the opinion of
someone that's familiar with both of these.

Jeffrey Haas
01:50:02

Meanwhile, I have homework.

Lancheng Qin
01:50:12

@Alvaro (1) Yes, actually we only need to add the new information; (2)
what do you mean by "internal-to-the-AS interfaces"?

Nan Geng
01:55:56

@ jeff this draft only focuses on the validation of source prefixes
owned by the local network (AS).

Jeffrey Haas
01:58:18

@nan I understand that. But the security model is "if you have a router
in the igp, it must be trusted". That can mean either:
1) You will implicitly trust all networks injected into the igp as
"valid" sources of truth.
2) You should evaluate the networks via an external source of truth.

2 has additional igp considerations outside of SAV purposes. That is,
it's a security problem.

Nan Geng
02:00:56

The security problem seems not specific for sav.

Alvaro Retana
02:01:23

Lancheng Qin said:

@Alvaro (1) Yes, actually we only need to add the new information; (2)
what do you mean by "internal-to-the-AS interfaces"?

On 2: you need to block packets sourced from inside the AS. Any address
that belongs to AS1, not just the edge subnets.