RE: VPN Identifiers

[[e-mail]]

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

> -----Original Message-----
> From: W. Mark Townsley [mailto:[e-mail]]
> Sent: 13 August 2003 13:47
> To: Spencer,R,Richard,XGH5 R
> Cc: [e-mail]; [e-mail]
> Subject: Re: VPN Identifiers
> 
> 
> 
> 
> [e-mail] 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
> 
> 
> > 
> >  
> > 
> > 
> 
> 
>