Re: globally unique identifiers for lightpaths?

[Erik-Jan Bos <erik-jan.bos@xxxxxxxxxx>]

Hi Ronald and Dave:

I too support the global naming of lightpath. As one of the "design
criteria" I think it should adhere to the KISS principle as much as
possible.

Hence, I think that the system we come up with should:
* Ensure uniqueness.
* Be maintenance free as much as possible (i.e. a name should not change
when one of the characteristics of the lightpath changes).
* Avoid any notion of a central authority or repository.
* Be able to generate a name on the spot by an organization (i.e.
without going back and forth with one or more peer organizations).

Hope this helps.

__

Erik-Jan.


David Reese wrote:
> Ronald,
> 
> I support the idea of a global name/number.  I would propose that it
> contain all of the local entity names and their local circuit names
> which make up the global lightpath (rather than embedded in the name per
> your last suggestion).
> 
> Dave Reese
> 
> On Dec 5, 2007, at 10:44 PM, Ronald van der Pol wrote:
> 
>> On Wed, Nov 21, 2007 at 14:42:20 +0100, Licia Florio wrote:
>>
>>> Dear all,
>>>
>>> Please find attached the minutes of the meeting held in Prague.
>>
>> Potential "Lightpath Management Group" members,
>>
>> One of the items that came up in Prague was global identifiers
>> for lightpaths. At the time I was not convinced this was needed.
>> That is beginning to change. The more lightpaths there are, the
>> more difficult it becomes to be sure that we are talking about
>> the same lightpath.
>>
>> One drawback that I still see is that it is an extra burden:
>> - for each new lightpath we need to come up with a name
>> - the name has to be put into the administration
>> - for those who want to keep local names the mapping
>>  between local name and global name needs to be put into
>>  the administration
>>
>> So, what do you think? Should we start using global names
>> for lightpaths?
>>
>> I think we should give it a try. If we agree we need a
>> naming convention. There are several possibilities.
>> Some examples:
>>
>> Just a unique ID consisting of a number.
>> pro: easy to generate
>> con: gives no semantical information at all
>> con: where do we keep a list of IDs that are already given out?
>>
>> end_site_1-end_site_2-number
>> pro: identies from where to where the lightpaths goes
>> con: no topological path information
>>
>> gole_1-gole2-....-gole_n-number
>> pro: topological information about the path
>> con: this can become a rather long string
>>
>> In the latter two cases the sourcing GOLE could give out the number.
>> This number has to be unique for that GOLE only (end_site_1 or
>> gole_1).
>>
>> Ideas? Comments?
>>
>>     rvdp
>>
>>
>