RE: VPN Identifiers

richard.spencer@bt.com Tue, 12 August 2003 16:34 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 MAA20870 for <l2vpn-archive@odin.ietf.org>; Tue, 12 Aug 2003 12:34:35 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc66-0001dw-6R for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 12:34:10 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7CGYANm006311 for l2vpn-archive@odin.ietf.org; Tue, 12 Aug 2003 12:34:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc66-0001di-2d for l2vpn-web-archive@optimus.ietf.org; Tue, 12 Aug 2003 12:34:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20845 for <l2vpn-web-archive@ietf.org>; Tue, 12 Aug 2003 12:34:04 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mc64-00026O-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 12:34:08 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mc64-00026K-00 for l2vpn-web-archive@ietf.org; Tue, 12 Aug 2003 12:34:08 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc5x-0001cL-AI; Tue, 12 Aug 2003 12:34:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mc5w-0001c0-5B for l2vpn@optimus.ietf.org; Tue, 12 Aug 2003 12:34:00 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20832 for <l2vpn@ietf.org>; Tue, 12 Aug 2003 12:33:54 -0400 (EDT)
From: richard.spencer@bt.com
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mc5u-000268-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 12:33:58 -0400
Received: from saturn.bt.com ([193.113.57.20] helo=cbibipnt02.HC.BT.COM) by ietf-mx with esmtp (Exim 4.12) id 19mc5t-00025y-00 for l2vpn@ietf.org; Tue, 12 Aug 2003 12:33:57 -0400
Received: by cbibipnt02.hc.bt.com with Internet Mail Service (5.5.2654.89) id <QXLGYB34>; Tue, 12 Aug 2003 17:33:35 +0100
Message-ID: <B5E87B043D4C514389141E2661D255EC019C0FEE@i2km41-ukdy.nat.bt.com>
To: erosen@cisco.com
Cc: l2vpn@ietf.org
Subject: RE: VPN Identifiers
Date: Tue, 12 Aug 2003 17:33:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2654.89)
content-class: urn:content-classes:message
Content-Type: text/plain; charset="ISO-8859-1"
Sender: l2vpn-admin@ietf.org
Errors-To: l2vpn-admin@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Id: <l2vpn.ietf.org>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>

Eric,

The VPN ID needs to be used in provisioning, auto-discovery, signalling and
AAA. So whatever VPN ID format is defined will have to be supported by
automated provisioning systems, auto-discovery mechanisms, signalling
mechanisms and AAA mechanisms. VPN ID format support should not be dependant
on the mechanisms used. A provider should be able to select which mechanisms
they want to use without having to worry about what VPN ID formats they
support. For example, a provider might deploy a VPN network using signalling
mechanism X and AAA mechanism B, but later decide to change over to
signalling mechanism Y. In this scenario the provider should not have to
completely reconfigure its AAA database because signalling mechanism X uses
a different VPN ID format to signalling mechanism Y.

As described in your signalling draft, RFC2685 VPN IDs could be used in BGP
based auto-discovery/signalling as they can be encoded as Route
Distinguishers/Targets. However, the draft also states that any other method
of assigning a unique identifier to a VPLS and encoding it as an RD will do.
The LDP VPLS draft currently uses a VC ID, although the draft states that
this will be replaced with a VPN ID TLV. The RADIUS discovery draft
currently uses a variable length VPN ID which has the format:
vpnY.domainZ.net, although this could be anything and is just used as an
example.

The point is that currently different mechanisms use different VPN ID
formats. If it is decided that draft-ouldbrahim-ppvpn-gid-03.txt is the best
VPN ID format to use then that's fine, but for inter-dependency and
interoperability reasons it should be used across all VPN mechanisms.
Looking at draft-ouldbrahim-ppvpn-gid-03.txt, do we really need 4+ different
naming methods for a VPN? I think two options for global identifiers at the
most should be sufficient, i.e. AS#, or OUI, although obviously one global
ID would be preferable.

Richard

> -----Original Message-----
> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: 11 August 2003 18:26
> To: Spencer,R,Richard,XGH5 R
> Cc: Sasha@AXERRA.com; l2vpn@ietf.org
> Subject: Re: VPN Identifiers 
> 
> 
> 
> We already  have an  8-byte VPN-Id format  which can  be 
> based either  on AS
> numbers or on OUIs, and is  extensible to other possibilities 
> as well.  Have
> you looked at draft-ouldbrahim-ppvpn-gid-03.txt? 
>