headers
Kanoj Sarcar | 1 Oct 2003 03:44
Picon

Re: IPoIB link address

Vivek Kashyap wrote:
> 
> See below in <VK>

Hi,

> 
> Vivek
> --
> Vivek Kashyap
> Linux Technology Center, IBM
> vivk <at> us.ibm.com
> kashyapv <at> us.ibm.com
> Ph: 503 578 3422 T/L: 775 3422
> 
> 
>                       Kanoj Sarcar
>                       <Kanoj.Sarcar <at> Sun        To:       "H.K. Jerry Chu" <Jerry.Chu <at> Sun.COM>
>                       .COM>                    cc:       Vivek Kashyap/Beaverton/IBM <at> IBMUS, vandana <at> cup.hp.com, ipoverib <at> ietf.org
>                       Sent by:                 Subject:  Re: [Ipoverib] IPoIB link address
>                       Kanoj.Sarcar <at> Sun.
>                       COM
> 
> 
>                       09/30/2003 09:56
>                       AM
>                       Please respond to
>                       Kanoj.Sarcar
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vivek Kashyap | 1 Oct 2003 23:49
Picon
Favicon

Re: Concensus determination

On Tue, 30 Sep 2003, bill wrote:

> There are two separate issues that are being discussed now.  I think it
> is time to get some concensus building going - So with my working group
> chair hat on I would like to declare
>
> For the IPoIB Broadcast GID -
> Choices
> FF1x:401b::255.255.255.255
> FF1x:001b::255.255.255.255
> FF1x:0000::255.255.255.255
> FF1x:0000::1
> FF1x:191b::255.255.255.255
>
> There were two people that had 401b as their prefered choice - none with
> it as a "NO".  I would like to make the
> FF1x:401b::255.255.255.255 the concensus choice for the working group.
> If there are any technical reasons why FF1x:4001b::255.255.255.255 WILL
> NOT work - bring them to the list - otherwise I hope that this is now a
> settled issue.

Yes, I agree with the choice of FF1x:401B::255.255.255.255.

>
> The other issue is what to do around links, and how to
> create/modify/track IB Multicast groups (the Broadcast-GID) - the
> choices appear to be:
> A) Make it a requirement that the broadcast-GID won't be torn down
> unless the link is torn down.
> B) Always have to full-member join broadcast-GID - even if it is a v6
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.K. Jerry Chu | 2 Oct 2003 07:30
Picon

Re: IPoIB link address

<snip>

(co-chair hat off!)

>>a) make it a requirement that the broadcast-GID won't be torn down unless
>>the link is torn down.
>>
>>
>>This is somewhat circular since we define the link using the broadcast-GID.
>>Additonally, the admin will have to find some method to know that the link
>>can be brought down.
>>
>>b) Always have to full-member join broadcast-GID.
>>
>>Now, the admin will always know if someone is using the link and can do a
>>managed shutdown.
>>
>>
>>c) Always derive the data from the broadcast-GID and track it either by
>>full-member joining or reports.
>>
>>Now, the admin can delete/modify as needed. the nodes will respond 
>>accordingly.
>>
>
>I would prefer (c) too. This allows a deployment to not have any admin 
>involvement if necessary. Again, as I said before, if the implementation 
>decides to join full-member, there is no issue.

Not sure I understand what exactly c) is. It refers to v6 only so v4 MUST
(Continue reading)

Permalink | Reply | 2 comments |
headers
Vivek Kashyap | 2 Oct 2003 10:58
Picon
Favicon

Re: IPoIB link address

On Wed, 1 Oct 2003, H.K. Jerry Chu wrote:

> <snip>
>
> (co-chair hat off!)
>
> >>a) make it a requirement that the broadcast-GID won't be torn down unless
> >>the link is torn down.
> >>
> >>
> >>This is somewhat circular since we define the link using the broadcast-GID.
> >>Additonally, the admin will have to find some method to know that the link
> >>can be brought down.
> >>
> >>b) Always have to full-member join broadcast-GID.
> >>
> >>Now, the admin will always know if someone is using the link and can do a
> >>managed shutdown.
> >>
> >>
> >>c) Always derive the data from the broadcast-GID and track it either by
> >>full-member joining or reports.
> >>
> >>Now, the admin can delete/modify as needed. the nodes will respond
> >>accordingly.
> >>
> >
> >I would prefer (c) too. This allows a deployment to not have any admin
> >involvement if necessary. Again, as I said before, if the implementation
> >decides to join full-member, there is no issue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
H.K. Jerry Chu | 2 Oct 2003 15:46
Picon

Re: IPoIB link address

<snip>

>> Not sure I understand what exactly c) is. It refers to v6 only so v4 MUST
>> always join the broadcast group, right?
>
>The suggestion is in general for an IPoIB link. The link attributes are
>derived from the IPoIB broadcast-GID. In the case of v4 it just so happens
>that IP broadcast maps to this and so a node will surely join it. We have
>earlier always talked of full-join since the node will send and receive
>packets on the broadcast GID. However, with the notion that one need not
>join the broadcast GID I believe we need to, irrespective of the IP layer,
>state that :

I am confused. What is the notion that "one need not join the broadcast
GID" for v4? There isn't any leeway for v4 - it must join the broadcast
group for ARP to work.

>
>a) either full-join b) or track the broadcast-GID using traps/reports.
>(the GIDs could be joined sendonly or nonmember joined or as some have
>suggested not joined at all).
>
>
>>
>> I prefer not to require v6 to join the broadcast group. This is compatible
>> with c). But I prefer to continue to leave the creation/maintainence of
>
>Yes, it is in conformance with (c).
>
>> the broadcast group out of scope because the broadcast group should really
(Continue reading)

Permalink | Reply | 502 comments |
headers
Vivek Kashyap | 2 Oct 2003 18:59
Picon
Favicon

Re: IPoIB link address

On Thu, 2 Oct 2003, H.K. Jerry Chu wrote:

> <snip>
>
> >> Not sure I understand what exactly c) is. It refers to v6 only so v4 MUST
> >> always join the broadcast group, right?
> >
> >The suggestion is in general for an IPoIB link. The link attributes are
> >derived from the IPoIB broadcast-GID. In the case of v4 it just so happens
> >that IP broadcast maps to this and so a node will surely join it. We have
> >earlier always talked of full-join since the node will send and receive
> >packets on the broadcast GID. However, with the notion that one need not
> >join the broadcast GID I believe we need to, irrespective of the IP layer,
> >state that :
>
> I am confused. What is the notion that "one need not join the broadcast
> GID" for v4? There isn't any leeway for v4 - it must join the broadcast
> group for ARP to work.

Jerry, I think we are all confused :).

Join is of three types: Full member, Nonmember, Sendonlynonmember.

As far as I know one will have to join (implying one of the above three) to
retrieve the multicast information. In the case of v4, for the broadcast-GID
one will have to either full-member join or non-member join. Both allow for
sends and receives except the latter does not count the requester for
deletions(at the SM).

In my previous note I meant 'need not full-join'. Until now we have always
(Continue reading)

Permalink | Reply | 502 comments |
headers
Kanoj Sarcar | 2 Oct 2003 19:54
Picon

Re: IPoIB link address

"H.K. Jerry Chu" wrote:
> 
> <snip>
> 
> (co-chair hat off!)
> 
> >>a) make it a requirement that the broadcast-GID won't be torn down unless
> >>the link is torn down.
> >>
> >>
> >>This is somewhat circular since we define the link using the broadcast-GID.
> >>Additonally, the admin will have to find some method to know that the link
> >>can be brought down.
> >>
> >>b) Always have to full-member join broadcast-GID.
> >>
> >>Now, the admin will always know if someone is using the link and can do a
> >>managed shutdown.
> >>
> >>
> >>c) Always derive the data from the broadcast-GID and track it either by
> >>full-member joining or reports.
> >>
> >>Now, the admin can delete/modify as needed. the nodes will respond
> >>accordingly.
> >>
> >
> >I would prefer (c) too. This allows a deployment to not have any admin
> >involvement if necessary. Again, as I said before, if the implementation
> >decides to join full-member, there is no issue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Vandana Rao | 2 Oct 2003 21:17
Picon

Re: IPoIB link address

Hi Vivek,

At 09:59 AM 10/2/2003 -0700, Vivek Kashyap wrote:
>On Thu, 2 Oct 2003, H.K. Jerry Chu wrote:
>
> > <snip>
> >
> > >> Not sure I understand what exactly c) is. It refers to v6 only so v4 
> MUST
> > >> always join the broadcast group, right?
> > >
> > >The suggestion is in general for an IPoIB link. The link attributes are
> > >derived from the IPoIB broadcast-GID. In the case of v4 it just so happens
> > >that IP broadcast maps to this and so a node will surely join it. We have
> > >earlier always talked of full-join since the node will send and receive
> > >packets on the broadcast GID. However, with the notion that one need not
> > >join the broadcast GID I believe we need to, irrespective of the IP layer,
> > >state that :
> >
> > I am confused. What is the notion that "one need not join the broadcast
> > GID" for v4? There isn't any leeway for v4 - it must join the broadcast
> > group for ARP to work.
>
>Jerry, I think we are all confused :).
>
>
>Join is of three types: Full member, Nonmember, Sendonlynonmember.
>
>
>As far as I know one will have to join (implying one of the above three) to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kanoj Sarcar | 2 Oct 2003 21:24
Picon

Re: IPoIB link address

Vivek Kashyap wrote:
> 
> On Thu, 2 Oct 2003, H.K. Jerry Chu wrote:

Hi,

> 
> > <snip>
> >
> > >> Not sure I understand what exactly c) is. It refers to v6 only so v4 MUST
> > >> always join the broadcast group, right?
> > >
> > >The suggestion is in general for an IPoIB link. The link attributes are
> > >derived from the IPoIB broadcast-GID. In the case of v4 it just so happens
> > >that IP broadcast maps to this and so a node will surely join it. We have
> > >earlier always talked of full-join since the node will send and receive
> > >packets on the broadcast GID. However, with the notion that one need not
> > >join the broadcast GID I believe we need to, irrespective of the IP layer,
> > >state that :
> >
> > I am confused. What is the notion that "one need not join the broadcast
> > GID" for v4? There isn't any leeway for v4 - it must join the broadcast
> > group for ARP to work.
> 
> Jerry, I think we are all confused :).
> 
> Join is of three types: Full member, Nonmember, Sendonlynonmember.
> 
> As far as I know one will have to join (implying one of the above three) to
> retrieve the multicast information. In the case of v4, for the broadcast-GID
(Continue reading)

Permalink | Reply | 6 comments |
headers
Vivek Kashyap | 3 Oct 2003 08:45
Picon
Favicon

Re: IPoIB link address

On Thu, 2 Oct 2003, Kanoj Sarcar wrote:

> Vivek Kashyap wrote:
> >
> > On Thu, 2 Oct 2003, H.K. Jerry Chu wrote:
>
> Hi,
>
>
> >
> > > <snip>
> > >
> > > >> Not sure I understand what exactly c) is. It refers to v6 only so v4 MUST
> > > >> always join the broadcast group, right?
> > > >
> > > >The suggestion is in general for an IPoIB link. The link attributes are
> > > >derived from the IPoIB broadcast-GID. In the case of v4 it just so happens
> > > >that IP broadcast maps to this and so a node will surely join it. We have
> > > >earlier always talked of full-join since the node will send and receive
> > > >packets on the broadcast GID. However, with the notion that one need not
> > > >join the broadcast GID I believe we need to, irrespective of the IP layer,
> > > >state that :
> > >
> > > I am confused. What is the notion that "one need not join the broadcast
> > > GID" for v4? There isn't any leeway for v4 - it must join the broadcast
> > > group for ARP to work.
> >
> > Jerry, I think we are all confused :).
> >
> > Join is of three types: Full member, Nonmember, Sendonlynonmember.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane