Re: WG Last Call

[Tony Bates <[e-mail]>]

 Rohit Dube <[e-mail]> writes:
  * On Thu, 21 Aug 97 09:19:51 PDT [e-mail] writes:
  * =>Folks,
  * =>
  * =>This is the IDR WG Last Call for advancing 
  * =>draft-ietf-idr-as-dedicated-00.txt to an Informational RFC.
  * 
  * 
  * I had some comments on the draft -
  * 
  *    3.1 Full Routing Table Announcement
  * 
  *    A BGP customer using	the dedicated AS must carry a default route
  *    (preferably receiving from its provider via BGP).
  * 
  * I assume this is because (using the example) X can't see the routes 
  * from Y and vice-versa. Given that the proposed RFC is informational, the
  * authors may want to ellaborate.
  * 
That's correct. This is becuase of the BGP loop detection. I am not
sure we really need to ellaborate as to why as this is in the
implications section.

  * 
  *    3.2  Change of External	Connectivity
  * 
  *    The dedicated AS specified by a provider is purely for use in peering
  *    between its customers and the provider. When	a customer using the
  *    dedicated AS	changes	its external connectivity, it may be necessary
  *    for the customer to reconfigure their network to use	a different AS
  *    number (either a globally unique one	if homed to multiple providers,
  *    or a	dedicated AS of	a different provider).
  * 
  * Does using a dedicated AS preclude a back-up connection between two
  * customers of the same provider? BGP peering between two customer networks
  * using _the_ deidicated AS number is ofcourse not possible, but what
  * about peering between a customer who has a dedicated AS number and another 
  * who has a "real" AS number assigned to it. It seems to me that this 
  * would work fine. Perhaps this is worth commenting on in this section.
  * 
  *

It in fact does not preclude this ability but is to some degree not
the problem we are trying to solve and I would argue that this is the
slippery slope. If you have a backup connection you really have a
different routing policy for your ISP and should be looking at getting
a unique ASN. RFC1930 explicity allows for such a requirement.

  *    3.4  Routing Registries
  * 
  *    For example, the	"mntner" attribute or the "community"
  *    attribute of	a route	object can be used along with the "origin"
  *    attribute in	generating the filtering lists.
  * 
  * Again, because this is a proposed informational RFC, the authors may want t
  * o
  * provide a reference for the "mntner" (is there an RFC for this yet?) and 
  * "community" (RFC 1997) attributes.
  * 
There is a reference in the para above. It is [5]. RFC1786 which
details both of these attributes.

  * 
  * On a different note, I am curious about the reasoning behind the 
  * restriction that there be only _one_ dedicated AS number. It appears to 

We do not explicitly restrict you to one dedicated ASN and could in
fact be more than one. However, eventually you will still have the
same implications as using one dedicated AS which is why we describe
it this way. The other slight downside is you also have to manage/keep
track of all of these AS's for potentially very little gain.

  * me that any number of dedicated AS numbers can be handed out by the provide
  * r, 
  * as long as the provider is able to strip out these AS numbers at its 
  * egress points (to other providers). If one such AS number is handed out
  * per customer which needs an AS number, we would have the added advantage 
  * that defaults need not be propagated to the customers and they would see 
  * the full routing table.
  * 
Except that this clearly only scales for (65535 - 64512) 1023
customers at most.

  * Am I missing something? 
  * 

Doesn't scale.

	Cheers,
			--Tony