Re: ASN draft

[Paul Traina <[e-mail]>]

  From: [e-mail] (Bill Manning)
  Subject: Re: ASN draft
  A sparing partner! Yeah!
  
  
  But that does/should not detract from the fact that they don't share revenue
  streams or cost exposure. They don't have the same technical staffs nor are
  they addressing the same customer base.   The rational for sharing the up
  stream ISP ASN is:

  	-stupidity (anyone have a mis-configured OSPF default blow away IGRP?
  	-can't/won't (we don't trust you so we'll use statics, besides it
  		      slows down the exaustion of a "scarce" resource -ASN's)
  	-hardware (we can't afford new HW so are staying w/ our p4200s and
  		   we want full (whatever the heck that means) routes.)

OK, I'm having problems following you.  Any sane ISP definitely would use
reason #2 or a redistributable IGP with filtering on the input.  However,
that's really kind of a moot point, since I can fake up an AS as I'm
importing stuff from another IGP into BGP.

The real reason for doing it is #2/wont.

Adding additional ASNs when there is no need due to routing policy:
	(a) makes proxy-aggregation a serious pain in the ass
		(e.g. right now, it's trivial to proxy-agg PSI but not
			screw over ex-PSI customers who have taken their
			chunk of PSI's original address space with them).
	(b) makes it more difficult to determine when and where it's safe
		to aggregate in general
	(b) increases the dirversity of AS paths for no good reason
		(which chews up memory)

I think the biggest disagreement we have is the idea of wrapping ones mind
around the idea of using ASNs _in_the_context_of_BGP_.  Perhaps we should
be calling the darn things something other than ASNs,  because several
autonomous systems should be encouraged to share a single ASN (their
providers) if there isn't a routing decision that should be made based upon
that ASN.

When I open up the back of Microtimes and see how many different Mom and Pop
ISPs are showing up, and how many of them are targeting individual users,
the concept of doling out ASNs to people who don't need them for routing
decsisions scares the living s--- out of me.
		
  > Let's cut to the chase...
  > 
  > > 4. Common errors in allocating ASes
  > > 
  > >    The term AS is often confused or even misused as a convenient way of
  > >    grouping together a set of prefixes which belong under the same
  > >    administrative umbrella, even if within that group of prefixes there
  > >    are various different routing policies. Without exception, an AS must
  > >    have only one routing policy.
  > > 
  > > This seems to fly in the face of the BGP definition (and the one to which
  > > I subscribe). ASNs have more uses than just routing. They are the way to
  > > define administrative/political/trust bounds.
  > 
  > Which are ONLY useful for making route determinations.  If there is no
  > route determination differential, then there's nothing wrong with clumping
  > together ASs.
  
  again, how to descriminate once you are in the IGP side of things?

Who says that I have to use my ASN as my IGP identifier?  That was a common
preconception that we at cisco unfortunately foisted on people for years.
Gee, I have an IGP, the first thing I'll do is go to the NIC and get an AS.
This draft is here to put a bullet in that idea.  It was a mistake, we're
sorry. :-)

Why does my IGRP, EIGRP, or OSPF identifer (what we used to call the ASN)
have to have anything to do with a NIC assigned AS?  All I need to do is
make sure that my IGP identifier is unique within the bounds of my greater
IGP cloud.  For instance, at cisco, we use EIGRP 109 for engineering's
RP identifier.  MIS uses EIGRP 1 and IGRP 109.  The cIX (cisco Internet
Exchange) which is the group of physical nets that touch all of the ISPs
that we work with happens to use EIGRP 108.  Note the interesting thing
here... EIGRP 108 is being redistributed into BGP 109 (109 is our official
AS)... we could have (used to) distribute IGRP 109 into BGP 109.  Big deal.
  
  > The whole concept of an AS under common administrative bounds has nothing t
  > do with the way BGP uses ASs _today_.  I think we can all agree on that
  > statement, so let's get to the more conceptual question:
  
  I'll have to agree here.

Whew. :-)
  
  > Is there any reason to maintain the idea of an AS as a collection of prefix
  > under common administration and sharing the same security/trust policies?
  > 
  > If you can show just cause, then I'm willing to agree with you, at which
  > point, I will wet my panties because we're going to run out of AS space nex
  > week.  However, I think that you will be hard pressed to show a case where
  > an AS could possibly be shown to have anything other than the same routing
  > policy (don't forget, path's are trivially spoofable).
  > 
  
  On more than one occasion, (back when I was doing real work :) I would find t
  my downstream clients would incorrectly configure the OSPF/IGRP etc default
  and that would raise havoc with my IGP which would in turn affect my BGP peer
  with the outside world.  For this reason, we would use EGP or static routes
  to insulate their dyanmics to their own "administrative domain"  If they want
  to fornicate themselves... fine, just leave me alone.  When BGP was available
  we migrated them to BGP.  It's faster and actually had support for some neato
  features not found in EGP... (can you say CIDR... I knew you could).

Yeah, but you can do the same thing with statics or classfull IGPs right now,
the big thing is to remember to filter the hell out of anything you get from
a customer.  The only advantage BGP offers the customer is that he can look
at all of those AS paths and perhaps make interesting decisions based on the
AS paths.  However 99.99% of all customers are just pointing default somewhere
(including many multi-homed sites) so there's really not a strong reason to
BGP<->BGP with them any more.

I realize this is a reversal of previous things I've said over the years,
sorry,  I didn't expect Al Gore and Mark Anderson to come along and make
this stuff trendy. :-)