Minutes IETF104: lsr
Link State Routing
||Minutes IETF104: lsr
IETF-104 Wednesday 11:20am
LSR WG Session 1
1) Administrivia - 5 minutes
- Blue sheets
- Jabber room: firstname.lastname@example.org
2) WG Status Update - 10 minutes - Acee/Chris
Acee: We’ve been waiting for the update of H-bit support doc.
Padma: The authors agree to update the doc this week.
3) Update to LSR Dynamic Flooding - 15 minutes - Tony Li
Dave Allen: Do you have diameter of the flooding topology relative to the
Tony: Implementation specific, we do have a diameter constraint in ours.
Acee: You wouldn’t want to do anything on the LAN, you don’t want to
change that. Would it be algorithm specific? Why do you need to
Tony: The question is whether or not we specify LAB in the flooding topology?
4) Update to IS-IS Spine-Leaf Extensions - 10 minutes - Les Ginsberg
Chirs H: You had leaf-leaf support long time ago. there seemed to be
looping options, did you see it and address it?
Les: Yes. I'll talk about it more.
Chris H: The earlier version seemed to have some loops with metrics and
default is this no longer the case?
Les: We never talked about overload before, that probably will address
the problem -- need to double check.
Acee: I haven't read the update. the overload bit, the leaf still
connected will set the overload bit.
Les: This is not meant to be dynamic.
Acee: Understand now. I thought it would change dynamically.
Acee: I'd advice everyone to read it. this is a big change.
Acee: One reason we adopted it was it was meant to be for data center
and simple. I hope it doesn't get too complicated.
5) Update IS-IS Invalid TLV - 10 minutes - Les Ginsberg
Les: Ready for WG adoption.
Chris H: Anybody in the room disagree? None. We'll ask this on the list,
seems obvious though.
(Target: 12:05 Actual 12:00)
6) Update to IS-IS SRv6 - 10 minutes - Peter Psenak
Peter: Wwe think it's ready for WG adoption.
Acee: Gow many read the draft? How many are following SPRING about the
adoption of SRv6? We'll do the adoption call right after SPRING.
(Target: 12:15 Actual 12:02)
7) OSPFv3 BIER Extensions - 10 minutes - Peter Psenak
Acee: Consistent with doing OSPFv2 and IS-IS extensions also being in BIER.
Peter: The adoption call should happen in BIER.
Acee: Ut was agreed when BIER was chartered. People deploy OSPFv3 network
will need it.
Les: So no adoption call here.
Peter: Right, not here.
(Target: 12:25 Actual: 12:05)
8) OSPF Admin Tags - 10 minutes - Peter Psenak
Les: Did we make a conscious decision not to support 64bit tag?
Acee: I put a explanation in appendix.
Les: Just want to make sure.
Stephane L: What's your use case?
Peter: I don't have a use case.
Stephane: We have sufficient mechanisms.
Acee: Did this draft long time ago. I agree with you.
(Target: 12:35 Actual 12:11)
9) OSPF Reverse Metric - 10 minutes - Ketan Talaulikar
Ketan: Looking for WG adoption.
Acee: How many read the draft? A few.
Acee: We will discuss it on the list about the use case. I know it's
related with l2vpn, so you don't know the underlay characteristics.
Chris H: Anyone object to adopting this? None.
(Target: 12:45 Actual: 12:16)
10) OSPF BFD Strict Mode - 10 minutes - Ketan Talaulikar
Chris H: You found incompatibility?
Chris H: Is it functionally broken?
Ketan: To make it work, both routers need to have explicit configurations.
in LAN, there might be inconsistencies. It becomes difficult to
Chris H: You may want to add in appendix the problem description.
Ketan: It's not currently in the draft.
Chirs H: It's interesting to describe the interoperability issue and how this
solutions interacts with them and fixes them.
Ketan: Looking for inputs from other implementations and get feedback.
Acee: If you get a hello, and it doesn't have the B set. you don't look at
Ketan: Yes. We will need more feedback.
(Target: 12:55 Actual 12:27)
11) Updates to Flooding Reduction - 10 minutes - Huaimo Chen
Acee: I don't think FTC requires scheduler synchronization like SPF because
you don't nee to update RIB or FIB, it's internal.
Peter: Agree with Acee. You don't need scheduler.
Huaimo: It's better to have it. So we have better control.
Chris H: I don't like this either. We have got along just fine without
specifying timer backoff values, I don't think this is needed.
Sue: Two things. One of the deployment of IGP is in IP RAN, some links
transceiver get browned out unexpectedly. That's why some of these
problems are important. IGP is used to signal this kind of thing for
convergence. I suspect only simulation done to look at IGP convergence.
Acee: Does it support the mechanism like scheduler?
Sue: No. Mine is straight into the problem. There are two groups doing
solutions. Mine is theoretical research of not having consistency.
It's a common problem.
Sue: 2nd question is for Acee. Most open source, whether you should have a
scheduler or not, your code has a scheduler when to run it.
Acee: He's talking about distributed algorithm. My opinion is the best
scheduler is not to have one. The problem is what you do during the
Sue: If you have no scheduler, you may get into problem.
Chris H: I was saying this should be not standardized. It's implementation
thing. It should not be on the wire.
Huaimo: This is not on the wire. It's a TLV.
Chris H: If you're standardizing what to use, then that's on the wire.
Huaimo: It's an optional TLV.
Sue: You put into jitter to avoid synchronization. I don't see this being
discussed in Tony's draft. Why?
Chris: It's interesting to talk about. If we want to be agile, we don't want
to specify it.
Sue: We had the problem in the past. Are we going to get into the same
problem? Like FRR, they talk about single link failure.
Huaimo: I'd like to request WG adoption.
Chris H: Chair comment. My expectation with your draft is it should be a
standardized distributed algorithm, but it looks like that's now in
your appendix. This is talking about more generic flooding thing. I
like your FT-bit, this is valuable, but this should go into the
generic doc. Why is it specific to yours?
Huaimo: For distributed algorithm, every node will compute FT.
Chris H: The generic draft is supposed to signaling flooding topology info
centralized or distributed. This was supposed to be for a concrete
distributed algorithm. Tony's work is a framework, going forward he
will need to have algorithms standardized. This should not be just
in your algorithm, it's a general useful thing.
Acee: You want it to be consistent in both centralized and distributed way.
That's why it's general applicable.
Huaimo: This is more about distributed algorithm.
Chris H: We want the draft adopted to talk about central and distributed.
Originally, I was talking about move distributed out of the thing,
but that's not where we landed. We landed with a framework, then we
were going to have distributed algorithms that were standardized
outside of that. When we first talked about in the list, we started
from centralized and distributed. That's where the confusion starts.
But now the work we adopted covers signaling both cases. The FT
bits should go into the general one.
Huaimo: You asked us to remove the centralized one.
Chris H: Are you disagreeing with the process? It's not Tony's document anymore.
it's LSR WG doc, people get credit working on it. We don't want to
have two docs. I thought we all agreed on it, we should take it offline.
Chris H: for example, if you think your scheduler is needed, it should go into
the doc we adopted because it's a generic thing. If your algorithm
requres this scheduler specifically, then it should be in your draft.
Aijun Wang: I think the WG doc is for centralized solution. but for deployment,
the distributed one might be more useful. There are overlaps. I
think it's not fair to put it into the WG doc. We should provide
Chris H: Did you say unfair? We're talking about standards.
Aijun Wang: The original distributed solution was from Huaimo's draft, not Tony's.
Chris H: We want to separate the signaling and the algorithms. You think we
should separate signaling? This is against WG consensus.
Aijun Wang: There is overlap. I'm not saying we should go back. We should do
different solutions. The current WG doc is for centralized algorithm.
Chris H: We should take it offline. Nobody saying no to any of the stuff, I'm
just saying it's in the wrong place because we already have a
document for signaling.
Huaimo: in your request for adoption, you said tony's draft was for
Chris H: I said that was a mistake. That's not where we agreed to at the end.
Tony had sent an email at some point saying I think we're looking at
this wrong, and I said yes, and most people agreed. Tony reframed it
as this one is about signaling, and the other ones are about
algorithm. I misspoke originally.
Huaimo: The adoption was based on your statement.
Chris H: It doesn't matter. we should follow the consensus. I understand
you're not happy.
Huaimo: Happy is not the word to describe my feeling. We've been working
hard on it.
Chris H: Now we're back to credit. If some of your work showing up in a doc
without your name, you can complain.
Huaimo: It's hard to get something new into a doc adopted?
Chris H: So you're saying is that you think it's too hard to get any new work
into the WG doc. This is IETF process, let's take it off line.
Acee: We're in a circular discussion. Are there technical discussions?
Les: Co-author on the draft adopted. Regarding the FT bit, operationally
it overlaps with how we signal temporary flooding. If we decide this
is a good idea, we need to decide how to signal it to get both out
of it. That's why it needs to be in the same document.
Huaimo: These are two different things.
Tony Li: The way to make progress in IETF is to send ideas to the list and
discuss it. I have no objection to your idea, let's talk about it.
Huaimo: Regarding the discussion, I remember it might be Robert that made a
suggestion once that the centralized one send a signal to
distributed one, the distributed should take over. I don't remember
Sue: I'd suggest to take it offline.
Acee: Let's discuss the scheduler and FT bit separately.
Acee: Please read the drafts. I'd recommend you read Sue's draft. The
packet slicing draft will be presented, but should belong to TEAS.
Chris H: Please take a look at ethpad and make sure your comments are there.
Target: 16:10 Actual: 16:17
12) OSPFv3 Extended LSA YANG Model - 10 minutes - Acee Lindem
Chris H: Do we have this is ISIS?
Acee: No, ISIS is always TLV based. this is specific to OSPF.
Chris H: So, WG procedure-wise, should we require future TLVs to also augment
Acee: At some point, you can batch them. It could be painful to do one at
Jeff Hass: For things you know you should specify them.
Chris H: What happens if it's done through augmentation?
Yingzhen: This would lead to many tiny modules but easy to keep track of. If we
do batching, might be harder to keep track of all features. The WG
needs to make a decision.
Chris H: Not sure it's worth worrying about, maybe.
Jeff Hass: Same issue we have in the BGP.
Acee: We didn't really agree with what the base. We did take SR out.
Jeff H: Don't make modules so small. Add in all the state you can at the time.
Better use examples.
Acee: We'll put in examples.
Chris H: What happens to the "unknown tlv" nodes when they become "known"
Acee: I know what should happen but we should document.
Chris H: Let's take it offline. This is a NETMOD/YANG question, and I'm not
sure it has been answered yet.
Target: 16:20 Actual 16:30
13) Packet Network Slicing using Segment Routing - 10 Minutes - Ran Chen
Acee: This has lots of touching points of many WGs. This is leveraging the
intra domain, flex-algo, this is different from VPN+ is that it's
using data plane by using different algo.
Ran: The advantage of this solution is it's easy to achieve inter domain.
Acee: This might be the last time that this is presented in LSR.
Jie: The mechanism is overall in line with VPN+. This is more SR focus,
maybe you can take a look at our solution in SPRING. You introduced
new identifier, maybe something existing with extension can be reused.
Acee: This is the question for TEAS.
Ran: This is more general solution. I'll do the presentation at TEAS and
collect feedback. I know your VPN+ draft, but it's complicated for
Jie: You mentioned to use SR policy. But SR policy is initiated from the
headend. How do you use this info in the transit node?
Ran: I’ll update the draft to clarify.
Acee: The proposal was to add to OSPF and IS-IS information.
Vishnu: You’ve presented in TEAS. Please take it to the list.
Sandy: This doesn’t conflict with multi-domain. This API is easier for
Target: 16:30 Actual: 16:40
16) IPRAN Grid Ring Topologies Flooding Use Case - 15 Minutes - Sue Hares
Uma: This is IPRAN topology, but 5G RAN is all L2 network.
Sue: This is not 5G.
Acee: You talked about ring, then you show GRID.
Sue: All those rings are hang off those Grids.
Uma: You should add l2 into it.
Sue: Want to join the effort?
Uma: Yes. What about FRR for multi failures?
Sue: You may want to have fast convergence before FRR.
Uma: If you separate FRR, there are other cases that may benefit, like
multiple failure handling.
Acee: This is a good topic to take to the list.
Sue: Yes. We'd like to continue the discussion.
Target: 16:45 Actual: 16:55
14) Hierarchial IS-IS - 10 Minutes - Tony Li
Chris H: You have to specify how you do areas. How to you interact and divide?
Tony: There is no obvious way. The obvious way is through configuration.
one comment from Les and Paul is nobody knows what SAP hey? They
suggested area identifier, and we will discuss once we have a proposal.
xx: what's the reason not to use BGP?
Tony: BGP is meant to interconnect domains. We're trying to scale up ISIS
within one AS. BGP is not meant for one domain.
Acee: Any other considerations for backward compatible?
Tony: There should not be interoperability issue. We've fixed bugs, no more
Tony P: Is there going to be a lessons learned session at next IETF?
Acee: It looks like simple extension, but it's not.
Chris H: I can do another 4 hour.
Tony P: I'll prepare for it.
Rajiv Asati: Thinking about the problems I've run into, this rings a bell. With
hundreds of routers, scale becomes an issue. it's nice to extend
level 1 across hundreds of routers.
Tony: There are upper bounds in one area. used to be 1000 in 90s. So the
idea is to scale up, to bump up the isis limitation.
Rajiv: It makes sense to scale up with reasonable convergence.
Acee: How many read drafts? about half. How many would like to have
multiple levels? How many operators?
Tony: I'll ask for WG adoption after next revision.
Chris: Have you done simulations?
Chris H: I'm curious about adjs on LAN at every level.
Tony: I don't think there is a problem because there are going to be
separate PDUs on every level.
15) IS-IS Area Abstraction - 20 Minutes - Tony Li
Acee: Why not full mesh tunnel?
Tony: Flooding issue.
Huaimo: We had TTZ drafts on the same topic. We had several options, group
several nodes, or full mesh. we need to have a discussion.
Tony: Please hold it in 3 slides.
Cengiz: Ysually networks are hierarchical. I like your first proposal. This
is also about scale? re they competing?
Tony: I like both. They're different tools.
Cengiz: Maybe your first proposal is good enough for 20 years. What about
Tony: This is intentionally topo agnostic.
Rafal: Can it be anything other than isis?
Tony: Yes, similar mechanisms can be used in ospf.
Rafal: Us there interactions between levels?
Tony: Yes, there are some. You have to level 1 to distribute info.
Acee: You need send L2 info over L1.
Jeff H: What happens if you partition?
Tony: You're right. IGP don't like area partitions. There have been
solutions for that. I'm not trying to cover it.
David: I did look at similar ideas several years ago.
Acee: OSPF does have primitive version of the virtual link. IS-IS is simpler
because it has only one level-2 area.
David: I know the idea works. But did you see how much you save? I'm not
convinced at reducing flooding is worth the extra hassle.
Acee: From ospf experience with virtual links, you could have leaded the
L2 prefixes into L1 then use routing. That will handle partition.
David: That's what I did with partition.
Tony： tTe problem we have if we keep carrying on, level 2 will explode.
David: if you start hiding level 2, are you expecting it become arbitrarily
David: I'd like to see how much it saves before I'm convinced.
Tony: We already have uses cases that gave up IGP. we go real scale problem.
David: This is large change. Have you considered level 3 and up and leave
level 1 and 2 as it is?
Tony: I'm not scared of changing this in level 2.
John Scudder: This is fun. not sure whether it's useful, but definitely fun. Each
level is modeled as a router. What if partition happens, then it will
become two routers. So there will be area leaders. Is there something
along that line or TBD?
Tony: It's TBD. It's better to have a tunnel rather than 2 routers.
John: How do you flood across?
Tony: Flooding through area leader is the key.
John: So I'm just not exposing it?
Difference between TTZ
Tony : We should combine. Let's talk offline.
Tony P: Is TTZ an RFC?
Tony L: No, it's still a draft.
Chris H: In OSPF, TTZ is experimental RFC.
Tony P: One difference. They don't try to make an area look like on router,
that needs to be resolved.
Rajiv: The square box don't need to communicate with others?
Tony: The square boxes are L1 routers, and they don't have visibility
outside of their own area for communications. Those things do exist.
Rajiv: Only circles have reachability?
Tony: The reachability is still there. It's about what's in the database.
Tony P: TTZ was to carve out something that's not area boundary and made it
hard to do anything else. If you leak prefix, you could make it work.
Alvaro: I'm one of the authors of TTZ draft. The right thing to do is to work
on this together. Let's talk it offline.
Peter: Virtual link is mentioned. It was meant to fix a bad network design.
Tony: Yes, we are trying to fix the hierarchy that was not optimal. This
might not be the perfect solution, but we're trying to get somewhere.
Acee: I didn't understand all the details until today.
Tony: If I understated something, I apologize and please comment.
Sue: I thought the writing was easy and clear.
Chris H: From a chair stand point. we decided not to do TTZ. I'd be interested
to know what changed. Why do we need it now?
Tony: I'm interested in this because of a real customer issue.
Acee: The area borders are the L1L2 routers, but you only see them as L2
Tony: Happy to add clarifications about the one big router.
Cengiz: SPs typically don’t like complicated stuff. I like the multiple level
solution. This is one is more complicated and implementations will be
buggy. We need feedback from SPs.
Chris H: Did you have an example in the draft?
Tony: Yes. It has to be more general.
Robert: If L1 has only default routes, it works well only when L1 is stub,
not transit. What about suboptimal in L1?
Tony: Yes, but that’s orthogonal.
Acee: Isn’t that a network design issue?
Rajiv: What’s your scale result? In terms of nodes.
Tony: that customer wants the entire world.
John: This can happen recursively?
Acee: Please have a discussion with Huaimo and Alvaro.
Chris H: Please send in your requests for IETF 105 early. thanks.