Skip to main content

Minutes interim-2020-lsr-01: Thu 09:00
minutes-interim-2020-lsr-01-202004020900-00

Meeting Minutes Link State Routing (lsr) WG
Date and time 2020-04-02 13:00
Title Minutes interim-2020-lsr-01: Thu 09:00
State Active
Other versions plain text
Last updated 2020-04-07

minutes-interim-2020-lsr-01-202004020900-00
LSR Interim Agenda
Chairs: Acee Lindem, Chris Hopps
Secretary: Yingzhen Qu

WG Status Web Page: http://tools.ietf.org/wg/lsr/

Session #1
Date: Thursday, 02 April 2020
Start Time: 09:00 America/New_York


9:05
IGP Flexible Algorithm - Peter Psenak
https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/

Chris Hopes:   If the selection is done domain wide. Are you using system id
               for selection?
Peter:         The FAD selection happens in an area. It doesn’t have to be the
               same across areas. The selection is contained in each area.
Jie Dong:      Why os FAD generation from level 1 to level 2 not allowed?
Peter:         Where would you put your FAD definition? It is very likely in
               the backbone. The reason we define this is to avoid looping of
	       FAD. You don’t want loop it back to L2. It doesn’t mean you
	       can’t have FAD in L1, but it can’t be leaked.
Jie:           Did you consider the leaking between multiple instances or
               protocols?
Peter:         No. The redistribution is about prefix, not anything else. You
               implementation can do it, but it’s local behavior, not needed
               in this draft.
Jie:           So maybe each protocol can have their own 128 flex algos?
Peter:         Yes.
Xuesong Geng:  Is it allowed for user to change the metric? What if I want to
               use latency as metric?
Peter:         You can change the regular IGP metric. You’re allowed to change
               the delay metric.
Xuesong:       If I want a low-delay path. How can I do it?
Peter:         We allow the delay metric to be set manually. It’s up to the
               user to set the delay metric.
Acee:          Since there are implementations. We will poll how many read it,
               and see whether it’s ready for LC.
Chris H:       My concern is people may want to read the change.
Peter:         I can wait a bit. Not in a rush, but don’t want to wait until
               next IETF.
Chris H:       Everyone should read. It’s getting close to the WG LC.
Acee:          We’ll do a poll on the list.
Alvaro:        It will be great to have some operational considerations in
               the draft. To help people understand why.
Peter:         I can add it.


9:15
An Algorithm for Computing Dynamic Flooding Topologies - Sarah Chen
https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/ 

Acee:          Do you have always use the subgraph you just added for
               endpoint selection for the next one?
Sarah:         Yes.
Xuesong:       Is this algorithm supporting only single failure? How about
               multi-failure?
Sarah:         The goal is to have a bi-connected graph so it still works when
               there is single failure. If there are multiple failures, we’ll
               need to do partition repair and flood over some temp links if
               the graph becomes disconnected.
Xuesong:       So in case of multi failures, we don’t go back to the original
               topology, but just some special links, right?
Sarah:         The area leader detects the topo change.
Xuesong:       Do you think it’s necessary to add some description about
               that.
Tony Li:       It’s in the base dynamic flooding draft.
Aijun Wang:    This algorithm can be used centralized mode, can it be used in
               distributed mode? How to ensure each node gets the same result?
Sarah:         For distributed mode, you need to make sure all the nodes get
               consistent results. We haven’t considered that.

9:45
Area Proxy - Tony Li
https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/  

Chris H:       Is it working with SRv6 SID?
Tony:          I took the format from existing ISIS SR decoding. I’m not sure
               about 128bits SID.
Acee:          It’s different SUB-TLV.
Tony:          I’ll add SRv6 support.
Acee:          Speaking as WG chair. We started a bit discussion, considering
               we also have a similar TTZ draft for abstracting the areas. We
               didn’t see strong support on the list. Also there is
               collaboration problem. Is it still the case you have anonymous
               customer wants it?
Tony:          Yes. There are several customers interested in this.


9:30
Hierarchical IS-IS - Tony Li
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-extended-hierarchy/

Chris H:       A picture will be helpful. Will it work if you advertise
               all levels always, make it mandatory?
Tony Li:       You could do that. But you may want to expand levels
               anyway.
Chris H:       If you’re level 5, you can always advertise level 0.
Tony Li:       That’s expanding the LSP space.
Les Ginsberg:  If you know what area you want to use at each level, you can
               always advertise them. But if you don’t know, you can advertise
               0.
Chris:         Yes. I understood the transition. The tradeoff is LSP space.
               You can put real number there, but not enable them.
Tony:          Correct.
Acee:          Speaking as chair, is anybody implementing this? (No answer)
Chris:         The customer changed their minds?
Tony:          Customers are still interested, however multiple instances are
               capable of doing similar things. Adequate workaround. Nobody is
               in a rush to implement it.


10:00
Topology-Transparent Zone - Huaimo Chen
https://datatracker.ietf.org/doc/draft-chen-isis-ttz/

Chris H:       There are two similar solutions. OSPF is an experimental RFC,
               has OSPF been implemented? Has it been live in networks?
Huaimo:        We have a prototype implementation, but no deployment yet.
Chris H:       As far as I know, OSPF has not been deployed even though it’s
               an RFC. There are lots of similarities with differences. I’m
               not sure what to do with it.
Acee:          I’m not sure either. We have one more that’s not exactly the
               same but solves the same problem, flood reflector. In the
	       past, we did experimental for all of them.
Acee:          Huaimo mentioned OSPF is experimental draft. Considering its
               Complexity and there are lots of corner cases.
Alvaro Retana: What did we agree to? Considering I’m on one of the drafts,
               Martin Vigoureux will be in charge.


10:10
IS-IS Flood Reflection - Tony Przygienda
https://datatracker.ietf.org/doc/draft-przygienda-lsr-flood-reflection/


Chris H:       I read the draft, it’s still complex to me. It talks about
               using L1 as transit for L2. Does it also do flood reduction?
Tony P:        It’s not about flooding reduction. If I’m forced to compare,
               it’s much less L2 topology to flood around. We haven’t thought
               through about multi-hierarchy levels, but as Tony pointed out,
               multi-instances can also solve the problem from practical
               point of view. This is for traditional a L1 and L2 network.
	       This will work without changes to BGP LS.
Acee:          You said you added a section for tunnels.
Tony:          The prefix leaking is how you do without tunnels if you do it
               correctly.
Acee:          Just like ospf virtual links. How do you scale it? Do you have
               multiple L1 areas in parallel?
Tony:          Precisely. L2 doesn’t change much. It’s very practical problem.
               Forklifting the whole network even part of the network is a
	       no starter.


10:20 
IGP for Network High Availability - Huaimo Chen
https://datatracker.ietf.org/doc/draft-chen-lsr-ctr-availability/

Tony Li:       Seems to me this is controller communication channel issue,
               shy should it go into IGP?
Huaimo:        This is an information channel. It’s for communications when
               failure splits the group.
Tony:          You could have each instance advertise themselves, not in IGP.
Huaimo:        The election process happens in the cluster, IGP is just
               distributing selection information.
Tony:          Your TLV is a list of controller IDs?
Huaimo:        Those IGP just advertise information about controllers.
Tony:          Why do you need a proxy? Why do you need somebody to advertise
               multiple controller id?
Huaimo:        I agree. Normally we don’t need those.
Tony:          I still don’t understand.
John Scudder:  I agree with Tony. As I said in IDR, there are some well-known
               solutions, should not be in routing protocols. RFC7787,
               Distributed node consensus protocol, I’m not recommending it,
               but it exists.
Huaimo:        That’s another way. There are number of ways to provide HA,
               This is just another solution, might be simpler.
Chris H:       Echo early comments. The consensus is that this is a
               well-studied problem. There are five authors, not any references
	       for what has been done before. As Tony said, why is it here?
	       Regarding LSR, you will advertise the controllers and IGP as a
	       transport. We may not want that.
Huaimo:        We’ll look at references.


10:30
Passive Interface Attribute - Aijun Wang 
https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-00

Ketan:         About using prefix to identify link? As discussed on the
               list, may not appropriate for inter-area links. The Link
	       type stub may not enough to identify what kind of link it is.
	       I don’t think it’s a good way of discovering the topology.
Aijun:         Do you have any other idea?
Ketan:         We can look at other proposals, let’s discuss offline.
Aijun:         Ok.
Chris:         Sounds like there will be more discussion on the list.


10:40
IGP Extensions for Advertising IFIT Node Capability - Yali Wang
https://datatracker.ietf.org/doc/draft-wang-lsr-ifit-node-capability-advertisement/

Acee:          You would have to compute a path with all the nodes have iFIT
               capability.
Yali:          Let’s look at the 2nd example. If there is any specific routing,
               like SRv6, we need to know the head and end node has iFIT
               capability to avoid header leaking. Transit node has trace
               option-type.
Acee:          You have to know the exact path for transit information. We can
               take it to the list.
Chris H:       It’s about advertising application in ISIS/OSPF. For an operator
               to deploy this, you just need to write a YANG model, you don’t
               need it in IGP. I think telemetry is important, but whether
               advertising it in IGP is needed, non-routing stuff. We need WG
               consensus.
Yali:          NETCONF/YANG is another way to do it. But this is another way
               to do it, why not?
Chris H:       If you start adding application capability in routing, more will
               come. Why is it needed in routing?
Robin Li:      From my point of view, MSD is advertised by IGP. I don’t think
               IFIT is an application, it can also related to SR path. IFIT
               information is needed when calculating SR path, so it’s path
               attribute related.
Chris:         Are you saying you will change routing based on iFIT info?
Robin:         Maybe not the path, but SR policy.
Chris:         If you’re saying you will route differently based on whether I
               can trace it? Then it belongs to routing. Otherwise, it’s
               something above.
Robin:         It belongs to traffic engineering. Let’s discuss it more on the
               list. Process wise, why is BGP-LS also in the draft?
Chris:         Speaking as chair, that’s the agreement with IDR.
Robin:         Might be too early to individual draft.
John Scudder:  Presumably any draft is hopping to get to WG doc, and you want
               the right format. I don’t think it’s too early.
Acee:          If this is just the information about capability, I don’t have
               much problem. But if we put other type of information, it will
               be too much. Speaking as WG member, also author of RFC 7770.
Jeff T:        Leaking this information to control plane is not a good idea.
               You will need configuration channel anyway. Comparing with MSD
               is not correct. MSD is used to calculate path.
Acee:          I agree with respect to MSD, it’s not the same type of use
               case.
Jie Dong:      Another example is seamless BFD.
Chris:         But it’s related to adj and path computation.
Rakesh Gandhi: There is one requirement that SR head node needs the info.
Aijun Wang:    It should be in IGP. If you use NETCONF/YANG, it’s not enough.
Chris:         I don’t understand it. You can query anything with YANG. IGPs
               don’t have to be used as transport for router capability. The
               encapsulations, the calculation node needs to know it. As a
               chair, if you have some information want the network to know,
               we think of IGP easily. But we have to push back on this.
Robin:         There are not many protocols can be used.
Rakesh:        For SR MPLS, we use PCEP for advertising encapsulation
               capability.
Acee:          Speaking as co-chair, we should take it to the list. Another
               point is whether iFIT framework will be adopted.
Yali:          if the network is changing, IGP is more efficient way to
               collect the information.
Acee:          Is the framework being adopted? That has to come before we
               consider this.
Robin:         We will discuss iFIT in OPSWG, which is informational.
Chris:         As WG chair, it’s our job to let them know if we don’t like
               this work.


10:55
IGP Extensions for Segment Routing based Enhanced VPN - Jie Dong
https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/
 
Tarek Saad:    What’s the relationship between VTN ID and MTID? About
               VTN ID, is it global?
Jie:           We have 3 solutions: in the 1st and 2nd solution, it is 1:1;
               in the 3rd solution, it is different, we allow n:1 mapping;
               With respct to 2nd question, VTN ID is global for
	       multi-domain.
Tarek:         MT ID is IGP construct, it’s within a domain.
Jie:           If you deploy in multiple domains, there are some
               constraints.
Tony P:        These L2 bundles running off L3? The real problem is the
               semantics, it’s not clear what the semantics is when you
	       have multiple topologies.
Jie:           We need to specify the semantics about topology-specific
               TE.
Tony P:        How the resources are shared in IGP? L2 is an optimization.
Jie:           I’ll think about it.