Subject: RE: VPN Identifiers

From: [email-masked]
Date: Sun, 10 Aug 2003 23:25:39 +0100

Sasha,

Thank you for expressing your position on this subject. I agree that if a
provider communicates with other providers today it will have AS numbers
assigned to its IP/MPLS network.

However, I am approaching this problem from the viewpoint that MPLS networks
in the future might not necessarily use the Internets IPv4 address space. I
agree that this is currently out of scope as far as this working group is
concerned, but I would like to see a VPN ID format defined that could be
used regardless of what VPN address space is used. For example, a service
provider may choose to use an out-of-band control plane and a centralised
routing/signalling mechanisms along with IPv6 addressing for its MPLS VPN
network. I am not saying that BT or any other providers consider this to be
the best approach, but it is one option and I know of at least one vendor
that supports this functionality.

However, just because IPv4 addressing might not be used by some providers in
the future, this does not mean that AS numbers should not be used as global
identifiers, just that this raises the question regarding how easy it will
be for VPN providers that do not offer Internet connectivity to obtain AS
numbers. This is a minor point and does not even apply to BT which does
offer Internet connectivity, I'm just attempting to explore what the global
element of the VPN ID should be and what the format/length should be.

I am also approaching this problem from the viewpoint that VPN IDs *could
be* used across multiple VPN technologies e.g. ATM, SHD/SONET, MPLS, IP,
etc. I agree that this too is currently out of scope as far as this working
group is concerned, but from a providers perspective it would be *very
useful* if the same VPN ID could be used across all VPN technologies. So for
example, a provider might use the same auto-discovery mechanism and the same
VPN ID format for L1 VPNs across SDH/SONET, L2 VPNs across MPLS, and L3 VPNs
across IP. 

I realise that this approach and thinking is out of scope as far as this
working group is concerned, but the VPN ID defined in this working group for
IP/MPLS will have to be used (or translated) by any provider that wants to
re-use VPN IDs across some or all VPN technologies. 

As long as the VPN ID format defined within this working group does not
impose any scalability restrictions and is globally unique I can't see any
reason why it can't be used across different VPN network technologies.

Thanks,

Richard

> -----Original Message-----
> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 10 August 2003 12:18
> To: Spencer,R,Richard,XGH5 R
> Cc: [email-masked]
> Subject: RE: VPN Identifiers
> 
> 
> 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
> 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 12:09 PM
> > To: Sasha Vainshtein
> > Cc: [email-masked]
> > Subject: RE: VPN Identifiers
> > 
> > 
> > Sasha,
> > 
> > > 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.
> > 
> > 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 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.
> > 
> > RS> Agreed but this doesn't answer any of the original 
> > questions, i.e. type
> > of global identifier, VPN ID length, format etc.
> > 
> > Richard
> > 
> > > 
> > > 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
> > > > 
> > > > 
> > > > 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: Eric Rosen <[email-masked]>
Date: Mon, 11 Aug 2003 13:25:38 -0400

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?