[openib-general] RE: [swg] IP Addressing Annex v4.

[Kanevsky, Arkady]

Updated annex that incorporates responses to Ted's comments.

Arkady Kanevsky                       email: arkady at netapp.com
Network Appliance Inc.               phone: 781-768-5395
1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195
Waltham, MA 02451                   central phone: 781-768-5300
 

> -----Original Message-----
> From: Kanevsky, Arkady 
> Sent: Monday, February 13, 2006 11:04 AM
> To: Ted H. Kim
> Cc: swg at infinibandta.org
> Subject: RE: [swg] IP Addressing Annex v4.
> 
> comments in-line.
> 
> Arkady Kanevsky                       email: arkady at netapp.com
> Network Appliance Inc.               phone: 781-768-5395
> 1601 Trapelo Rd. - Suite 16.        Fax: 781-895-1195
> Waltham, MA 02451                   central phone: 781-768-5300
>  
> 
> > -----Original Message-----
> > From: Ted H. Kim [mailto:ted.kim at sun.com]
> > Sent: Wednesday, February 01, 2006 1:11 PM
> > To: Kanevsky, Arkady
> > Cc: swg at infinibandta.org
> > Subject: Re: [swg] IP Addressing Annex v4.
> > 
> > Arkady,
> > 
> > Some comments on v4 -
> > 
> > p.1, line 28 - suggest removing the word "Agent" - since 
> that word has 
> > a particular meaning in the context of the IBTA management model, 
> > which probably should not be referred to here
> 
> OK. Removed from all 3 places.
> But CM stands for both protocol definition as well as "provider". 
> I suggest to spell out Communication Manager(s) instead of CM.
> CM will be used for Connection Management (protocol).
> 
> > 
> > p.2, lines 17-20 and throughout the annex - while you use the 
> > requestor/responder terminology which is used in the LWG chapters a 
> > lot, I think it might be better to use active/passive to make it 
> > consistent with the CM chapter or do you mean something different 
> > here?
> 
> active/passive refers to model not communicating entities.
> IBTA chapter 12 uses client/server for the entities.
> I will change requestor/responder to client/server.
> 
> > 
> > since the annex is short can you set it so tables are not broken 
> > across pages?
> 
> When I change Table attribute to start at the top of the page 
> the requirement before it (2 lines) take the whole page alone.
> I will leave this formating to an editor when they merge 
> Annex into the spec.
> 
> > 
> > p. 4 table 2, while the numerical values are the same, perhaps you 
> > should break out byte zero as the AGN byte (i.e.
> > IBTA part of the SID space to be consistent with how Annex A3 
> > structures the SID space - this is implied by p. 5, line 10
> > -- but the table maybe should reflect it as well
> 
> OK.
> I will call byte 0 - IBTA AGN.
> Bytes 1-3 will retain the name - Prefix of RDMA-aware Service 
> ID range.
> 
> > 
> > p. 7, Table 5 -  Is there a reason why the suggested values 
> start at 
> > byte 41 (alignment?)? I would guess the largest suggested 
> value would 
> > be an IPv6 address, which won't take the whole 41-71 range anyway.
> > 
> > Table 5 - Also should any remaining space in the ARI area, be 
> > classified as "reserved"?
> 
> OK.
> I had split it into bytes 41-56 for suggested value and 57-71 
> for "remaining ARI field".
> 
> Should we add that for ARI "0x00" - unspecified, there is no 
> suggested resolution?
> I think not we can leave it to Provider to not specify 
> anything and set byte 3 to 0x00 (no suggested value).
> 
> > 
> > 
> > Thanks,
> > -ted
> > 
> > 
> > 
> > 
> > 
> > 
> > Kanevsky, Arkady wrote:
> > > Major changes are:
> > > definition and use of "downward compatible", ARI suggested value.
> > >  
> > > Arkady Kanevsky                       email: arkady at netapp.com 
> > > Network Appliance Inc.               phone: 781-768-5395
> > > 1601 Trapelo Rd. - Suite 16.        Fax: 781-895-119 
> > > Waltham, MA 02451                   central phone: 781-768-5300
> > 
> > --
> > Ted H. Kim
> > Sun Microsystems, Inc.                  ted.kim at sun.com
> > 222 North Sepulveda Blvd., 10th Floor   (310) 341-1116
> > El Segundo, CA  90245                   (310) 341-1120 FAX
> > 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip_address_annex_v5.pdf
Type: application/octet-stream
Size: 70284 bytes
Desc: ip_address_annex_v5.pdf
URL: <http://lists.openfabrics.org/pipermail/general/attachments/20060213/4735c38d/attachment.obj>