[bmwg] Re: draft-ietf-bmwg-conterm-03.txt

Randy Bush <randy@psg.com> Wed, 14 August 2002 00:10 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26259 for <bmwg-archive@odin.ietf.org>; Tue, 13 Aug 2002 20:10:05 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27133; Tue, 13 Aug 2002 20:08:05 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA27107 for <bmwg@optimus.ietf.org>; Tue, 13 Aug 2002 20:08:03 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26212 for <bmwg@ietf.org>; Tue, 13 Aug 2002 20:06:43 -0400 (EDT)
Received: from localhost ([127.0.0.1] helo=rip.psg.com.psg.com) by rip.psg.com with esmtp (Exim 4.10) id 17elhg-0004fz-00 for bmwg@ietf.org; Tue, 13 Aug 2002 17:08:00 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: bmwg@ietf.org
Message-Id: <E17elhg-0004fz-00@rip.psg.com>
Date: Tue, 13 Aug 2002 17:08:00 -0700
Content-Transfer-Encoding: 7bit
Subject: [bmwg] Re: draft-ietf-bmwg-conterm-03.txt
Sender: bmwg-admin@ietf.org
Errors-To: bmwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
X-BeenThere: bmwg@ietf.org
Content-Transfer-Encoding: 7bit

From: Alex Zinin <zinin@psg.com>

> hit pause.  let's see them fix this first.  i knew it needed fresh
> eyes.  thanks!

OK, here's some more I got:

> 2.3.1 Default Route
> 
>    Definition:
>               A Default Route is a route entry that can match any
>               prefix.

Any prefix or any address? I would expect the later.

> If a router does not have a route for a particular

"doesn't have a more specific route"? i.e., the default
is a route, and a matching route, in fact...

>               packet's destination address, it forwards this packet to
>               the next hop in the default route entry, provided its
>               Forwarding Table (Forwarding Information Base (FIB)
>               contains one.

"_the_ next hop" assumes single path, i.e., I can have multiple
next hops for the default.
How can I forward a packet to a part of a data structure (route entry)?
"next-hop router" is probably meant, right?

> The notation for a default route for IPv4 is
>               0.0.0.0/0 and for IPv6 it is 0:0:0:0:0:0:0:0 or ::/0.

0/0 is another one for v4

...
> 2.3.2 Default Free Routing Table
> 
> 
>    Definition:
>               A default free routing table has no default routes and is
>               typically seen in routers in the core or top tier of
>               routers in the network.
> 
>    Discussion:
>               The term originates from the concept that routers at the
>               core or top tier of the Internet will not be configured
>               with a default route (Notation in IPv4 0.0.0.0/0 and in
>               IPv6 0:0:0:0:0:0:0:0 or ::/0).

no need to repeat the notation.

> Thus they will forward
>               every prefix to a specific next hop based on the longest
>               match on the IP addresses.

forward "prefix"? hmmm... :)


>               Default free routing table size is commonly used as an
>               indicator of the magnitude of reachable Internet address
>               space. However, default free routing tables may also
>               include routes internal to the router's AS.

...

> 2.3.3 Full Default Free Table
> 
>    Definition:
>               A full default free table is a set of BGP routes generally
>               accepted to be the complete set of BGP routes collectively
>               announced by the complete set of autonomous systems making
>               up the public Internet.

Shouldn't this definition say something about there being no
default route?

> Due to the dynamic nature of the
>               Internet, the exact size and composition of this table may
>               vary slightly depending where and when it is observed.

s/may vary slightly/will vary/

Also, the different view in different places will not be
because of the dynamic nature of the Internet, but because
of the properties of the protocol.

>    Discussion:
>               Several investigators ([17],[18],[19]) measure this on a
>               daily and/or weekly basis; June 2001 measurements put the
>               table at approximately 105,000 routes, growing
>               exponentially.

Seems not to be the case any more. Maybe we should avoid putting
time-sensitive data here?

...

> 2.3.4 Full Provider Internal Table
> 
>    Definition:
>               A full provider internal table is a superset of the full
>               routing table that contains infrastructure and non-
>               aggregated routes.

changing the name to "full provider-internal table" might be
a good idea: otherwise, "... internal table" being bigger
than the full routing table hits hard at first sight.

...
> 2.4 Classes of BGP-Speaking Routers
> 
>    A given router may perform more than one of the following functions,
>    based on its logical location in the network.
> 
> 2.4.1 Provider Edge Router
> 
>    Definition:
>               A provider edge router is a router at the edge of a
>               provider's network, configured to speak BGP, which peers
>               with a BGP speaking router operated by the end-user.

Shouldn't this def talk about an _external_ BGP session?

> The
>               traffic that transits this router may be destined to, or
>               originate from non-contiguous autonomous systems.

Why is this important for this definition, especially considering
the "may"? Should it be moved to the Discussion section? What is
"non-contiguous autonomous systems", btw?

>    Discussion:
>               Such a router will always speak eBGP and may speak iBGP.
...
> 2.4.2 Subscriber Edge Router
> 
>    Definition:
>               A subscriber edge router is a BGP-speaking router
>               belonging to an end user organization that may be multi-
>               homed, and which carries traffic only to and from that end
>               user AS.

Strange. I would expect this definition to be symmetric to
the one of a PE, but we can see even some terminology
inconsistencies...

>    Discussion:
>               Such a router will always speak eBGP and may speak iBGP.

The eBGP part seems to belong in the definition...

> 2.4.3 Inter-provider Border Router
> 
>    Definition:
>               An inter-provider border router is a BGP speaking router
>               which maintains BGP sessions with another BGP speaking
>               router in another provider AS.

Can it have more than one session?

> Traffic transiting this
>               router may be directed to or from another AS that has no
>               direct connectivity with this provider's AS.

"directed to or from"... maybe "originated in or destined for"?

>
>    Discussion:
>               Such a router will always speak eBGP and may speak iBGP.

e/iBGP have not been defined, BTW.


_______________________________________________
bmwg mailing list
bmwg@ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg