* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Lsr Status Pages

Link State Routing (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2018-Feb-23 —  
Chairs
 
 


IETF-103 lsr minutes

Session 2018-11-06 0900-1100: Chitlada 3 - Audio stream - lsr chatroom
Session 2018-11-06 1120-1220: Chitlada 3 - Audio stream - lsr chatroom

Minutes

minutes-103-lsr-00 minutes



          LSR IETF103 Meeting Minutes
          
          Chairs: Acee Lindem
                  Chris Hopps
          Secretary: Yingzhen Qu
          
          WG Status Web Page: http://tools.ietf.org/wg/lsr/
          
          1) Administrivia - 5 minutes
          - Blue sheets
          - Scribe/jabber
          - Jabber room: lsr@jabber.ietf.org
          
          2) WG Status Update - 10 minutes - Acee/Chris
          
          WG status is now available online.
          
          Chris H:  for TE attributes draft, it has been submitted. what's been
          hold up?
          Acee:     the SR draft, 8 authors.
          Les:      have you done the IESG submission? We'll take care of it.
          
          3) IS-IS TE App - 5 minutes - Les Ginsberg
          https://datatracker.ietf.org/doc/draft-ietf-isis-te-app/
          
          Acee:    anybody objects? No implementation yet. But people are using
          the
                   encodings. We’ll take the last call to the WG list.
          
          4) IS-IS RFC 5306BIS - 5 minutes - Les Ginsberg
          - https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-rfc5306bis
          
          Les:    this is equivalent to OSPF.
          Chris:  any objection? Nobody objects.
          
          
          5) IS-IS Spine Leaf - 10 minutes - Les or Naiming Shen
          - https://datatracker.ietf.org/doc/draft-shen-isis-spine-leaf-ext
          
          Les:     ask for WG adoption.
          Chris H: is the dynamic flooding compatible with this?
          Les:     the leaf node are not part of the flooding. You use dynamic
          flooding
                   for up layers.
          Chris:   it’s like of overloaded LSP. when you said the horizontal
          links, I
                   don’t remember that being talked.
          Les:     there was a B bit. The leaf can be a backup node to the
          spine. The
                   feedback we got considered this unnecessary. The leaf node
                   doesn’t
                   know full topology, it gets information from spine. It just
                   needs
                   to know which spine to use as default route.
          Chris:   I didn’t see anything talking about horizontal links. what
          happens if
                   there are?
          Naiming: We had a B bit if we can go through leaf to spine. Now we
          don’t flood
                   our neighbors LSP back over there. We will need to put something
                   like
                   high metric there.
          Les:     this is not really useful.
          Acee:    I think this has little overlap with other proposals. It does
          a small
                   subset of RIFT. We don’t need to worry about overlap for
                   adoption call.
          Chris:   other than the one I mentioned. I think the work is done other
          than
                   the point I mentioned. I think we’ll be collapsing all flood
                   reductions.
          Les:     this is a complimentary proposal.
          Chris:   this is only for bottom layer.
          Les:     you could use this for up layers, but that's not our primary
          target.
          Tony
          Przygienda: we should push 7356, then it has more potential.
          Acee:    7356 is for Link-scope LSP.
          Les:     right now the draft allow you put this into hellos or link
          scope LSPs.
                   the link scope lsps are better solution. I’ll consult with my
                   coauthors. I have no objection.
          Les:     the answer before was wait. Can we ask for WG adoption now?
          Chris:   yes, we can do that. shall we do it at interim?
          Acee:    I disagree at this point. this draft doesn't have overlap,
          we don't
                   need to wait for interim. we have an implementation going. I
                   don't
                   want to delay it.
          Chris:   I don't object as a chair. does anyone object?
          Tony P:  if I were to run this group, I’ll try to get to 7356.
          Les:     I support your suggestion. We have two mechanisms, you're
          suggesting
                   to use one of them.
          Tony P:  this optimization is optional.
          Les:     I don’t think any changes required to this draft.
          Tony P:  they have to proper deal with it. I'm not objecting, I'm
          suggesting.
          Acee:    why don’t you put it down during adoption?
          Naiming: I agree with Les and Tony. We may move to link-scope LSP. In
          this
                   case, the special case is to not flood back. You may only need
                   100
                   lines to support this. Really simple.
          Chris:   we’ll take it to the list.
          
          6) Update on dynamic flooding - 10 Minutes - Sarah Chen
          - https://datatracker.ietf.org/doc/draft-li-lsr-dynamic-flooding/
          
          Tony Li: so if there is no discussion, We’d like to ask for WG
          adoption.
          Chris H: we have to resolve one issue. I think we’re ready. We have
          another
                   draft out there.
          Huaimo:  we have two different solutions for flood reduction. Last IETF
          some
                   people proposed to merge the drafts. I’m wondering whether
                   we just
                   want to progress only one. we need to have more discussions.
          Chris:   I look at the timeline. Tony published his draft in Jan.
                   the distributed one was in March. Both were presented at IETF
                   101.
                   There were some problems with the distributed one, it wasn't
                   fully
                   baked. During transitions to next IETF, Tony brought in the
                   idea of
                   distribution. You added the centralized solution. I think one
                   way
                   going forward to have you work on distributed algorithm, so
                   that
                   won't conflict. this is my opinion as a member of the
                   WG. Tony’s
                   draft is well written. Your proposal is very
                   complicated. That’s
                   my opinion as WG member. My suggestion is to have you work on
                   distributed solution.
          Huaimo:  Jeff had a requirement draft in DC. Then people start to work
          on flood
                   reduction. After both drafts presented, some people thought
                   disctributed
                   is more practical, we should have more discussions. Maybe we
                   should
                   combine together or separate them.
          Acee:    speaking as a chair, I like the way Chris positioned the
          draft. I
                   support progress both distributed and central controlled.
                   In Manet, 3 different solutions, they all came in as
                   experimental.
                   we don't want to lose this work.
          Huaimo:  both drafts resolve the same issue.
          Chris
           Martin: in terms of the splitting, that's the piece that makes the most
                   sense.
          
          7) IS-IS Sparse Link-State Flooding - 10 Minutes - Gunter Van de Velde
          -  https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-dnfm/
          
          Acee:    is that the only thing reduced? parallel links?
          Gunter:  I will explain later. I even have pics.
          Chris:   doesn’t this end up computing spinning tree?
          Gunter:  it’s like a sparse tree.
          Les:     in the spirit of Chris proposal, do you see we can take your
          idea
                   into other draft? Do you see it reasonable?
          Gunter:  we actually envision is as simple implementation. how to move
          it
                   forward, we’ll discuss offline.
          Tony Li: my concern about the diameter, also the degree. It’s key
          because it
                   controls the speed of flooding. If the degree of the nodes is
                   too
                   high, and multiple anchors, that could cause instability.
          Gunter:  we have a solution for that, it will be in the next version.
          Chris
          Bowers:  I support this. It doesn’t seem to fit in Tony’s draft. It's
          not just
                   distributed, it has signaling, not just a subset of it.
          Chris
          Martin: back to to Tony’s point. The nature of flooding tree doesn't
                   seem to be have resilience. I’m not sure this is the best
                   approach.
          
          8) OSPF Flooding Reduction - 10 Minutes - Huaimo Chen
          - https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/
          
          Acee: no time for comments. We will discuss offline.
          
          9) Distributed Algorithm for Constrained IGP Flooding - 15 Minutes -
          Dave Allen
          - https://datatracker.ietf.org/doc/draft-allan-lsr-flooding-algorithm-00/
          
          
          Tony P:  I looked at the details. Will that produce the lowest diameter
          tree?
                   I saw this tie breaking, but didn't understand it.
          Dave:    the diameter is corresponding to physical.
          Tony P:  how to choose root?
          Dave:    we looked it while looked multicast a while ago. I didn't
          consider it
                   in this case.
          Tony P:  you don’t have degree control. you probably need to address
          it.
          Acee:    we’re not going to standardize all these. Implementations
          will be
                   preferred.
          Chris:   I think not just implementation, but differentiation. They're
          not
                   exactly the same but similar.
          Alvaro:  what’s gonna happen next? Straw men? Interim? On the list?
          Chris:   we have to have a discussion first, then interim based on the
          results.
          Acee:    we decided to put spine-leaf aside, since it’s
          incremental. we're
                   gonna put in the straw men for the centralized and distributed
                   algorithm
                   framework.
          Chris:   we need to settle the two drafts covering the same
          technology. after
                   we solve that, we'll have the interim to discuss the algorithm.
          
          10) IS-IS Invalid TLV - 10 Minutes -  Les Ginsberg
          - https://datatracker.ietf.org/doc/draft-ginsberg-lsr-isis-invalid-tlv
          
          Tony P:  thanks for doing it. If you need co-author.
          Jeff
          Tantsura: very needed. This clarifies what happens when security is
          asking.
                   Looking forward to ospf as well.
          Les:     one reason for writing this so new draft can reference.
          Michael: I had experience with this, the LSP got dropped because no v6
                   enablement. I support this work.
          Shraddha
          Hegde:   question about allowing unknown TLVs in the purge. are you
          suggesting
                   if an implementation doesn't understand the TLV in the purge
                   you should
                   accept it?
          Les:     you have version N, you understand some TLVs. Then new TLV is
                   introduced after your implementation. you don't know whether
                   that TLV is allowed in the purge or not, so you have to accept
                   it.
          Shraddha: what if new draft allow TLV in the purge?
          Les:     we’re introducing a new backward compatibility issue.
          
          11) IS-IS over TCP - 15 Minutes -  Gunter Van de Velde
          - https://datatracker.ietf.org/doc/draft-hsmit-lsr-isis-flooding-over-tcp/
          
          
          Acee:    no time for questions. How may people read it? Many.
          Acee:    Cisco has an IPR, I’ll check.
          Tony LI: I support this work. I suggest we use quic instead of TCP.
          
          
          12) IS-IS SRv6 - 5 minutes - Ketan Talaulikar
          - https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions/
          
          Ketan:    ask for WG adoption.
          Acee:     how many read? Not many.
          
          
          13) LSR Discovery of PCE Security - 10 Minutes - Qin Wu
          - https://draft-wu-lsr-pce-discovery-security-support-00
          
          Acee:     I don’t see no reason we can’t adopt it.
          Chris:    if no more comments on this one. We can talk about TCP.
          
          Break 10-20 Minutes
          
          14) Level 1 IS-IS Area Abstraction - 15 Minutes - Tony Li
          - https://www.ietf.org/id/draft-li-area-abstraction-00.txt
          
          Acee:     so you're going to tunneling the traffic?
          Tony Li:  no.
          Acee:     that indicates level 1 router will have all routes.
          Tony LI:  level 2 is going to exchange LSPs across the tunnels, and the
          level
                    2 area border routers are going ot have to be able to compute
                    transit across level and area, and provide that transit.
          Acee:     that means level 1 only router will have all the level 2
          routes.
          Tony Li:  I'm suggesting that we tunnel from area entry to area exit.
          Acee:     that's what I originally asked but you said no.
          Tony Li:  we're not using the tunnel for area leader, but from entry
          to exit.
          
          Chris H:  I could benefit if there are pictures.
          Tony Li:  yes, in next draft.
          Acee:     we really need to think about it. in ospf, we got rid of it
          because
                    of added complexity.
          Tony Li:  shared links cause scale problem.
          Acee:     I'm just questioning the use case of needing an arbitrary area
          for
                    transit.
          Tony:     that's going to happen sooner or later as network scale up,
          in stead of
                    flat you will need hierarchy.
          Cengiz
          Alaettinoglu: you want to be able to transit. How do you set the metric?
          Tony Li:  I didn't explain this in the draft. There are no metrics that
          are
                    advertised outside of the area. This is abstraction, and it
                    has
                    the pain of suboptimal routing.
          Cengiz:    will you have loops?
          Tony:     no, because you're getting the shortcuts computed through the
          area.
          Cengiz:    you will have to have encapsulations.
          Tony Li:  yes. inside the area, there are l1 router.
          Jeff T:   two questions: MT and traffic engineering
          Tony LI:  I don't see a problem with MT. but traffic engineering, it’s
          an
                    abstraction, you can do TE within the area, even for the
                    tranist
                    traffic. but external traffic coming in this area do not
                    control its path.
          Jeff T:   remember for RSVP TE, border router wouldn't know what's
          inside.
          Tony:     Correct. that border router can manage traffic within the area,
          but
                    not from the head end.
          Jeff T:   probably need to do some extension.
          Tony:     there is nothing for CSNP to compute. area entry is the best
          place.
          Chris
          Martin:   imagine a leaf-spine router. The root router will be the ABR,
                    and the leaves are more likely to be the inter area connection
                    points.
                    To your points, Jeff, you can just hide that information. I
                    hope this
                    helps to clarify the use case.
          Tony P:   choosing an ingress will be difficult, you may end up with a
          bad
                    ingress. you may try to advertise metric, but you end up
                    advertising
                    this full mesh with some approximation. It's inherent limitation
                    of
                    abstraction.
          Chris M:  we don’t have TE between line card and router. everybody
          agree?
          Tony Li:  if links fail within l1 area you can compute a new route
          that's
                    gonna happen.
          
          Acee:     I encourage people to read it. This is an extension to base
                    mechanism. This is definitely interesting. Let’s have a
                    discussion on mechanisms and deployment cases.
          
          
          15) Hierarchial IS-IS - 15 Minutes - Tony Li
          - https://datatracker.ietf.org/doc/draft-li-hierarchical-isis/
          
          
          Les:       still wrapping my head around this. If we do this, we’d
          prefer to
                     use 7056 encoding. There is no such thing in 10589 as an L2
                     only
                     router, so circuit type 2 is actually illegal. I’d like to
                     see how
                     this is being used in discussions.
          Chris:     I’m shocked. I didn't realize there is no just l2 operation.
          Les:       by definition. Level 2 is level 1 router in that area. there
          are
                     many implementations that has L2 only CLI just for convenience,
          
                     so you don't have to got to every circuit and say the circuit
                     is l2 only.
          Tony Li:   no level 1 circuit only.
          Tony
          Przygienda: my only question you assume the highest level get connected,
          right?
                     we assume people don't do stupid things like partition area
                     0 in OSPF.
          Tony Li:   I don't intentionally suggest people do stupid stuff.
          Acee:      you’re keeping all the same semantics, Level n manages
          level n-1.
          Tony:      yes. in theory, you can have a router from level 1 to level 8.
          Acee:      a circuit would be in how many levels?
          Tony:      as many as you want. but those levels must be contiguous.
          Chris H:   I'm wondering whether we have to configure the area according
          to
                     the level?
          Tony Li:   yes, it would make sense for the end sap to be hierarchical.
          Stewart
          Bryant:    I see case you might want to build a level 4 router with its
          sub
                     component in level 1. this is a special case with
                     discontinuous.
          Les:       this is interesting discussion. Deployment cases. So people
          know
                     the good ways to use them. we could debate.
          Stewart:   this is a special case of level 1 being special.
          Les:       let's talk about it more.
          Tony:      I haven’t find a case to use discontinuous level yet.
          Acee:      if we were to adopt it, we will need implementations.
          
          
          16) IS-IS Mult-Topology Deployment - 10 Minutes - Uma Chunduri
          -
          https://datatracker.ietf.org/doc/draft-chunduri-lsr-isis-mt-deployment-cons/
          
          
          Acee:      is this standard tracked?
          Uma:       that’s a mistake. It’s meant to be informational. I will
          fix it.
          
          Les:       this is a well known limitation of the protocol, nothing
          new. If
                     you look at MT, you can support whatever address family.
          Uma:       you said address family, but it's a topology.
          Les:       there is not limitation what address family can run in a
          topology.
                     This is well known.
          Uma:       I'm saying 5308 can also be used for IPv6.
          Les:       you're correct. I'm saying this is well known.
          Uma:       well known to some people, but some people don’t know.
          Les:       there are some people who don't understand this, it was
          clearly
                     stated in 1195. there have been proposals support tunneling
                     between different address families, it never got a lot of
                     support
                     but this has been talked about.
          Mikael
          Abrahammson: there is a mechanism if I forget to configure ipv4 address
          on a
                     link to bring it up, it won't use isis for ipv4. If I’m
                     isis adj,
                     and I have no ipv4 or ipv6 address on the link, I'm not gonna
                     use
                     the link. if you have MT, do you need both IPv4 and IPv6
                     addresses?
          Acee:      we don't want to require IPv4, the goal is to go with IPv6
          only.
                     do you think this draft is useful?
          Mikael A:  I haven’t read the draft. But so far I think it’s useful.
          Chris H:   this may be useful across area, outside of routing, like ops.
          Tony P:    I was against putting reserved topology values. We should
          have
                     called it IPV6 transitional topology? so people know the
                     toplogy
                     concept is completely orthogonal to address family concept. I'd
                     rather
                     reissue the draft with 20 bits putting this not not not.
          Jeff T:    this draft is not meant for isis implementations, it’s
          meant for
                     customers. To help people understand it and how to deploy it.
          Chris:     like writing a paper in a magazine on how to deploy it.
          Tony
          Przygienda:it may get lost.
          Chris H:   he is trying to make clarifications.
          Les:       I'm sympathetic to people get confused, but this was very
          well
                     defined. But if we had thought about MT in 1998 about IPv6,
                     we
                     wouldn't have two TLV types. we didn't anticipate it.
          Mikael A:  you have to write different kind of document for operation
          people.
                     you don't get pitfalls from reading the protocol.
          Jeff T:    we’ve been reading tutorials in routing. It’s good to
          have a
                     reference.
          
          17) Preferred Path Routing Graph - 10 Minutes - Uma Chunduri
          - https://datatracker.ietf.org/doc/draft-ce-lsr-ppr-graph/
          
          Zafar Ali:  the problems listed are not problems. You are looking for a
                      problem to fit your solution. slide 3, we have solution for
                      data statistics without additional label. it's not a problem.
          Uma
          Chunduri:   how do you do it? the problem I see is if FRR happens,
          you will
                      mess up with your accounting, you need to approve it.
          Zafer:        Please read my draft. I can approve you. you need additional
          state
                      in the network, OAMs are complicated. You think it's simple
                      but
                      by the time it’s done, it’s complicated.
          Uma:        binding Sid is also FIB entry adding network state.
          Acee:       why don’t you start a discussion on LSR list?
          Uma:        yes, I’ll.
          
          18) OSPF Prefix Originator Extension - 10 Minutes - Aijun Wang
          -
          https://www.ietf.org/internet-drafts/draft-wang-lsr-ospf-prefix-originator-ext-00.txt
          
          
          Acee:       the changes were to remove different encodings, and some
          are not
                      backward compatible. we only kept ospfv2 extended
                      lsas. Ospfv2
                      prefix attribute lsa, ospfv3 extended lsa. We took out the
                      non backward compatible ones. Aijun had a use case if you
                      have all numbered case and it was moved to appendix.
          Jeff T:     regard the use cases, usually it's not meant to be
          propagated
                      through the area, that's why BGP LS gets it to controller. I'd
          
                      suggest to change the use case.
          Jie Dong:   that’s why we put it in appendix.
          Acee:       our compromise is appendix. we need to discuss it in the
          list. I
                      think it's a good idea. You have a BGP ls draft? That one
                      already
                      adopted, we may also do adoption here. I may not be an
                      author.
          
          



Generated from PyHt script /wg/lsr/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -