Subject: VPN Identifiers

From: [email-masked]
Date: Sun, 10 Aug 2003 09:49:54 +0100

There has been some discussion on the mailing list regarding the VPN ID
naming space but I do not believe any consensus has been reached. This
subject was also discussed recently by a few colleagues within BT, it
focussed on 4 main questions:

1. How should the VPN ID be made globally unique?
2. Should the VPN ID be human readable or machine readable?
3. Should the VPN ID be fixed or variable length?
4. How big should the VPN ID be?

The discussion concluded that to support inter provider VPNs the VPN ID must
be have a globally unique element and a locally administered element, but
what should the globally unique element be? One possible solution would be
to use MAC OUI's, but what about service providers that don't have these?
Another possible solution would be to use AS numbers, but what about service
providers that don't have Internet connectivity and just want to provide
VPNs? The global element must be controlled by an appropriate authority but
we need to be able to re-use existing global IDs. Service providers will not
want to have to wait (weeks or even months) for new global IDs to be
allocated to provide VPNs.

From a management/provisioning perspective it would be useful if VPN IDs
were human readable. This would make it intuitively obvious by looking in
the RADIUS database or by looking at BGP advertisements which VPNs sites
belong to. One possible solution might be to use DNS, but this raises the
question whether VPN IDs should be of fixed or variable length? A fixed
length would be preferable so that they could be easily parsed and to make
it simpler to carry them in a signalling protocol, which leads on to the
question how long should they be? We need to get the length right the first
time to avoid problems in the future, one suggestion was to make the length
8 bytes.

Feedback on the above would be much appreciated.

Regards,

Richard

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 10 Aug 2003 12:16:22 +0200

Richard,

I think that "service providers that do not have Internet connectivity but
just want 
to provide VPNs" do not have to worry about global uniqueness of their VPN
IDs
because they cannot participate in inter-provider VPNs.

A single value in the global  idenifier namespace (whatever it is) could be
allocated 
to indicate that the VPN ID using this value as its global identifier is
actually 
a private VPN ID of this provider and its uniqueness is limited accordingly.

Did I miss something?

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Sunday, August 10, 2003 10:50 AM
> To: [email-masked]
> Subject: VPN Identifiers
> 
>

---

From: [email-masked]
Date: Sun, 10 Aug 2003 11:09:04 +0100

Sasha,

> because they cannot participate in inter-provider VPNs.

RS> Why can't a provider participate in inter-provider VPNs just because
they don't provide Internet connectivity via their VPN network? What if the
VPN network is an MPLS network, who says the provider will be using the
Internet IPv4 address space for addressing, or that they will even be using
IPv4 addresses? Providers already offer inter-provider/transit VPNs where IP
doesn't enter into the equation at all, e.g. ATM VPNs where the ATM network
has its own separate address space.
 
> a private VPN ID of this provider and its uniqueness is 

RS> Agreed but this doesn't answer any of the original questions, i.e. type
of global identifier, VPN ID length, format etc.

Richard

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 10 Aug 2003 13:18:14 +0200

Richard,

I have not expressed my position accurately enough.

What I intended to say is that if a provider communicates with the
other providers for whatever reason (e.g., for providing inter-provider
VPNs), it probably has AS number(s) assigned to its network.
And, vice versa, a provider that does not have any AS numbers assigned
probably cannot communicate with the other providers.

Whether Internet access is or is not provided as part of the VPN
service is not relevant.

And, IMO, VPNs provided over networks that do not use IPv4/IPv6 addresses
(like ATM networks you have mentioned) are out of scope of this WG. 
The current WG charter defines its scope as following:

<quote>
The WG is responsible for standardization of the following solutions:

1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
  across an IP and an MPLS-enabled IP network, allowing standard
  Ethernet devices communicate with each other as if they were
  connected to a common LAN segment.
  
2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
  point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
  point-to-point Ethernet) across an IP and an MPLS-enabled IP network.

3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
  IP network, allowing standard IP devices to communicate with each
  other as if they were connected to a common LAN segment or a point-
  to-point circuit.
<end quote>

As you see, it mentions IP networks (MPLS-enabled or not) as
the only type of networks over which the L2 VPN services are
provided.

With best regards,
                                   Sasha Vainshtein

> Sent: Sunday, August 10, 2003 12:09 PM
> To: Sasha Vainshtein
> Cc: [email-masked]
> Subject: RE: VPN Identifiers
> 
> 
> Sasha,
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Mon, 11 Aug 2003 13:57:31 -0400

Eric,

> 
> 
> 
> 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? 
> 
> 

Yes. Actually I was going to suggest to the WG to
consider the gid draft as part of the vpn identifiers 
discussion. 

It looks to me all what is needed is a format that guarantees
uniqueness of the id route target and 2685 formats. 
It's length is however limited to 8 octets in length. 
I personally don't see a requirement to support variable length 
gids at this point in time.

Hamid.

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Tue, 12 Aug 2003 14:15:33 -0400

Richard,

[clipped...]

> 
> The point is that currently different mechanisms use different VPN ID
> formats. 

I would say instead "different mechanisms use different global unique
identifiers some of them are intended to uniquely identify a VPN."

>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.

draft-ouldbrahim-ppvpn-gid-03.txt tries to define formats for 
supporting global unique identifiers mainly intended for VPN 
solutions and mostly targeting control planes, and among these 
formats it supports the route target and RFC2685 formats within
an 8 octets length field. These ids are required to be unique 
only within a given solution and they do not necessarily identify 
a VPN. A particular solution may decide to assign a gid to uniquely 
identify a VPN if it wants to, and may want to use gids for other
purposes as well. 

The draft does not solve the problem of defining a unique VPN-ID 
format intended to be used everywhere across all solutions including 
management. In my view if one wants to solve this problem and enforce 
that id on all solutions and on all the components of a given solution
then there is already rfc2685 standard which pretty 
much meets the definition you mentioned below. Whether solutions 
within l2vpns will be using it everywhere is obviously 
another thing. 

Hamid.

> > From: Eric Rosen [mailto:[email-masked]]
> > Sent: 11 August 2003 18:26
> > To: Spencer,R,Richard,XGH5 R
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: VPN Identifiers 
> > 
> > 
> >

---

From: [email-masked]
Date: Wed, 13 Aug 2003 14:16:10 +0100

Mark,

I agree with you.  But I also want to emphasis another point Richard made in
an earlier mail.....that is, we should decouple identifiers (by they names,
as here, or addresses) from other functional components, like specific
instances of routing or signalling protocols.  In the case of named entities
these are either abstract 'group' objects (like a VPN-ID) or an external (to
the network, but may bind to a network access point address) 'single'
objects.  Further, addresses belong to network access points in the
data-plane and quite clearly ought to be able to be used with any signalling
(or routing) protocol.....including case of 'none'.

regards, Neil

> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: 13 August 2003 13:47
> Cc: [email-masked]; [email-masked]
> [email-masked] wrote:
> >>Eric:
> >>With regard to the requirements you've  stated, I don't think 
> >>it matters how many different methods there are for  producing 
> >>VPN-ids, as long as there is no ambiguity introduced into the 
> >>encodings. 
> > 
> > 
> > I agree, but only if the same encodings are supported by 
> all the VPN drafts.
> > For example, lets say a network operator decides that they 
> want to deploy a
> > VPLS service today using BGP auto-discovery along with LDP 
> signalling. BGP
> > auto-discovery has an 8 byte field that can be used to 
> encode an RFC2685 VPN
> > ID, but the LDP signalling draft currently uses has a 4 
> byte VC ID to
> > identify a VPN. So what VPN ID format should the operator use? The
> > alternatives seem to be i) use 4 byte VPN ID in both, or ii) use two
> > different VPN IDs and map/translate between the two. Option i) has
> > scalability/global uniqueness issues and option ii) 
> requires multiple VPN
> > IDs to be provisioned/managed. If there are operators that 
> have deployed
> > VPLS using a combination of these two mechanisms or there 
> are alternative
> > options then I would be interested in hearing about them.
> > 
> > Looking at things from a vendors perspective specifying a 
> single VPN ID
> > format would make implementation simpler/cheaper. Looking 
> at things from an
> > operators perspective as long as ALL the VPN ID formats are 
> supported by ALL
> > the VPN protocols/systems that need to use VPN IDs then 
> there is no issue.
> > The provider can just select whichever VPN ID meets their 
> requirements
> > without having to worry about which mechanisms support 
> which VPN ID format.
> > The issues arises when the operator has to manage multiple 
> VPN IDs or
> > perform VPN ID translation because the mechanisms/systems 
> the operator wants
> > to implement use different VPN ID formats.
> > 
> > Richard
> 
> Ambiguity between VPN ID formats or not, isn't the real point 
> that you can't 
> turn 8 octets into 4 without losing a significant amount of 
> information? The 
> showstopper I see here is with the unacceptably low common 
> denominator 
> introduced by the 4 octet VCID used by LDP signaling today 
> more than anything else.
> 
> draft-rosen-ppvpn-l2-signaling-03.txt addresses the current 
> LDP limitation, and 
> L2TPv3 has used a variable length endpoint identifier since 
> day one. Perhaps the 
> 4-octet IDs should be banished to manual setup only, and the 
> 8+ octet format(s) 
> used for pseudowires setup via auto-discovery.
> 
> - Mark
> 
> 
> > 
> >  
> > 
> > 
> 
> 
>

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Wed, 13 Aug 2003 12:12:22 -0400

Eric,

> 
> 
> 
> Richard> If there is  consensus that this is  the best VPN ID 
> to  use then I
> Richard> would like to see all the drafts support its use. 
> 
> Not much chance of that. 
> 
> No one has presented a requirement for a single kind of VPN id. 
> 

Yes. That is why I think the simplest approach is to use GIDs and 
each solution can equate gid to vpn-id in all its 
components if it wants to including management, and the
operator picks the format it prefers supported within
a given solution. Looks to me a pragmatic proposal.

Hamid.