Minutes IETF102: lsr
minutes-102-lsr-00

Meeting Minutes Link State Routing (lsr) WG
Title Minutes IETF102: lsr
State Active
Other versions plain text
Last updated 2018-07-24

Meeting Minutes
minutes-102-lsr

   LSR WG Agenda IETF-102
Time Slot (150m): Monday, July 16, 2018 09:30-12:00 EDT
Chairs: Chris Hopps and Acee Lindem
Secretary: Yingzhen Qu

  - Intro, Adminastriva, Document Status
      o Presenter: LSR Chairs (Christian Hopps, Acee Lindem)
        Les: 7810bis is not an RFC yet. we’d like to progress it fast.

  - Yang Updates
      o Presenter: Yingzhen Qu
      o Document: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/
      o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-yang
      o Document: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/
      o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/
       Chris: I’d like to have both OSPF and ISIS progress together.
       Acee: Considering the size of the documents, maybe better to progress
             them consecutively. Instead of sending 240 pages document, 
             120 is probably preferred.
       Chris: I want to send both because if something wrong found in
              one document, it can be fixed in both.
       Jeff Hass: Considering what’s happened for BFD model, I’d suggest one
                   at a time. Otherwise you may get lots of unusual comments,
                   and it’s easier to get them resolved before sending the doc.
       Yingzhen: The authors are actively working on both documents and address
                 comments together.
       Chris: I just don’t want to see an extra meeting added to this process.

    - OSPF Link Traffic Engineering (TE) Attribute Reuse
      o Presenter: Peter Psenak
      o Document: https://datatracker.ietf.org/doc/draft-ietf-ospf-te-link-attr-reuse
       Peter: Should be ready by next IETF for LC.
       No question asked.


     - IGP Flexible Algorithm
      o Presenter: Peter Psenak
      o Document: https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo
       Acee: Would it be possible to specify a loopback for each service 
             and use Flex algorithm w/o segment routing?
       Peter: By loopback you mean specific address?
       Acee: Yes
       Peter: You can.  The intention is you don’t have to.
       Acee: That would have be described in a separate IP-only draft.
       Peter: probably
       Acee: Speaking as Chair, I was not asking for this draft. It was 
             just hypothetical.

      - Dynamic Flooding on Dense Graphs
        o Presenter: Peter Psenak
        o Document: https://datatracker.ietf.org/doc/draft-li-dynamic-flooding
         Acee: Is there an implementation done or underway?
         Peter: We’re looking at it. 
         Acee: For these last two flood reduction, people are look at implementations.
         Peter: This is a generic solution for any arbitrary topology.
         Chris: Doesn’t multicast give you this kind of tree?
         Acee: It’s not reliable.
         Peter: You may come up with a spanning tree, but you want more, at
                least a bi-connected flooding tree. This is more interesting.

      - IS-IS Extensions to Support Routing over IPv6 Dataplane
       o Presenter: Peter Psenack
       o Document: https://datatracker.ietf.org/doc/draft-bashandy-isis-srv6-extensions
        Acee: So for routers which don’t support this, will it install a route based on
              Normal OSPFv3?
        Peter: The router will see two different TLVs, reachability tav is preferred,
               but the result is the same.
        Jie Dong: Question about End.X SID sub-TLV. I see algorithm is added. In SR-MPLS,
                  the algorithm is applicable only to prefix SID.
        Peter: In SRv6, the address is global. Although the locator SID has algorithm,
               we also added it here, it’s for consistency. You have certain locators
               which you want to use for a certain algorithm, but the end SID would
               actually fall from forwarding perspective, which will be part of a
               different locator and for a certain algorithm. You want to make sure
               you have a strict association. So, by specifying algorithm here you make
               sure that you're not going to use the wrong locator during the 
               transition. That's basically the reason.
        Jie: So, if there's any inconsistency between these sub-TLV and the locators
             algorithm, which one will be preferred?
        Peter: Basically what you say is if I have a locator which is for a certain
               algorithm, I make sure that this one will pick that one and not the
               other one. For example, if you for some reason remove that locator
               that this one may fall into a different locator, so it is like you want
               this it to be algorithm five but it will fall back from the forwarding
               perspective.  The best match would be something the locator which is of
               algorithm six. You don't want that to happen, you want to make sure that
               you pick the right locator so that's the reason why we have the algorithm
               field here.
       Sue Hares: Have you worked with BGP to make sure the changes are correct?
       Peter: If you mean BGP-LS, yes.


     - Restart Signaling for IS-IS
       o Presenter: Les Ginsberg
       o Document: https://datatracker.ietf.org/doc/draft-ginsberg-isis-rfc5306bis
        Chris: Does anybody object? No. Do people support? (a tleast 1/2 the
               room raised their hands). We’ll ask on the list. 
               Comment from Jabber, no slides number.

      - IS-IS Routing for Spine-Leaf Topology
       o Presenter: Naiming Shen or Les Ginsberg
       o Document: https://datatracker.ietf.org/doc/draft-shen-isis-spine-leaf-ext
        Acee: We have lots of discussion on flood reductions. Chris and I are
              discussing strategy. We’d like to ask WG on how to progress them and
              deploy them? You want to add about requirement?
        Chris: We got lots of solutions. So I’m wondering how we pick?  Or let the 
               market decide? How to best progress?
        Jeff Hass: I didn’t follow this draft. My question is if you end up 
                   with different topologies. How could this be applicable? One of
                   the things we've seen in the presentations including the open
                   fabric presentation, is that other topologies are being explored
                   for things. my question/comment to you all is this is optimized for
                   that situation. If you end up with a different topology other than
                   CLOS, how does this feature potentially interact with those? So as
                   you consider do extensions you know consider how it might actually
                   interact if you try to deploy it a different topology.
        Acee:  I think this one is simpler that it's just between tier 0 and tier 1,
             so it's not limited to CLOS.
        Jeff Hass: Right and that's going to be probably the the single most common
                   thing when you look at the other topologies know is when you get
                   no an extra layer to up that it becomes more interesting. But my
                   suspicion based on how this is seems to be presented is that the
                   generalization of here's how it apply for the next levels are you
                   actually doing Auto provisioning though otherr topologies.  So
                   you have basically the easy mode for clos and therefore you're
                   going to have to know this is your levels 1 and 2, and that they
                   auto-discover each other and can tell that they're miss wired.
        Acee: Zero touch provisioning it is targeted clos.
       Chris Martin: I was just gonna say that if you look at the agenda we still
                     have I think two or three more presentations that cover areas
                     like this and that doesn't include what's happening, for
                     example, in RIFT. So going back to your point, in terms of how
                     the market looks, at this point I would say that there's really
                     what I mean from my view and just Jeff just mentioned this as
                     well. There are at least four different approaches that are
                     really tied to CLOS, and then there's maybe one or two that are
                     in terms of generic topology. So maybe we look at them as they
                     apply to them maybe the bigger use case which is leaf/spine or
                     CLOS, and then you know the generic use case which is arbitrary
                     topologies, and then let's decide there. Because there obviously
                     is a big need for addressing this problem, and I just going back
                     I mean having these discussions over the past couple years,
                     we're trying to solve a flooding problem that's limiting link
                     state protocols being used in leaf/spine or in clos topologies.
                     If that's what we're trying to do, then that should be the
                     fundamental requirement. you know a lot of the work that's
                     coming out now over the past five years has been to try to fix
                     the flooding problem, so we have BGP being used to fix flooding.
                     When now it looks like everybody said well maybe we should just
                     fix the flooding problem. So if that's the fundamental
                     requirement I don't know if Chris is what you're suggesting that
                     we go to a requirements document first, to try to solve flooding
                     problems in IGPs. if that I mean I’ve seen a presentation at
                     Manoa in 2000 and it was this comparative anatomy presentation. 
                     And basically there's a problem with scale is reduces really to
                     flooding this is almost 20 years ago, and there's been no attempt
                     made, so if that's really where we're trying to do then why we just
                     focus on that.
        Chris Hopps: I don't know whether we go to do a requirmemnts document or not, or
                     if it's enough to just talk on the list. But I think especially
                     when you get competing solutions, and try to pick one, then
                     sometimes requirements document helps focus on that. But I don't
                     know if we're there yet.
       Russ: My take on this is I'm much preferential to having unified signaling 
             than a unified solution at this moment. Because there are different scales
             and different kinds of topologies like Chris said, and Acee said that.
             You know we need to look at and I would just prefer for the moment just to
             get on the path of having unified singnaling and let's not worry about
             which solution is best depending on what happens in the marketplace, and
             where things go in the future. Because I'm not convinced that a
             requirements document is needed and I'm not certain that a requirements
             document is gonna be able to capture like operational realities in a way
             that's gonna have to be helpful in the long term.
       Jeff T: We started DC Routing a few IETFs back. As a result, we have two new
               WGs. I don’t think the end goal is to address the problem for
               specific topology. We should focus not only on flooding, but a new
               protocol on particular topology and see how it fits.
       Dino: Leaf/Spine topology has a big market. If you want to fix this problem
             in simple but large scale, have you considered static routing? ECMP and
             static routing will take you a long way.
       Chris H: Yes. 
       Acee: A lot of these Controller-based solutions basically are 
             static routing. It's just more dynamic than in the past.
       Dino: In SDN, what controllers do are in management plane to configure static
             routes. It was “ ip route” command in the 90s.
      Naiming: This proposal is very similar to static routes. You actually install
               two static routes. 
      Tony P: The links still fails. The problem is you need to split whether you
              have a direct topology or generic topo.  If you work on that stuff, I 
              think you have to keep it apart, I think in the north/south direction,
              the topology is actually quite tractable, and there's a couple of
              different proposal of different properties. the generic problem has
              been walked for twenty with by multiple people with poor results. and
              I do not think that the results were improved because nothing new in
              graph theory and the properties you will find hot links and so on and
              so on are still in place. Whether the north-south is more immediate 
              and I think it's much more tractable so it's kind of meta input.
     Naiming: Yeah, agreed. It's more into like the first tier fully mesh.
     Acee: Let’s start this on the list.


    - Preferred Path Routing (PPR) in IS-IS/OSPF
       o Presenter: Uma Chunduri
       o Document: https://datatracker.ietf.org/doc/draft-chunduri-lsr-isis-preferred-path-routing
       o Document: https://datatracker.ietf.org/doc/draft-chunduri-lsr-ospf-preferred-path-routing
     Acee: So the selection of preferred path is separate work? How do you 
           know which subset of paths you’re going to do  preferred path?
     Uma: PCE does the calculation like SR.
     Acee: This draft covers only the dataplane and the advertisement of
           the paths?
     Ketan: Isn’t this similar to RSVP-TE path, but populate the paths in IGP?
            It’s flooded across the domain and program the data plane. It’s 
            really flooding N**2 paths across the domain?
     Uma: You don’t have to advertise the path if there is no issue with SPF 
          SR.
     Ketan: Let’s say if there are 1000 paths, they will be flooded in the IGP
            domain. It’s really RSVP flooded by IGP.
     Uma: in RSVP, you don’t flood.
     Ketan: In RSVP, it’s only flooded to this hops, but you’re flooding
            the domain.
     Acee: Let’s take it on the list.
     Dino: #1 - Overwhelmed by the complexity. #2 - Your tax overhead was
                completely understated, #3 - I think you have to build new machinery
                to reinvent MPLS in a more complicated way. This is just my opinion 
                and you could take it or leave it, doesn’t matter. You could have
                solved this problem with straight source routing, with not every
                hop-by-hop as the SID. You just could have found a repair path input
                one entry in the source route to get around the failure and that would
                have taken you a long way.
     Uma: It’s not only for FRR. FRR is a by-product.
     Dino: the basic stuff is complicated, and there is more coming.
     Chris: Let’s take it on the alias.
     Acee: Do you want to start a discussion on the alias?

     Uma: Yes. We’re ready.


    - IGP Extensions for Segment Routing based Enhanced VPN
     o Presenter: Jie Dong
     o Document: https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/
     Peter: Biven MTR is available, obviously you can use it. My question is
            how’s the scalability? How many slices are you thinking of? You
            have too provision on each interface. There might be alternative
            solutions that can achieve the same thing in a better way.
     Jie: Let’s discuss it offline. The scalability of MTR is depending on the
          number of slices you have.  We may see whether some optimization
          possible.
      Dino: I have a general statement not just about this presentation. I see
            maybe every five years, IGP is being used to ship the information
            across the network. You store it in LSPs in the middle of a network
            while nobody is using it but only the edge. We saw this long time
            ago with IBGP, and put in route reflectors. We need a reliable
            mechanism. Running multicast on edge for transport. There are only
            so many possible ways to do routing. People are taking all possible
            combinations.
      Stewart: I agree we need a general purpose way to propagate the message,
              but we do need to move along and ISIS seems to be a good 
              solution in short term. We should separate the problems in long
              term.
      Chris H: Just want to clarify, Dino meant you may want to have it only
               on the edge routers not the center of the network. 
      Dino: You have no flexibility because you have to change all routers.
      Stewart: This case it’s needed on all routers.
      Dino: Another way to think about it is to use mapping system. 
      Stewart: For this particular application, we need it everywhere for 
               traffic engineering to steer traffic.
      Acee: Because you’re doing resource reservation, you need not only edge
            routers to have the state. 
      Stewart: We will need to introduce more states. it’s about particular
               resource.
      Jeff T: We have it presented in RTGWG several times. We need a more
               structured way. You may not want to flood it everywhere.
      Acee: TRhe base network slicing should advance before this one, correct?
      Jie: Yes.
      Acee: I’d advise people to read this draft. But we’re dependent on the
            progress of the base draft in SPRING?
      Jie: Yes.

    - OSPF Extend for Inter-Area Topology Retrieval
     o Presenter: Aijun Wang
     o Document: https://datatracker.ietf.org/doc/draft-wang-lsr-ospf-inter-area-topology-ext/
     Acee: There is some history. We rejected a long time ago overloading OSPFv2
           TOS bits for other purpose. All those using non-TLV proposals were
           rejected. I think Padma had a proposal a long time ago reusing TOS
           and we didn’t do it. At that time we didn’t have a way to extend ospfv2, 
           now we should only use TLV.
     Chris H: You should just use TLV.
     Ketan: We shared comments offline. I think some of the non backward-compatible
            were addressed. Like Acee mentioned, we should use TLV. I’d support the
            use of source router id TLV.
     Acee: You can look at the use case, it might be weak. This could be used for
           other things, but please use TLV.
     Peter: I think we can use the source router id, but I don’t think it fixes
            what you’re trying to solve. Because what you advertised is prefix
            and you associate it with the Router ID.  but what you have seems to
            try to do if I understood it from the layout, you are trying to 
            reconstruct the topology but there's no topology data it's just the
            prefix. So I don't know how are you going to use this to reconstruct
            any topology data.
      Jie: Let’s take it offline. How to use the topology and prefix together.


    - IS-IS Support for Openfabric
     o Presenter: Russ White
     o Document: https://datatracker.ietf.org/doc/draft-white-openfabric/
     Chris: I just want to clarify that we didn’t want to have any requirement
             document, that seems like a over kill.
     Russ: That’s fine.
     Acee: This seems to be a separate track because it diverges enough from 
           standard IS-IS. Maybe it can be experimental? Have you considered
           checksum?
     Russ: Yes, we considered checksum. This should not matter. 
     Christian: Flooding scope is not impacted by the checksum.
     Russ: If you have more questions, take them to the list.
     Chris: Do we have anybody with interop lab? To test these different
            algorithms? Maybe publishing paper?
     Russ: This is actually modeled using the same model as OSPF MANET. This
           is pretty much already deployed and running.
     Acee: OSPF MANET is much more complex than this one.
     Russ: Yes

    - OSPF Flooding Reduction
     o Presenter: Huaimo Chen
     o Document: https://datatracker.ietf.org/doc/draft-cc-ospf-flooding-reduction/
     Les: We have two presentations saying the same thing. From WG
          perspective, we should not progress two documents.
     Acee: Intuitively Tony’s is better. You’re reverting back to normal
           flooding when you have more load in the network. You’re saving
           flooding when the flooding topology doesn't change.
     Huaimo: In that case, we have different solutions. we use those links
             to guarantee when one critical node is down, we use those
             links. In between some of the nodes are doing normal flooding,
             most of nodes are still optimized.
     Chris: Second what Les is saying, we don’t need two proposals for
            the same thing. 
     Huaimo: Tony’s original proposal was centralized, and mine was
             distributed. Now Tony has distributed mode. There are
             more modes now.
     Chris: Maybe there are room for working together.
     Chris: Isn’t static configure work better?
     Huaimo: Static config is fine. we provide more options for
     customers.