WG Last Call on ASAP and ENRP specifications

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool

Re: WG Last Call on ASAP and ENRP specifications

All:

I have a LOT of comments yet to make on asap and a couple
of tweaks (if I remember right) to suggest for the
common-param's... How I am coming up with these is
by "eatting my own dog-food" and implementing asap
based on the spec..

Now that being said, I am doing this mainly at 30,000 feet it
seems.. and I am still not done implementing ASAP... there
is no way I will get to ENRP (which I bet will have has many
or MORE comments then I have already collected in my
annotated version of asap-13)...

I will try to convert my comments on ASAP into an email
tommorrow at 30,000 feet again as I travel back from
networkers... Will I make the Friday deadline? I hope
so.. but I may not get it sent until Saturday AM..

IMO my comments are changes enough that I think we will need
another spin of ASAP... and another LC.. after we sort things
out :-D

ENRP.. well.. this is a tricky one.. since I just don't
have the cycles to implement this for a few weeks at
the very least .. and I know it will need updates 

R

Ong, Lyndon wrote:
> Hi Folks,
>  
> Maureen and I would like to initiate WG Last Call on the ASAP and ENRP
> specs, plus the associated
> common parameters draft.  The applicable drafts are:
>  
> 1) draft-ietf-rserpool-asap-13.txt
> 2) draft-ietf-rserpool-enrp-13.txt
> 3) draft-ietf-rserpool-common-param-10.txt
>  
> Last Call will begin on Friday, June 9, ending Friday, June 23.  Please
> submit comments with the
> related draft title in your subject header (e.g., "LC Comment on ASAP"
> or "LC Comment on Parameters")
> so people can keep track of comments more easily.
>  
> Cheers,
>  
> Lyndon
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> rserpool mailing list
> rserpool <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rserpool

--

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

RE: WG Last Call on ASAP and ENRP specifications

Hi Randy,

If there are a lot of comments coming from implementation, and it will
be
a rush to document these by Friday, my suggestion would be to extend the
Last Call period for another week.  Would that be OK to everyone?

That would make the end of Last Call Friday, June 30th.

Cheers,

Lyndon 

-----Original Message-----
From: Randall Stewart [mailto:randall <at> lakerest.net] 
Sent: Thursday, June 22, 2006 8:34 AM
To: Ong, Lyndon
Cc: rserpool <at> ietf.org; Lars Eggert; Maureen.Stillman <at> nokia.com
Subject: Re: [Rserpool] WG Last Call on ASAP and ENRP specifications

All:

I have a LOT of comments yet to make on asap and a couple of tweaks (if
I remember right) to suggest for the common-param's... How I am coming
up with these is by "eatting my own dog-food" and implementing asap
based on the spec..

Now that being said, I am doing this mainly at 30,000 feet it seems..
and I am still not done implementing ASAP... there is no way I will get
to ENRP (which I bet will have has many or MORE comments then I have
already collected in my annotated version of asap-13)...

I will try to convert my comments on ASAP into an email tommorrow at
30,000 feet again as I travel back from networkers... Will I make the
Friday deadline? I hope so.. but I may not get it sent until Saturday
AM..

IMO my comments are changes enough that I think we will need another
spin of ASAP... and another LC.. after we sort things out :-D

ENRP.. well.. this is a tricky one.. since I just don't have the cycles
to implement this for a few weeks at the very least .. and I know it
will need updates 

R

Ong, Lyndon wrote:
> Hi Folks,
>  
> Maureen and I would like to initiate WG Last Call on the ASAP and ENRP

> specs, plus the associated common parameters draft.  The applicable 
> drafts are:
>  
> 1) draft-ietf-rserpool-asap-13.txt
> 2) draft-ietf-rserpool-enrp-13.txt
> 3) draft-ietf-rserpool-common-param-10.txt
>  
> Last Call will begin on Friday, June 9, ending Friday, June 23.  
> Please submit comments with the related draft title in your subject 
> header (e.g., "LC Comment on ASAP"
> or "LC Comment on Parameters")
> so people can keep track of comments more easily.
>  
> Cheers,
>  
> Lyndon
> 
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> rserpool mailing list
> rserpool <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rserpool

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

RE: WG Last Call on ASAP and ENRP specifications

Sounds good. 

-- Maureen
Maureen Stillman
Nokia Enterprise Solutions
Acting Director SMC Systems Architecture

-----Original Message-----
From: ext Ong, Lyndon [mailto:Lyong <at> Ciena.com] 
Sent: Thursday, June 22, 2006 3:30 PM
To: Randall Stewart
Cc: Lars Eggert; Stillman Maureen (Nokia-ES/MtView); rserpool <at> ietf.org
Subject: RE: [Rserpool] WG Last Call on ASAP and ENRP specifications

Hi Randy,

If there are a lot of comments coming from implementation, and it will
be a rush to document these by Friday, my suggestion would be to extend
the Last Call period for another week.  Would that be OK to everyone?

That would make the end of Last Call Friday, June 30th.

Cheers,

Lyndon 

-----Original Message-----
From: Randall Stewart [mailto:randall <at> lakerest.net]
Sent: Thursday, June 22, 2006 8:34 AM
To: Ong, Lyndon
Cc: rserpool <at> ietf.org; Lars Eggert; Maureen.Stillman <at> nokia.com
Subject: Re: [Rserpool] WG Last Call on ASAP and ENRP specifications

All:

I have a LOT of comments yet to make on asap and a couple of tweaks (if
I remember right) to suggest for the common-param's... How I am coming
up with these is by "eatting my own dog-food" and implementing asap
based on the spec..

Now that being said, I am doing this mainly at 30,000 feet it seems..
and I am still not done implementing ASAP... there is no way I will get
to ENRP (which I bet will have has many or MORE comments then I have
already collected in my annotated version of asap-13)...

I will try to convert my comments on ASAP into an email tommorrow at
30,000 feet again as I travel back from networkers... Will I make the
Friday deadline? I hope so.. but I may not get it sent until Saturday
AM..

IMO my comments are changes enough that I think we will need another
spin of ASAP... and another LC.. after we sort things out :-D

ENRP.. well.. this is a tricky one.. since I just don't have the cycles
to implement this for a few weeks at the very least .. and I know it
will need updates 

R

Ong, Lyndon wrote:
> Hi Folks,
>  
> Maureen and I would like to initiate WG Last Call on the ASAP and ENRP

> specs, plus the associated common parameters draft.  The applicable 
> drafts are:
>  
> 1) draft-ietf-rserpool-asap-13.txt
> 2) draft-ietf-rserpool-enrp-13.txt
> 3) draft-ietf-rserpool-common-param-10.txt
>  
> Last Call will begin on Friday, June 9, ending Friday, June 23.  
> Please submit comments with the related draft title in your subject 
> header (e.g., "LC Comment on ASAP"
> or "LC Comment on Parameters")
> so people can keep track of comments more easily.
>  
> Cheers,
>  
> Lyndon
> 
> 
> 
> ----------------------------------------------------------------------
> --
> 
> _______________________________________________
> rserpool mailing list
> rserpool <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rserpool

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

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool

comments to ASAP.. and a few for ENRP

Now here is what I picked off at 30,000 feet... Friday..
and I added one more at the end that I detected as
I was implementing... Notice that term.. considering
I am not done implementing and still generating comments..

I think there will be more comments as I finish
implementing.. and a bunch of comments (besides the
few I make here) when I get to implementing ENRP...

---------Comments----------------------

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

--------------------------------------------
Section 2.2.10

The server idenity field is confusing.. it is actually
(from at least what I can tell and what I remember) a
32 bit field.. yet it appears in the document to
be a TLV.. it should not be. 

Note also I researched this a bit in ENRP as well
and there seems to be multiple names used for the
same field.. this needs to be consistent (so here
is an ENRP comment.. I guess I lied :-D)

--------------------------------------------

End of Section 2... and a confusion on my
part. No where in asap can I find a specific
directive that the way you tell ASAP vs other
things is in the PPID field from SCTP (or
its equivalant tcp adaption thingy). Now
this should be spelled out here.

Secondary question.. should we not have
an ENRP related PPID as well? Or is
that really needed since the ENRP deamons
can setup seperate sockets to deal with
inter ENRP comm?

--------------------------------------------

Section 3.4

There is no specification of how your
home server changes. This should be explictly
stated. In general an ASAP client should be
promiscuous.. any time a HB comes in from
an ENRP server, that should become the
new home ENRP servers. ENRP servers themeselves
end up agreeing on who owns whom.. and thus
only one will send a HB.. normally where 
you orginally registered at. Now also we 
need comments about the "subscribe for update"
that we wanted to do in here somewhere too.

I.e. I can ask for dynamic updates to any
pool handle reg/de-reg as a client. A change
occurs and the ENRP home server pushes it
out to me.. but of course a change of 
home server forces a re-reg of this request
since ENRP does not share who is getting
pushed data. 

This all needs to be put in both ENRP and
ASAP.. so far its un-specified.

-------------------------------------------

3.6 server hunt...

states:

   SH1) The PE or PU SHOULD try to establish an association or
      connection with no more than three ENRP server addresses.  An
      endpoint MUST NOT try to establish more than three association or
      connections at any single time.

RRS:different or the same guy (3 addresses)? What
I think we want is 3 unique ENRP servers.. not
3 addresses.. since an ENRP server can and should
be multi-homed :-D

Also this section states:

     SH5.1) The endpoint MUST double the value of the T5-Serverhunt
         timer.

RRS: What caps the doubling.(RTO.Max?). or does it just go on and on? And
     for that matter, why double with a 120 second timer? It
     really is so SLOW I think we should NOT double it

     Note in TCP/SCTP RTO.Max is 60 seconds...

-------------------------------------------

3.7.1 send failure

states:

   In such a case, the ASAP endpoint should not re-send the failed
   message.  Instead, it should discard the failed message and start the
   ENRP server hunt procedure as described in Section 3.6

Should it not also note the action it was after and
queue this to use once you find a new enrp server? Aka
if you are requesting resolution of pool name X, should
you not indicate to the request (there is a timer running
there) that you are now getting a new name server.. and then
after that occurs, resubmit the request? You should
but this is not clearly defined...

It is also not clear what you do in case C i.e.
a registration failure. This should be specified
(fix what is wrong if you can deduce it and
 retry.. or report to the user the failure)

----------------------------------------

5.1 default values

   T5-Serverhunt - This timer is used during the ENRP server hunt
      procedure and is normally set to 120 seconds.

RRS: This is way to big if your doubling

---------------------------------------

5.3 states:
   MAX-REG-ATTEMPT - The maximum number of registration attempts to be
      made before a server hunt is issued.

RRS: So what is the default.
and

   MAX-REQUEST-RETRANSMIT - The maximum number of attempts to be made
      when requesting information from the local ENRP server before a
      server hunt is issued.

RRS: So what are the default values for the above three items??

---------------------------------------

Another issue.. PE-Id..

The value is globally unique to all
pools? Or should be. We need to specify
this very clearly... the fact that
there is a home-enrp-server id in
the pe info is confusing. It makes one
wonder if the home-enrp-server+pe-id
is unique OR is it just the pe-id which
is unique?? 

I think we wanted pe-id unique alone, so
in such a case maybe the name resolution
response message should have the home-enrp-server
id set to 0 for the responses to the PU's and
PE's... I think the field is there for use
in ENRP.. but for ASAP we don't need to
see this field.. it is confusing and it
actually gives away a bit of information.

Maye ENRP should say something about this
field MUST be set to 0 in the response message
to a name resolution request...

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool

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

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)

Topics for the agenda

_______________________________________________
rserpool mailing list
rserpool <at> ietf.org
https://www1.ietf.org/mailman/listinfo/rserpool

Re: Topics for the agenda

We could talk about the RSerPool API... Randy, Peter and myself had
some discussions.

I could also present the rsplib, developed by Thomas Dreibholz.

Best regards
Michael

On Jul 1, 2006, at 3:35 PM, <Maureen.Stillman <at> nokia.com> wrote:

> Please send any topics for the Montreal agenda.  We have a 2 hour  
> slot.
>
> Thanks.
>
> -- Maureen 
> Maureen Stillman
> Nokia Enterprise Solutions
> Acting Director SMC Systems Architecture
>
> _______________________________________________
> rserpool mailing list
> rserpool <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/rserpool