Subject: RE: a problem statement (was: Extending BGP)

From: "Tony Li" <[email-masked]>
Date: Fri, 8 Aug 2003 01:10:39 -0700

Well said, here here!!!

Further, if an SP is going to make the commercial 
decision to support said services, whether or not they
are in BGP or some other protocol, they will still be part
of whatever implementation, sharing the same processor
and memory resources.  Just shifting the deck chairs doesn't
change the amount of wood on the deck.

Tony

|    -----Original Message-----
|    From: Pedro Roque Marques [mailto:[email-masked]] 
|    Sent: Friday, August 08, 2003 12:43 AM
|    To: Alex Zinin
|    Cc: [email-masked]
|    Subject: a problem statement (was: Extending BGP)
|    
|    
|    Alex Zinin writes:
|    
|    > Let's keep the original concerns in mind.
|    
|    > To repeat what I've said already, one of the major concerns is
|    > stability of Internet routing.
|    
|    If that is the goal or one of the goals you are trying to 
|    pursue, it
|    would seem to me that you would have to go through the process of
|    analyzing what it depends on and gather data as to what causes of
|    instability. Most service providers keep information of 
|    which defects
|    cause faults in their network, for instance, and many times have
|    information about their root causes.
|    
|    However, imho, the reasons behind this discussion have 
|    nothing to do
|    with extending routing protocols and much less how to do 
|    so. One need
|    only keep in mind that the characteristics of 
|    unextended-BGP are much
|    more of an issue in operational networks than any extensions.
|    
|    IMHO, the real issue behind this debate is that services 
|    providers are
|    themselfs internally divided about issues of future direction and
|    service offerings. There are people that believe in an IP-centric
|    service offering and/or infrastructure and people that believe that
|    there is the requirement to converge network infrastructure and/or
|    provide additional services.
|    
|    Some in the IP-centric camp are attempting to get a 
|    statment from the
|    IETF that going against their particular view of the world 
|    threatens
|    the stability of the internet.
|    
|    I personally have no idea which faction is correct in terms of
|    direction given it is essentially a commercial decision 
|    based on data
|    which i don't have access to.
|    
|    But it seems to me that it is a rather poor idea to 
|    attempt to settle
|    it in the IETF precisely because it is a commercial 
|    decision. And one
|    that is particular to each service provider.
|    
|    Lets assume for a moment that the IETF publishes a 
|    document which says
|    that "multi-service offering networks" are a treat to internet
|    stability or something of the sort. How is that going to fly on a
|    discussion with management or the marketing department on a given
|    carrier/provider ? Does anyone really intend to suggest to their
|    marketing department to be really creative and sell the 
|    fact that they
|    don't provide a given service offering ?
|    
|    The "stability of the internet" is a scare tactic that simply won't
|    fly with management on any service provider, imho.
|    
|    The IETF can and should address engineering problems... in 
|    this case
|    it means make the upmost to make services successful and
|    deployable. Which is the exact opposite of what the people 
|    that don't
|    "want to see any code changes" are looking for...
|    
|    Providing fault isolation in a multi-service router is 
|    something that
|    probably most vendors are working on/have products/have 
|    powerpoint. It
|    is however a problem that doesn't start or end in BGP.
|    
|    This is also an issue that service providers have been 
|    working on with
|    vendors for a considerable amount of time, in a 
|    constructive way and
|    with demonstrable results.
|    
|    If people want to work on this particular goal i would suggest
|    starting w/ the requirement lists that have been developed 
|    by several
|    SPs. Some of these are already quite mature by now.
|    
|      Pedro.
|    
|    _______________________________________________
|    routing-discussion mailing list
|    [email-masked]
|    https://www1.ietf.org/mailman/listinfo/routing-discussion
|    

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

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 8 Aug 2003 10:34:28 -0400

-> > Further, if an SP is going to make the commercial 
-> > decision to support said services, whether or not they
-> > are in BGP or some other protocol, they will still be part
-> > of whatever implementation, sharing the same processor
-> > and memory resources.  Just shifting the deck chairs doesn't
-> > change the amount of wood on the deck.
-> > 
-> 
-> But if the SP doesn't want those services and they are separate 
-> processes then they don't have to turn them on. If they are 
-> built into 
-> something else that the SP does want to run then they 
-> probably get the 
-> bugs whether they like it or not.

  Building a robust BGP implementation is nothing to do with 
  "what BGP carries". I would like to share some of the historic
  events in real complex systems...in mid 90's most of the well
  known operating systems (Linux and BSDs) became so complex
  to handle. For that they didn't stop adding stuff in to OS.
  All they did is, modularized the kernels to dynamically load/
  unload modules as and when needed. Neither they chose to go
  for micro kernel architectures nor they re-invented the wheel.

  AFAIK, every vendor's protocols implementations have a life
  cycle (accept the truth)...for protocols like BGP the life cycle 
  of an implementation may be less. Because the rate of change 
  may be more for BGP. Every vendor has to re-design their code to 
  enhance the performance. This is nothing to do with changing 
  the BGP protocol spec. More over this is nothing to do with 
  IETF.

  If service providers think that a particular vendors' BGP 
  implementation became so complex, ask them to re-design their
  implementation. Or go to different vendor, who is better at
  that time. 

  The better solution for this (IMHO) is to take the problems
  case by case basis and evaluate:
  1. What is getting overloaded (implementations/design) ?
  1. Why *this particular extension* fits (won't) into BGP ?
  2. If *this is not the best fit into foo* (after discussion 
     in apt list) then ask, did we accumulate enough such cases 
     to fork another new protocol ?

  Again, IMHO, the evaluation of a protocol must not be 
  based on current available limitations in the systems 
  engineering. Given a chance, one can really modularize any complex
  protocol...can do SMP of these modules over different processors...
  can fork multiple threads/processes...can improve the performance
  drastically regardless of how many extensions we do. 

  To be frank, BGP is not at all complex when compared to other 
  complex systems. BGP may look complex if we compare it with ping.

Venkata.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 8 Aug 2003 10:34:28 -0400

Venkata.

---

From: "Tony Li" <[email-masked]>
Date: Fri, 8 Aug 2003 13:43:27 -0700

|    > Well said, here here!!!
|    > 
|    > Further, if an SP is going to make the commercial 
|    > decision to support said services, whether or not they
|    > are in BGP or some other protocol, they will still be part
|    > of whatever implementation, sharing the same processor
|    > and memory resources.  Just shifting the deck chairs doesn't
|    > change the amount of wood on the deck.
|    > 
|    
|    But if the SP doesn't want those services and they are separate 
|    processes then they don't have to turn them on. If they 
|    are built into 
|    something else that the SP does want to run then they 
|    probably get the 
|    bugs whether they like it or not.

If the SP doesn't want a service, then the SP shouldn't turn it on.
If the SP didn't turn it on, then the code happily sits behind
an 'if' statement, never to be executed.

Tony

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 8 Aug 2003 17:41:42 -0400

-> On Fri, Aug 08, 2003 at 01:43:27PM -0700, Tony Li wrote:
-> > If the SP doesn't want a service, then the SP shouldn't turn it on.
-> > If the SP didn't turn it on, then the code happily sits behind
-> > an 'if' statement, never to be executed.
-> 
-> Yet other stuff is still present in the path that wouldn't be there
-> if the feature wasn't in the code base at all, even if we
-> extend your analogy to #ifdef.
-> 
-> But we are on the wrong path.  Next! :-)

  Ask for dynamically loadable modularized BGP implementation.

  Why do we always think that "complete BGP" with all (unnecessary) 
  extensions is compiled and loaded into memory even if 75% of code 
  never executes. Ask your vendor to do code profiling and request 
  for better implementation. That will solve the above problem(s).

  Conditional compilation is not the only solution for the problem. :)

Venkata.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Fri, 8 Aug 2003 17:41:42 -0400

Venkata.