Subject: RE: [Ipoverib] Proposed Update for IPOIB Interface MIB

From: "Harnedy, Sean" <[email-masked]>
Date: Mon, 29 Apr 2002 09:49:36 -0400

The current IPOIB Interfaces MIB (Definitions of Managed Objects
for InfiniBand Interfaces Types: draft-ietf-ipoib-ibif-mib-01.txt)
defines the Infiniband interface to appear as a layer 2 interface
for IP (IPOIB). The Interfaces MIB definition of ifPhysAddr in this 
MIB equates an InfiniBand port with an interface. Because it is a 
port, the LID was chosen as the best value to reflect the "ifPhysAddr"
as the address that goes over the wire.

The GID+QPN information is important and related to the port. I
propose adding a table of IPOIB Link Layer Addresses that is 
associated with each InfiniBand interface. This is necesary because
the relationship of GID+QPN can be 1:n for any given port. 

Perhaps, something like this:

ibIpoibLinkLayerAddrTable OBJECT-TYPE
   SYNTAX      SEQUENCE OF IbIpoibLinkLayerAddrEntry
   MAX-ACCESS  not-accessible
   STATUS      current
   DESCRIPTION
      "This table contains information about all IPOIB link
       layer addresses associated with this InfiniBand interface."
   ::= { ibIfObjects n }

ibIpoibLinkLayerAddrEntry OBJECT-TYPE
   SYNTAX      IbIpoibLinkLayerAddrEntry
   MAX-ACCESS  not-accessible
   STATUS      current
   DESCRIPTION
      "Information about specific IPOIB link layer addresses 
       associated with this InfiniBand interface."
   ::= { ibIpoibLinkLayerAddrTable 1 }
   
IbIpoibLinkLayerAddrEntry ::= SEQUENCE {
   ibIpoibLinkLayerIndex     INTEGER,
   ibIpoibInterfaceID        OCTETSTRING(SIZE(4)),
   ibIpoibGlobalIdentifier   OCTETSTRING(SIZE(16))
   }

ibIpoibLinkLayerIndex  OBJECT-TYPE
   SYNTAX      INTEGER (1..n))
   MAX-ACCESS  read-only
   STATUS      current
   DESCRIPTION
      "Index of the GID+QPN IPOIB Link Layer addresses
       in the table."
   ::= { ibIpoibLinkLayerEntry 1 }

ibIpoibInterfaceID  OBJECT-TYPE        
   SYNTAX   OCTETSTRING (SIZE(4)),
   MAX-ACCESS  read-only
   STATUS      current
   DESCRIPTION
      "The Interface ID. This object contains 1 octet 
       for reserved (must be 0) and 3 octets for the
       queue pair number (QPN)."
   ::= { ibIpoibLinkLayerEntry 2 }

ibIpoibGlobalIdentifier  OBJECT-TYPE   
   SYNTAX   OCTETSTRING (SIZE(16))
   MAX-ACCESS  read-only
   STATUS      current
   DESCRIPTION
      "The Global Identifier (GID)."
   ::= { ibIpoibLinkLayerEntry 3 }

This will allow the statistics and counters currently defined in the
MIB to be unchanged and add the flexibility of defining the additional
IPOIB Link layer address definitions.

Sean

-----Original Message-----
From: Larsen, Roy K [mailto:[email-masked]]
Sent: Friday, April 26, 2002 9:05 PM
To: 'Bill Strahm'; Aditya Dube
Cc: [email-masked]
Subject: RE: [Ipoverib] MIB's ifPhysAddress needs to be updated

Bill,

If the MIB is IPoIB agnostic, what is it doing in the IPoIB working group?
If it doesn't need to jive with the information returned from things like
ifconfig(8), arp(8), and netstat(8), why does this group care about this MIB
at all?

Roy

-----Original Message-----
From: Bill Strahm [mailto:[email-masked]]
Sent: Friday, April 26, 2002 4:14 PM
To: Aditya Dube
Cc: Bill Strahm; [email-masked]
Subject: Re: [Ipoverib] MIB's ifPhysAddress needs to be updated

Again, an interesting problem,

What would you consider ifInOctets to be if the Physical address is GID +
QPN.

Now think about that answer in an environment that is both IP and IB native,
would each QPN now be an interface in the ifTable ???

The if MIB is designed to handle the Layer 2 properties of the interface 
without regard to what is running on top of it.  Rather than simple Ethernet
where IP runs directly on top of Ethernets Layer 2 interface, in Infiniband
we have IP running on top of Infinibans Layer 3 UD interface.  I hate to
tell
you but I will fight adding QPN to the ifPhysAddress tooth and nail becasue
it does not belong there (in my humble non-chair role)  If you can explain
how
to get other layer 2 protocols on top of Infiniband without incurring 64K
interfaces, I will listen.

Bill
On Fri, Apr 26, 2002 at 02:39:18PM -0700, Aditya Dube wrote:
> Bill
> 
> The MIB document predates the decision to use the GID + QPN as the
> physical address.
> 
> In the current scheme, the entity reported as the physical address by
> the encapsulation layer is inconsistent with what one gets using the
> MIB.
> 
> Aditya Dube
> 
> -----Original Message-----
> From: Bill Strahm [mailto:[email-masked]] 
> Sent: Thursday, April 25, 2002 10:00 AM
> To: Aditya Dube
> Cc: [email-masked]
> Subject: Re: [Ipoverib] MIB's ifPhysAddress needs to be updated
> 
> You are making a subtle mistake... The MIB is an Infiniband layer 2 MIB,
> not 
> an IP over IB Layer 2 MIB...
> 
> The procedure is the same for any draft in the group, get group
> concensus
> on the change, and then the author will update the draft accordingly...
> 
> Bill
> On Thu, Apr 25, 2002 at 09:37:24AM -0700, Aditya Dube wrote:
> > IMO, the IpOverIB's notion of a physical link layer address and what
> the
> > MIB reports as the MAC address should be the same. 
> > 
> > If the MIB draft is to be amended to comply with IPoverIB, what is the
> > procedure for it to happen?
> > 
> > Aditya Dube
> > 
> > -----Original Message-----
> > From: Larsen, Roy K [mailto:[email-masked]] 
> > Sent: Wednesday, April 17, 2002 11:45 AM
> > To: 'Bill Strahm'; Aditya Dube
> > Cc: [email-masked]
> > Subject: RE: [Ipoverib] MIB's ifPhysAddress needs to be updated
> > 
> > But it's being define in the IPoIB working group.  Why isn't it
> > legitimate to say it should support IPoIB hardware address semantics?
> > 
> > Roy
> > 
> > -----Original Message-----
> > From: Bill Strahm [mailto:[email-masked]]
> > Sent: Wednesday, April 17, 2002 11:34 AM
> > To: Aditya Dube
> > Cc: [email-masked]
> > Subject: Re: [Ipoverib] MIB's ifPhysAddress needs to be updated
> > 
> > 
> > The problem is that ifPhysAddr covers more than just IP, it is just
> > the layer 2 wire representation of address.  If you can show me an
> > IB format that includes GID+LID in a packet header, I might conceed
> > defeat here.
> > 
> > The address duplicating across multiple subnets is a red herring.  You
> > can assign identical Ethernet MAC addresses, so long as they are on
> > differing subnets as well.  
> > 
> > >From RFC 2863...
> >             "The interface's address at its protocol sub-layer.  For
> >             example, for an 802.x interface, this object normally
> >             contains a MAC address.  The interface's media-specific
> MIB
> >             must define the bit and byte ordering and the format of
> the
> >             value of this object.  For interfaces which do not have
> such
> >             an address (e.g., a serial line), this object should
> contain
> >             an octet string of zero length."
> > Note that there is no mention of any Layer 3 semantics.  
> > 
> > We can bring the topic up for discussion, I don't know which of the
> MIB
> > authors are currently active right now though.
> > 
> > Bill
> > 
> > On Wed, Apr 17, 2002 at 11:19:24AM -0700, Aditya Dube wrote:
> > > 
> > > As the Lid is an assigned address rather than a burned in address,
> as
> > in
> > > Ethernet, the chances of duplicate ifphysaddr's in a network
> spanning
> > > multiple IB subnets are a lot higher. We should reduce this chance
> as
> > > much as possible.
> > > 
> > > The ifphysaddr is also not in sync with what IpOverIB has decided to
> > use
> > > as the link address in ARPs.
> > > 
> > > IMHO the two, ifphysaddr and the link address is an arp packet,
> should
> > > match.
> > > 
> > > Aditya Dube
> > > 
> > > -----Original Message-----
> > > From: Vivek Kashyap [mailto:[email-masked]] 
> > > Sent: Tuesday, April 16, 2002 12:18 PM
> > > To: Aditya Dube
> > > Cc: [email-masked]
> > > Subject: Re: [Ipoverib] MIB's ifPhysAddress needs to be updated
> > > 
> > > The same question was addressed last october/november.
> > > See the message:
> > > 
> > >
> >
> http://www1.ietf.org/mail-archive/working-groups/ipoverib/current/msg000
> > > 87.html
> > > 
> > > Vivek
> > > 
> > > 
> > > 
> > > > 
> > > > This is a multi-part message in MIME format.
> > > > 
> > > > --------------InterScan_NT_MIME_Boundary
> > > > Content-Type: multipart/alternative;
> > > > 	boundary="----_=_NextPart_001_01C1E577.F19F4F03"
> > > > 
> > > > ------_=_NextPart_001_01C1E577.F19F4F03
> > > > Content-Type: text/plain;
> > > > 	charset="us-ascii"
> > > > Content-Transfer-Encoding: quoted-printable
> > > > 
> > > > 
> > > > In the MIB draft, the ifPhysAddress is specified as the LID. This
> is
> > > out
> > > > of sync with the IpOverIb draft. Can the ifPhysAddress in the MIB
> be
> > > > changed to match  IPoverIB's physical address, i.e. the GID + QPN?
> > > > 
> > > >
> http://www.ietf.org/internet-drafts/draft-ietf-ipoib-ibif-mib-01.txt
> > > > 
> > > > Aditya Dube
> > > > 
> > > > 
> > > 
> > > _______________________________________________
> > > IPoverIB mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/ipoverib
> > 
> > _______________________________________________
> > IPoverIB mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipoverib
> > 
> > _______________________________________________
> > IPoverIB mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib