Subject: RE: [Ipoverib] IPoIB/ifconfig question

From: "Larsen, Roy K" <[email-masked]>
Date: Tue, 14 Jan 2003 11:25:53 -0800

Ah yes, 24 bits....  I had a brain fart and was thinking the QPN was 16.
Then if fixed length is desirable, what you show for #4 is better than the
60 digit #1 (regardless of what the mib draft proposes).  It just isn't
practical to display 60 characters (although 47 characters is pretty much in
the same camp) and is not very parsable by a human.  Remember, this sequence
would be displayed for things like ifconfig(8) and arp(8) which are fairly
frequent administrative operations.  I still like #3 but since I don't do
much network administration, I don't know what the impact of a variable
length hardware address would have.

The network admin tools I work with already use a hardware type based
library for displaying interface specific information so there is no need to
follow Ethernet convention from my point of view.

Roy

-----Original Message-----
From: Kanoj Sarcar [mailto:[email-masked]]
Sent: Tuesday, January 14, 2003 11:00 AM
To: Larsen, Roy K
Cc: [email-masked]; Kanoj Sarcar
Subject: Re: [Ipoverib] IPoIB/ifconfig question

"Larsen, Roy K" wrote:
> 
> Kanoj,
> 
> While not a draft issue, I agree that it would be nice to use this forum
to
> set a de facto standard for IPoIB hardware address display format.  Given
> the long length, I'm inclined to go with the most condensed representation
> which would be #3.  However, this does not provide a fixed length display
> which is useful for scripting applications so I'm thinking a modified #2
> with all fixed length numbers and a single field QPN of 0014 instead of
> 0:14).
> 
> Roy
>

Roy,

It was pointed out to me that 

http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibmib-tc-mib-02.txt

has

IbGuid ::= TEXTUAL-CONVENTION
     DISPLAY-HINT "1x:"
     STATUS      current
     DESCRIPTION

It would seem to me that unless there is good reason for deviation,
tcpdump/snoop/ifconfig/arp et al could just use this format (maps to
option 1).

Another reason I prefer 1 is because scripts written with the ethernet
format in mind would mostly work (if the length issues were fixed in
the script). Option 2 packs 16 bits in between each :, whereas these
ethernet based scripts pack 8 bits. 

What do you think?

The reason I went with 0:14 for the QPN (in #3) is because the QPN is 
actually 4 bytes, with the top byte set to 0. So QPN = 0x00123456 
could be a possible value (theoretically). To represent that, I would 
need to say 12:3456:... I wanted this to look the same (in terms of
number of :s) as in the case of QPN=0x00000014. Or are you suggesting
something like

4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781

in this case?

Thanks.

Kanoj
  
> -----Original Message-----
> From: Kanoj Sarcar [mailto:[email-masked]]
> Sent: Monday, January 13, 2003 2:35 PM
> To: [email-masked]; Kanoj Sarcar
> Subject: [Ipoverib] IPoIB/ifconfig question
> 
> Hi,
> 
> Here's an IPoIB implementation issue that I would
> like to get feedback on from implementors.
> 
> What should the ifconfig/arp/packet-sniffer output look like for
> the mac address part of an IPoIB interface? In the examples below,
> assume QPN=0x14, GID prefix is FE80::0 and GID suffix is
> 0002c900011c9781, so that the mac address in hex is
> 14FE800000000000000002c900011c9781.
> 
> Some options might be
> 
> 1. 00:00:00:14:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81
> (or 0:0:0:14:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81)
> 2. 0:14:FE80:0000:0000:0000:0002:c900:011c:9781
> (or 0:14:FE80:0:0:0:2:c900:011c:9781)
> 3: 0:14:FE80::2:c900:011c:9781
> 
> I understand this is probably not something that should be
> put into any of the I/Ds, but it would be nice if various
> vendors' outputs matched. My choice is option 1, since it
> is the closest to how most systems represent ethernet
> addresses (except the length of course). Most systems'
> "arp" command is also easily converted to handle this
> format and obviates the need for complicated parsing.
> 
> Note that the I/D
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ipoib-link-multicast-02.txt
> 
> on page 8 section 8.0 represents IBA multicast GIDs in v6
> format, I am not sure whether to suggest that the link layer
> address should also be represented similarly by network tools.
> 
> For reference, here's the ifconfig output line that prints
> mac addresses on Solaris and Linux:
> Link encap:Ethernet  HWaddr 00:06:5B:4E:E4:6E
> ether 8:0:20:d9:4:97
> 
> Thanks.
> 
> Kanoj
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Roland Dreier <[email-masked]>
Date: 14 Jan 2003 12:27:18 -0800

One thing to think about in regards to how to display a HW address is
the fact that a GID technically _is_ an IPv6 address, so it might make
sense to display it as one.

Best,
  Roland

---

From: Roland Dreier <[email-masked]>
Date: 14 Jan 2003 12:27:18 -0800

Best,
  Roland

---

From: Kanoj Sarcar <[email-masked]>
Date: Tue, 14 Jan 2003 12:45:24 -0800

> length hardware address would have.

I think we are down to #1 and #4, right? (Another point against #3 is that
it *might* be confusing to have a v6 protocol layer addressing scheme applied
to a link layer address; specially since the link layer address is not 128bits 
long). 

Here they are (with QPN=0x123456):

1. 00:12:34:56:FE:80:00:00:00:00:00:00:00:02:c9:00:01:1c:97:81
(or 0:12:34:56:FE:80:0:0:0:0:0:0:0:2:c9:0:1:1c:97:81)
4. 123456:FE80:0000:0000:0000:0002:c900:011c:9781
(or 123456:FE80:0:0:0:2:c900:11c:9781)

Given the irregularity (length wise) in the first few digits in 4, 
I would think #2 would be better. Here it is:

2. 12:3456:FE80:0000:0000:0000:0002:c900:011c:9781
(or 12:3456:FE80:0:0:0:2:c900:11c:9781)

I do have a preference for #1 still, primarily because 

a. it is the most easily adapatable to the "arp" command (ie, when you
are doing a "set" operation, it is very easy to teach "arp", which on
most systems currently only expect ethernet addresses, how to parse a
#1 style ib command, in contrast to #2 or #4). Any other format picked
can of course be handled, I have seen the least amount of work with #1 
while prototyping (I am dealing with Solaris, but I expect that to be 
true on most other systems like BSD too; Linux has a -H option, so this
is not an issue).

b. I do believe there is value in matching the MIB format, specially since
admins might want to correlate the outputs from various commands (ifconfig,
arp, snoop and SNMP).

c. Any current scripts that parse ethernet addresses (HWaddr output in
Linux etc) if applicable on IPoIB would need to be converted; I am not
aware of any, but if there are some, logic in a. again applies.

The advantage of 2 and 4 are their somewhat shorter lengths.

> follow Ethernet convention from my point of view.

What about (sysadmin) scripts that parse output from ifconfig (ie look at 
HWaddr field), which currently assume ethernet format? 

I assume you are talking about Linux (and thus you have the -H arp option 
to help)? Notice, you could still build in automatic parsing in Linux "arp", 
which on seeing format #1 will recognize it as an IPoIB address (ie,
the default type for 20b addresses can be IPoIB, similar to the default
type for 6b addresses is ethernet; this would allow admins not to have
to specify -H for each IPoIB operation, thus making IPoIB just a little
more similar to ethernet); I imagine it will be just a little harder to
do #2 or #4.

Thanks.

Kanoj

---

From: Kanoj Sarcar <[email-masked]>
Date: Tue, 14 Jan 2003 12:45:24 -0800

Thanks.

Kanoj