Re: comments to ASAP.. and a few for ENRP

Randall Stewart <[email protected]> Wed, 28 Jun 2006 09:42:27 -0400
Newsgroups gmane.ietf.rserpool
Message-ID <[email protected]>
All:

And another thought as I work through implementing
the PE/PU side stuff..

In the Pool Element are two sets of transport
addresses:

User Transport Param

ASAP Transport Param.


Now, the ASAP param must be SCTP...

What is the purpose of this entry?

The document is not clear and, in thinking about its uses
I can come up with a couple of  scenario's none of which I like:

a) The ASAP TP is the communication endpoint used by the
    PE to register and talk to the ENRP server... problem with
    this IMO is that the PU does NOT need this information! Now
    it may be here implicitly since ENRP and ASAP use the
    same message format.. if so thats ok.. we just need to
    make sure the parameter is NOT sent in a name-resolution-resp
    by the ENRP server... this needs to be documented if so..

b) The ASAP TP is used when the peer has a different DATA transport
    (say UDP) and wants to still communicate with ASAP.. i.e. we
    end up with seperate control and data connections/paths.
    This, I think, is the real purpose of this info.. and I don't
    like it one bit. Why, it really becomes a mess if you allow
    seperate PU <-> PE data and asap communication. The issue is
    coordination. We have, over the PE<->PU control side a number
    of messages (COOKIES, BUSINESS-Cards ... etc).. The COOKIE, for
    example, needs to arrive first.. ahead of anything else to assit
    the PE in building state... But coodinating between two transports
    is a royal pain.. and much more difficult.  IMO if the user wishes
    to use UDP for DATA only, then thats ok.. they work at a more
    primitive level.. and don't get all the benefits necessarily...

If the transport for data is control+data then no matter how you
slice it in the case of <b> its redundant .. since it should contain
the same information...


So, I think we should cut the ASAP transport parameter out of the
PE message unless ENRP uses it between its peer servers... have
not looked at that aspect.. but if its for multiple connections
between PU-PE.. I think it will be more headache then usefulness.

Comments??

R


-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)