Subject: RE: [Ipoverib] Encapsulation Issues

From: "Deleganes, Ellen M" <[email-masked]>
Date: Wed, 7 Nov 2001 16:20:01 -0800

After reading some of the previous discussion threads on SL usage, I would
like to change my vote regarding the determination of the SL. While it would
be nice not to have to go back to the SM to get the SL, this does not appear
to be practical for the vast majority of configurations.

I agree with Jerry, the choice of the SL by an individual node should be
left completely up to implementations and the IPoIB spec should not talk
about generic IB rules.

Regards,
Ellen Deleganes

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 12:57 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Ipoverib] Encapsulation Issues

Jerry writes:
> >1. Determination of service level
> >Option a: Use SL from all hosts multicast group
> >Option 1: Use SL from path record
> 
> Does the choice of SL by individual node affects interoprability?
> If not, I contend that this doesn't belong here (IPoIB standard). We
> should leave this completely to implementations. The same arguement
> applies to other IB attributes as well. IPoIB spec should focus on
> aspects of IB that are required in order for the IP level
interoperability.
> It should not talk about generic IB rules. IPoIB clients are themselves
> IB clients. Their compliance with IB spec is always assumed.
> 

Ellen writes:
> 
> 1.            Determination of service level
> 
> Preference for option a: use the SL from the all hosts multicast group.
The
> reason this was preferred over the option to use the SL from the path
record
> is that getting the SL from the path record requires the implementation to
> either cache the SL or go to the SM to get the path record. 
> 

	What does InfiniBand say about SL ?

        * SL is meant for QoS. SL is meant for load balancing. SL is
          meant for avoiding deadlocks.

        * It is a must that the SLs in a fabric are setup to avoid a
          deadlock. This is ensured by the subnet manager (SM).

        * There may be multiple SLs between any two endpoints but IB
          provides no mechanism to choose from the multiple SLs.

        * For cross IB subnet traffic the SLs are derived based on the
          GRH:TClass value as per the IB routing chapter with the
          TClass of 0 mapping to the best effort SL. 
		
        Thus there is an assumption that there is a QoS framework in
        place. The IB specification leaves the usage and mode of
        determination of the SL for the application to decide. The SL
        and list of SLs are available in the SA but it is upto the
        endnode's application to choose the 'right' value.

        IP is one such IB application and so IPoIB needs to define a
        set of rules on the choice of the SL. Furthermore it would be
        nice, some may say required, to have all the nodes agree on a
        common set of rules so that they come up with the same
        answers. 

	How about the following :

        The node is free to determine the SL to be used in any
        implementation specific way. A configuration parameter must be
        provided that when set implies that the all-IP nodes multicast
        GID SL is suitable to be used for all unicast traffic in the
        IPoIB subnet. Thus who value the benefits outlined by Ellen
        may set their subnets to use the common SL others can
        determine the SL by accessing the SA.

Vivek

-- 
Vivek Kashyap
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: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 7 Nov 2001 17:16:52 -0800 (PST)

>like to change my vote regarding the determination of the SL. While it would
                   ^^^^^
                   
In case you are not already familiar with IETF philosophy, we don't vote here.
But we rely on "rough consensus and running code".

Rgds,

Jerry

---

From: "Deleganes, Ellen M" <[email-masked]>
Date: Thu, 8 Nov 2001 06:47:40 -0800

My apologies, I meant to say "opinion" not "vote". I will try to be more
careful in the future.

Regards,
Ellen

-----Original Message-----
From: H.K. Jerry Chu [mailto:[email-masked]]
Sent: Wednesday, November 07, 2001 5:17 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] Encapsulation Issues

                   ^^^^^
                   
In case you are not already familiar with IETF philosophy, we don't vote
here.
But we rely on "rough consensus and running code".

Rgds,

Jerry