Re: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request]

RJ Atkinson <rja@extremenetworks.com> Sat, 09 November 2002 13:02 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17771 for <ieprep-archive@odin.ietf.org>; Sat, 9 Nov 2002 08:02:12 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id gA9D4EB23480 for ieprep-archive@odin.ietf.org; Sat, 9 Nov 2002 08:04:14 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9D4Ev23477 for <ieprep-web-archive@optimus.ietf.org>; Sat, 9 Nov 2002 08:04:14 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17758 for <ieprep-web-archive@ietf.org>; Sat, 9 Nov 2002 08:01:40 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9D3Bv23441; Sat, 9 Nov 2002 08:03:11 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA9D2rv23419 for <ieprep@optimus.ietf.org>; Sat, 9 Nov 2002 08:02:53 -0500
Received: from gnat.inet.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17723 for <ieprep@ietf.org>; Sat, 9 Nov 2002 08:00:19 -0500 (EST)
Received: from extremenetworks.com (unknown [10.30.20.242]) by gnat.inet.org (Postfix) with ESMTP id 7214967103; Sat, 9 Nov 2002 04:24:06 -0500 (EST)
Date: Sat, 09 Nov 2002 08:02:50 -0500
Subject: Re: FW: [Re: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request]
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Mime-Version: 1.0 (Apple Message framework v546)
Cc: ieprep@ietf.org
To: "Ayyasamy, Senthilkumar (UMKC-Student)" <saq66@umkc.edu>
From: RJ Atkinson <rja@extremenetworks.com>
In-Reply-To: <A29143A40AEAE3459FF829D1DD43316101D9AFF4@KC-MAIL2.kc.umkc.edu>
Message-Id: <8CE1F5B9-F3E3-11D6-A484-00039357A82A@extremenetworks.com>
Content-Transfer-Encoding: 7bit
X-Mailer: Apple Mail (2.546)
Content-Transfer-Encoding: 7bit
Sender: ieprep-admin@ietf.org
Errors-To: ieprep-admin@ietf.org
X-BeenThere: ieprep@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=unsubscribe>
List-Id: Internet Emergency Preparedness Working Group <ieprep.ietf.org>
List-Post: <mailto:ieprep@ietf.org>
List-Help: <mailto:ieprep-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ieprep>, <mailto:ieprep-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

On Friday, Nov 8, 2002, at 22:31 America/Montreal, Ayyasamy, 
Senthilkumar (UMKC-Student) wrote:
> But, we should also remember that telephone networks are the major
> ones to be affected. One of the major reason for the robustness of
> Internet is the redundancy among ISP ( which is not the case in
> PSTN network.) In NY area, verizon was the hot spot/congestion point
> as all carriers junction at verizon.

Hmm.  Not sure what you mean by "carriers" and what you mean by 
"verizon".
"carrier" could mean either telephone company or ISP given the preceding
text.  Verizon is a firm, not a location.

There are several ISP interconnects in lower Manhatten.  The most
significant one is on Hudson Street, but others do exist.

>> Access to the US NASA feeds of the mars lander landing was a bigger
>> problem in Internet terms, yet even then the problems were on NASA's
>> access links and its servers, rather than in any large ISPs network.
>
> But, Code RED had major effect on the routing system than the above 
> one..

That impact varied directly with (1) which firm's routers one had 
installed
and (2) one's configuration for those routers.  Folks with 
hardware-based
ACLs didn't have big problems.  Folks using CPU-based ACLs had problems,
because the CPU became over-burdened.  This is not a systemic issue or
a protocol issue, but rather an equipment selection/deployment issue.

> Although, failure analysis in BGP was well studied by Ahuja/labovitz, 
> it was
> not done for intra-domain(link state) network ( as reconvergence time 
> is less
> when compared to inter-domain.) But It is necessary to study them, 
> both for
> helping researchers/operators.

	Inside an ISP, I-BGP is used internally in addition to an IGP -- and 
I-BGP
is more significant to the convergence of the routing system as 
perceived
by customers/users.

> - "Service availability" is a common term in telephone networks. But, 
> with
> the advent of VoIP/ priority traffic, it is necessary to define service
> availability in Internet too. For doing such things, failure modeling 
> is
> the base step ( studying rate/CDF of failures etc.)
> ( It will help operators to define terms for SLA )

	Several operators have defined both "service availability" and "SLA".
The current definitions vary among carriers.  Customers who don't read
their SLAs closely might be disappointed by what the SLAs actually 
promise.

> - Learning Objective functions for OSPF weight optimization
>   ( helps researchers/operators)

Not clear what you mean by "Learning Objective functions".

> This is very important for this group..
> For example:
>  - when your talking about Japan-IAA system ..It is application
> layer and IETF has nothing to say about a data base unless they
> want to load balance like content distribution networks.

"Voice over IP" and "SIP" are also examples of application-layer 
services.

> - Recently, alternate routing - In application layer, it is
> feasible (TRIP ) but in Network layer, not possible in near future.

I do not understand your meaning.

> But, once the SIP requirement was shipped to Sipping group, we should
> only be talking in network layer realm.

I would not object to that proposal.

	As Ken explains much better than I do, the reason there are 2 separate
documents is to separate issues architecturally.  His 
draft-carlberg-ets-general-*
is focused on concerns relating to the IP-layer, while 
draft-carlberg-ets-telephony-*
is focused on concerns relating to VoIP applications (at the 
application-layer).

	Clearly some folks will want to use IEprep for VoIP stuff, so having 
that
documented is helpful.  However, other folks will not want to use IEprep
for VoIP, so the VoIP-related stuff needs to be separated out cleanly 
from
generic IEprep stuff.

	And it would still help if we could get more specific, clear 
documentation
on the GETS-like or IEprep-like services in use or contemplated for use 
in
countries other than US and JP.  This needs to come from folks in the 
relevant
country, rather than being claims by person in country X about country 
Y's
needs.

Ran
rja@extremenetworks.com

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