Subject: [Ecrit] LoST Sync -08

From: "Hannes Tschofenig" <[email-masked]>
Date: Wed, 21 Oct 2009 00:37:02 +0300

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-ietf-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

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 22 Oct 2009 14:16:57 +0200

Hannes,

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.
However, shouldn't Figure 1 be labeled with LoST sync for every arrow?
Figure 3: shouldn’t the FG exchange mappings pointing to LoST servers
only and not mappings pointing directly to PSAPs?

karl heinz

On Tue, Oct 20, 2009 at 11:37 PM, Hannes Tschofenig
<[email-masked]> wrote:
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit
>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Thu, 22 Oct 2009 21:21:20 +0300

Hi Karl Heinz, 

Thanks for your quick feedback. 
 
>Hannes,
>
>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. 

>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? 

Ciao
Hannes

>> 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:
>>

---

From: Karl Heinz Wolf <[email-masked]>
Date: Thu, 22 Oct 2009 20:49:17 +0200

> the FG Finland. Although one could do that this is not really the idea of
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?

> example there is no other LoST server and hence it only exchanges what it

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?

karl heinz

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 23 Oct 2009 11:13:13 +0300

Hi Karl Heinz, 

>> 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 
>> example there is no other LoST server and hence it only 
>exchanges what 
>> it has.
>>
>> Does this make sense?
>
>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

>>>http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost-sync/
>draft-iet
>>>> f-ecri
>>>> t-lost-sync-08.txt
>>>>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 23 Oct 2009 12:44:50 +0300

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 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: [email-masked] [mailto:[email-masked]] 
>On Behalf Of Hannes Tschofenig
>Sent: 23 October, 2009 11:13
>To: 'Karl Heinz Wolf'
>Cc: [email-masked]
>Subject: Re: [Ecrit] LoST Sync -08
>
>Hi Karl Heinz, 
>
>
>>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?
>>
>

---

From: Karl Heinz Wolf <[email-masked]>
Date: Sun, 25 Oct 2009 21:52:50 +0100

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

> for Austria only (instead of re-distributing the mappings provided from it's

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

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 26 Oct 2009 11:38:53 +0200

>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. 

>> 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

>>>>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?
>>>
>>>
>>>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
>>>>>>