headers
Kanoj Sarcar | 1 Feb 2003 06:06
Picon

IPoIB/DHCP

Hi,

I have an issue with section 2.1 of draft-ietf-ipoib-dhcp-over-infiniband-04.txt.
I think it should be reworded to allow the following two formats for the client-id:

     Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
   |  61 | 21  |  0  | Unique-value(4 octets) |   GID (16 octets)          |
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+

    Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
   |  61 | 21  |  32 | QPN  (4 octets) |   GID (16 octets)          |
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+

Note that if the 20 byte client identifier does not represent the MAC address
of the interface, the type should be 0. The type can be 32 only if the mac
address is being used as the identifier.

In fact, I doubt the neccesity of specifying the second format, since it represents
an unstable address (QPN), which is likely to change whenever a port is 
rebooted.

For the rationale, please see section 9.14 of RFC 2132:
"A hardware type of 0 (zero) should be used when the value field
contains an identifier other than a hardware address (e.g. a fully
qualified domain name)."

Thanks.
(Continue reading)

Permalink | Reply | 0 comments |
headers
bill | 3 Feb 2003 19:52

FW: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21, 2003)

A friendly reminder of the Internet cutoff dates for the March meeting
in San Francisco.

If you are planning on creating or updating a draft for the meeting,
make sure your draft is in long before the cutoff date, otherwise it
will not post until after the meeting.

Thank you

Bill Strahm

-----Original Message-----
From: owner-ietf-announce <at> ietf.org [mailto:owner-ietf-announce <at> ietf.org]
On Behalf Of Internet-Drafts Administrator
Sent: Monday, February 03, 2003 4:08 AM
To: IETF-Announce:
Subject: Internet-Draft Cutoff Dates for San Francisco, CA (March 16-21,
2003) 

NOTE: There are two (2) Internet-Draft Cutoff dates

February 24th: Cutoff for Initial Submissions (new documents)

All initial submissions(-00) must be submitted by Monday, February 24th,

at 09:00 ET.  Initial submissions received after this time will NOT be
made available in the Internet-Drafts directory, and will have to be
resubmitted.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larsen, Roy K | 3 Feb 2003 21:09
Picon
Favicon

RE: IPoIB/DHCP

Kanoj,

I tend to agree.  The client-id issues was thrashed on the list and it
basically devolved to what was stated in the last paragraph of 2.1

"This document does not preclude the use of other 'client identifier' type,
such as fully qualified domain name(FQDN) or the EUI-64 value associated
with the interface."

However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the
bill.  However, for the reasons you state, we do not plan on using in our
implementation.

Roy

-----Original Message-----
From: Kanoj Sarcar [mailto:Kanoj.Sarcar <at> sun.com]
Sent: Friday, January 31, 2003 9:07 PM
To: ipoverib <at> ietf.org
Cc: vivk <at> us.ibm.com
Subject: [Ipoverib] IPoIB/DHCP

Hi,

I have an issue with section 2.1 of
draft-ietf-ipoib-dhcp-over-infiniband-04.txt.
I think it should be reworded to allow the following two formats for the
client-id:

     Code  Len   Type  Client-Identifier
(Continue reading)

Permalink | Reply | 2 comments |
headers
Kanoj Sarcar | 3 Feb 2003 21:25
Picon

Re: IPoIB/DHCP

"Larsen, Roy K" wrote:
> 
> Kanoj,
> 
> I tend to agree.  The client-id issues was thrashed on the list and it
> basically devolved to what was stated in the last paragraph of 2.1
> 
> "This document does not preclude the use of other 'client identifier' type,
> such as fully qualified domain name(FQDN) or the EUI-64 value associated
> with the interface."
> 

Roy,

> However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the

The client identifier format suggested in the document does not use the QPN,
rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the
MAC address, thus the type should not be 32, but should be 0.

I do agree that if an implementation does use the QPN as the 4 octets, it
should set the type to 32.

I think something like this would be more appropriate:

    Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
   |  61 | 21  |  0  | Unique-value(4 octets) |   GID (16 octets)          |
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
(Continue reading)

Permalink | Reply | 1 comment |
headers
Yaron Haviv | 4 Feb 2003 00:27

RE: IPoIB/DHCP

One observation on the DHCP issues,

If we eventually don't use the real IPoIB MAC address (GID+QP) why not to
just settle for
Uniqe Value (4) + GUID (8) = 12 < 16
This way we will have a unique address, which also enable determining the
node (Base GID = Subnet Prefix + GUID)
And avoid all the hassle of dealing with long 20 byte addresses

This way we don't need to change DHCP at all
Also we see many other implementation issues that prevent using the 20 Byte
address without messing with the OS code
In some OS's it is even not practical

Not to mention that some network monitoring and diagnostic tools fail to
work in such an environment (20 bytes)

Yaron

-----Original Message-----
From: ipoverib-admin <at> ietf.org [mailto:ipoverib-admin <at> ietf.org]On Behalf Of
Kanoj Sarcar
Sent: Monday, February 03, 2003 10:26 PM
To: Larsen, Roy K
Cc: ipoverib <at> ietf.org; vivk <at> us.ibm.com
Subject: Re: [Ipoverib] IPoIB/DHCP

"Larsen, Roy K" wrote:
>
> Kanoj,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Larsen, Roy K | 4 Feb 2003 01:05
Picon
Favicon

RE: IPoIB/DHCP

Yaron,

Are you suggesting putting the value you describe in the chaddr field?  That
won't work.  The DHCP server must be instructed to reply with a broadcast
and since we can't use the chaddr field, we must use the client ID field.
Once we use the client ID field, any unique and persistent value/character
string (like the one you outline below) should work just fine since it is
opaque to the DHCP server.

Roy

-----Original Message-----
From: Yaron Haviv [mailto:yaronh <at> voltaire.com]
Sent: Monday, February 03, 2003 3:28 PM
To: Kanoj.Sarcar <at> sun.com; 'Larsen, Roy K'
Cc: ipoverib <at> ietf.org; vivk <at> us.ibm.com
Subject: RE: [Ipoverib] IPoIB/DHCP

One observation on the DHCP issues,

If we eventually don't use the real IPoIB MAC address (GID+QP) why not to
just settle for
Uniqe Value (4) + GUID (8) = 12 < 16
This way we will have a unique address, which also enable determining the
node (Base GID = Subnet Prefix + GUID)
And avoid all the hassle of dealing with long 20 byte addresses

This way we don't need to change DHCP at all
Also we see many other implementation issues that prevent using the 20 Byte
address without messing with the OS code
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vivek Kashyap | 4 Feb 2003 02:09
Picon
Favicon

Re: IPoIB/DHCP

Kanoj,

You are right - the GID by itself is not the MAC address. This brings up
the two options you have mentioned:
      - when  QPN is included in the client-identifier; the hardware type
is 32.
      - when  a value other than QPN is used in forming the
client-identifier; the hardware type is 0.

I am ok with making the change as suggested by you. Is it agreeable to all?

Vivek

--
Vivek Kashyap
Linux Technology Center, IBM
vivk <at> us.ibm.com
kashyapv <at> us.ibm.com
Ph: 503 578 3422 T/L: 775 3422

                                                                                                                                       
                      Kanoj Sarcar                                                                                                     
                      <Kanoj.Sarcar <at> sun        To:       "Larsen, Roy K" <roy.k.larsen <at> intel.com>                                      
                      .com>                    cc:       ipoverib <at> ietf.org, Vivek Kashyap/Beaverton/IBM <at> IBMUS                          
                      Sent by:                 Subject:  Re: [Ipoverib] IPoIB/DHCP                                                     
                      ipoverib-admin <at> ie                                                                                                
                      tf.org                                                                                                           

                                                                                                                                       
                      02/03/2003 12:25
(Continue reading)

Permalink | Reply | 4 comments |
headers
H.K. Jerry Chu | 11 Feb 2003 22:13
Picon

upcoming IETF meeting in San Francisco

The next IETF meeting is fast approaching, but we have not scheduled
a slot for IPoIB yet. Our current deliverables are

1) Encapsulation draft
2) link and multicast draft
3) DHCP draft
4) MIB drafts

The first three drafts went to the IESG and are currently being revised
based on feedback and IBA 1.1 spec. Vivek and I will published the
revised drafts in a few days. The MIB drafts have been updated, and
are getting close to last call.

Bill and I are interested in knowing your opinion on if we have business
to conduct in San Fransisco.  If you have a presentation that you would
like to make, or an agenda item to discuss - bring it to the list so we
know that we need to schedule a meeting.  The deadline for this will be
Friday 21 Feb.  If we do not have any requests for agenda items by then
we will not schedule a meeting, if there are agenda requests we will
schedule a meeting.

Included here are the Important Meeting Dates:

January 7, Tuesday - Working Group and BOF scheduling begins
January 13, Monday - Registration begins
February 24, Monday - Internet Draft Cut-off for initial document (-00)
submission at 09:00 ET
February 25, Tuesday - Working Group and BOF scheduling closes at 17:00 ET
March 3, Monday - Internet Draft final submission cut-off at 09:00 ET
March 7, Friday - Registration and Pre-payment cut-off at 12:00 noon ET
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.K. Jerry Chu | 20 Feb 2003 23:16
Picon

IPoIB slot in San Francisco

We've got a morning slot on Tuesday in the upcoming San Francisco
IETF:

TUESDAY, March 18, 2003
0800-1800 IETF Registration -
0800-0900 Continental Breakfast -
0900-1130 Morning Sessions
INT        dnsext     DNS Extensions WG
INT        ipoib      IP over InfiniBand WG
OPS        bmwg       Benchmarking Methodology WG
RTG        rpsec      Routing Protocol Security Requirements WG
SUB        mpls       Multiprotocol Label Switching WG
TSV        avt        Audio/Video Transport WG

Please make your travel plan accordingly, but beware that the schedule
may change until the scheduling closes in a week or so.

For those who plan to make presentations, please let me know your
topics and how much time you need.

Thanks,

Jerry
Permalink | Reply | 0 comments |
headers
bill | 28 Feb 2003 22:39

FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt

For MIB authors and reviewers in the working group:

The OPS area has taken the task of reviewing all MIB documents that are
processed in working groups...

This document describes the process and what they might be looking for,
please take a look and make sure your documents won't run into problems
from this review (at the IESG last call level)

Bill

-----Original Message-----
From: owner-wgchairs <at> ietf.org [mailto:owner-wgchairs <at> ietf.org] On Behalf
Of Wijnen, Bert (Bert)
Sent: Tuesday, February 25, 2003 6:33 AM
To: wgchairs <at> ietf.org
Subject: FW: I-D ACTION:draft-ietf-ops-mib-review-guidelines-01.txt

FYI. This is the second revision that has incorprated all comments and
feedback we got. From now on we will be using these guidelines when we
do MIB doctor review.

It would be good if your editors/authors check their MIB documents
against this as well, and that you as WG chairs try to make sure that
the WG has taken these guidelines into consideration when they approve
(bu WG Last Call) such a document.

If any questions come up... feel free to post them to
the mibs <at> ops.ietf.org mailings (general MIB related discussions
list) or send them to myself.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane