Skip to main content

Minutes IETF110: lsr
minutes-110-lsr-00

Meeting Minutes Link State Routing (lsr) WG
Date and time 2021-03-08 16:00
Title Minutes IETF110: lsr
State Active
Other versions plain text
Last updated 2021-03-15

minutes-110-lsr-00
IETF 110 LSR Meeting Minutes

Chairs: Acee Lindem
        Chris Hopps
Secretary: Yingzhen Qu
  
Date: Monday, 8th March 2020 
Time: 17:00 – 19:00 UTC+1
 

0   17:00   15m WG update   Acee/Chris

Xuesong:   For "authors believe it's ready for WG LC", does it mean 
           there is no WG consensus yet?
Acee:      The consensus will be determined during WG LC.
Chris H:   The authors believe a draft is ready, if someone doesn't 
           think so, they can comment.
Tony Li:   draft-ietf-lsr-dynamic-flooding implemented, but there 
           is no interoperability yet.
Chris B:   Dynamic flooding on Dense topo, is it Alvaro's comments on 
           adding OSPF?
Acee:      No, it's SRv6 extension.
Chris:     For flooding parameters, Bruno has asked WG adoption, but 
           there are two drafts and there are still tests going on. The 
           work is progressing. There is no rush on adoption. Speaking
           as WG member, we may need to think out of the box.
Xuesong:   I have seen OSPF/ISIS SRv6 YANG adoption call in the queue 
           for long time, just wondering when it will happen?
Acee:      There is nothing controversial about these two drafts,
           should happen soon.

Alvaro:    Welcome John Scudder as new LSR AD. He's taking over LSR 
           from me. Thank you for the WG, after merging OSPF and ISIS, 
           it's been working great. All the things done in last 
           3-4 years, it's lot of work. It's great to see the two 
           protocols progress together.
Chris H:   Thank you for all your hard work Alvaro.


1   17:15   10m OSPF Transport Instance
https://datatracker.ietf.org/doc/draft-acee-lsr-ospf-transport-instance/
Yingzhen Qu

Linda       What's the application ID here? It it a network application or 
Dunbar:     end-user application?
Yingzhen:   It can be any application that wants to use OSPF transport 
            instance to disseminate application-specific information.
Linda:      If I'm an application attached to a router, can I create my
            own sub-tlv to be attached?
Yingzhen:   Yes.
Linda:      How do I tell router I need this information?
Yingzhen:   That's out of scope for this document.
Acee:       It's meant for non-routing information. So I guess you don't
            mean a prefix, you mean an end-point for an application.
Uma         The MEC computing use case in the draft is not correct, 
Chunduri:   There is no way for a UE to communicate with the network
	    directly.
Yingzhen:   OSPF transport instance can only disseminate non-routing 
            information inside ospf network, how UPF communicate with 
            ospf network is out of scope of this draft. UPF can run an 
            OSPF transport instance, or use other ways to communicate.
Chris H:    Worst case just pull the use case out of the draft.            
Tony Li:    "Routing protocols are not dump trucks", this will impede 
            the operation of the protocol.
Yingzhen:   That's why we're using a transport instance. It's for 
            non-routing information, not route calculation.
Tony Li:    We should design a different protocol for doing this.
Chris:      Did you not like genapp for ISIS either?
Tony Li:    Yes, it's not OSPF specific.
Acee:       Let's move this to the list.
Aijun Wang: What's sparse topology?
Yingzhen:   An OSPF transport instance can run on a different topology 
            from the routing instance. Let's discuss more on the list.


2   17:25   10m IGP Flex Algorithm
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/ 
Peter Psenak

Alvaro:    I'm glad you guys caught that as this was next in my queue. 
           Since we're going to go for another last call, and this 
           seems to be significant change, I'm going to bump the 
           document back to the WG. Please put it on John's queue.


3   17:35   15m Flexible Algorithms Bandwidth Constraints
https://datatracker.ietf.org/doc/draft-hegde-lsr-flex-algo-bw-con/
William Britto

Acee:      Speaking as WG member. This is a good example how flex-algo 
           can be used. Whatever we talk about the measurement of the 
           delay, jitter, etc, there are questions as to how it is done.
	   I know it's out of scope, but it will be helpful to provide
	   guidance on frequency of updating such info.
William:   Thanks.
Gyan
Misha:     Just wondering, how to avoid instability?
William:   We expect operators use with caution. If you want to bring 
           down a link, you have to define the threshold and make sure 
           it's safe. For dynamic bandwidth, it only changes when 
           members change.
Uma:       Useful draft. I'd like to see the impacts to packet reordering.
Jie:       The bandwidth metric, is it tightly coupled with flex-algo?
William:   It's generic, can be used in any application.
Jie:       please clarify it. In this draft, latency is on a particular 
           link instead of end-to-end, what's the use case?
William:   You may want to exclude a particular link.
Shraddha:  Just clarifications. it's basically to dynamically exclude 
           some links when the bandwidth or latency change. The 
           measurement and how often to update the parameters is out 
           of scope. We will add text about area partitions.


4   17:50   10m Using Flex-Algo for Segment Routing based VTN
https://datatracker.ietf.org/doc/draft-zhu-lsr-isis-sr-vtn-flexalgo/
Yongqing Zhu/
Jie Dong

Tarek Saad: Flex-algo has overhead of advertising the definition, nodes 
            consuming it, and doing SPF with the respective algorithm. 
            You'll soon realize you can't do as many flex-algos as you'd 
            want. Any consideration for this limitation?
Jie:        Regarding scalability, we do have a section on scalability 
            in the draft. We also have other drafts that support multiple 
            VTNs sharing the same topology, it requires more extensions 
            to the control-plane though.
Tarek:      Why would we standardize something we know is unscalable?
Jie:        we have another draft in TEAS. Each mechanism has different 
            pros and cons, scalability is one aspect.
Chris:      We should discuss this on the list before we get into an 
            adoption discussion.
Peter       What you're trying to do here is advertise VTN specific info 
Psenak:     about the link. The way you're trying to do this is by 
            hijacking the bundle advertisement, pretending it's 
            specific to the VTN. I'm not sure that's the right approach. 
            There's no direct info about the VTN for which you advertise 
            the information, too error-prone. If you want to advertise 
            VTN-specific stuff, define your own VTN-specific information, 
            don't use hijacking and mapping.
Chris H:    As a WG member, when I saw admin color, I was hoping this 
            would just be an informational draft.
Jie:        to Peter's comment, we reused admin group to correlate with 
            flex-algo ID, is based on existing flex-algo idioms. 
            Introducing a dedicated identifier would be a different 
            approach that would require more extensions. 
Chris H:    Again, this is good for discussion on the list.
 

5   18:00   8m  IGP Flexible Algorithm with L2bundles
https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-05
Ran Chen

Peter P:   As a flex-algo co-author, we never intended to use L2 links 
           in the flex-algo calculations. Do we want to do this? Seems 
           like the right solution is SR-TE. It's *possible* to do it 
           inside flex-algo, but I'd prefer to keep it L3 specific.
Ran:       Thanks, we've discussed your mails, but we think the problem 
           needs to be solved. See section 5. 
Chris:     Would be helpful if more people would engage on the list.


6   18:08   8m  Algorithm Related IGP-Adjacency SID Advertisement
https://tools.ietf.org/html/draft-peng-lsr-algorithm-related-adjacency-sid-02
Ran Chen

Tony Li:    We already have ample mechanisms within flex-algo for doing 
            this kind of thing, for example coloring. Why do we need 
            this?
Ran:        that was in my motivation slide.
Tony Li:    I'm not following you but OK.
Acee:       Please post the question on the list so it can be discussed 
            more.


7   18:16   10m IGP Extensions for SR Slice Aggregate SIDs
https://tools.ietf.org/html/draft-bestbar-lsr-spring-sa-00
Tarek Saad

Acee:       As chair, I think the whole slice TE concept would needs
            to be adopted in TEAS first, and whether or not the concept
	    of slice-aggregate is the right one, before we jump to 
            encodings.
Tarek:      Sure. We are working on that in TEAS.
Peter P:    How many of these aggregates are we talking about. You just 
            mentioned flex-algo doesn't scale to hundreds, and I agree.
Tarek:      Good question, I don't claim to have the final answer. We 
            need to be realistic, shooting for the order of hundreds to
	    a thousand. The point of our proposal is that we want to
	    decouple topology and IGP path computation (primary and backup)
	    from the number of forwarding treatments. 
Peter P:    Hundreds or thousands of these? Could be a scalability issue.
Tarek:      Hundreds of SAIDs. 
Tarek:      Our proposal in SPRING has two options. One is purely 
            data-plane, but that has implications for hardware, so we 
            also have this option.
Jie:        The drafts you mentioned in TEAS and SPRING have overlap/
            conflict with (for example) enhanced VPNs. We need to 
            resolve those first.
Tarek:      We're presenting at the TEAS meeting and we're open to 
            discussion.
Jie:        For scalability, we also have a draft in TEAS. Let's also 
            discuss that.
Uma:        For hundreds to thousands slice aggregates, why do you 
            present SAID with 32 bits?
Tarek:      we'll think about it. we're open to reducing the field 
            size if required.
Acee:       If field size is the only problem, there's no barrier!


8   18:26   10m OSPF Extension for 5G Edge Computing Service
https://datatracker.ietf.org/doc/draft-dunbar-lsr-5g-edge-compute-ospf-ext/ 
Linda Dunbar

Chris H:    As WG member, I don't have time for the philosophizing, 
            but you're trying to push application load-balancing into 
            routing and ask routing to do that. That is a big ask, a
	    big change. You have to add the info because anycast solves 
            the simple problem, very well. But not for you because 
            you're trying to do more. You will get pushback on the 
            whole idea from people who don't want routing to do this. 
            You can do this in other ways.
Linda:      In 3gpp there's project called Edge Computing, and anycast 
            is proposed as a way to do load-balanceing. We're not
	    trying to replace application load-balancers. 
Chris:      I get it, but you are not actually using anycast, you're 
            expanding it. I'm not saying its good or bad I'm just
	    saying it's a big ask.
Acee:       I'll take it to the list, but I'm happy you fixed the 
            encodings. 

From the chat:
Joel Halpern: This seems to be the same confusion of stuffing things 
            into the routing system that parts of the dyncast documents 
            have. Don't solve this problem in routing.
Jeff
Tantsura:   +1
Tony Li:    +1
Randy Bush: Where to solve it if not in routing? App layer?
Tony Li:    In the load balancer?
Randy:      L4 or L7?
Jeff T:     DNS + anycast works pretty well
Gyan:       +1
Joel:       One approach I have discussed is a mapping system (LISP, 
            ALTO, ...) Even better from my perspective is to teach the 
            end-systems to ask an appropriate control component (not 
            the routing) for the information it needs.
            DNS still claims not to give context-sensitive answers. If 
            we ignore that, sure, DNS works.
Randy:      I assure you that there are context sensitive DNS
            deployments.
Jeff T:     IGP should be the last place where this kind of stuff is 
            pushed to.
Joel:       @Randy - I hope I was careful on the phrasing. I am sure 
            there are as many abuses of DNS as there are of the IGPs. 
            Using DNS for the query protocol doesn't bother me.



9   18:36   10m Updates of PUA mechanism
https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
Gyan Mishra(Verizon)
Aijun Wang(China Telecom)

Acee:       As a WG member, two comments (made them last time but they 
            were not taken). First, how do you know which holes you're 
            protecting? Are they configured on the ABRs? How do you 
            know a priori what the ABR is missing if it's not 
            configured?
Gyan:       I don't know if I'm completely understand your question, 
            but I would say if the prefix is missing within the range 
            that notification happens from the...
Acee:       You're assuming you know about the prefix, and then it goes 
            away. You won't protect anything you don't know about when 
            you come up, because it's stateful.
Gyan:       Yes, anything that you know about.
Acee:       It's somewhat timing-based. It's kind of broken in that 
            way. The other problem is the way you're doing it, if not 
            everyone in the domain supports it, you'll attract traffic 
            toward the black hole - the prefix originator T:V is the 
            wrong method for this.
Gyan:       thanks for the comments, we'll take it to the list for more 
            discussions.


10  18:46   10m IS-IS Multi-Flooding Instances
https://datatracker.ietf.org/doc/draft-wang-lsr-isis-mfi/
Yali Wang

Acee:       As a WG member, you say it's easier to implement. Have you 
            implemented it?
Yali:       this is the result of our analysis. Not from implementation 
            results.
Acee:       I would disagree that it'll be easier to implement. We can 
            discuss on the list.