[Rserpool] FW: [Fwd: Re: Review: draft-ietf-rserpool-arch-11.txt] Baker comments

["Ong, Lyndon" <[e-mail]>]

Third response from Randy.

L. Ong

--- Begin Message ---

Fred:

A better exam such running on  the same 
> physical hardware) that has registered with a pool server. 
Yep, if I start 20 copies of the process foo, which all
register has "randall".. they all are on the same machine and
provide the "randall" service... Hopefully I would start
them on multiple boxes too :-D


  Instead of
> focusing on the hardware it runs on (the server), could  you call it an 
> "application instance" or an "instance of an  application", and the pool 
> itself a pool of application instances?

Amen.. we needed you to be present in the naming wars of the past..

I like the term application instance and "pool of application
instances". Much more clear to me and hey, even though its not
my previous terms .. I don't have to have a mental image and
translate between the two :-D

> 
> I'm a humble engineer. I just make stuff work. When I define terms, I  
> usually try to do so in a manner that will help me point to objects  in 
> pictures. So far, the terminology in this document has me  completely 
> lost. If you were to explain it in English...

I cannot disagree.. since I never agreed with the terminology myself :-D

> 
>> 2.1.2.  ENRP Servers
>>
>>    The second class of entities in the RSerPool architecture is the
>>    class of ENRP servers.  ENRP servers are designed to provide a  fully
>>    distributed fault-tolerant real-time translation service that  maps a
>>    pool handle to set of transport addresses pointing to a specific
>>    group of networked communication endpoints registered under that  pool
>>    handle.
> 

boy is the above not a confusing set of gibberish :-D

> 
> what is a "transport address"?

A transport address is a open socket that some application is
listening on for messages :-D Usually a IPaddress+Port+Protocol type.


> 
> I can tell you what a TSAP is, or a TCEPID, if that is what you're  
> getting at. A TSAP is the name a transport client uses to identify  its 
> connection to the transport, and a TCEPID is the name used to  identify 
> the transport in a a remote system when talking to the  network layer 
> and asking for connectivity (it translates to an NSAP  and a 
> multiplexing ID). In the IP architecture we don't talk much  about those 
> concepts, though - that's OSI. We generally talk about  the network 
> layer having addresses and the transport layer having  ports, and when 
> talking to a remote application we talk about the  network address and 
> transport port number that the application is using.

The combination of an IP address + Port is a transport address.. this
is a term we put into SCTP.. I think... and has echoed into these
documents... I still don't like the 2.1.12 paragraph :-D


> 
> If that is what you're calling a "transport address", you'd best  define 
> the term. The text in this section about the destination  address, 
> protocol, and port might be a good starting point.

Hmm I am surprised or maybe not.. that its not defined in the document
:-0

> 
> Or if you really mean an internet address, say so. We have enough  
> confusion in the IETF with bellheads that call the physical layer the  
> "transport". We don't need people misidentifying the internet  sublayer 
> of the network layer as the "transport" too. SCTP and TCP  are 
> transports - that's what the "T" stands for.

Yep..


> 
>> 2.1.3.  Pool Users
>>
>>    A third class of entities in the architecture is the Pool User (PU)
>>    class, consisting of the clients being served by the PEs of a  server
>>    pool.
> 
> 
> What on God's Green Earth is a "user" in this situation? Is it a  
> person? An application? What?

To me its a client application that wants to use the pool aka
a client that wants to gain access to an application instance
to service a request...

> 
>> 2.2.2.  Aggregate Server Access Protocol
>>
>>    The PU wanting service from the pool uses the Aggregate Server  Access
>>    Protocol (ASAP) to access members of the pool.
> 
> 
> OK. So I'm a pool user (kid in a bathing suit, ple might be IP-Fix or say BGP..

I have a pool of IP-Fix collectors.. and some
number of routers that want to be PU's... aka
the client that sends data to the collectors.

Or.. I have a pool of BGP Servers that also act
as clients .. you point your two pools at each
other.. some at ISP-1 and the other at ISP-2..

Now your BGP servers talk over rserpool to each
other in a peer-2-peer form.. if one of them
fails.. it fails over to another WITHOUT withdrawing
routes... necessarily..

Hmm.. Maybe I can construct a more sensical example
with these :-D

R


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)

--- End Message ---

_______________________________________________
rserpool mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rserpool