Minutes IETF104: lsr
minutes-104-lsr-01

Meeting Minutes Link State Routing (lsr) WG
Title Minutes IETF104: lsr
State Active
Other versions plain text
Last updated 2019-04-08

Meeting Minutes
minutes-104-lsr

      IETF-104 Wednesday 11:20am
LSR WG Session 1


1) Administrivia - 5 minutes
- Blue sheets
- Scribe/jabber
- Jabber room: lsr@jabber.ietf.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
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

Dave Allen:   Do you have diameter of the flooding topology relative to the 
              original graph?
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 
              put all?
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
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext
Les presenting.
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.

(11:54)
5) Update IS-IS Invalid TLV - 10 minutes - Les Ginsberg
- https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv

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
- https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions

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
- https://datatracker.ietf.org/doc/draft-psenak-bier-ospfv3-extensions/
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
- https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-admin-tags
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
-  https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-reverse-metric

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.
Ketan:     Yes.
Chris H:   Anyone object to adopting this? None.
    
(Target: 12:45 Actual: 12:16)
10) OSPF BFD Strict Mode - 10 minutes - Ketan Talaulikar
- https://datatracker.ietf.org/doc/draft-ketant-lsr-ospf-bfd-strict-mode

Chris H:   You found incompatibility?
Ketan:     Yes.
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 
           figure out.
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 
           BFD.
Ketan:     Yes. We will need more feedback.

(Target: 12:55 Actual 12:27)
11) Updates to Flooding Reduction - 10 minutes - Huaimo Chen
- https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

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 
           transition period.
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 
            different solutions.
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 
            centralized solution.
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
            details.
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.




Thursday Meeting

Target: 16:10 Actual: 16:17
12) OSPFv3 Extended LSA YANG Model - 10 minutes - Acee Lindem
- https://datatracker.ietf.org/doc/draft-acee-lsr-ospfv3-extended-lsa-yang/

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 
           models?
Acee:      At some point, you can batch them. It could be painful to do one at 
           a time.
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" 
           through augmentation?
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
-  https://datatracker.ietf.org/doc/draft-peng-lsr-network-slicing/
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 
           inter-domain case.
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 
           inter-domain case. 

Target: 16:30 Actual: 16:40
16) IPRAN Grid Ring Topologies Flooding Use Case - 15 Minutes - Sue Hares
- https://datatracker.ietf.org/doc/draft-hares-lsr-grid-ring-convergence/

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
- https://datatracker.ietf.org/doc/draft-li-hierarchical-isis/

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
           inter PDUs.
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?
Tony:      No.
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.


Target: 16:55
15) IS-IS Area Abstraction - 20 Minutes - Tony Li
- https://www.ietf.org/id/draft-li-lsr-isis-area-abstraction/

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 
           topology?
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 
           large?
Tony:      Yes.
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?
Tony:     Yes.

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 
          routers.
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?
Tony:     Yes.
Rajiv:    What’s your scale result? In terms of nodes.
Tony:     that customer wants the entire world.
John:     This can happen recursively?
Tony:     Yes.
Acee:     Please have a discussion with Huaimo and Alvaro.

Chris H: Please send in your requests for IETF 105 early. thanks.