Re: ASN draft

[Paul Traina <[e-mail]>]

  From: [e-mail] (Cengiz Alaettinoglu)
  Subject: Re: ASN draft 
  
  Paul Traina ([e-mail]) on February  6:
  > Which are ONLY useful for making route determinations.  If there is no
  > route determination differential, then there's nothing wrong with clumping
  > together ASs.
  
  I agree with this definition. However, I am not sure if we agree what
  the "route determination differential" is. Perhaps we do.
  
  Two domains, a provider and a customer, may have the same set of policies
  and it may be OK for the customer to use the provider's ASN if they
  were in isolation.
  
  However, a third transit provider, distant in the Internet, may want
  to *differentiate* between the provider and the customer, or this
  customer from another customer of the provider. That is there is
  "route determination differential". If the customer uses the same ASN
  as its provider, the third provider is forced to use network lists,
  which do not scale as nicely.

Yes, in the few cases where that is required, I would have no problem
encouraging folks to either use ASNs or communities to mark paths.
However, the big reason for doing this is, I believe, the classic argument
of "I don't want IBM to get Apple's traffic."  I feel that using BGP to
enforce security-driven policies is foolhardy,  and that the best use of
BGP's policy controls is for more standard traffic direction policy,  at
which point a stub site would never want to be routed differently than their
ISP since they, by definiton, don't have a backdoor.
  
  I guess in this case these three domains (as being "consenting
  adults"), may agree to use a different ASN for this customer. The
  draft fails to mention that "route determination differential" can be
  somewhere other than the customer and the provider and may cause a
  different ASN for the customer.

Absolutely.
  
  The draft also fails to mention that the main motivation of the work
  is to avoid ASN space exhaustion. It sound more like this is what we
  would do even if the ASN space was infinite.

Actually, I'm worried about AS space exahaustion, but I'm also worried about
the proliferation of path components for no good reason (hence we created
the atomic aggregate attribute in BGP).  Carrying around extra gunk just
chews up more memory and slows down anything that's trying to use the AS
path information for real policy differentiation.  That's why I want the
"default" to be that organizations don't get their own AS unless they have
a _reason_ to do so.