[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ecrit] LoST Sync -08
>Since lost-sync references RFC5582, it should be in sync with
>this RFC I would suggest.
Well. When one recognizes that a past document is not completely right there is also the option to revise it.
>
>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.
It is largely a configuration aspect, I believe.
Ciao
Hannes
>karl heinz
>
>>
>> In any case, here is the updated draft:
>>
>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/draft-iet
>> f-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
>>>
>>
>>
>_______________________________________________
>Ecrit mailing list
>Ecrit at ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit
>