Subject: Addressing Architecture for VPN Identifier

From: "Tissa Senevirathne" <[email-masked]>
Date: Thu, 08 Aug 2002 15:06:23 +0000

I thought to start a discussion to see how approriate to re-visit VPN 
addressing architecture ? Below is some of the thoughts. Please feel free to 
comment

What is a VPN identfier?
Is it numerical representation or numerical and semantic representation ? 
When there is more than one flavour of VPN, it appears that both numerical 
and semantic representation is important.

Presently RFC 2685 is the only standardized method for VPN identification. 
In practical sense 2685 format is not widely used. On the other hand 2685 
was designed when only L3 VPN was in use. Lately, various classes of VPN has 
become popular and global VPN discovery has become an important subject. 
(well that 56 bit alignment is creating interesting challanges whenever I 
try to encode this thing in a PDU )

More recently there is discussion on ability to use different VPN signaling 
and discovery methods within the same PE, just like different routing 
protocols are used. Also there is discussion on unified signaling and 
discovery methods.

I feel that, re visiting the VPN  addressing architecture would help to 
solve some of the issues and allow proper identification/administration of 
VPNs.

Some of the Requirements I though applicable are:

. Mutually exclusive address space for VPN classes(L3,L2..)

   . Address space for private VPN addresses

   . Address space for official addresses allocated by addressing
   authority.

   . Ability to encode VPN attribute as part of the address.

   . Structure (Format and the size ) of VPN identifier should be 
implementation and algorithm friendly. (e.g. in a 32 bit machine 32 or 64 
bit aligned numbers can be handled much more efficiently than 56 bit number)

Some background discussion:

VPN discovery methods that is being discussed presently, can be used to 
discover various types of VPN (VPRN, VPLS, VPWS etc..). However, it is 
important that PE devices has ability to identify the type of VPN that was 
discovered. This may be achieved by having discovery method specific 
attributes,.

There are few disadvantages to this method. Firstly, some discovery methods 
may lack such ability. Discovery specific attributes needed to be available 
in the VPN policy engine (or another words VPN policy module need to know 
how to interpret discovery attributes). In the same time ability to use 
multiple discovery methods or signaling methods may be restricted because of 
the fact each discovery method is using it’s own set of attributes, (or lack 
of it)

However, having an addressing architecture that has structure to identify 
VPN type and other VPN attributes, allows to consolidate VPN policy and also 
allows to mix and match different discovery methods. Or possibly use it in a 
way close to routing protocols interact in one system.

On the other hand , with a structured VPN address, network administrators 
may be simply looking at an address can tell it is VPRN , VPLS etc.. As of 
2685 this is one of  any possible numerals in 2^32 bit number and different 
providers may choose to use different methods to number VPRN, VPLS etc..

Thanks

Tissa

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: Sam Kumaran <[email-masked]>
Date: Fri, 9 Aug 2002 06:29:31 +0100 (BST)

I think you are trying to play neutral by saying
2685 address format is not widely used.. IMHO 2685
should not have been a standard.

 Re-visiting address architecture is very important,
specially the fact PPVPN charter (as stated on the WG
page) is closing in December.

Sam

>From: "Tissa Senevirathne" <[email-masked]>
>To: [email-masked]
>Subject: Addressing Architecture for VPN Identifier
>Date: Thu, 08 Aug 2002 15:06:23 +0000
>
>I thought to start a discussion to see how approriate
to re-visit 
>VPN addressing architecture ? Below is some of the
thoughts. Please 
>feel free to comment
>
>What is a VPN identfier?
>Is it numerical representation or numerical and
semantic 
>representation ? When there is more than one flavour
of VPN, it 
>appears that both numerical and semantic
representation is 
>important.
>
>Presently RFC 2685 is the only standardized method
for VPN 
>identification. In practical sense 2685 format is not
widely used. 
>On the other hand 2685 was designed when only L3 VPN
was in use. 
>Lately, various classes of VPN has become popular and
global VPN 
>discovery has become an important subject. (well that
56 bit 
>alignment is creating interesting challanges whenever
I try to 
>encode this thing in a PDU )
>
>More recently there is discussion on ability to use
different VPN 
>signaling and discovery methods within the same PE,
just like 
>different routing protocols are used. Also there is
discussion on 
>unified signaling and discovery methods.
>
>
>I feel that, re visiting the VPN  addressing
architecture would help 
>to solve some of the issues and allow proper 
>identification/administration of VPNs.
>
>implementation and algorithm friendly. (e.g. in a 32
bit machine 32 
>or 64 bit aligned numbers can be handled much more
efficiently than 
>56 bit number)
>VPN discovery methods that is being discussed
presently, can be used 
>to discover various types of VPN (VPRN, VPLS, VPWS
etc..). However, 
>it is important that PE devices has ability to
identify the type of 
>VPN that was discovered. This may be achieved by
having discovery 
>method specific attributes,.
>
>There are few disadvantages to this method. Firstly,
some discovery 
>methods may lack such ability. Discovery specific
attributes needed 
>to be available in the VPN policy engine (or another
words VPN 
>policy module need to know how to interpret discovery
attributes). 
>In the same time ability to use multiple discovery
methods or 
>signaling methods may be restricted because of the
fact each 
>discovery method is using it’s own set of attributes,
(or lack of 
>it)
>
>However, having an addressing architecture that has
structure to 
>identify VPN type and other VPN attributes, allows to
consolidate 
>VPN policy and also allows to mix and match different
discovery 
>methods. Or possibly use it in a way close to routing
protocols 
>interact in one system.
>
>On the other hand , with a structured VPN address,
network 
>administrators may be simply looking at an address
can tell it is 
>VPRN , VPLS etc.. As of 2685 this is one of  any
possible numerals 
>in 2^32 bit number and different providers may choose
to use 
>different methods to number VPRN, VPLS etc..
>
>Thanks
>
>Tissa
>
>
>

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com