RE: [PCN] Architecture draft - probing section & general updates.

<philip.eardley@bt.com> Mon, 05 November 2007 18:57 UTC

Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip78a-0002Qt-63; Mon, 05 Nov 2007 13:57:28 -0500
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Ip78Y-0002Qf-RV for pcn-confirm+ok@megatron.ietf.org; Mon, 05 Nov 2007 13:57:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip78Y-0002QX-Gh for pcn@ietf.org; Mon, 05 Nov 2007 13:57:26 -0500
Received: from smtp3.smtp.bt.com ([217.32.164.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip78X-00081u-V3 for pcn@ietf.org; Mon, 05 Nov 2007 13:57:26 -0500
Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 18:57:24 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PCN] Architecture draft - probing section & general updates.
Date: Mon, 05 Nov 2007 18:57:23 -0000
Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B342DC@E03MVZ1-UKDY.domain1.systemhost.net>
In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646512DFE32B@zcarhxm1.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [PCN] Architecture draft - probing section & general updates.
Thread-Index: AcgW7SC2PEVcOi1+Qg+vZ1UxgSPGoQDfIixAAVzgg4A=
From: philip.eardley@bt.com
To: babiarz@nortel.com, lars.eggert@nokia.com
X-OriginalArrivalTime: 05 Nov 2007 18:57:24.0858 (UTC) FILETIME=[B405EDA0:01C81FDD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f66b12316365a3fe519e75911daf28a8
Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Errors-To: pcn-bounces@ietf.org

Joe - trying to clarify... what's the PCN-domain? Does it run from one
*enterprise* LAN edge switch/router to another (there's a tunnelled link
between them), or from the end terminals. Ie what are the
pcn-boundary-nodes {&pcn-interior-nodes)?

The scenario isnt captured I think in the draft-ietf-pcn-architecture,
so something should probably be added...

Thanks
Phil. 

> -----Original Message-----
> From: Jozef Babiarz [mailto:babiarz@nortel.com]
> Sent: 29 October 2007 21:06
> To: Lars Eggert
> Cc: pcn@ietf.org; Geib, Ruediger
> Subject: RE: [PCN] Architecture draft - probing section & general
updates.
> 
> Hi Lars,
> I did not explain my scenario that clearly, I confused people the word
> "access node". So here goes a second try.
> 
> I'm thinking of a scenario that many enterprises face today. Large
multi
> location enterprises use multiple WAN links or VPS to interconnect
their
> locations (branch offices). PCN is run inside the enterprise network
> including WAN links which may be tunneled across the carrier network.
> Carrier network is not required to support PCN as the enterprise
traffic
> including PCN marking is tunneled, however it could.  Network Access
> Control with PCN admission control is done at the *enterprise* LAN
edge
> switch/router. New flows can be routed to any egress LAN edge
> switch/router and some flows will (between different locations) be
> routed over one of the WAN links which are normally bandwidth
> constrained. There is a high probability that many of the edge LAN
> switches/routers will have no flows setup between each other (no
> ingress-egress aggregate) as there are a large number of edge LAN
> switches/routers in the enterprise network and people calling patterns
> change. They normal expect that they should be able to call anyone.
> 
> 
> Regards, Joe
> email:babiarz@nortel.com
> Telephone:613-763-6098
> 
> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert@nokia.com]
> Sent: October 25, 2007 5:54 AM
> To: Babiarz, Jozef (CAR:0S03)
> Cc: Geib, Ruediger; pcn@ietf.org
> Subject: Re: [PCN] Architecture draft - probing section & general
> updates.
> 
> On 2007-10-24, at 19:14, ext Jozef Babiarz wrote:
> > I'm thinking of a scenario that many enterprises face today. Large
> > multi
> > location enterprises use multiple WAN links or VPS to interconnect
> > their
> > locations. PCN is run inside the enterprise network including WAN
> > links
> > which maybe tunneled across the carrier network. Network Access
> > Control
> > with PCN admission control is done at the enterprise access edge
> > nodes.
> > New flows can be routed to any egress access edge node and some
flows
> > will (between different locations) be routed over one of the WAN
links
> > which are normally bandwidth constrained.
> 
> I understand your scenario so far.
> 
> > There is a high probability
> > that many access nodes will only have one flow between each other as
> > there are a large number of them.
> 
> I don't see how this follows, however. It seems that if the sites
> that are being interconnected aren't tiny, there should very likely
> be multiple flows per ingress/egress pair, no?
> 
> Lars
> 
> 
> _______________________________________________
> PCN mailing list
> PCN@ietf.org
> https://www1.ietf.org/mailman/listinfo/pcn


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