IETF-57 RTG area meeting minutes

[Alex Zinin <[e-mail]>]

Thanks to Ross and Dimitri, minutes from the meeting below.
Folks who were at the meeting--please review and let me
know if something is so inaccurate it should be fixed.

--
Alex


Announcements (Bill Fenner)

        - RIP working group is finished and will be ended
        - There is a routing area website: www.rtg.ietf.org 
        - THere is a routing area mailing list: [e-mail] 

Working Group Reports

IDR status  (Sue Hares)
        - are in a holding patter until base spec is complete (are on -21)
        - see agenda for IDR working group

IS-IS
        - no report

Manet (Alex)
        - four protocol specification are going to experimental status 
                AODV was published as RFC 3561
                others in progress (one recently reviewed)      
                Implementation is in progress

Multicast Last Mile BOF
        - no report

OSPF Status 
        - two RFCs (NSSA 3101; 3509)
        - five documents in working group last call or beyond
                - OSPF V2 TE is through to the RFC editors
                - BCP prioritization fo OSFP packets
                - refresh reduction in stable topologies
        - two mibs and v3 and authentication for V3 need more work
        - two new documents are just starting at this IETF

MSDP
        - document done
        - MIB almost done

PIM
        - three major drafts in progress
        - they have been pretty stable for a while
        - trying to arrange appropriate reviewers

RPSec 
        - didn't meet

SSM 
        - didn't meet at this IETF

UDLR    - no meeting (but status report)

        - 30 June, submitted revised version
        - Major changes from v00.txt (now v01.txt)
          . write PPPoE experiment
          . wrire PIM-SM and MSDP experiment
          . add NAT
        - IPv6 over UDLR
          . no exp i-d
          . 18 june, start discussion on mailing list
          . if there is common interest make a draft charter an propose to AD's

VRRP
        - Radia Perlman is now co-chair of the group
        - security has been removed from VRRP after considerable discussion
        - v2 and v3 drafts have been updated. V2 is ready for WG last cann as
          draft standard. VRRPv3 MIB has just been submitted to the working
          group, and needs review. 

UDLR
        - no report

IP Forwarding MIB (Brian)

a while ago updated MIB support for IPv6 requested. Most of these are
in last call in the IPv6 working group. A request: Why not fix other
stuff, such as making it easier to support in today's forwarding
engines? This work is starting now that the IPv6 is stable. Question
to people designing forwarding engines: Is the current IP Forwarding
MIB that is currently defined for IPv4 useful at all? If not, should
we fix it now. Send opinions to Bill Fenner of the routing area
mailing list.

Panel: Routing Protocol Overload
        Panelists: 
                Dave Meyer      
                Pedro Marques
                Ron Bonica
                Gargi Nalawade
                
Introduction by Alex: 

Why are we here: Community is polarized over use of routing protocols
for uses which go somewhat beyond the narrow definition of routing
(particularly wrt BGP). Alex would like to see the community talk.
Alex characterized the two viewpoints as:

        Camp 1:
        - MP-BGP framework is a useful tool to distribute info among INET routers
        - Fair treatment of different AFI/SAFI’s is an implementation problem
        - We know how to do this, leave this to us
        Camp 2:
        - This is dangerous. Risks the Internet. Any instability or code complexity 
          caused by one use of BGP could destabilize the main purpose, which is 
          Internet inter-domain routing. 

Alex would like us to walk out of this room with some understanding of
where we are going. He would like us to find a common ground. Please
respect other points of view. Please don't bring personality issues to
the discussion. Don't just state your opinion, but instead explain the
reason for the opinion.

Panelists present their opinion:

Dave Meyer:
        - Musings on NLRI loading, stability, and signaling in the Internet
        - It is hard to get hard evidence on what we ought to do. Maybe we need
          a study on the topic. 
        - BGP and maybe IGPs can form an effective transport
          for new features. 
        - BGP is also used in the Internet
        - BGP in the Internet can have stability issues in some cases.
        - It seems reasonable to ask what effect loading BGP with other information
          will have on routing stability.
        - Dave can't quantify anything about the stability. Dave has talked to a lot 
          of people.
          Plusses: Operational simplification; Code Re-Use; BGP code will be 
          carefully optimized.
        - Operational complexity: Worry about breaking one thing when doing 
          something else. Single point of failure. Internal queue management 
          needed. 
        - Much of this is conjecture. 
        - What if we wanted to start from scratch: Would we want a generalized
          feature transport Mechanism? If so, is BGP this mechanism? As an example
          MSDP ended up looking a lot like BGP. 
        - Proposal: create problem statement. Draft Requirements, framework and
          architecture. Perhaps we should present a problem statement at the next IETF. 
Ron Bonica
        - Defining the scope of BGP
        - Background on the problem: Routers support many applications which require
          the synchronization of databases on multiple routers. 
        - BGP could support all of these applications. 
        - Ron echoed concerns that he has heard: Will BGP get buggy as we make it 
          more complex? Is there a possibility of mis-configuration: As functionality 
          increases, will information be leaked incorrectly between service providers, 
          and possibly be mis-interpreted? 
        - Mitigations for these concerns are available: BGP software is already fairly
          modular. Data transfer is separate from other functions. This implies that as
          we add more to BGP, we add new modules. Controls exist to protect against 
          mis-configuration.
        - Big Bug issue: What if something really bad happens?
        - BGP incomprehensibility: What if it gets too big for a human to understand?
        - Perhaps we should document BGP as a number of separate modules. 
        - Options
                - restrict BGP to main use, and clone it for other reasons
                - abstract data transfer from other parts
                - let BGP grow
        - None of these solutions are necessarily right. 
                - if clone, end up fixing same bugs in multiple code bases and updating 
                  code multiple times
        - We are on shaky ground in taking on this issue. Most of this discussion is about 
          software engineering. The IETF doesn't normally do software engineering. 
        - Proposal: That we listen to vendors and operators. Study the issue. 

Pedro Marques:
        - (Mostly agree with Dave. This is an issue to study)
        - Look at this from the point of view of System Availability in 
          Multiservice Networks
        - What is router availability?
        - What does it depend upon?
        - Is there is an impact on deploying a new service in the router? Yes.
        - Don't just look at one component of this. Look at overall system and
          network availability. The resource sharing issue surfaces whenever you
          introduce a new service on the router. However, resource sharing is also
          an issue when you have only IP Internet service (eg, sharing between BGP
          and an IGP; sharing between multiple BGP neighbors, so that one neighbor
          doesn't seriously impact another). 
        - System availability is a system design issue. There are significant software
          engineering aspects of this. System availability is generally improved by 
          maximizing code re-use. This leads to fewer defects. 
        - The most problematic issue is internal infrastucture changes (internal to the
          router). This is independent of the protocol issue, and independent of anything
          that we do in the IETF. 
        - If a given problem requires point to multipoint distribution of information, 
          then re-use of BGP is more cost-effective than inventing a new solution. 
        - Summary: Resource sharing is always an issue. This is not limited to multi-
          service issues. There are serious issues here, but these are primarily software
          engineering issues and therefore outside of the scope of the IETF. 

Gargi Nalawade
        - Consider "Routing Protocol Overhead". 
        - What is BGP: A routing protocol, or a database distribution protocol? 
        - If it is a routing protocol, should it be doing database distribution?
        - If it is a database distribution protocol, should it be doing routing?
        - BGP definitely does routing. If it does both, what % of its task should
          be doing routing? 
        - Question is not whether BGP can do this, of course it can. But the 
          question is whether BGP should do this. 
        - Routing related information which is closely tied to BGP must be
          carried in BGP. 
        - What's the solution: Identify the problem. What is routing related?
          Then we can talk about solutions. 
        - This is not just a BGP issue. IGPs carry opaque LSAs and/or 
          extensible TLV. Why have a BGP-specific solution.
        - She agreed with Pedro that cloning is bad for the health. 

Open Discussion:
        - Yakov: Gargi's comment that she doesn't want BGP to carry Shakespeare is
          not relevant to the discussion. The decision should be based on a cost/benefit 
          analysis, not on what she wants. 
        - Mark Handley: We might want to distinguish Protocol implementation 
          overloading, versus protocol instance overloading, versus protocol design 
          overloading. Instance is most important. We are talking about fate sharing; 
          If you have two services sharing the same protocol, then they share the same
          fate. If two services need to be coupled then fine, but otherwise don't put 
          them in the same protocol instance. Congestion control sharing is also 
          potentially an issue. Example from different world (SIP): SIP was designed to 
          operate over <didn't hear>. Then SIP got instant messaging added to it, then 
          it was realized that instant messaging included video, this was too much, 
          then they fixed it by removing some features and handling them otherwise. 
        - Chandra (from cisco): The concerns that people have expressed are not clearly
          articulated. Are we talking about overloading the protocol, versus the 
          implementation, versus a protocol instance? These are not the same, and 
          he doesn't know which one is the concern. Is this an issue of configuration 
          modules, or software implementation? If this is a configuration issue, then 
          you can fix this as a configuration issue and not as a protocol design issue. 
        - Dave Meyer wants to understand whether putting more into BGP effects
          global Internet stability. 
        - Rahib: What if any impact will this have on the scalability of the routing 
          protocol? 
        - Rob (Austein): Has spent time with DNS. When you keep adding features
          to a protocol, pay attention to who gets benefits and who suffers the pain. 
        - Kurt (Lindqvist) We are getting lazy: We are trying to make it easy by using
          the same protocol over and over. The threshold for adding things to the 
          protocol is too low. Where does this end? 
        - Kireeti: Don't ask if you are overloading the protocol or system. Ask about
          multiservice platforms: Is this a good idea? The resource contention comes
          from having multiple services on the same physical platform. Do we want a 
          box doing IP, and a different box doing L2VPNs,  and a different box doing
          L3 VPNs, etc.. The issue is whether we put these in one box or in multiple 
          boxes. If the box falls over, then you have taken down whatever is on the 
          box. Putting multiple services on the same box will have an impact, and 
          therefore require careful implementation. Whether you put them in the same 
          protocol is at the most a second order issue. It is normal for reachability 
          information and routing information to be in a routing protocol: An IP VPN
          prefix is reachability information. A layer 2 prefix is reachability information. 

        - Ross Callon: Some have talked about software engineering, others have 
          expressed concerns about internet stability and a few said "I don't care about 
          software engineering, I care about Internet stability". We need to understand
          that software engineering is a major impact on Internet stability, and thus the 
          people who are talking about software engineering are talking about internet 
          stability, and are trying to address what is the most critical part of Internet 
          stability. Using the same protocol does not preclude a careful partitioning of 
          resources within a device, nor does it preclude using separate TCP connections. 
          Using a different protocol does not guarantee using different resources: If 
          multiple services are in the same physical device, at some level there will be 
          some sharing of resources. Therefore the primary issue is not the protocol. The 
          primary issue is the services on the box, and how much information needs to be 
          exchanged between the boxes. Adding new services to the box requires new 
          information. This will have some impact. Ross has heard comments from 
          multiple service providers that they don't want ten different types of boxes in 
          their network, so they want multi-service devies.  The issue is then how best to 
          provide this.  

        - Someone from UUnet/MCI: BGP and IS-IS are sort of bread and butter for us. 
          They want these protocols to be solid. At one point when IPPPN got added to 
          code base, it caused a major outage to their network, even though they didn't 
          use it. This is because it impacted the software on their machines in a negative 
          way. Once you put a new feature into the box, particularly into the same 
          protocol, will this cause a problem - possibly even if they don't use the feature? 
          They run the same code in the core as in the edge, even though they don't 
          need the same features in the core. They can turn off a protocol, if things are in
          a separate protocol. Reply: You can turn off the address family.
        - Hamid (I think that this was Hamid Ould-Brahim): Before a routing protocol 
          becomes a protocol, there is a set of problems that the working group looks at. 
          If a different working group faces the same problems, then they tend to select 
          the same solutions. He doesn't see a problem here. In many cases when 
          distributing other sorts of information, you end up facing the same problems. 
          Thus you may use the same solutions, such as using route reflectors. Thus you 
          can gain from experience. This is a natural way of  solving problems.

        - Lixia Zhang: Good software engineering can reduce the number of bugs. 
          However, the number of bugs will grow faster than linearly. More modular 
          code will help. We are not just here to build protocols.

        - Pekka Savola: Do we want multiple services or not: In their network, then 
          definitely don't want them. Pedro: No vendor will build a product for a 
          single company, or even for a limited market segment. Enterprise features,
          X.25 tunneling features will get added. There is the potential for impact.
          How do we design things in the most reasonable way to minimize the 
          amount of new code which is needed to provide a certain set of functions. 
          If you have one problem then if you re-invent the wheel. 

        - marlove(?): He is only three years out of college, and remembers his 
          software engineer course: But I didn't get his point. 

        - Gargi: Whether or not it is a new protocol there may be some code
          re-usability. 

        - Luyuan Fang: I agree that there are two problems: Code and mis-configuration. 
          Our configuration of BGP for Internet routing,  and our configuration of VPN 
          services are separate. Thus having the same protocol does not require having a 
          single configuration tool. Are we talking about multiple services on one box, or
          a single service per box? They are putting multiple services on one box. They 
          are going to consolidate even more. A University network might not need as 
          many services. As a large service provider, they can't afford to put ten different 
          boxes into their network to support ten different services. Luyuan feels we 
          should eave it up to the vendor to determine the best way to make this reliable 
          and robust. We can't stop progress, we need to standardize how to offer the 
          multiple services on one box. It doesn't matter to them whether it is one 
          protocol or multiple protocols.

        - Alex: in the life of a protocol, there will be times when you need to think 
          carefully about whether or not you want to extend the protocol further, or
          start new protocols.

        - Curt: We have enough to do operationally just to get packets forwarded. I 
          am not so worried about adding more lines of code to the routers. I am more 
          worried about having that code executed. I want to know what I am running. 
          When we got the problem with BGP: We had the VPN code in the BGP. 
          We got the problem because the code was delivered in the software. It was
          a vendor coding thing, but this is going to happen. Different BGP 
          configuration has already been done with the consideration that BGP is 
          only doing IP routing. Other services might have a different characteristics
          in terms of how rapidly data is updated / exchanged, hold down timers, for
          example. 

        - Andrew(?): We need to separate concerns about bugs versus features. Bugs 
          do happen. Don't let one particular bug that occurred in one implementation 
          obscure the entire conversation. The code has to evolve. 

        - someone from DT (Rahul Volk?): Talking about design or architectural
          principles sometimes get into fuzzy areas. Since Roman time, we have 
          had divide and conquer as a principle. Using the protocol which is already
          there to improve TTM doesn't seem right. There is a tradeoff between 
          code reuse and speed of deployment, versus adapting the solution for
          problems that are not foreseen. 

        - Pedro: Someone made a comment before regarding who pays the cost
          of adding functions. No customer has ever said "do it perfectly, and we 
          will wait five years for it". If customers were to say this, we will respond
          to it. Cost and who are willing to pay matters. 

        - Alex: If we look ten years ahead, do we want a very large number of 
          attractive features implemented in BGP, or do we want something else.

        - Pedro: Ten years from now, there will be a protocol called BGP, which
          will have almost no resemblance to what is there today. Unicast routing
          will evolve over time. Technology goes in cycles. Today the stimulus
          is for VPNs. Next year it may be something else, and BGP will evolve
          to handle this. 

        - Gargi: We will always have short term requests. This should not preclude
          us from looking for a long term solution. Putting things into BGP might
          be the correct long term solution, but we should investigate whether this
          is the right thing to do. 

        - Ron: If we were doing BGP over again, we might want to design two
          protocols, a generic data transfer protocol, and a routing protocol which
          computes routes, and which uses the data exchange protocol to carry its 
          routing information. 

        - ?? (didn't get who): in the short term we have a set of vehicles and a 
          set of problems. 

        - Rahul Aggarwar: Three issues: (i) Protocol overload; (ii) implementation 
          complexity / software engineering; (iii) Deployment issues. How strongly
          coupled are the new features with the old features in BGP? Probably not
          very. If we put new information into BGP and carry it around, is this a
          problem.  

        - Bill Fenner: There has been a lot of work on the stability of routes in BGP
          and the stability of inter-domain routing. If you put more things over the 
          same protocol, are you violating the original assumptions. 

        - Gargi: Just because you use a new SAFI, there is still some impact on the 
          overall BGP. Existing SAFI's may be effected. 

        - Rahul reply: He is making a distinction between code changes and protocol
          procedures. 

        - Dino: MSDP: Why was this not in BGP: Multiple service providers said
          that they wanted it in BGP in order to make it easier to deploy. Dino had a 
          concern that it might evolve after deployment, and that this might have future
          impacts on BGP which we can't anticipate. Also, if it fails, then it is easier to
          remove if it fails. If you want things stable, you can't change it. Pedro 
          questioned whether this was an appropriate analogy. 

        - Yakov: If I follow your logic, then we should take multicast and IPv6 out
          of BGP, and have four protocols (unicast IPv4, multicast IPv4, unicast
          IPv6, and multicast IPv6):
        - Dino: It is a cost-benefit tradeoff. 

        - Yakov: We agree that it is a cost-benefit tradeoff. BGP was designed to 
          carry 1,000 routes. BGP was not designed to carry CIDR, nor IPv6. BGP 
          carries much more than this today. It has evolved over time to meet 
          new requirements. We have other precedents of putting multiple things into 
          one protocol: Two such precedents are IP and TCP. In order to decide what 
          should go into BGP and what should not go into BGP requires cost-benefit 
          analysis. If you want to add something which folds in well, you do so. If 
          you want something that requires very different procedures, then you use a
          new protocol. 

        - Vach: Cost benefit analysis is a way to consider alternatives (eg, use a 
          linked list or use a tree - this is a cost-benefit analysis). Using a flooding 
          protocol for information which doesn't need flooding is a good example
          of a bad tradeoff. 

        - Chandra: We know that BGP can be extended to have multiple sessions 
          (eg, per-SAFI). BGP can therefore become a session demultiplexer. I am
          getting the feeling after listening to this that some people feel they can
          drive protocol implementation architecture by driving one or multiple 
          protocols.

Panelist summaries:
        - Ron: software is about software extensibility and stability. These are 
          software engineering issues, and the IETF doesn't do software engineering.
           Others have pointed out that we want modularity but we can't force
          any particular software design by deciding what goes into what protocol.
          This implies that we have a really hard problem. 

        - Dave: Wants to talk more about protocol design and less about software
          design. There is a tradeoff between features and bugs. We can't get away
          from that. What is the effect on the Internet architecture.

        - Pedro: What are the concerns that people have? He would like to get the
          concerns enumerated so that the concerns can be understood.

        - Gargi: Has heard concerns from operators that they want the core Internet
          functionality to be solid, and not impacted by any additions. Whether 
          something belongs in BGP needs to be handled on a case by case basis. 
          Even though some things may look okay in BGP today, we also have to 
          pay attention to whether this will belong in BGP in the future. 

Questions from Alex:

  - How many ISPs ? ~ 10
  - Who thinks BGP overloading is not an issue ? ~ nobody
  - Who thinks BGP should not change at all ? ~ very few
  - Who believes we should pursue the direction of a new protocol
    potentially based on MP-BGP framework and used for  distribution of
    generic non-routing related info among the routers? ~ lot of support


_______________________________________________
routing-discussion mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/routing-discussion