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: Mark Prior <[email-masked]>
Date: Fri, 08 Aug 2003 17:51:28 +0930

> 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.

Mark.

---

From: Mark Prior <[email-masked]>
Date: Fri, 08 Aug 2003 17:51:28 +0930

Mark.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 08 Aug 2003 10:00:09 -0400

Mark> But if the SP doesn't want those services and they are separate 
Mark> processes then they don't have to turn them on. If they are built into 
Mark> something else that the SP does want to run then they probably get the 
Mark> bugs whether they like it or not. 

What you are really saying is that you want to be able to get an image which
has only  the features you care  about and no  others.  It seems to  me that
this is an issue between you and your vendor, and the IETF has nothing to do
with it.  No vendor would ever decide how to set up the process structure of
a  particular box  based on  what the  IETF says.   And if  you  have vendor
quality issues, don't expect that they will be resolved by IETF discussion.

The  discussion  has revealed  a  couple  of  specific areas  where  certain
protocol features of  BGP may make it difficult to get  the desired level of
robustness.  It seems  that these can be addressed  by BGP enhancements like
"soft  notifications"  or "multiple  sessions  without multiple  addresses",
things that can be addressed in the IDR WG.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 08 Aug 2003 10:00:09 -0400

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 8 Aug 2003 10:10:25 -0400

> things that can be addressed in the IDR WG. 

I think this covers the majority of the protocol-level fault tolerance
I would like to see.

Alex, do you think this should go further?

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 8 Aug 2003 10:10:25 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: Henry Kilmer <[email-masked]>
Date: Fri, 8 Aug 2003 11:18:12 -0400

>change the amount of wood on the deck.

One of the concerns I have is the ability to selectively run "new"
things.  In the past, I have even gone so far as to install extra
routers within pops and only turned on new features in them (sometimes
using a suite of tunnels to get things working) leaving my core
infrastructure alone.  This allowed me to test new features,
protocols, enhancements and services without jeopardizing the
infrastructure carrying live traffic.  One network I ran even kept
this seperate structure for the service offering for awhile.  Every
provider that I have worked for prioritized existing IPv4 customers
over new products.  So even with competing pressures within ISPs (they
*need* to generate revenue an commonly use new products to do so), the
infrastructure still needs to be the top priority.

This sort of rollout can be done within BGP or with a different
distribution protocol.  The point is the concern for the
infrastructures integrity and not necessarily the mechanism.  But I
would also say that it does not *necessarily* mean they share the same
processor and memory resources.  Nor do they have to share code.

One of the points I thought I heard in this conversation was a concern
over the existing BGP stability in the Internet.  It has also been
pointed out that BGP as a protocol is simple and should not have
issues.  Randy mentioned stats and a presentation he was working on
talking about concerns with existing BGP implementations.  Would it
not be prudent to get more details on this before extending one of the
critical elements of making the infrastructure work?  Or do we feel
that we have enough from the work Craig did a few years ago?  I
personally would like to hear more about the issues and concerns
before adding more to the protocol.

-Hank

---

From: Henry Kilmer <[email-masked]>
Date: Fri, 8 Aug 2003 11:18:12 -0400

-Hank

---

From: Alex Zinin <[email-masked]>
Date: Fri, 8 Aug 2003 16:03:19 -0700

Jeff-

 Yes. This, I thinks, maps to step 3 "meanwhile considerations" in
 the message about next steps I sent on Aug 1st.

 I will be creating the design teams I mentioned, including the one to
 work on documenting this part of the discussion. The document would
 then be discussed here and taken to IDR for further actions.

 More details later on the list.

-- 
Alex
http://www.psg.com/~zinin/

---

From: Alex Zinin <[email-masked]>
Date: Fri, 8 Aug 2003 16:03:19 -0700

Jeff-

---

From: Mark Prior <[email-masked]>
Date: Sat, 09 Aug 2003 22:10:57 +0930

> quality issues, don't expect that they will be resolved by IETF discussion.
I don't care if the features are there or not, although my obvious 
preference would be for them not to be there (that is why I don't run 
cisco enterprise images or T images for that matter), but I do care if 
their presence impacts the robustness of the features I am using. While 
this could be claimed to be a vendor implementation problem if the IETF 
stops adding unrelated items to BGP just because its there and does sort 
of the same thing then the vendors will be less likely to add them too. 
After all marketing are probably only interested in having the longest 
"supports RFC xxxx" list in their propaganda.

Mark.

---

From: Mark Prior <[email-masked]>
Date: Sat, 09 Aug 2003 22:10:57 +0930

Mark.