Hi Brandon,

Thanks again for the response.  I just wanted to make one quick comment.
 We do try to submit all of our changes and patches back to the
upstreams.  It makes our lives much easier on the integration side.  If
we don't submit something it's through an oversight as opposed to
anything else.  Like all open source developers, sometimes our patches
are accepted and sometimes they aren't.  OSS is an amazing, wonderful,
and often painful process...

Cheers,
Robert.

Brandon Bennett wrote:
> Thank you for the very detailed response and you have made some of my
> first impressions fears fade away.
> 
> Great to hear that you are planning on providing customization to
> vbash.  It is not a bad shell, it just seems odd to combine bash with
> my router configuration.  I was afraid of tab-completion issues and
> accedental commands being ran (or overlapping)
> 
> I can understand about XORP, but my understanding was that vyatta was
> going to help groom XORP and submit patched back up stream like many
> commercial to OSS projects do.   I too am looking for a router to
> handle large BGP configs so this is a good step in the right
> direciton.
> 
>  I am just going to miss the JunOS type polices and am not looking
> forward route-maps,  OSPF/BGP network statements, etc.   I thought
> XORP had done that part right.   It seems like a ugly pig (IOS/Quagga)
> with lipstick on (JunOS type stanzas).
> 
> 
> Again I really appreciate the quick and detailed response and will be
> following the development closely.
> 
> 
> Thanks again,
> 
> Brandon
> 
> 
> 
> On Wed, Feb 27, 2008 at 12:50 PM, Robert Bays <[EMAIL PROTECTED]> wrote:
>> Hi Brandon,
>>
>>  Sorry to hear your first impression of Glendale was not up to
>>  expectations.  Could you help us to understand your reactions a little
>>  better so we can improve on the next milestone?  Specifically, which
>>  parts of the vbash shell didn't you care for?  Was it a look and feel
>>  issue or was it more of an issue with the configuration syntax or
>>  something else entirely?  The goal of vbash was to have the user
>>  interface be configurable to have either a bash look and feel or a
>>  Juniper like look and feel based on user preference.  We accomplish this
>>  by allowing the user to set an environment variable in the shell that
>>  changes the help and auto completion to limit their output and set a
>>  user level that limits execution privileges to router commands only.
>>  There are a few areas we need to work on, such as space auto completion,
>>  but we hope to get it to the point where there is no visual difference
>>  between a Juniper like shell and the vbash shell if you choose to setup
>>  your user that way.  Could you let us know, in your opinion, what else
>>  we need to do to reach that goal?
>>
>>  As related to the routing protocol stack, the decision was made to
>>  change after extensive analysis of the potential to scale XORP in large
>>  routing topologies.  Many of our users are running big, complicated BGP
>>  networks and we ran into some fundamental limits with the existing code
>>  base.  We did spend a significant amount of time optimizing that code
>>  with some success before hitting a fundamental performance limit.  It
>>  was at that time that we had to weigh options.  The decision to switch
>>  was not taken lightly and was based on testing results looking into a
>>  combination of factors; primarily stability and scale and only
>>  secondarily feature differences.  It would help us if you give a
>>  configuration example of what you liked in the previous release that the
>>  current release falls short on or a feature comparison where there are
>>  deficiencies.  Maybe we can craft the next release more in line with
>>  those expectations.  IMHO, in the end it shouldn't matter what routing
>>  protocol stack is being used as the underlying technology as long as it
>>  is fast, scalable, stable, easy to use, and has the features that
>>  satisfy the topology requirements of the installation.  We made the
>>  switch after extensive analysis of the "fast, scalable, stable,
>>  features" requirements.  Maybe we can change the presentation to better
>>  help with the "easy to use" requirement.
>>
>>  Cheers,
>>  Robert.
>>
>>
>>
>>  Brandon Bennett wrote:
>>  > I have been following the the development of Vyatta over the course of
>>  > about the past year and have been really excited to see it progress.
>>  > As a Network Engineer for that last 7 years I have been brought up on
>>  > IOS and over the past 2 years or so I have been learning JunOS.
>>  >
>>  > Initially with previous Vyatta releases I was very excited to see the
>>  > JunOS like XORP engine being used along with it's powerful policies,
>>  > elegant configurations solutions, and overall ease of use.
>>  >
>>  > After reading the release notes for Glendale (VC4 Alpha 2) I was very
>>  > excited about the new features and loaded it up in a VMWare as soon as
>>  > I could.   Lets just say I was more than disappointed once it loaded
>>  > up.
>>  >
>>  > 1) The new vbash interface.   I love the fact that there is a UNIX
>>  > interface to my routers (even newer versions of IOS can do this and
>>  > JunOS has it out of the box).  Being able to do some lower level
>>  > troubleshooting via a csh/bash/sh/etc CLI is invaluable.  That being
>>  > said there is no reason I need to combine my Unix CLI with my
>>  > Router/Configuation CLI.   I see this as a very very poor design
>>  > decision and it will only attract to Unix admins turned Network
>>  > admins.  Vyatta will have a hard time being a serious competitor to
>>  > Juniper, Cisco and the others.
>>  >
>>  > Going forward I would like to see vbash and a traditional both
>>  > interface be supported, although as stated in my next point this may
>>  > no longer be possible with the move to Quagga and away from xorpsh
>>  >
>>  > 2) Quagga?!?   What happened to my elegant OSPF configuration?  What
>>  > happened to my wonderful and simplistic BGP configuration.  Now i have
>>  > a rehash of IOS (via Quagga) for configuring my routing protocols.
>>  > JunOS/XORP routing policy was so elegant and now I am stuck with
>>  > 1980's route-maps, community-lists and access-lists.   Cisco still
>>  > uses these for one reason:  It's legacy code.   Vyatta is a brand new
>>  > router from the ground up.  There is no need to go backwards.
>>  >
>>  > Also from a architectural stand point XORP has a great design base.  I
>>  > am very sad to see it go.   I would like to know if there was any
>>  > other reason from going away from a XORP base to Quagga besides quick
>>  > turn around on features (and loose some great, features in the
>>  > process)
>>  >
>>  > I also don't know if completely switching gears at this point in the
>>  > game is wise.  If you want a IOS like router you should of started
>>  > there.
>>  >
>>  >
>>  >
>>  > There are some great things I have to say about Glendale as well:
>>  >
>>  > The RBAC is a great for a team supporting the routers.
>>  > The other OSS projects you are able to incorperate into the systems
>>  > (Remote VPN, wanpipe, etc)
>>  >
>>  >
>>  > Although I know you will take this email seriously, I know you have
>>  > already gone down a path I don't 100% approve of.  So now I am going
>>  > back to my proprietary Juniper and Cisco routers and wait for the day
>>  > for another FOSS router to come out again.
>>  >
>>  >
>>  > ~Brandon
>>  > _______________________________________________
>>  > Vyatta-users mailing list
>>  > Vyatta-users@mailman.vyatta.com
>>  > http://mailman.vyatta.com/mailman/listinfo/vyatta-users
>>  _______________________________________________
>>  Vyatta-users mailing list
>>  Vyatta-users@mailman.vyatta.com
>>  http://mailman.vyatta.com/mailman/listinfo/vyatta-users
>>
> _______________________________________________
> Vyatta-users mailing list
> Vyatta-users@mailman.vyatta.com
> http://mailman.vyatta.com/mailman/listinfo/vyatta-users
_______________________________________________
Vyatta-users mailing list
Vyatta-users@mailman.vyatta.com
http://mailman.vyatta.com/mailman/listinfo/vyatta-users

Reply via email to