# IETF 118 LSR Minutes   {#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:   {#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