Re: WG Last Call

Rohit Dube <rohit@cs.umd.edu> Sat, 23 August 1997 01:54 UTC

Received: from cnri by ietf.org id aa21852; 22 Aug 97 21:54 EDT
Received: from merit.edu (merit.edu [198.108.1.42]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid VAA29485 for <ietf-archive@cnri.reston.va.us>; Fri, 22 Aug 1997 21:57:38 -0400 (EDT)
Received: (from majordom@localhost) by merit.edu (8.8.7/8.8.5) id VAA09688 for idr-outgoing; Fri, 22 Aug 1997 21:30:52 -0400 (EDT)
Received: from darling.cs.umd.edu (darling.cs.umd.edu [128.8.128.115]) by merit.edu (8.8.7/8.8.5) with ESMTP id VAA09684; Fri, 22 Aug 1997 21:30:48 -0400 (EDT)
Received: by darling.cs.umd.edu (8.8.5/UMIACS-0.9/04-05-88) id VAA17132; Fri, 22 Aug 1997 21:30:46 -0400 (EDT)
Message-Id: <199708230130.VAA17132@darling.cs.umd.edu>
To: Yakov Rekhter <yakov@cisco.com>
cc: idr@merit.edu, skh@merit.edu
Subject: Re: WG Last Call
In-reply-to: Your message of "Thu, 21 Aug 1997 09:19:51 PDT." <199708211619.JAA12476@puli.cisco.com>
Date: Fri, 22 Aug 1997 21:30:45 -0400
From: Rohit Dube <rohit@cs.umd.edu>
Sender: owner-idr@merit.edu
Precedence: bulk

On Thu, 21 Aug 97 09:19:51 PDT yakov@cisco.com 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.


   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.


   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 to
provide a reference for the "mntner" (is there an RFC for this yet?) and 
"community" (RFC 1997) 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 
me that any number of dedicated AS numbers can be handed out by the provider, 
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.

Am I missing something? 

TIA.
--rohit.
#include <stddisclaimers.h>