IETF 118 LSR Minutes

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

Monday Session I 09:30 - 11:30, November 6, 2023

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

• Les Ginsberg: Do you want to progress the mt-vtn draft considering
  the direction that TEAS is going?
• Acee: It's informational. It's doable if you don't require a lot of
  scalability. We'll let the WG decide.

9:40
IGP Unreachable Prefix Announcement
https://datatracker.ietf.org/doc/draft-ietf-lsr-igp-ureach-prefix-announce/

Peter Psenak (10 mins)

• Aijun Wang: There is existing TLV for the function, why do we need
  another?
• Acee: Do you mean overloading the prefix origin TLV that you
  proposed at one time?
• Acee: It's overloading. It doesn't cover the two use cases.
• Aijun: The U flag is not needed. The operator can schedule the
  switchover, no need for IGP to carry such info. In your proposal,
  LSinfinity is used, but currently there are other proposals to use
  LSinfinity, and we want to keep the network simple. There are other
  issues raised on the list, such as network partition, which we can't
  ignore.
• Acee: We've been through of these things. Can you take it to the
  list?
• Aijun: We can compare the proposal, and choose the better one.
• Chris: The WG already reached consensus and adopted a document, so
  that choice has been made.
• Aijun: No, the issue is not solved.
• John Scudder: Our time is to discuss technical issues, keep the
  questions focus to the point. Instead of making speeches, please
  engage with the person presenting.
• Aijun: I can summarize the technical issues on the list and the WG
  should resolve them.
  *

9:50
Multi-part TLVs in IS-IS
https://datatracker.ietf.org/doc/draft-pkaneria-lsr-multi-tlv/
Les Ginsberg (10 mins)

• Acee: with RFC 7770, OSPF advertises both informational and
  functional router capabilities. We want to have a decision about
  whether this is a good idea for IS-IS.
• Chris: Les, I don't agree with you about the backward compatibility,
  and the reason is we have different definitions of backward
  compatible. My definition is that you're not creating loops because
  some routers are misinterpreting information. With that, most
  solution is backward compatible because they don't create loops.
  Your definition is much narrower in that same routing exists before
  will exist after. We care about not breaking the network.
• Les: We're on different pages. No way with partial deployment the
  network will work.
• Shraddha Hegde: If a router can't process two TLVs, it's possible to
  from loops.
• Chris: yes, you're right.
• Huaimo Chen: My proposal is backward compatible.
• Tony Przygienda: Chris, I disagree with you. Backward compatible
  means I can add this stuff to the network and the network will be
  up. After we add multi-part TLVs, there are routers in the network
  that don't understand them. This will cause problems, same as the
  other solution.
• Acee: speaking as WG chair, we're going to do an adoption call on
  this draft.

YANG Model for IS-IS PICS
https://datatracker.ietf.org/doc/draft-qgp-lsr-isis-pics-yang/
Yingzhen Qu (10 mins)

• Tony P: I'd encourage operators to get involved. This will allow you
  to query a router without IS-IS running. This provides more
  granularity beyonds RFCs.
• Acee: I think this is good information. We have to be careful on the
  granularity. Are we going to do for every RFC? We should do this for
  OSPF as well. It's a lot to take on, but excellent information.
• Chris: It might be useful to say I support this RFC without any
  deviations.
• Yingzhen: We can look into this.

10:10
Advertising Link and Node Security Properties in OSPF/IS-IS
https://datatracker.ietf.org/doc/draft-przygienda-lsr-ospf-security-states/

Tony P (10 mins)

Acee: Speaking as co-author, this is experimental and still in very
early stage.

10:20
Improved OSPF Database Exchange Procedure
https://datatracker.ietf.org/doc/draft-hegde-lsr-ospf-better-idbx/
Shraddha Hegde / Tony P (10 mins)

• Liyan Gong: Thank you for considering our comments in the list.
  There are still issues to be discussed.
• Shraddha: Please send your comments to the list.

10:30
OSPF Adjacency Suppression
https://datatracker.ietf.org/doc/draft-cheng-lsr-ospf-adjacency-suppress/

Liyan Gong / Weiqiang Cheng (10 mins)

• Acee: I don't understand the route delete scenario. When the
  restarting router goes down, the neighbor state is terminated. If
  there are problems with that, we'd had heard of them a long time
  ago. I didn't understand the first point in the comparison. We
  should talk more on the list.
• Chris: Let's go to the list.
• Les: I really think the two drafts should be merged. The first one
  requires only local change so there are no interop issues, the
  second is more robust since it allows the starting router to decide
  when to start forwarding.
• Ketan Talauikar: In this comparison table, one is only local change,
  which is a big advantage.
• Weiqiang: Speaking as a co-author, we can consider merging the
  draft. We will work offline.

10:40
Advertising Unreachable Links in OSPF
https://datatracker.ietf.org/doc/draft-gong-lsr-ospf-unreachable-link/
Liyan Gong / Weiqiang Cheng

• Ketan: Option A doesn't have separate encoding, so it might be
  simpler, but it requires a capability to be distributed area wide.
• Acee: Yes, we need a capability no matter which solution.
• Ketan: So option 1 is simpler. "maxmatric-1" means it's still
  reachable. Should also look at TE metric and make similar changes.
• Liyan: Please send your questions to the list.
• Acee: I don't think there is compatibility issue, but we'll look at
  the stub router RFC.

10:50
IGP Flexible Algorithm with Link Loss
https://datatracker.ietf.org/doc/draft-wang-lsr-flex-algo-link-loss/
Yifan Wang (10 mins)

• Fang Gao: Packet loss is not stable, when it is used as metric, it
  is not acceptable if it causes topology changes rapidly.
• Krzysztof Szarkowicz: If there is QoS configured on the link, say
  20% bandwidth for best effort, so there is traffic loss for the best
  effort class. Have you considered that?
• Acee: You need separate topology for that class of service. This
  seems to be useful to me. We have to discuss more.
• Juliusz Chroboczez: There are two kinds of link loss. Physical layer
  and network layer. by the time of network layer, it's too late. If
  you're working with loss due to congestion, it's a different
  problem. You're generating a negative feedback loop which causes
  oscillations.
• Acee: With respect to TE, we only have a single number for loss in
  RFC 8570.
• Sasha Vainshtein: There is a problem with this proposal. After you
  decrease the packets sent on the link, the link may return to no
  loss. You can't exclude the link just based on packet loss.

• 11:00
  Prefix Flag Extension for OSPFv2 and OSPFv3
  https://datatracker.ietf.org/doc/draft-chen-lsr-prefix-extended-flags/

  Ran Chen (10 mins)

• Peter: Question to the WG. do we want to back-port the existing
  flags to this? so only need to look at one place.

• Acee: I'm not sure it's helpful because they're fix formatted and
  can't be removed. The slides confused me, you were allocating bits
  for v3 not v2? That's wrong.
• Ran Chen: Right.

11:10
IGP Color-Aware Routing
https://datatracker.ietf.org/doc/draft-lin-lsr-igp-car/
Mengxiao Chen / Changwang Lin (10 mins)

• Chris: When you have your slides showing domains, do you mean
  operators are running three different IGPs without BGP? Or three
  areas with ABRs?
• Mengxiao Chen: It should be ASBR.
• Chris: Is the scenario real? Some operators are running without BGP
  connecting these domains?
• Mengxiao: In this slide, ASBRs are in differ IGP domains. BGP is
  only on PE nodes.
• Acee : This needs more discussions. I couldn't visualize how much
  overlay information is to put into the underlay.
• Elmar Kirchner: You should have two ASBRs in between domains. Even
  when you have two ASBRs, you don't have an IGP running between them,
  so it doesn't work.
• Acee: 15-20 years ago, people did mutual redistribution between IGP
  domains using tags and policy.
• Aijun: Agree with the previous opinion. There should be 2 ASBRs.
• John Scudder: From the chat, this is something being worked on at
  IDR, it's premature in LSR.

11:20
Prefix Dissemination for Semi-Automatic Addressing and Renumbering
David Lamparter (10 mins)

This was not presented due to the WG session time limit expiring.

From Chat:

Yingzhen Qu
00:00:22

Hi, please help with the joint note taking:
https://notes.ietf.org/notes-ietf-118-lsr

Les Ginsberg
00:01:43

Some folks are reporting audio only access is not working.

Henk Smit
00:02:30

Hi. I'm trying to listen in via the audio-only (free) option.
It doesn't seem to work. I download the .m3u file, it starts VLC, but
VLC can't connect.
Is the audio-only stream supposed to work? TIA.

Lorenzo Miniero
00:02:56

Les: checking, thanks for the heads up!

Sasha Vainshtein
00:09:12

Voice quality is very poor. Can something be done about that?

Sasha Vainshtein
00:10:28

I am watching via the full client, video stream is OK, but audio is
not:wink:

Henk Smit
00:10:39

Audio-only works now. Just very low volume.

Daniam Henriques
00:12:26

@Sasha, switching to the old client resolved the audio issues for me

Sasha Vainshtein
00:13:50

How do I do that?

Daniam Henriques
00:15:24

Click three dots on the bottom, click switch to old client

Sasha Vainshtein
00:16:07

Tried that, no difference:face_with_raised_eyebrow:

Sasha Vainshtein
00:17:10

May I ask the presenters and the speakers at the mike to speak louder?

Lou Berger
00:17:29

Les is really loud for me

Boris Khasanov
00:17:46

indeed

Christian Hopps
00:18:05

he sounds great in the room

Lou Berger
00:18:23

Chairs mic seems low

Lou Berger
00:18:41

but workable

Christian Hopps
00:20:48

@meetecho I do not have a button next to the participant to hand them
control

Loa Andersson
00:20:50

the speaker mike is faint, but I hear Les fine

Lorenzo Miniero
00:21:24

Christian: you need to click on their avatar, the controls will appear
below them

Lorenzo Miniero
00:21:40

The document with the plus icon is the one to hand them control

Lorenzo Miniero
00:21:54

(the avatar in the participants list I mean)

Nitsan Dolev Elfassy
00:32:35

The specific microphone for commenters is hardly audible

Tony Li
00:34:25

Can we please replace 'PICS' with an IETF term?

Les Ginsberg
00:34:45

Fine with me - open to suggestion.

Christian Hopps
00:35:28

@lorenzo thanks i will try that

Tony Li
00:35:29

How about 'support'?

Les Ginsberg
00:36:01

As in "IS-IS Support"?

Tony Li
00:36:10

Yah

Les Ginsberg
00:36:22

Something like that seems fine.

Christian Hopps
00:36:42

isn't this useful for OSPF too?

Les Ginsberg
00:37:08

Could be - in which case you would have "OSPF-Support" module.

Les Ginsberg
00:37:24

Different modules.

Christian Hopps
00:39:09

I'm going to ponder the color of this shed and get back to the list
later :-D

Louis Chan
00:43:20

But this pics model does not ensure interop

Tony Li
00:44:08

Nothing ensures interop except testing

Les Ginsberg
00:44:18

+1

Louis Chan
00:44:35

exactly...so the usability is less than expect4ed

Tony Li
00:45:19

? What is expected is exactly what is advertised: the ability to get
supported features out of the management plane.

Les Ginsberg
00:45:39

It is not intended to "guarantee interoperability". It is to provide the
operator with the info needed to know whether all routers in the network
support a given feature. It does not replace interoperability testing.

Sasha Vainshtein
00:46:01

+1.

Tony Li
00:46:18

+1

Robert Raszuk
00:47:26

Is the definition of "supported" == enabled here or just there is code
on the box which if enabled will support feature xyz ?

Sasha Vainshtein
00:47:47

The underlying assumption is that the vendor adding a new feature will
also advertise its support.

Louis Chan
00:48:02

Even it the operator what is in the network, he can't run it without
full testing with different versions of sw and different vendors...for
RFP purpose, that might sound...but not useful for continual deployment
scenario

Christian Hopps
00:48:10

@robert: the latter

Les Ginsberg
00:48:34

AS stated, protocol does not need to be configured to obtain the
information - whether it is enabled isn't rtelevant here.

Robert Raszuk
00:49:19

Thx Chris, But this may be a bit tricky as feature X even if supported
may require features Y & Z to actually run ... often Y & Z may be coming
from outside of ISIS/OSPF too.

Sasha Vainshtein
00:52:15

@robert: If a supported feature has to be enabled, there should be a R/W
knob to do that via YANG.

Louis Chan
00:54:13

In fact, it does not require to implement on a node. Just implement from
a company web site perspective, keys to lookup are model#, sw version
and license keys. same result.

Robert Raszuk
00:56:06

@Louis - pretty good point. In fact if you have modular software and
download only features of the protocol which you actually need how
useful this will be ?

Tony Li
00:56:57

Still useful. There are points within each feature that you would need.

Tony Li
00:57:16

See all of the attributes within the SR support container.

Yingzhen Qu
01:00:05

agreed with Tony, the RFC level module has more details than just saying
"I support RFC 8667"

Louis Chan
01:00:05

Still useful...use cost vs benefit...vs simply workaround

Louis Chan
01:00:30

just cost vs benefit...typo

Tony Li
01:01:23

Orthogonal question: should anything within the support YANG tree be
"rw"?

Yingzhen Qu
01:02:07

It should be "read-only" since it's OPS state.

Tony Li
01:02:39

That would seem more appropriate to me...

Yingzhen Qu
01:02:45

will add "config false"

Tony Li
01:03:14

Thx!

Boris Khasanov
01:33:26

@meetecho Can you pls increase sound level of the queue mic ?

John Scudder
01:33:47

(Also reported mic level to secretariat OOB)

Lorenzo Miniero
01:34:18

The AV team is already aware

Louis Chan
01:37:15

Just converting link loss to different colour would be a simple
workaround

Tony Li
01:37:47

Changing color would not fix the oscillation

Louis Chan
01:38:10

yes...need damping then.

Louis Chan
01:38:22

which is unavoidable

Tony Li
01:38:47

Damping only bounds the frequency of oscillation

Louis Chan
01:39:15

loss is also a function of time.

Tony Li
01:40:11

Not always... You can have a pattern sensitivity, for example.

Louis Chan
01:40:49

for wireless link, interference is unpredictable.

Louis Chan
01:41:09

so thus loss

Tony Li
01:41:43

Not everything in the world is a wireless link.

Nitsan Dolev Elfassy
01:43:15

In light of the variance of loss the solution seems non deterministic

Tony Li
01:52:25

Given the mess in IDR, would it be better to hold off on this until
there is a CT/CAR resolution?

Lou Berger
01:58:27

mic worked fine