Re: Comments on draft-ietf-ip-over-infiniband-04.txt
Vivek Kashyap <[email protected]>
| Newsgroups | gmane.ietf.ipoib |
|---|---|
| Message-ID | <Pine.WNT.4.44.0305091242230.1344-100000@w-vkashyap95.des.sequent.com> |
Roy, On Fri, 2 May 2003, Roy Brabson wrote: > 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. Yes, we discussed it but finally kept this form. > > - 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? Working on it. > > - 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. The two drafts have different contexts -- this draft discusses the impact on the IP MTU due to the encapsulation defined in this draft and other parameters affecting the MTU. The link-multicast draft discusses the choice and setting of the link's MTU. > > - 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. The description in the draft states the methods by which InfiniBand interface identifiers can be used to setup the interface id. It then recommends the use of the GUID (EUI-64) value. This does not preclude any of the other legal methods - as you also note. The other methods need not be specified since this is a SHOULD/RECOMMENDED clause - implying that there are situations where the other methods may be used (such as manual or as per RFC3041). It appears that RFCs/drafts for other media also discuss the identifiers associated with the interface and not the other methods (none of which are explicitly blocked). Vivek > > Roy > _______________________________________________ > IPoverIB mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/ipoverib > > __ Vivek Kashyap Linux Technology Center, IBM