Comments on draft-ietf-ip-over-infiniband-04.txt

Roy Brabson <[email protected]>
Newsgroups gmane.ietf.ipoib
Message-ID <OF33979943.5101E52D-ON85256D1A.005068A0-85256D1A.0051C300@us.ibm.com>
As with my comments on draft-ietf-ipoib-link-multicast-04.txt, I've 
just started to look at IPoIB, so please forgive me if some of the 
comments below have been discussed previously. 

- I've seen this discussed previously, but wouldn't it make sense to 
  combine this draft with draft-ietf-ipoib-link-multicast-04.txt?  You
  can't implement one without the other, and each draft only seems to 
  have about 5-10 pages of unique text.

- The draft contains a reference to draft-ietf-ipoib-architecture-02.txt. 
  I've been unable to find a copy of this draft, either current or in an
  internet draft archive.  draft-ietf-ipoib-architecture-01.txt is an 
  expired draft which hasn't been updated in almost 18 months.  Should 
  this reference be deleted, or is referenced draft updated and published 
  as an RFC?

- Section 4.0 covers the setting of the IBoIB MTU.  But I'm wondering 
  why this is even discussed within this document at all.  Isn't it 
  already covered in "IP link and multicast over InfiniBand networks" 
  draft, which seems to be the better place for this information?
 
  I actually prefer the text within this section over that in the "link 
  and multicast" draft - maybe this section should be deleted and this 
  text can replace that in the other draft.

- Section 5.0 seems to require that the interface identifier be selected 
  either from the GUID or, if the IPoIB subnet is contained within an IB 
  subnet, from the LID.  I don't believe is the intent, as there are 
  quite a few other ways that an interface identifier may be generated - 
  as per RFC 3041, via manual configuration, or some other algorithm as 
  deemed necessary by the IPoIB node.  I would prefer to see the text 
  indicate that the GUID SHOULD be used if privacy is not a concern, but 
  other mechanisms may be used as deemed appropriate.

Roy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.