* 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-108 lsr minutes

Session 2020-07-30 1410-1550: Room 5 - Audio stream - lsr chatroom

Minutes

minutes-108-lsr-00 minutes



          IETF 108 LSR Meeting
          Chairs: Acee Lindem
                  Chris Hopps
          Secretary:
          Yingzhen Qu
          Date: Thursday, 30 July 2020
          Time: 14:10 - 15:50 UTC
          1
          Administrivia and WG update
          Acee/Chris
          Chris H: What is the status of
          the base network programming draft?
          Peter:   SRv6 programming is in AD
          review, and is progressing in the
                   SPRING WG.
          Chris H: It still
          needs to do IETF LC, right? Perhaps there could
                   still be issues
          raised?
          Martin:  Yes, it's going to IETF LC. This will happen by the
          end of the
                   week. it could be contentious. From LSR perspective,
          this
                   should progress. The appeal has been cleared.
          Chris:   One
          objection during the appeal was around the penultimate hop
                   and
          that affects the TLV space. We could do LC and submit it to
                   IESG,
          but we don't want to be seen as doing an end-run on the
                   process,
          with people pointing at the TLV saying "see the TLV
                   is already
          there."
          Martin:  You need to be careful. I don't expect the network
                   programming draft will progress faster. Most concerns were
                   about PSP, and the new version has added clarifications
          and
                   use cases. I believe we're on the safe side.
          Chris:
          Hopefully this will progress between this and next IETF.
          2 IGP Flex
          Algorithm
          https://datatracker.ietf.org/doc/draft-ietf-lsr-flex-algo/
          Peter Psenak
          Peter:    Ready for WGLC. There are multiple
          implementations.
          Chris H:  This is reasonable. Any objection? (no) I
          think it's
                    ready moving forward.
          Acee:     I will send some
          editorial comments.
          Peter:    Sure.
          3 OSPF Prefix Originator Extensions
          https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-prefix-originator/
          Ketan Talaulikar
          Acee:     Speaking as co-author, we made lots of
          changes. Please
                    read the new version. It now has two TLVs
          because of new
                    use cases.. We'd like to have more reviews
          before WGLC.
          4 Experimental results on IS-IS flooding
          Sarah Chen
          
          Acee:     What's the TX interval for PSNP numbers?
          Sarah:    1 ms
          as TX interval.
          Chris H:  Thank you. This is fantastic. This is what
          had been asked
                    for during the interim. Is there simulation
          code available?
          Sarah:    I used our production code, and I already
          put the
                    threshold-based PSNP in our production code.
          Eduard:
          Thanks for the good research. In new production, ISIS
                    will
          typically have some signature for security reasons, like
                    MD5,
          and this adds 100 ms or 200 ms delay, and will
                    influence the
          results. Do you have anything for
                    certification purpose?
          Sarah:
          No.
          Acee:     can you put it to the list?
          Eduard:   It's long on purpose,
          for security computation, it
                    protects against brute force
          attacks.
          Jeff Haas: Nice to see these things. The results are similar to
          what
                    we see when we did TCP performance tuning in BGP. Tony
          Li
                    confirmed that it's done on real hardware as well. These
          are
                    optimistic results. One concern is in real network, it
          may
                    start to deteriorate. For future, I'd suggest to start
                    putting in machinery to start perturbing and see how quickly
                    and often things get dropped in bursts. That would simulate
          the real world a bit better.
          Sarah:    There are so many parameters that
          we can tune. The purpose
                    of this simple setting is to show the
          correlation between
                    LSP interval and PSNP interval.
          Tony P:
          I'm assuming the retransmission is done ASAP. Suggesting
                    faster
          PSNP is good idea. I think the combination of this
                    hybrid PSNP
          plus transmit ramping up should solve 99% of the
                    problem. That's
          my guts feeling.
          Les:      Echo other people's comments, great work. If
          the LSP
                    transmission interval is 1ms and you have 2000 LSPs, why
          did
                    you take 3 seconds?
          Sarah:    it's our implementation. There
          is some overhead.
          Les:      this is great work. Hybrid PSNP is great
          idea. Given that
                    testing doesn't include dynamic adjustments
          of either drafts,
                    so we can't draw conclusion whether the
          RX-based or TX-based
                    approach might be the best one.
          Sarah:
          The initial work was to test the drafts, but was happy to
                    see
          PSNP works fine and solved the issue.
          Bruno:    I'm interested in
          results from stronger sender, weaker
                    receiver. May try multiple
          senders?
          Sarah:    That's a good point.
          5 IS-IS Topology-Transparent
          Zone
          https://datatracker.ietf.org/doc/draft-chen-isis-ttz/
          Huaimo Chen
          
          Chris H:  As a chair, we wish we had one draft between area proxy
                    and TTZ. There are differences. I know the authors tried to
                    work together at one point. Since we have multiple proposals,
                    that can't seem to come together, we though we would try the
                    experimental track and let the market decide. You also said
                    most people think it's good, I don't know that's the case.
          I know there are lots of people putting +1 out there, but
                    how
          many implementations? How many operators want to deploy?
                    I'm
          not saying those are barriers to adoption but I'm not
                    sure that
          you can claim most people support. I saw lots of
                    experts think
          this is overly complex, that having zones and smooth
                    transition
          might add some value, but can't justify the complexity.
                    So
          as a chair I want to let you know, if we move forward with this,
                    many of the experts with industry knowledge are probably
          not going
                    to review or provide feedback. If this then gets
          submitted to IESG,
                    it will have to be in the report about
          a very rough consensus on
                    the work and that many experts in
          the group did not agree
                    with it.
          Acee:     With chair hat on,
          the time line is a misrepresentation.
                    The draft did go forward
          once and it was quite different,
                    and then it was rejected by
          ISIS WG and expired, and came
                    back after area-proxy draft. It's
          not really the same. The
                    draft is more like area-proxy. I don't
          know why it was
                    changed in 2013 to get rid of the single node
          abstraction.
                    Also agree with Chris, regarding lots of "+1"
          support, not
                    sure how many read the draft. Speaking as WG
          member, the
                    other two drafts (area-proxy and route reflectors)
          have much
                 better specifications. I share the concern with the
          distributed
                  algorithm, maybe you have done some experiments
          for the transition.
              But things don't happen all at once without
          handshaking across
                   the whole routing domain in the zone. So I
          don't think the draft is
              as seamless as it claims, the quality is
          not as good as the
                    other two drafts, even though it has higher
          goals.
          Huaimo:   In 2013, the draft included two solutions. Abstract
          the
                    zone to a single node, select Zone DR/leader which
          generates
                    LSP for the zone. Second solution is to abstract
          the zone
                    with edges fully connected.
          Acee:     When it was
          resurrected in recent history in only included
                    the full mesh of
          edges.
          Huaimo:   Along the path, we focused on one solution. Now people
          are
                    interested in abstracting as single node, we brought back
                    something published in 2013.
          Chris H:  it's individual draft,
          trying different things is fine. I
                    echo Acee's comments. Ot
          doesn't feel finished. You
                    mentioned you just have two adjs
          on the link at one time,
                    although it doesn't specify how that
          works. For P2P, that
                    wouldn't work. You have mechanisms with
          TLV to do the
                    transition. We don't want to end up where you
          can do things
                    10 different ways. We try for KISS solution,
          keep it
                    simple silly. All these options are running up against
          that.
          Huaimo:    The draft provides more options because we want to have
                     discussions and we will converge to one option.
          Chris H:
          That's reasonable.
          Huaimo:    For smooth transition, we did experimental
                     implementation. If we don't have smooth transfer, when we
          abstract area to a single node, we will have adjcency flaps.
                     If
          we don't have a solution, we have service
                     interruptions.
          Chris
          H:   Nobody is arguing that. What I see people arguing is that
          nobody
                     really cares about a brief service interruption
          because it's not
                     going to happen that often. Routers
          come up and down.
          6 Flooding Topology Minimum Degree Algorithm
          https://tools.ietf.org/html/draft-ietf-lsr-flooding-topo-min-degree-00
          Huaimo Chen
          Skipped due to time limitation - now WG document.
          
          7Using IS-IS MT for SR based Virtual Transport Network
          https://datatracker.ietf.org/doc/draft-xie-lsr-isis-sr-vtn-mt/
          Chenhao
          Ma /Jie Dong
          Tony Li:   have you considered using flex-algo? seems
          you can
                     simplify things.
          Jie:       we did. For flex-algo,
          we have a draft describing the
                     routine.
          Peter:     what's
          this draft standardizing? I see nothing.
          Jie:       We had discussions
          on the list about how to use topology
                     TE attributes
          to advertise information at policy level,
                     which is
          not fully specified. whether this draft is
                     standard
          or informational, we need the WG's feedback.
          Peter:     I'm
          not sure you need to standardize.
          Chris H:   so it is for
          informational.
          Acee:      we'll discuss more after the base draft
          adopted in SPRING.
          8 IGP Extensions for Segment Routing Service Segment
          https://datatracker.ietf.org/doc/draft-lz-lsr-igp-sr-service-segments/
          Yao Liu
          Acee:      You could use BGP to communicate, so don't
          need this.
          Yao:       Yes, if there is BGP.
          Chris H:   The IGP
          is special, we don't need extra info. The
                     feedback is
          BGP-LS is designed to carry such info, not IGP.
          Yao:       The
          main purpose is to provide info to BGP-LS.
          Chris H:   You're
          using IGP as transport. We can continue on the
                     list.
          
          9 IS-IS Extensions to Support Packet Network Slicing using SR
          https://tools.ietf.org/html/draft-zch-lsr-isis-network-slicing-03
          ISIS Extension to Support Network Slicing over IPv6 Dataplane
          https://tools.ietf.org/html/draft-peng-lsr-isis-network-slicing-srv6-00
          IGP Flexible Algorithm with L2bundles
          https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-01
          
          Ran Chen
          
          10 Prefix Unreachable Announcement
          https://datatracker.ietf.org/doc/draft-wang-lsr-prefix-unreachable-annoucement/
          Aijun Wang / Zhibo Hu
          Acee:      Ff there are connections between ABRs,
          we don't need to
                     mess up the protocol.
          Praveen:   How different
          is this with already existing mechanism,
                     like max-age? Is
          it specific to summary route?
          Acee:      Yes.
          Praveen:   There is no
          special relation between BGP and IGP.
          Acee:      There are lots of
          solutions for this problem. the draft
                     is half-baked. I don't
          think it's the right way.
          Praveen:   In RIFT, we have default route
          issue.
                     [aijun was having audio problems so couldn't reply]
          Chris B:   Please don't use this time to trash other people's draft. The
                     presenter is having  audio problems so no one is around to
          defend
                  the work.
          Chris H:   Yes, there was some support on the
          list for this work, so I was
                     hoping that someone or another
          one of the other coauthors would
                  join the queue. Since that
          is not happening, I suggest we continue
               this on the list.
          
          
          The Chat History
          Jeffrey Haas
          Question for Sarah's presentation on
          reduction interval slide (slide 5?) - is duration including the # of
          retransmits?
          John Scudder
          Kind of interesting that retransmissions drops
          as txinterval drops, until you get txint down to 1
          Jeffrey Haas
          it does
          feel like they're hitting a rate limiter
          I'd also be interested in the
          transmission cadence. insufficient gapping with highly grouped bursts
          might lead to drops there as well
          Tony Li
          Yes, duration is wall clock
          from first LSP to last LSP.
          Tony Przygienda
          yeah, we have the stuff
          forever and we have no massive RTX'ssions
          probably some implementation
          problem
          Jeffrey Haas
          Tony Li, that includes the retransmits?
          Tony
          Przygienda
          but there is tons good stuff here
          I'll chime in
          Tony Li
          Yes,
          rexmit included.
          Thank you, Tony!
          Jeffrey Haas
          Interesting. It suggests
          paying the retransmit tax is still worth it for the reduced total time
          
          Tony Li
          No, hang on...
          Tony Przygienda
          hysteresis has to be very
          aggressive on back-off
          Yingzhen Qu
          I'm wondering whether data traffic
          has any impact?
          Tony Przygienda
          not if implemented correctly
          Christian
          Hopps
          Yingzhen, shouldn't
          Jeffrey Haas
          It's all queues. Depends on
          what's the resources being competed for.
          Tony Li
          These experiments were
          pure control plane.
          No hardware was harmed. Or used.
          Tony Przygienda
          yeah, if you don't prioritise properly from input until protocol read
          out you're toast no matter what
          Jeffrey Haas
          Tony Li - raw and not
          on traditional router with host plane ?
          I guess better question is
          what's the platform? If raw linux, this discussion is a bit off for
          actual routing hardware
          Tony Li
          Control plane in namespace containers,
          all on one server.
          Jeffrey Haas
          But does help develop the optimistic
          limits
          ah. container underlay mechanisms can lead to weird behavior
          on bursty traffic
          Tony Li
          We did repeat on physical hardware, same
          results.
          Jeffrey Haas
          observations from tcp in bgp land in similar
          environemtn
          John Scudder
          Did I correctly understand the last line to
          be "too fast to meter"?
          Tony Li
          Tool failure.
          John Scudder
          ah
          Henk
          Smit
          So faster bursting of LSPs causes fewer retransmissions ? It seems
          the sender's retransmission code is too aggressive ....
          Tony Li
          Faster
          PSNPs decreases retransmissions.
          By default, retransmisssions are more
          aggressive than PSNP, which is just plain broken.
          Henk Smit
          Sure. But
          I assume that if you have the receiver send PSNPs every 2 sec, you have
          set the sender
          Tony Przygienda
          sigh, I say it on the mike, I assumed
          e'body knows that you obviously break the spec and send PSNP (ACKS) as
          fast as you can
          mea culpa
          Henk Smit
          ... sender's retransmit-interval
          to at least 3 sec.
          Tony Li
          "Everybody knows" is pointless. We're out
          to revise specs.
          We need to write it down.
          Tony Przygienda
          correct,
          as I said, "mea culpa"
          too many implementations over course of my
          life I guess until one doesn't realise such stuff
          Henk Smit
          Tony,
          in the example by Sarah, when you set psnp-interval to 2 sec, what did
          you set the rxmit-interval to ?
          Tony Przygienda
          no interval, I think
          what they suggest i.e. fast start with ramp up is best solution
          I was
          frankly always greedy & ACK'ed as fast as I could
          Henk Smit
          Question
          was for Tony Li.
          Tony Przygienda
          oh, sorry
          differentiate ;-)
          Henk Smit
          Sorry. :)
          Tony Li
          Left the rexmit alone.
          Henk Smit
          Old IOS code has
          that set to 5 sec. Can I assume your code still has it to 5 sec ?
          Tony
          Li
          Bad assumption. But that's not the point.
          The point is that without
          fast PSNPs, delay seems like you need rexmit.
          Tony Przygienda
          and yes,
          what Jeff says about the bursts is very relevant but very HW specific and
          very hard to put finger on. It's the usual trashing with too much context
          change vs. state compression slowing convergence
          Henk Smit
          Just trying
          to understand why # of retransmits increases when you transmit slower. It
          seems so counter-intuitive.
          Tony Przygienda
          and then once you start do
          that on tons interfaces lots of other stuff kicks on in terms of buffer
          management
          nope, basically not enough PSNPs make it out to confirm all the
          stuff that came in
          so the TXer starts to RTX because timers kick in
          Tony
          Li
          Exactly.
          Tony Przygienda
          that's why the greedy PSNP basically works
          albeit the ramp up suggested here is somewhat better since it protects
          receiver
          so this TX watching for retx/loss and backing off and ramping
          up PNSP @ receiver is gold locks IMO
          no need for any fast signalling,
          the protocol pacing basically drives max. hysteresis and both the TXer
          and the RXer can clamp down the hysterisis
          Tony Li
          Our data doesn't
          support that. All it says is that faster PSNP is a requirement.
          Henk
          Smit
          Sure. Another rule-of-thumb would be: psnp-interval should be
          (much) lower than rxmit-interval. I just wonder if that was the case
          here.
          Tony Li
          It wasn't. The point is that a PSNP of about 15 entries
          is near optimal.
          Henk Smit
          OK. Good to know that number. I'm just
          wondering why it is 15 ...
          Tony Li
          It's a balance between excessive
          overhead and acking before the transmitter gets bored.
          Tony Przygienda
          this will be implementation dependent, link etc anyway ... if both sides
          adjust they'll find the optimal point, that's the point of dynamic system
          hysterisis
          Tony Li
          It's not clear that we need sophisticated.
          The data
          shows that performance is good as long as you don't wait to 90.
          Tony
          Przygienda
          well, you break the spec on PSNP side as you suggest (and
          I always did ;-) and TX otherwise you won't speed up
          how sophisticated
          you want to make it is kind of implementation technique IMO
          Tony Li
          The
          question is what do we write down.
          Tony Przygienda
          well, as usual it's
          dangerous to write implementation guidelines as Yakov always warned ;-)
          I like hysteresis since that will amount for weird things like losses
          due to link error, buffer overruns and so on but it's surely more complex
          than saying "just send TX as fast you want and send PSNP _fast_" ;-)
          Jeffrey Haas
          These days I'm fond of "implementation considerations". If
          you don't have great flow control, drop rate, and queue behaviors in
          reactions to bursty traffic are things to watch for.
          If you had a nice
          mechanism to communicate the sustainable xmit cadence, that'd help a
          ton
          Tony Przygienda
          back pressure signalling is always difficult/slow
          and surprising ;-) And we don't have _fast signalling_ into link-state
          seems to me personally like an overkill. but that's just me ;-)
          in rift
          doing weird stuff (well, HW did it for me unintentionally) I found that
          putting SeqNr on packets & seeing losses of eg. a PSNP packet and backing
          off very aggressively improves the RTX rate in overlaod/problems. But we
          don't have that on ISIS formats so that's it
          Jeffrey Haas
          how fast you
          tune the too hot/too cold on your faucet is certainly a problem. better
          to find a warm enough and leave it alone for a while
          Tony Li
          Thus 15.
          Tony Przygienda
          that's just hysteresis parameters and matter of taste,
          you want fast ramp-up, fast slow-down and so on
          and 15 may be a great
          number or may not depending on how fast the TX go/link and so on but it
          may be the simplest recommendation
          Jeffrey Haas
          for obvious reasons,
          I see this as akin to bfd session tuning
          Tony Przygienda
          same thing
          really
          Tony Li
          It's a control loop.
          Tony Przygienda
          yep ;-) wonderful
          if you can make 30 years career aspect of a single concept you study
          in dynamic control theory 101 ;-)
          Tony Li
          Re: TTZ -- I'm still open to
          collaborating, but it MUST be in public and NOT on a design team. Legal
          stuff.
          Les Ginsberg
          But is there a need to introduce "zone". Can't we
          do whatever is needed using areas?
          Tony Li
          I think so, but...
          Robert
          Raszuk
          Well BGP is not a dump track ...
          truck
          John Scudder
          aaaand this
          is why I'm not in the "virtual is the solution to everything" camp
          Tony Li
          Ayup
          Christian Hopps
          +1
          Henk Smit
          Solution for all these
          disconnect problems: someone should build a better Internet ....
          :)
          
          Aijun Wang
          Can we discuss this on the maillist? there still exists
          noise.
          John Scudder
          Plus we're over time anyway.
          
          



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