[132091] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Recent operational experience choosing between PBB-TE, MEF9+14,

daemon@ATHENA.MIT.EDU (Francois Menard)
Sat Nov 13 20:27:23 2010

From: Francois Menard <francois@menards.ca>
In-Reply-To: <20101114090843.66961da7@opy.nosense.org>
Date: Sat, 13 Nov 2010 20:27:15 -0500
To: Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org


So if T-MPLS is a look-out for trouble, for =
much-bigger-than-metropolitan network architectures, I am down to 3 =
choices.

Let's assume PBB-TE is not yet widely implemented and let's assume that =
there are few automated provisioning interfaces designed for MEF9+14 =
equipment, then it doesn't leave much other choice but VPLS does it not =
?

F.

On 2010-11-13, at 5:38 PM, Mark Smith wrote:

> On Fri, 12 Nov 2010 08:30:19 -0500
> Francois Menard <francois@menards.ca> wrote:
>=20
>> I'm embarking on a new project which involves a large scale MAN =
network where ultimately, the objective is to carry QinQ, while at the =
same time delivering services over IPv6.
>>=20
>> The objective is to support jumbo frames on all interfaces, at least =
to carry QinQ standard-size ethernet frames, but ideally as large as =
possible
>>=20
>> There seem to be 4 approaches to do this.
>>=20
>> a) The IEEE PBB-TE approach - but little implementations.
>> b) The MEF9+14 approach, mature, but manual provisioning
>> c) The VPLS approach, concerns with too much manual provisioning.
>> d) The T-MPLS approach, concerns with maturity
>>=20
>> The objective is to support the functionality not only in the CORE, =
but also on cost effective multi-tenant & redundant customer CPEs.
>>=20
>> I have not seen a, or b or d supported in a low-cost customer CPE.
>>=20
>> I am currently favouring c, for reasons of maturity and wide =
implementation, but may be missing on recent progresses in the b) land.
>>=20
>> Any thoughts ?
>>=20
>> Any published IETF material on the topic ?
>>=20
>=20
> I'd avoid T-MPLS -=20
>=20
> "Uncoordinated Protocol Development Considered Harmful"
>=20
> http://tools.ietf.org/search/rfc5704
>=20
> Regards,
> Mark.



home help back first fref pref prev next nref lref last post