Re: [Ecrit] LoST Sync -08

[Karl Heinz Wolf <khwolf1 at gmail.com>]

Since lost-sync references RFC5582, it should be in sync with this RFC
I would suggest.

On Fri, Oct 23, 2009 at 10:44 AM, Hannes Tschofenig
<Hannes.Tschofenig at gmx.net> wrote:
> Btw, I noticed that there are even more ways to deploy it. For example, the
> Austrian FG could distribute a single mapping that says it is responsible
> for Austria only (instead of re-distributing the mappings provided from it's
> child LoST servers).

In this case it would be necessary to have a LoST server at the top of
the Austrian tree the FG can refer to. This LoST server would direct
requests to the West, East and Vienna servers, respectively.

karl heinz

>
> In any case, here is the updated draft:
> http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-ietf-ecri
> t-lost-sync-08.txt
>
> Let me know if you like it better now.
>
> Ciao
> Hannes
>
>
>>-----Original Message-----
>>From: ecrit-bounces at ietf.org [mailto:ecrit-bounces at ietf.org]
>>On Behalf Of Hannes Tschofenig
>>Sent: 23 October, 2009 11:13
>>To: 'Karl Heinz Wolf'
>>Cc: ecrit at ietf.org
>>Subject: 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
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>_______________________________________________
>>Ecrit mailing list
>>Ecrit at ietf.org
>>https://www.ietf.org/mailman/listinfo/ecrit
>>
>
>