Subject: Re: [Ipoverib] link descriptor in address resolution packets

From: "H.K. Jerry Chu" <[email-masked]>
Date: Tue, 15 Jan 2002 17:08:27 -0800 (PST)

>        I feel the argument on including the LIDs vs. GIDs is
>        revolving round two issues:
>
>	GIDs : Why are they needed ?
>
>                They cannot be justified by saying that IP subnets can
>                span IB subnets because no benefit has been listed.
>                Nor is the IB specification anywhere near providing
>                such an infrastructure.

No that's not the main reason. GIDs is highly persistent compared to
LIDs. There is a great deal of "hidden" benefit from having a persistent
component in a "MAC address" that have been pointed out many times before
(e.g. for diagnosis purpose, less dependency on gratuitous ARP getting
through...)

>
>	LIDs : Get from SA
>
>                It is wrong to link LID lookup to getting the
>                information from the SA because other information is
>                kept at the SA. This is because the other information
>                can be got in implementation dependent way. The two
>                are disjoint.

The linkage is there because you argued to include LID for performance
reason, but a high percentage of implementations that require a trip to
SA won't realize any performance on an already infrequent ARP operation.

>
>
>        How about agreeing to disagree and do the following in
>        address-resolution packets:
>
>
>	GID + QPN + Cap flags + LID
>
>
>        The order is as specified above. Those that don't want to use
>        the LID can ignore it in received packets and not record it in
>        their information. All they are asked to do is record their
>        own LID when sending the address-resolution request/reply.
>        They ignore the LID in the request/reply they receive. Note
>        that this format has nothing to do with the format in which
>        the link address is recorded in the system.
>
>	That should work for all implementations.

You can't do that without violating layering. ARP modules in most stacks
are independent of link types. Driver is not supposed to peek into ARP
packets.

Jerry

>
>Vivek
>
>-- 
>Vivek Kashyap
>Linux Technology Center, IBM
>[email-masked] 
>[email-masked] 
>503 578 3422 (o)
>
>_______________________________________________
>IPoverIB mailing list
>[email-masked]
>http://www.ietf.org/mailman/listinfo/ipoverib

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

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 15 Jan 2002 22:49:29 -0800 (PST)

> (e.g. for diagnosis purpose, less dependency on gratuitous ARP getting

        I am not sure what you mean by the examples. For persistency
        you need the GUID not GID. You talked about subnet mergers and
        scoped GIDs. Mergers will cause the GIDs to change as much as
        LIDs. 

> SA won't realize any performance on an already infrequent ARP operation.

        No my argument has been that getting the LID in one
        request/response is highly desirable. I further argued that
        just because some may want to go to SA for path rate/SL that
        is no justification to say that LID also be got from the SA.

        Nothing stops those that want to consult the SA from
        consulting it. Similarly don't block the implementations that
        don't want to consult the SA.

> are independent of link types. Driver is not supposed to peek into ARP

        Don't make your driver peek into anything. You have an ARP
        module that is going to record the link address. This can
        always mark the entry incomplete, in the process or zero out
        the LID part. You have thus ignored the LID. When your trip to
        the SA is done your ARP module will update the entry. No
        violation of layers at all.

Vivek