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

Rtgwg Status Pages

Routing Area Working Group (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2004-Feb-19 —  
Chairs
 
 


IETF-109 rtgwg minutes

Session 2020-11-17 1200-1400: Room 6 - rtgwg chatroom
Session 2020-11-18 1430-1530: Room 6 - rtgwg chatroom

Minutes

minutes-109-rtgwg-00 minutes



          IETF 109 RTGWG
          
          Chairs:   Chris Bowers
                    Jeff Tantsura
          Secretary: Yingzhen Qu
          
          Date: Tuesday, 17 Nov 2020
          Time: 12:00 – 14:00 ICT
          Meetecho:
          https://meetings.conf.meetecho.com/ietf109/?group=rtgwg&short=&item=1
          
          
          1   12:00   10m Administrivia and WG update             Jeff/Chris
          
          Stephane:     Regarding the ti-lfa draft, we have reduced the number of
                        authors to be compliant with IETF rules, I think it is
                        ready for WG LC. can we add it to the LC queue?
          Jeff:         we'll handle your request and review your update.
          
          
          2   12:10   15m Multilevel configuration
          https://datatracker.ietf.org/doc/draft-bogdanovic-multilevel-configuration/
          Dean Bogdanvoic
          
          Tony Li:      how do you see it with the hierarchical architecture in
                        NETCONF or openconfig?
          Dean:         This is the area that requires lots of work. I don't have
                        a good answer yet.
          Jeff:         This is a large topic, and it's going to affect the models
                        that we've been working on for years.
          
          
          3   12:25   10m SRv6 Midpoint Protection
          https://datatracker.ietf.org/doc/draft-chen-rtgwg-srv6-midpoint-protection/
          Xuesong Geng
          
          Parag Kaneriya: how do you differentiate the condition the route is not
                        present vs. link down? IPv6 prefix not advertised, or not
                        link down?
          Xuesong:      on slide 2, there are three stages. when IGP is already
                        converged, and we can't find the route anymore, some
                        upstream nodes will do the proxy forwarding. If there is
                        no IGP convergence yet, node B, the adjacency of the
                        failed node will know that something wrong happened and
                        will do the proxy forwarding.
          Parag:        what about the function supposed to be executed at node E?
          Xuesong:      you mean the function should be limited to some nodes?
          Parag:        in SRv6, some function maybe executed at node E, maybe
                        accounting or rewrite?
          Xuesong:      so you're asking what if there are some functions ended
                        on node E. node B can only do the forwarding function.
          Parag:        can we use ti-lfa to avoid this situation?
          Xuesong:      there are cases discussed in the document about types of
                        B, we have different cases. There are different scenarios.
          Parag:        The idea would be to use backup path to reach E via ti-lfa.
          Xuesong:      actually it skipped failed node E.
          Jeff T:       we've not converging. you're asking to use ti-lfa. please
                        take your question to the list.
          Stewart:      So I'm afraid my question was very similar. When you set
                        up segment routing path you set that path up for a reason,
                        and that reason made me want traffic to go to a particular
                        node for a particular reason, or you want to protect other
                        paths from being overloaded by that traffic. So with all
                        repairs and alternatives, I get really worried that you're
                        going to bust all the original creating of the SR path.
                        And I would imagine the only node that could actually
                        reroute a path is the head end node, which has the whole
                        network at which it can to choose from, as opposed to a
                        node in the middle, which could be busting someone else's
                        SLA.
          xuesong:      Actually, I think that is a very good question. I can
                        respond to the question in two aspects. The first one is
                        that if some node, cannot be bypassed, We have some
                        mechanisms that are already being referenced in the
                        document. Maybe some node, like node E, it performs the
                        firewall to the whole path, so it can't be bypassed. We
                        can for example expand the IGP, and to advertise that I
                        cannot be bypassed so do not bypass me. This is the first
                        solution for that. And the second one is the motivation
                        for this solution is just to give a method to supplement
                        the ti-lfa mechanisms. Maybe something wrong happens in
                        the endpoint and we can have some methods to bypass the
                        failed node and to go to the next endpoint, at least the
                        packets will not be lost, and the the flow will not be
                        interrupted. So that is the motivation here. Okay. That
                        is my response so I think the mechanism itself is, is
                        reasonable and it can solve some problems here.
          Stewart:      Can we show you're not going to bust something else, then
                        fine but it's quite a complicated problem I already
                        mentioned, making sure you aren't going to bust so
                        carefully engineered traffic plan.
          Zhenbin Li:   To protect the function at E is a different scenario.
                        Second, the confusion is to mix with ti-lfa, this is for
                        SR traffic engineering, when E failed, we need B to proxy
                        forward the traffic. This can be explained in the mailing
                        list for details.
          Jeff T:       The motivation is not clear in the draft. It's difficult
                        to understand, so not good for WG adoption. I have a
                        question about experimental trucks. I mean you don't
                        define any new extension, you kind of define possible
                        behavior. So, probably informational would be better track
                        rather than experimental.
          Xuesong:      Actually there are some new behavior defined for repair
                        nodes. For example, to do the proxy forwarding we define
                        some SRv6 functions. So there will be some new functions
                        defined in this document.
          Jeff T:       I'm looking forward to reading new updated version of the
                        draft.
          Bruno:        it's about terminating a segment. let's have some
                        discussions in SPRING. We've discussed with Jeff, there
                        are multiple documents about terminating a TE or a tunnel,
                        and what do you do with a VPN etc.
          Jeff T:       please post your questions to the list.
          
          From chat:
          Ketan Talaulikar
          @ Parag - this proposal is somewhat similar to
          draft-ietf-spring-node-protection-for-sr-te-paths?
          @ Stewart - this was exactly the discussion that happened around the
          adoption of draft-ietf-spring-node-protection-for-sr-te-paths
          
          
          4   12:35   10m Egress Protection for Segment Routing Networks
          https://datatracker.ietf.org/doc/draft-hegde-rtgwg-egress-protection-sr-networks/
          Shraddha Hegde
          
          Stephane Litkowski: Could you elaborate more on how you are allocating
                        the service labels from the SID?
          Shraddha:     yes. that's right.
          Stephane:     so you can't make it work without repair label allocation.
          Shraddha:     that's too much overhead.
          Stephane:     you may want to clarify it in the draft.
          Shraddha:     yes, I'll.
          Peter:        So I have two comments here so first of all similar to
                        what Stephane was asking, I can see this working in a
                        preallocation. if we go to the very next hop becomes way
                        more complex to synchronize the sids or labels between
                        these especially if you have multiple PEs not just two
                        but even more. And the second question is, well, it looks
                        like more like a deployment. It's not really standardizing
                        any protocol extension, people always ask whether these
                        things should really be published as a draft. So, that's
                        my comment.
          Shraddha:     Yes, there are other solutions floating around. This is
                        one way to deploy it. we consider it as good informational
                        document. we got some feedback, allocating the labels
                        statically is a little complicated so we are also working
                        to see how we can automate that. And that will most likely
                        require protocol extensions.
          Peter:        Absolutely. That's definitely something to look at.
                        Because, as I said, it can become very complicated. Sounds
                        easy if you have two PEs and use the same label or sid.
                        If you do an allocation, other than third VRF, it can
                        really get more complicated
          Greg:         have you considered double failures?
          Shraddha:     So the multiple failures. there's always possibility that
                        traffic can get dropped or can undergo micro loops when
                        there are multiple failures that's applicable to ti-lfa in
                        general as well. And nothing special,  nothing different
                        for egress protection.
          Jeff T:       FRR never claims to protect double or triple failures,
                        it's a formal statement. Please send your question to the
                        list.
          Xuesong:      I have a concern about deployment complexity because the
                        request of static assignment of labels. The second is that
                        SRm6 is still under discussion for maybe not proper to
                        have a reference here.
          Jeff T:       points taken.
          
          
          5   12:45   15m Dynamic-Anycast in Compute First Networking use cases
          and Problem Statement
          https://datatracker.ietf.org/doc/draft-geng-rtgwg-cfn-dyncast-ps-usecase/
          Architecture of Dynamic-Anycast in Compute First Networking
          https://datatracker.ietf.org/doc/draft-li-rtgwg-cfn-dyncast-architecture/
          Yizhou Li
          
          Jeff T: we're not going to take questions here. Please send your questions
          to Yizhou.
          
          
          6   13:00   15m The Problem Statement for Precise Transport Networking
          https://datatracker.ietf.org/doc/draft-xiong-rtgwg-precise-tn-problem-statement/
          The Requirements for Precise Transport Networking
          https://datatracker.ietf.org/doc/draft-xiong-rtgwg-precise-tn-requirements/
          Daniel Huang
          
          
          7   13:15   15m BFD for Multi-point Networks and VRRP Use Case
          https://datatracker.ietf.org/doc/draft-mirsky-bfd-p2mp-vrrp-use-case/
          BFD on Multi-Chassis Link Aggregation Group (MC-LAG) Interfaces
          https://datatracker.ietf.org/doc/draft-mtm-rtgwg-bfd-mc-lag/
          Greg Mirsky
          
          
          
          8   13:30   20m Extension of Transport Aware Mobility in Data Network
          https://datatracker.ietf.org/doc/draft-mcd-rtgwg-extension-tn-aware-mobility/
          Kausik Majumdar
          
          Dhruv Dhoday: we were discussing this on chat. Flow spec would be a much
                        better choice, it will provide you much more granularity
                        for steering and we already have a mechanism both in BGP
                        and PCEP to do generic flow specification so why did you
                        not use that and instead define a new 5g metadata sub-TLV?
          Kausik:       you mean like BGP SR policy case?
          Dhruv:        in BGP and PCEP, we have a flow specification, where you
                        can have more granularity control of defining, which flows
                        needs to flow in SR policy or even in any PCEP base
                        tunnel. So we have much better techniques, in my opinion.
                        Were you aware of that?
          Kausik:       I'm aware of flow-spec. This is a generic approach. There
                        is already SAFI session, and we need the metadata. Either
                        do it with a SAFI session or flow spec, I don't see huge
                        advantages. But we can discuss more.
          Dhruv:        let's take this offline.
          Uma:          flowspec can be used, definitely, that will give much more
                        granular specification at the UPF and PE combined scenario,
                        but the here the case is the granular is not required,
                        rather than he wants to maintain end to end SLA. The
                        mobility domain and internet domain, if you want security
                        or one of their 30 characteristics, you want to maintain
                        that, and they want to maintain the same characters, that's
                        used in the mobile domain which is the resource based.
                        So yeah, you can use both ways, actually, to me.
          Jeff T:       so you're limited by UDP space, why don't we look up tid
                        so GTP header next, it will give you a much better context.
          Uma:          This is discussed in the DMM draft. I think the problem is
                        tid is a scalar. It doesn't represent the properties we
                        are seeking and that it is more loaded with 5g control
                        plane characteristics so we don't want to touch that, so
                        that's the reason. We had a calculation of how many slices
                        can be done in a typical network, that's in the DMM draft.
                        We found out for most practical deployments the UDP source
                        port ranges are good enough. The problem is we are limited
                        by what you can put in the packet, so we don't want to
                        enhance too many things in the data planes so that's why
                        we are limited with that UDP source port. it's kind of
                        middle ground approach we took.
          
          From chat:
          Dhruv Dhody
          Cant this be done by flowspec?
          
          Stephane Litkowski
          Right, this is also my question :) Flowspec will also provide the full
          granularity for steering
          
          Jeffrey Haas
          Flowspec is usually implemented as a firewall rather than destination
          based lookups. Different hardware paths.
          Regardless of whether you're looking at encoding stuff fancier than just
          destination based in flowspec or tunnel encaps, that's the penalty you
          pay.
          
          Tony Przygienda
          no free lunch. more complex lookup, more gates, more energy, will cost
          more. as a side note, isn't that what we have flow-id in v6 for?
          
          
          
          
          Date: Wednesday, 18 Nov 2020
          Time: 14:30– 15:30 ICT
          Meetecho:
          https://meetings.conf.meetecho.com/ietf109/?group=rtgwg&short=&item=2
          
          
          0   14:30   5m  Administrivia           Jeff/Chris
          
          1   14:35     10m   Protocol Assisted Protocol (PAP)
          https://datatracker.ietf.org/doc/draft-li-rtgwg-protocol-assisted-protocol/
          Shuanglong Chen
          
          Xiang Ji:     first question, how do we address IP path to run this
                        protocol? second question, for performance, instead of
                        TCP or UDP, have you considered SCTP?
          Zhenbin:      The first one depends on configuration, the reachability
                        is dependent on the forwarding table. For the 2nd, we only
                        considered TCP and UDP, we will consider your suggestion.
          Randy Bush:   I like the separation. I think it's architectural
                        reasonable, but not MD5, pick something from this
                        millennium.
          Zhenbin:      we will consider more options.
          Jeff T:       I would really advise the authors to articulate who is
                        the end consumer of the data, because networking devices
                        don't usually do anything with kind of information. So,
                        if the consumer of the data is NMS, the real question
                        would be why not use south north communication we already
                        have, such as gRPC. I'd really like to see better
                        justification of doing it horizontally rather than
                        vertically. And hopefully on the list.
          Zhenbin:      Thanks for your comments. We talked about the reason
                        to introduce west-east network monitoring. This should be
                        a light protocol,
          Randy Bush:   back to the discussion IDR, protocol has to have this
                        extract mechanism. That's what I meant when I said I kind
                        of like it architecturally.
          
          
          2   14:45   20m GRASP
          https://datatracker.ietf.org/doc/draft-ietf-anima-grasp/
          Toerless Eckert
          
          zhenbin:      Thank you for the information. This is a very valuable
                        reference for PAP. My understanding is that GRASP is based
                        on TCP, and I have a concern about resource consumption.
                        if PAP is used to locate BGP errors, we may need full
                        meshed TCP sessions, it's very challenging. Full mesh BGP
                        peers is already a challenge for operators, and PAP is
                        only for network monitoring, that's my concern.
          Toerless:     GRASP doesn't really specify the underlying protocol, it
                        can be used in TLS, QUIC, any secure transport protocols
                        and standardized in IETF. You can also use UDP or TCP,
                        just you have to consider security mechanisms.
          Brian Carpenter: The prototype code was done by me, it's not production
                        code. I looked in TCP or TLS at the moment. but I looked
                        at what would be involved in switching to UDP, the
                        messages of course could possibly well be wrapped up in
                        UDP packets and said, but my impression was that the
                        overhead that TCP allegedly adds, I would have to add
                        back into code, just to make sure that UDP messages are
                        delivered to the right. And you would also have to put in
                        more recovery logic, because UDP doesn't do it for you.
                        So, I'm not convinced that there's an efficiency argument
                        against using a transparent layer.
          Toerless:     Through the years and Anima we've seen a lot of opinions
                        about transport layer so I think that the prudent thing is
                        obviously to define the Message Protocol, independent of
                        the transport and the security as we've done in grasp and
                        then basically let the chips, or IETF, or whatever the
                        wisdom is. so I think if we had for example more IoT
                        people in here, they would come and say that some even
                        lower overhead on things that are based on UDP is really
                        crucial for very low end devices. That's why they did
                        COAB avoid TCP, and that's based on UDP, so I don't think
                        there is an industry wide common understanding of what the
                        best transport is. And that's why we did GRASP the way we
                        did it.
          Zhenbin:      Thanks for the information. We'll consider using GRASP
                        for PAP.
          Toerless:     I'd like you guys provide some detail examples, such as
                        BGP, for automation. With ANIMA, we have security
                        mechanisms, and we'd be happy to build those examples. If
                        we have this framework, we'd be happy to have routing
                        people using it.
          Zhenbin:      Happy to do it.
          Chris:        there seemed like a pretty good way to bootstrap the sort
                        of the use cases. We could spend a year or two discussing
                        things for PAP, but instead it makes sense to try these
                        use cases in the existing coding. It seems like you would
                        get a lot of benefit from a reliable transport. To begin
                        with, you wouldn't have to worry about a lot of protocol
                        stuff if you could just be sure that messages were getting
                        received. That would be a pretty good way to to get this
                        moving a lot faster with solid convincing use cases.
          Toerless:     I can't remember there was this one effort to try to unify
                        and build better common security for the different routing
                        protocols, and I think that ended in pretty much nothing.
                        If people also think that the securing of the routing
                        protocol is still something that the industry struggles
                        with, with that, beside the other operational examples
                        given in the PAP draft i think the securing might be
                        something that could be most easily done upfront.
          Jeff T:       Thanks Toerless for the presentation. Looking forward to
                        more collaborations.
          
          
          3   15:05   20m xBGP: When You Can't Wait for the IETF and Vendors
          https://dl.acm.org/doi/10.1145/3422604.3425952
          https://pluginized-protocols.org/
          Olivier Bonaventure
          
          Jeff Haas:    The nice thing that is an output of this presentation is
                        that, yes, plugins can be done for allowing code to be
                        hooked externally, you know the Linux kernel is an
                        excellent example of that. The challenge I think that's
                        not really covered in the paper, or at least the
                        presentation here of the paper is most of the headache
                        for BGP is really incremental deployment issues. So
                        writing code isn't all that bad. Getting code that can
                        run in implementations they're scattered around the
                        internet and follow BGP rules in terms of validation and
                        such. That's the main challenge. So they pay I agree that
                        having plugin frameworks is actually a very useful thing.
                        But I think that's not necessarily the hard problem here.
          Olivier:      But I think there are benefits in being able to deploy
                        extension inside an AS, so for ibgp only. So doing it over
                        external BGP is much more difficult, but for ibgp I think
                        it makes sense and it could address some use cases for
                        network operators that have specific requirements. And it
                        could it could also allow network operators or network
                        designers to develop new extensions, before they are being
                        discussed within the IETF. And so you could get
                        information, prototype, running code that could be
                        discussed within the IETF without having to change complex
                        implementations and to do a full implementation.
          Jeff Haas:    Understood. I'll leave my comments with I agree with you
                        that doing this is not hard. In that, if you contain, so
                        I'd call it the blast radius of this problem to something
                        that's strictly internal, you're right that this is not
                        too much of a problem, but the blast radius is really the
                        discussion that's the difficult one for incremental
                        deployment. It's very common for features in development
                        to have unfortunate side effects, far away from where
                        they're at. I will cite the attribute 128 issue that many
                        people are familiar with. As an example of a feature that
                        had two different versions that caused a large network
                        outages. My suggestion is perhaps part of the conversation
                        if you're going to talk at least about BGP is whether or
                        not, BGP should be basically leveraged to side protocol
                        for different purposes, separate the inter domain case
                        from your local case. That's it. Thank you.
          Jared Mauch:  I think this is interesting, but I have a lot of concerns
                        here specifically around deployability and usability
                        testing. So, if we were to do this, similar to what Jeff
                        was talking about with attribute 128 issue of which I'm
                        still trying to get the config out of our many network
                        devices, we have a variety of code bases that we still
                        run. I'm concerned about what happens when we deployed
                        these plugins and they have different results across
                        different vendors and how that kind of bug ecosystem
                        interacts because it's one thing to specify a protocol
                        and a method for transporting, but it's a whole another
                        thing to discuss what that operational impact is, and I
                        think similar to what Jeff commented about about the
                        internal use cases versus external use cases. We have a
                        lot of internal use cases where we transport BGP data and
                        signal that around our internal infrastructure. And those
                        use cases tend to not really align with what shows up in
                        the public Internet. And a lot of what happens is people
                        have many more fine grained signaling that they want to
                        do for geo location. Then what you actually want to
                        announce in the routing table. As a result, so I'm very
                        concerned about something like this and what happens to
                        the operational use case, when we have a lot better things
                        like if we want to signal to feed data or something there
                        is the geo RFC that was recently published. There was
                        discussion last week about how to actually go and
                        potentially authenticating sign that data to provide more
                        granular information than what you actually want to
                        publicly expose in BGP. there's definitely an interesting
                        idea but I really fear the unintended side effects that
                        this is going to introduce instability that'll create as
                        a result.
          Olivier:      there are two different parts of the presentation and
                        there are two different elements. So the first one is the
                        ability to consider a routing protocol a kind of
                        microkernel operating system that exposes an API and that
                        allows you to extend it. And this is generic, and although
                        we implemented in BGP because it was easy for us to extend
                        BGP and to do test with BGP. We believe that it can apply
                        to any routing protocol and that's why we discuss with
                        Jeff to present that here because this is an idea that is
                        generic and it would be applicable to any routing protocol
                        I agree with you that doing that over external BGP session
                        and over the pubic internet is something that would be
                        dangerous, and that would need to take much more care to
                        be able to do that. This is a research prototype which is
                        intended to show that you can extend a routing protocol,
                        you can view the routing protocol as a different way. And
                        for the BGP extensions and for the BGP use case, we are
                        focused on internal BGP issues we don't consider external
                        BGP as a possible solution right now.
          Rudiger Volk: I love this view and way of taking up the definition of
                        manipulation. When you provide agile to complexes you
                        introduce fragility and you need to control very
                        carefully. I see Jeff's points, however I note that we
                        usually industrial production is a system we already some
                        control points. In BGP, that's quite clear the policy
                        definitions are available to operators. My previous on
                        policy configurations did show me that evolving the
                        definitions of policy in a network is something exactly
                        points to the control problem that Jeff was mentioning.
                        BTW, this is about communities being used in Internet. I
                        see an opening with your approach to actually allow users
                        to do much nicer and better controlled stuff for extending
                        functionality far beyond what's been done so far with
                        policy language. Great power comes with great
                        responsibility, it should not be abused. Nevertheless the
                        agility is much needed.
          Olivier:      let me try to to answer a bit some of your concerns. So
                        you mentioned that operators do a lot of with BGP
                        communities to implement the policies. And basically the
                        BGP communities is an ad hoc solution so you have to play
                        with route filters which acts with access lists which with
                        maps and stuff like that, to be able to implement the
                        policies that operators wants. On the other side, by using
                        xBGP what you have is that you have standard programming
                        language in our prototype but this could be another
                        language. And when you have standard programming language
                        it's also possible to use software validation techniques
                        where you can specify the properties that the plugin is to
                        be able to support, to be able to be acceptable by a
                        router. So as you see we don't want a plugin that runs
                        forever, but we can have properties that are defined
                        formally, and we can design tools, based on the progress
                        in software verification that will verify that the plugin
                        is working, is behaving correctly according to the
                        appropriate properties of the underlying BGP. So that's
                        something that you can do if you have a much more
                        expressive language, then match the access list, route
                        maps that we have today. And we can leverage lots of
                        advances in software verification in the last year to
                        verify that.
          Eduard V:     Thanks for your presentation. I have one concern, by
                        itself is a good idea, but unfortunately from a generic
                        term world wide multi vendor interoperability is more
                        important, could not be a trade off instead of multi
                        vendor interoperability. The API should be exactly the
                        same for all implementations, on the previous slide if
                        you've seen that prototype implementation, in one case
                        you have 400 API calls and the other 600 API calls, this
                        is a very typical alarm. Big alarm because it looks like
                        you don't have mature stable API, which you could really
                        demand from all vendors, and it means there will be no
                        multi vendor interoperability. This particular effort will
                        not be accepted by the market. Therefore, from my point
                        of view, you could mitigate if multi vendor review your
                        problem. If you will clearly specify and make it mandatory
                        some basic feature or basic API calls, but you shouldn't
                        be very rigid for API, which should be in a mandatory.
                        Then it's potentially possible to progress.
          Olivier:      So just to answer your comments. We have a very simple
                        API, which is available on the website, that they can
                        provide the slide that Jeff shows here, shows the number
                        of lines of code that we have to change to be able to
                        implement the API. So this is not the number of API. So we
                        have about 10, different functions in the API so the API
                        is very simple. And the slide shows only the number of
                        lines of code that we had to change in the BGP
                        implementation to be able to support the API, which means
                        that in fact, the API was already part of the interworking
                        and build implementation and we did not have to change
                        that much to be able to support the, the abstract API
                        that I mentioned earlier with a workflow.
          Jeff T:       Thank you Olivier for the presentation. I'm looking
                        forward to hosting you anytime. Thanks you everyone for
                        joining us tonight.
          
          
          
          
          
          Some chat history:
          Eduard V
          AMINA presentation is very good - easy to understand even for new
          people. Thanks to Toerless.
          
          John Scudder
          There are some liabilities with reliable transports, but the benefits
          usually vastly outweigh them.
          
          Brian Carpenter
          https://github.com/becarpenter/graspy for the code etc
          
          Jeffrey Haas
          audio not working
          the effort was called karp
          
          John Scudder
          ^ routing protocol security, that is
          
          Jeffrey Haas
          the issue with karp was bootstrapping often required getting components
          of ip working before you could get the job of security or routing done.
          
          Joel Halpern
          Arguably, the issue with karp was that folks did not see enough return
          (value) for the effort. So they stopped.
          
          John Scudder
          An interesting metric of protocol complexity. If we are to believe it,
          it's actually encouraging it only is increasing linearly.
          
          Jeffrey Haas
          karp had many issues. but it was helpful in highlighting the
          bootstrapping issues. :-)
          
          Joel Halpern
          I grant the bootstrap part was (and is) non-trivial. BRSKI has a lot of
          moving parts to get around that.
          
          Jeffrey Haas
          my point, joel.
          
          Brian Carpenter
          Yes. I waited so long for BRSKI that I added something called Quick And
          Dirty Security to the GRASP prototype.
          
          Jeffrey Haas
          Anyone care to start the betting pool for first outage from the plugins?
          RIPE had a record for a while on those for a bit
          
          Jared Mauch
          I had an unknown BGP attribute finder that I ran for awhile when there
          was the large round of leaks of them, around the timeframe that the 128
          attribute issue occurred. Getting code upgraded on devices always takes
          longer than expected.
          
          Jeffrey Haas
          new code, faster, more agile, is not the problem. not blowing up the
          internet is. :-)
          that said, standardizing ways to interact with bgp pipelines is good.
          
          Jared Mauch
          I would be interested in improving the way the specs are written and
          how you do the capability signaling, etc.. vs bgp4+++++++++++++ but the
          path to transition would be difficult.
          
          Tony Li
          There are enough open source implementations so that if someone wants
          to blow up BGP, they don't need plugins.
          
          Jeffrey Haas
          The fun of plugins is that eventually you have same issue as things
          like linux kernel extnsions: overlaps, ordering issues, etc.
          
          John Scudder
          quite. security through obscurity (or through gatekeepers) is a
          non-starter. Nonetheless https://i.imgur.com/joMRjHj.jpg
          
          Jared Mauch
          considering how we moved away from plugins in web browsers, etc.. i'm
          similarly concerned about going down that path in routing protocols.
          
          Martin Horneffer
          Tony: which work well enough for academia?
          
          Jared Mauch
          and that's before the security/attack profile
          
          Tony Li
          Martin: my sense of the bar for academia is very, very low.
          
          Jeff Tantsura
          within right boundaries some fo this can be done, offloading best path
          to a custom algo was unthinkable just a few years ago
          
          



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