Subject: Re: [Rserpool] Comments on draft-ietf-rserpool-asap-04.txt

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Sep 2002 13:07:37 -0500

Hi, Michael,

Tuexen Michael wrote:
> 
> Dear Randy, Qiaobing,
> 
> see my comments below. However one remark: I tried to
> use the cvs diff command to find quickly Qiaobings changes.
> What I found was that the whole document (every line) was changed.
> The cvs diff is correct, the doc has now DOS line endings. After
> I have made my changes I will check it in with UNIX one again. Or
> should I try MacOS ones? Just kidding.

This is due to that I used emacs, diff, and cvs from my Windows side and I forgot
to 'vi' those new lines out before committing the files. Will remember that next
time :-)

...
> > > A PEER_ERROR message is defined in ENRP v04 already.
> > Probably the same needs to be
> > > done for ASAP. Since ENRP and ASAP are on different paths,
> > > they need to define their error message separately.
> >
> > Either that or more fodder for the common parameters document...
> >
> A error cause is already available in the Common Parameter doc.
> I will commit text for that and also for the error causes of
> the common parameter doc.

Thomas and I meant to say that we also need a stand-alone op error *message* on
both asap and enrp side. I'd prefer to have separate ERROR msgs since asap and
enrp are using separate msg type space now. We can still make the msg type value
common btw them, e.g., we can, for both enrp and asap, define msg-type=0xfe as Op
Error (assuming we still reserve 0xff for ietf extension). 

I've already have this defined in ENRP v04 (but msg type is not 0xfe yet). I can
make the change to asap if this sounds ok.

> > >
> > >>- - NAME_RESOLUTION_RESPONSE, ENDPOINT_KEEP_ALIVE_ACK, COOKIE_ECHO,
> > >>SERVER_HUNT_RESPONSE must contain an optional "Operational
> > Error" parameter.
> > >
> > >
> > > Sounds reasonable. In addition, with
> > NAME_RESOLUTION_RESPONSE + Op Error, we
> > > probably can remove NAME_UNKNOWN.

I've added op error TLV to NAME_RESOLUTION_RESPONSE, but not to others. I can make
these changes to the asap xml, too.

...
> > >>- - There should be the pool policies "Random" and "Weighted Random":
....
> > > more justification may be needed for this one. Seems quite
> > > computation intensive to match a distribution function.
> > >
> > Well probably one could call the 'least used' a weighted distribution
> > since you are really talking that the weight is what the least used
> > is looking at :>

At this point I'd suggest that we do not add any more load policies to the base
asap draft. If there is the need to define some different policies right now, it'd
be better to put them in a separate draft(s). That way, it would be easier for us
to discuss and refine the policies without interfering with the progress of the
asap draft, and we could avoid adding more text "load" to the base asap draft :-)

...
> > >
> > >>- - SERVER_HUNT_RESPONSE should contain at least one Server
> > Information
> > >>Parameter. This is useful for 2 reasons:
> > >>1. The nameserver may use a port different from the
> > well-known nameserver
> > >>port.
> > >>2. The nameserver may support SCTP and TCP or SCTP only;
> > some pool users may
> > >>only support TCP and therefore are only interested in
> > TCP-capable nameservers.
> > >
> > > I am not sure about this one. I guess I don't quite see
> > your scenario here. If a
> > > nameserver is listening on a different ASAP port and the PE
> > is doing the hunt by
> > > the well-known port, the server will never receive the
> > server_hunt in the first
> > > place. If the server is responding, then it means that the
> > PE did the hunt on the
> > > right port. Secondly, if a PE is TCP-only, it will by
> > definition only do the hunt
> > > over TCP and any server that responds to the PE is by
> > definition TCP-capable.
> > >
> > Wait a minute. PE's have a requirment to register and use
> > SCTP. At least
> > I thought so.. when did this change? The PU can use TCP so maybe the
> > comments are good for PU's but I don't think they apply to PE's.

Randy, you are right. My mistake. I meant to say PU (not PE). But my comment is
still valid.

> This has not changed (at least I'm not aware of that). But one point
> here is that you use UDP Multicast with a specific port number P'.
> When the NS answers you know one of its IP-addresses. You can know
> start an SCTP association for registering using SCTP port P'' on
> the NS. Randy, I think you are assuming P'=P''. That has not been
> stated yet. The other point Thomas is bringing up is that if the PU
> (not PE) is TCP only and uses Server Hunt for getting IP addresses
> of NS only NS are of interest which support ASAP/TCP name resolution.
> This is a valid point on the one hand, on the other I would request
> all NS to provide ASAP over TCP AND SCTP. Then we do not have to
> put this information into the SERVER_HUNT_RESPONSE_MESSAGE.

Now I understand your scenario - a TCP-only PU does a server-hunt over IP m-cast
and ...

Correct me if I am wrong, but my understanding is that every NS SHOULD listen to
incoming ASAP on both TCP and SCTP on the well-known ASAP port, as well as to the
well-known ASAP multicast channel. If this is the case, the NS will receive the
server-hunt from the PU on the ASAP multicast channel. When sending the response,
the NS should already have the IP and port(?) of the PU (by looking into the
"from" address of the arrived m-cast packet). What the NS doesn't know is what
transport (SCTP or TCP) it should use to send back the server-hunt-resp. So, what
we really need, I think, is to add a transport TLV to the server-hunt message to
indicate how to response.

...
> > >
> > > Yes. At the end, we will have a well-known ENRP port and a
> > well-known ASAP port for the server.
> >
> > Why do we need a "well known" ASAP port number. Do you mean a
> > ASAP port for the name server to listen on? If so I agree...

Precisely.

regards,
-Qiaobing
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 27 Sep 2002 13:07:37 -0500

Hi, Michael,

...

...
....

...

...

Precisely.

regards,
-Qiaobing