Subject: [Ecrit] Mapping Architecture Question

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 21 Sep 2006 03:07:32 -0400

Hi all,

consider the following picture from draft-ietf-ecrit-mapping-arch-00.txt:

           /-\        /-\        +-----+                 +-----+
          | S +******* R *********  FG *-----------------+  FG |
           \-/        \-/        |     |*                |     |
                                 +--+--+  *              +--+--+
                                    |      *                |
                                    |       *               |
                                    |        *              |
                                    |        *              |
                      /-\        +--+--+     *           +--+--+
                     | R +------>+  FG +-----*-----------+  FG |
                      \-/        |     |     *           |     |
                                 +--+--+    *            +--+--+
                                    |      *                |
                                    |     *                 |
                                    |    *                  |
                                    |***                    ^
                                   / \                     / \
                                  /   \                   /   \
                                 /     \                 /     \
                                /       \               /       \
                               -----------             -----------
                                 tree                     tree

What does each entity need to know?

* Seeker: It only needs to be configured with a resolver (=LoST server). 
See DHCP and DNS-based mechanism (i.e., a dynamic discovery mechanism).

* Resolver: It needs to be configured with the FG address, i.e., it 
needs to know at least one FG. Ideally, it knows which FG is responsible 
for which region. In this case it might just contact the right FG 
without contacting FGs. Additionally, the resolver might also know some 
other LoST servers within its tree to speed-up search.

I assume that the addresses of FGs and LoST servers a resolver knows is 
largely based on manual configuration?

The resolver will also cache service boundaries to speed up future 
search attempts.

* Forest Guide: The FGs need to be aware of each other. This is most 
likely be based on manual configuration. For example, the FG is manually 
configured with the address of the FG in Germany. The FG also needs to 
know the service boundaries of each FG. This might also be exchanged out 
of band.

Are my observations largely correct?

Ciao
Hannes

PS: The term 'tree' is a bit misleading since it collectively refers to 
the LoST server below a FG. The figure only shows resolves that are part 
of this tree but does not depict authoritative LoST servers.

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 21 Sep 2006 23:07:52 -0400

I write this at an airport without Internet connectivity and before I see
what Henning has in mind.

What I believed was that the FGs discovered each other, they were not
configured.  I could understand some kind of a boot process which had some
configuration data, but I thought the idea was that it was more or less a
free for all in FGs, which meant there was a possibility of two FGs giving
conflicting information on the resolvers.

I did expect the resolver to be configured with at least one FG to get
started.

Brian

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, September 21, 2006 3:08 AM
> To: ECRIT
> Subject: [Ecrit] Mapping Architecture Question
> 
> Hi all,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 24 Sep 2006 20:11:54 -0400

Please see below:

On Sep 21, 2006, at 3:07 AM, Hannes Tschofenig wrote:

> * Seeker: It only needs to be configured with a resolver (=LoST  
> server). See DHCP and DNS-based mechanism (i.e., a dynamic  
> discovery mechanism).

Agreed.

> needs to know at least one FG. Ideally, it knows which FG is  
> responsible for which region. In this case it might just contact  
> the right FG without contacting FGs. Additionally, the resolver  
> might also know some other LoST servers within its tree to speed-up  
> search.
>

Agreed on the needs-to-know one part. Caching takes care of the  
latter issue, without any special mechanism.

> I assume that the addresses of FGs and LoST servers a resolver  
> knows is largely based on manual configuration?

I don't like manual configuration, but since this involves trust and  
policies/politics, I don't see much hope for something else. If the  
forest guide is run by the VSP, one can imagine that this is  
configured in the same way as for resolvers, using the VSP's domain  
name.

> The resolver will also cache service boundaries to speed up future  

Service boundaries and mappings, yes.

>
> * Forest Guide: The FGs need to be aware of each other. This is  
> most likely be based on manual configuration. For example, the FG  
> is manually configured with the address of the FG in Germany. The  
> FG also needs to know the service boundaries of each FG. This might  
> also be exchanged out of band.

Yes.

> PS: The term 'tree' is a bit misleading since it collectively  
> refers to the LoST server below a FG. The figure only shows  
> resolves that are part of this tree but does not depict  
> authoritative LoST servers.

Resolvers aren't really part of the tree, since the tree is for  
authoritative servers only. Did I mess this up in the draft?