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)