Subject: RE: [Ieprep] access and enterprise networks

From: "Nguyen, An" <[email-masked]>
Date: Tue, 1 Apr 2003 09:53:28 -0500

Kimberly,

>
>-----Original Message-----
>From: King, Kimberly S. [mailto:[email-masked]]
>Sent: Monday, March 31, 2003 11:57 AM
>To: Ieprep (E-mail)
>Subject: [Ieprep] access and enterprise networks
>
>
>
>At the last meeting, people expressed an interest in addressing access and
>enterprise networks.  As frustrating as it might seem, if there is to be
any
>progress, the problem still has to be precisely defined.  
>
I thin we need to define what access and enterprise networks are and what
are the chokepoints in these network. We need a diagram that depicts this
whole thing.  

>Let's consider defining the problem and it would be nice to factor in some
>practical realities too.  
>
>Here are some assumptions: 
>
>A) ETS locations are known in advance of any emergency. When an emergency
>occurs, each will already be connected to a network (unless the emergency
>damaged the connection in which case that situation is out of scope).
>

I don't totally agree with the notion that locations of any emergency can be
predicted in advance. An known ETS location belongs to one of many emergency
scenarios. We cannot address all scenarios at once; therefore, we can only
move in small increments; that is, addressing congestion problem in this
specific scenario.

>
>So, what is it that we want to ensure?  Would ieprep like a service that
>provided some minimum bandwidth guarantee (like gold service) over the
>access link and that's sufficient to make everyone reasonably happy?  If
>that kind of service just isn't acceptable, then please provide some text
>and details about the problem you believe we need to address.
>

Does "Gold service" mean access traffic needs to be classified so that
traffic belongs to this gold service could be taken care of first when
congestion occurs? If the answer is yes, I would like to some proposed
mechanisms from the WG. If no, what else can be done to solve  this problem?

>Kimberly

An
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 1 Apr 2003 10:39:12 -0500

> are the chokepoints in these network. We need a diagram that depicts 

Agree.

A starting point is that an "enterprise network" normally has one of
2 flavours:

	(A)	campus or single-building network, most commonly built out
		of 10/100/1000 Ethernet these days.
	(B)  multi-site enterprise network (e.g. US General Electric Co.)
		with T1/NxT1/T3 links between/among the various sites and
		with any given site looking like (A) above.

An "access network" typically means the uplink between an enterprise
network and its IP service provider.  Access networks are most commonly
built out of T1/NxT1/T3 links, though for large multi-site enterprises
the uplink might sometimes be higher bandwidth (e.g. OC-3 ATM or SONET,
OC-12 ATM or SONET).

> mechanisms from the WG. If no, what else can be done to solve  this 

I don't know what form of "Gold service" meaning Kimberly meant,
so the following example uses the explanation that An provided:

	One possible mechanism (applicable ONLY IF there is a single
	administrative/policy domain, not for an inter-domain scenario):
	- packet classification based on arrival port, based on IP ToS or
		Ethernet 802.1p precedence markings, based on source/dest address
		and/or protocol (e.g. UDP, TCP, SCTP) and port number (e.g.
		SIP, SMTP, FTP), or based on other selectors.
	- mark IP ToS/Ethernet 802.1p based on the preceding packet 
classification.
	- deploy DiffServ within the enterprise network, with at least 3 
queues:
			- normal traffic (lowest priority)
			- preferred traffic
			- network control/routing traffic (highest priority, low bandwidth)
	- use DiffServ to apply class-based-queuing on access/uplink routers

The issue with inter-domain is mitigating risk of DoS/DDoS attacks
on the ISP's core or in the destination domain's network.

Ran
[email-masked]