Subject: RE: [Ipoverib] recharter consideration

From: Yaron Haviv <[email-masked]>
Date: Thu, 05 Sep 2002 23:39:42 +0300

Jerry,

We can try and target fail-over with IPoIB
In Ethernet a system can just use a MAC faking technique to migrate to a
standby station
In IB a client station cannot take over an HW address of a different machine
This poses restrictions on fail-over mechanisms
(One might suggest ARP's for it, however it doesn't solve the same problems)

We can try to have a mechanism, especially in conjunction with RC
Where we have a standby HW address configured, in case of failure we move to
the alternate address
(It is different from APM since the two paths direct us to two different end
nodes, not one)

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
H.K. Jerry Chu
Sent: Thursday, September 05, 2002 2:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Ipoverib] recharter consideration

In Yokohama we discussed a few new items that people thought
may be useful and have suggested to add them to the WG charter.
Note that these work items still need to be blessed by the
ADs and IESG before they can be adopted by the WG. For each
work item the ADs are looking for

a. clear benefit (over the added cost) and sufficient interest
from the WG

b. concise definition and scope

c. deliverables and milestones

The following is a summary of the work items that have been
brought up so far and the questions/issues raised by the audience
in the Yokohama meeting.

1) encapsulating IP datagrams using a non-UD transport (e.g.
UC, RC)

question - scope is not clear

2) demux IP datagrams over multiple QPs

issue - dubious benefit; it may introduce routing and session
establishment problems?

(Two opposed this item in f2f meeting.)

3) other client capability, e.g. SDP

issue - non-IP therefore out of scope

4) skipping TCP/UDP checksum when running over RC/UC.

issues - serious concern from many. difficult to ensure end2end
property. could be made to work in a limited set of cases but the
added complexity seems far outweigh the benefit.

All the above fall into the category of advanced features,
and their usage is completely optional. This way they should
not affect the basic IP over IB operation defined by the
existing IPoIB drafts.

Given the amount of concerns raised so far against 4), I'd like to
remove it from the list of consideration. If you have a problem with
that please bring it up to me and Bill. For the rest three I'll need
you to

1. show your interest and/or volunteer for the work
2. provide a concise description on what the item is, why it should
be considered (e.g. the benefit), and the deliverables

Jerry and Bill,
IPoIB co-chairs

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

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

---

From: "Bill Strahm" <[email-masked]>
Date: Thu, 5 Sep 2002 14:13:28 -0700

The first step is to produce an Internet Draft on how you would expect
such a feature to work... You might even just start with a requirements
document on what it needs to provide, and the limits etc.

Once this happens, we can determine if we need to add it to the charter.
This also shows that there is at least some interest in getting a
feature, not just people saying, it would be nice if someone else does
this work

Bill

-----Original Message-----
From: Yaron Haviv [mailto:[email-masked]] 
Sent: Thursday, September 05, 2002 1:40 PM
To: 'H.K. Jerry Chu'; [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] recharter consideration

Jerry,

We can try and target fail-over with IPoIB
In Ethernet a system can just use a MAC faking technique to migrate to a
standby station In IB a client station cannot take over an HW address of
a different machine This poses restrictions on fail-over mechanisms (One
might suggest ARP's for it, however it doesn't solve the same problems)

We can try to have a mechanism, especially in conjunction with RC Where
we have a standby HW address configured, in case of failure we move to
the alternate address (It is different from APM since the two paths
direct us to two different end nodes, not one)

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of H.K. Jerry Chu
Sent: Thursday, September 05, 2002 2:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Ipoverib] recharter consideration

In Yokohama we discussed a few new items that people thought may be
useful and have suggested to add them to the WG charter. Note that these
work items still need to be blessed by the ADs and IESG before they can
be adopted by the WG. For each work item the ADs are looking for

a. clear benefit (over the added cost) and sufficient interest from the
WG

The following is a summary of the work items that have been brought up
so far and the questions/issues raised by the audience in the Yokohama
meeting.

1) encapsulating IP datagrams using a non-UD transport (e.g. UC, RC)

issues - serious concern from many. difficult to ensure end2end
property. could be made to work in a limited set of cases but the added
complexity seems far outweigh the benefit.

All the above fall into the category of advanced features,
and their usage is completely optional. This way they should not affect
the basic IP over IB operation defined by the existing IPoIB drafts.

Given the amount of concerns raised so far against 4), I'd like to
remove it from the list of consideration. If you have a problem with
that please bring it up to me and Bill. For the rest three I'll need you
to

1. show your interest and/or volunteer for the work
2. provide a concise description on what the item is, why it should be
considered (e.g. the benefit), and the deliverables

Jerry and Bill,
IPoIB co-chairs

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