[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] LoST Sync -08
Hi Karl Heinz,
>>>I looked at the diff and have some comments. First I think
>it is good
>>>to have an example with a figure to better understand how it works.
>>
>> Thought so too.
>>
>>>However, shouldn't Figure 1 be labeled with LoST sync for
>every arrow?
>>
>> One could use LoST sync also in other places but in my example the
>> synchronization only happens between the FGs.
>>
>> I thought it would confuse if I indicate LoST Sync also between the
>> Austrian FG and the 3 LoST servers. The reader could easily get the
>> impression that the boundaries stored at these three servers
>are then
>> further distributed to the FG Finland. Although one could do
>that this
>> is not really the idea of the FG.
>ok, I see, so you wanted to prohibit that someone thinks that
>the mapping data will be syncronized all the way to the Finish FG?
>
>I have a suggestion for a different (maybe additional?)
>example: why not show the usage of LoST-sync between two LoST
>servers in the same cluster synchronizing complete mappings
>and one LoST server pushing up it's coverage reagion. Perhaps
>this makes it clearer, what do you think?
>
I am OK with additionally describing how the LoST servers push their
mappings up to the FG.
>>>Figure 3: shouldn't the FG exchange mappings pointing to
>LoST servers
>>>only and not mappings pointing directly to PSAPs?
>>
>> The FG exchanges whatever it is configured to exchange. In
>the Finland
>> example there is no other LoST server and hence it only
>exchanges what
>> it has.
>>
>> Does this make sense?
>
>I just looked at RFC 5582: "Forest guides do not provide
>mapping information
> themselves, but rather redirect to mapping servers."
>
>I would argue that having the URI of the PSAP is a mapping
>information, and therefore not intented to be contained in the
>FG. As you write in your draft, Finland has one server acting
>as forest guide and mapping server, I would say when acting as
>a FG it would have to distribute something pointing to itself
>when doing a lost-sync with another FG. Does this make sense?
It is true that the definition in RFC 5582 seems to suggest that.
However, when you consider that the FG must have the mapping data of all its
immediate children (in our case of the three LoST servers for the Austrian
FG) then this definition already seems a bit outdated. When a LoST request
gets sent to a FG it then has to look at the mappings it has to indicate to
what other LoST server one has to talk to.
One could, of course, configure the Finnish FG in a way that it matches the
definition, namely by letting the mapping to point to a FG again (which
co-locates the LoST server).
This would be possible, no doubt, but it is worth the additional layer of
indirection? I can still make the change.
Ciao
Hannes
>
>karl heinz
>
>> Ciao
>> Hannes
>>
>>>
>>>karl heinz
>>>
>>>On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig
>>><Hannes.Tschofenig at gmx.net> wrote:
>>>> Hi all,
>>>>
>>>> A little while ago we had a discussion about the LoST sync
>document
>>>> and I now provided the update and added a more descriptive example.
>>>> Please find the latest version here:
>>>>
>>>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/
>draft-iet
>>>> f-ecri
>>>> t-lost-sync-08.txt
>>>>
>>>> Let me know if the update addresses the raised comments.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> PS: I believe the discussion started with this comment:
>>>> http://www.ietf.org/mail-archive/web/ecrit/current/msg06634.html
>>>>
>>>>
>>>> _______________________________________________
>>>> Ecrit mailing list
>>>> Ecrit at ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ecrit
>>>>
>>>
>>
>>
>