Subject: Re: Ignore ARP requests from remote buses

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 7 Oct 1998 13:52:09 -0700

All,

In reading back through the mails, I would like to clarify a point made
subtly early in this discussion. It was related to multi-bus IP subnets.
Here is a picture.

        1394 LINK                                              1394 LINK
        BusID = 7           -------------------------          BusId = 8
     |-------------|--------| Bridge/Router/Brouter |-------|------------|
     |             |        -------------------------       |            |
 ----------------  |                                  ----------------   |
 | IP: 10.0.0.1 |  |                                  | IP: 10.0.0.2 |   |
 | BusId: 7     |  |                                  | BusId: 8     |   |
 | PhyId: 0     |  |                                  | PhyId: 0     |   |
 ----------------  |                                  ----------------   |
                   |                                                     |
          ----------------
----------------
          | IP: 10.0.0.3 |                                    | IP: 10.0.0.4
|
          | BusID: 7     |                                    | BusID: 8
|
          | PhyId: 1     |                                    | PhyId: 1
|
          ----------------
----------------

Subnet mask is 255.255.255.0.

I hope it is clear that an ARP request in such an environment MUST span
both buses.

With Peter's proposed clause, a bridge/router/brouter that forwarded ARP
requests over both buses would not work. Thus if a non-virtual id
solution was found, Peter's clause would be harmful.

DISCLAIMER: I neither know, predict, nor suggest that a non-virtual node id
bridging solution will or won't come about. I am only to pointing out
one ramification to the clause that Peter is suggesting.

-myron

---

From: Prabhakara Yellai <[email-masked]>
Date: Wed, 7 Oct 1998 14:46:08 PDT

Myron,
   If the device is an IP Router/Brouter, then we can't
   have the same IP subnet spanning on both buses (we can
   have multiple IP subnet on a single physical network but
   can't have same IP subnet spanning on multiple physical
   networks). So, ARP packets on one bus should not go on
   the other.

   If I recall Peter's email well, I thoght he was suggesting
   to have a bridge for non-IP protocols and a router
   for IP protocol connecting multiple buses and you could
   find these two funtional devices (bridge and router) in
   one physical device. In such a case, each bus will be assigned a
   unique IP subnet address ARP packets don't have to (rather should
   not) cross the bus boundary. Did I miss something?

Prabhakar

>        1394 LINK                                              1394
LINK
|
>          | BusID: 7     |                                    | BusID:
8
>          | PhyId: 1     |                                    | PhyId:
1

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: "Hattig, Myron" <[email-masked]>
Date: Wed, 7 Oct 1998 16:02:32 -0700

>    networks). So, ARP packets on one bus should not go on

Brain hickup - replace "bridge/brouter/router" with "bridge".

>    not) cross the bus boundary. Did I miss something?

It sounds like you're suggesting that it is okay if non-IP nodes
use bridges, but IP devices should never
use a bridge. If non-IP protocols benefit from a bridge, IP protocols will
also benefit from a bridge. This does not make sense to me.

I don't recall exactly who said what, but if we mandate that IP subnets
do not span multi-bus links, it does make things simipler. The problem is
this precludes IP nodes from taking advantage of 1394 bridges that
do not use virtual node IDs. (Again, I'm not suggesting anything about
the future success of virtual node IDs).

-myron

---

From: Prabhakara Yellai <[email-masked]>
Date: Fri, 9 Oct 1998 09:28:02 PDT

>Be that as it may, people will build 1394-1394 bridges.  I don't
believe
>that the AV/C community is going to redo all their protocols so that
they
>become IP compatible.  They will want to connected their devices across
>bridges.  So, there will be a need for bridges to support these
protocols.
>The 'requirement' for IP support in home networks is actually a bit
more
>dubious especially since it is not clear that IP, as currently defined,
will
>work across a 1394 bridge.
>
>David Wooten

I don't understand why AV/C community will have to redo all their
protocols to make them IP compatible if that 1394-1394 bridge
transparently performs 'routing' for IP (and other L3 protocols viz.,
IPX etc if required). AV/C community neither looses nor gains anything
by having the 1394-1394 bridge route IP packets. But, IP community
will and so will 1394 community (I guess, as bus resets don't
have to span across busses :-)).

Prabhakara

---

From: "Hattig, Myron" <[email-masked]>
Date: Fri, 9 Oct 1998 11:48:41 -0700

On Friday, October 09, 1998 9:28 AM, Prabhakara Yellai
[SMTP:[email-masked]] wrote:
> AV/C community neither looses nor gains anything
> by having the 1394-1394 bridge route IP packets.

True.

> But, IP community

True. Only the IP community benefits from a 1394-1394 bridge that
routes IP packets.

From the other msgs on this thread,
it sounds like we can agree that none of us know if
a single IP subnet will span multi-buses or not. If
individual IP subnets do NOT span multiple buses,
then Peter's clause is implicitly true. If IP subnets
span multiple buses then Peter's clause is required
with virutal node id bridges, but will cause problems
for non-virtual id 1394-1394 bridges.

Agreed?

-myron

---

From: David Zalatimo <[email-masked]>
Date: Fri, 9 Oct 1998 13:44:44 -0700

While the 1394.1 group is defining a thing they are calling a bridge, that
doesn't necessarily
mean that it has the same functionality as what is referred to as a bridge in
the networking
world.  In fact, the architecture of 1394 as a physical medium does not map
neatly into
a the layered networking architecture of the TCP/IP world.  To some extent,
using terms
like layer 2 and layer 3 don't really make a whole lot of sense when you are
talking about
1394.  The equivalent of a layer 2 bridge in the network world doesn't seem to
have much,
if any value in connecting 1394 busses together.

David Zalatimo

On Friday, October 09, 1998 11:38 AM, Tony Li [SMTP:[email-masked]] wrote:
> |  I was misusing the term 'bridge' in the 1394.1 context.  In that context,
> |  the protocols are 'supported' by routing 1394 packets using 1394 node ID's
> |  and channel numbers.  They aren't using IP addresses for routing.
>
>
> Understood.  However, if they are tampering with L3 packets in an L2
> device, they are certainly much more intelligent than one would expect.
>
>
> |  It might have been better to have used the term 'router' for the things
> |  that
> |  are used to allow communications between two or more 1394 buses, but that
> |  had some scary connotations also.  Maybe we should call these things
> |  'gluons'.  I'm sure that the particle physics people wont mind us co-
> |  opting
> |  one of their terms.
>
>
> I think that the industry-standard term 'brouter' might as well be used.
> Until, of course, the marketeers get hold of it.  ;-)
>
> Tony

---

From: Prabhakara Yellai <[email-masked]>
Date: Fri, 9 Oct 1998 14:01:17 PDT

Myron,
>for non-virtual id 1394-1394 bridges.

   Completely agree with you. However, I didn't see
   your pick of the two roads, having a good idea about
   where each one is taking us to. Is there any time out
   for consensus/vote/decision making :-)?

Prabhakar

---

From: Prabhakara Yellai <[email-masked]>
Date: Fri, 9 Oct 1998 13:53:00 PDT

David,

>Toni,
>
>I was misusing the term 'bridge' in the 1394.1 context.  In that
context,
>the protocols are 'supported' by routing 1394 packets using 1394 node
ID's
>and channel numbers.  They aren't using IP addresses for routing.
>

   This is how I would expect a smart 1394 bridge  function.
   A smart Ethernet bridge (Transparent Ethernet Bridge supporting
   Spanning Tree Protocol) 'routes' Ethernet Packets belonging to
   'unknown' L3 protocols based on the Destination MAC address.

Prabhakar

---

From: "Wooten, David" <[email-masked]>
Date: Mon, 12 Oct 1998 18:32:38 -0500

If you release the spec the way it is currently written (even with Peter's
proposed changes) ARP will not work over bridges.  Furthermore, you can't
send packets on the default IP channel across a bridge, EVER.  Not now, not
in the future, not EVER.  That's a terrible thing to institutionalize.

David Wooten

-----Original Message-----
From:   Hattig, Myron [SMTP:[email-masked]]
Sent:   Monday, October 12, 1998 5:07 PM
To:     [email-masked]
Subject:        Re: Ignore ARP requests from remote buses

On Friday, October 09, 1998 1:48 PM, Wooten, David
[SMTP:[email-masked]] wrote:
> I thought is was
> agreed that there wasn't going to be an IP spec until the IP devices
> knew
> how to work across bridges (because of the 0x3ff problem) so that
> bridges wouldn't have to do the twiddling.

I only recall opposition to postponing the IP/1394 spec. I clearly remember
Peter not supporting postponing the IP/1394 spec. I though David Z and/or
Prabhakar mentioned there was no need to postpone. The WG Co-chairs,
myself and Tony, certainly don't think there is a need to postpone the
IP/1394 spec.

I stated my position in my last email. I can live with Peter's clause, but
I prefer it not be present. I DO NOT support postponing the spec.

-myron

---

From: "Hattig, Myron" <[email-masked]>
Date: Mon, 12 Oct 1998 17:08:55 -0700

David,

If there is a market demand for something it will built. The possible
solutions we have discussed are:

1) a router that does some 1394 specific bridging
2) a 1394 bridge that only supports IP
3) a non-virtual node id bridge
4) 1394 hubs that connect dispersed devices using long distance 1394 while
being on the same bus, hub performs other bridge functions such as stream
isolation (not discussed, but an idea worth exploring)

In addition, the IETF has provisions to change specifications. If a spec is
determined to be broken because of a strong demand for an IP subnet to span
multi-bus 1394 networks (which is the only time IP needs a 1394 bridge) and
for these buses to be connected via 1394 bridges with virtual node IDs, then
the spec will forced to change.

IMHO, there are broad possibilities that will surely come about if demanded
by the market. Not ever in the future is a very long time.

-myron

---

From: "Wooten, David" <[email-masked]>
Date: Fri, 16 Oct 1998 03:00:44 -0500

Kenji,

I have just had a long talk with Peter.  I don't think he believes that the
clause he suggest actually fixes anything.  He seemed apologetic that he had
not had the opportunity to recant his suggestion. If he did withdraw his
suggestion, would that change your thinking?

David Wooten

-----Original Message-----
From:   Kenji Fujisawa [SMTP:[email-masked]]
Sent:   Thursday, October 15, 1998 11:49 AM
To:     [email-masked]
Subject:        Re: Ignore ARP requests from remote buses

> Here are three possible next steps:
> 1) Add the clause suggested by Peter, move forward with the draft.
> 2) Delay the draft until we have a clear understanding of what
coexistences
> of IP and bridges requires from both IP devices and bridges.
> 3) Do not add the clause suggested by Peter and move forward with the
draft.

> I look forward to comments from others.

Although I can not predict the P1394.1 spec at this moment, it seems
that
the remote-transaction capable node should be aware of the existence of
the
1394 bridge to some extent, such as
- maximum transmission speed,
- maximum packet size,
- split transaction timeout value,
- bus reset behaviour,
- (possibly) virtual node ids,
- and so on.

So, I think option (1) will be the safe way we can choose at this
moment.
As others mention, this clause will not prevent IP routing between 1394
busses.

Kenji Fujisawa
# All opinions are my own and do not reflect my employers

---

From: "Wooten, David" <[email-masked]>
Date: Sun, 18 Oct 1998 14:59:34 -0500

Myron,

Going back over some really old emails that I didn't get a chance to reply
to before.

The issue with IP and 1394 bridges is simple -- is IP going to be widely
used on 1394 or not.  If the answer is "no" then I think the IP group is
wasting its time.  If, however, the answer is "yes", then we need to make
sure that 1394.1 bridges can be deployed with IP support at an economical
cost.  I personally think that the most economic cost will be had when IP
and non-IP protocols use similar features of bridges.

My reason for wanting to make sure that we get the lowest incremental cost
for having IP support in 1394.1 bridges is that I don't want to see bridges
deployed without IP support.  If we take the attitude that IP is so
important that people will spare no expense to include it in their bridge
designs, we might be disappointed.  If bridges get deployed without IP
support then solutions will develop that don't require IP.  Then, it will be
VERY hard to get people to rip out their installed base of non-IP capable
bridges and replace them with IP capable ones.  It will also be hard to get
IP routers installed along side of 1394 bridges.  So, IMHO, IP will not be
widely used in 1394 environments unless standard 1394 bridges have IP
support.  Furthermore, that support will not be there if the incremental
cost of IP support is prohibitive.  So, lets make sure that IP support is as
inexpensive as we know how to make it in1394.1 bridges.

David Wooten

                -----Original Message-----
                From:   Hattig, Myron [mailto:[email-masked]]
                Sent:   Monday, October 12, 1998 7:09 PM
                To:     Wooten, David; [email-masked]
                Subject:        RE: Ignore ARP requests from remote buses

                David,

                If there is a market demand for something it will built. The
possible
                solutions we have discussed are:

                1) a router that does some 1394 specific bridging
                2) a 1394 bridge that only supports IP
                3) a non-virtual node id bridge
                4) 1394 hubs that connect dispersed devices using long
distance 1394 while
                being on the same bus, hub performs other bridge functions
such as stream
                isolation (not discussed, but an idea worth exploring)

                In addition, the IETF has provisions to change
specifications. If a spec is
                determined to be broken because of a strong demand for an IP
subnet to span
                multi-bus 1394 networks (which is the only time IP needs a
1394 bridge) and
                for these buses to be connected via 1394 bridges with
virtual node IDs, then
                the spec will forced to change.

                IMHO, there are broad possibilities that will surely come
about if demanded
                by the market. Not ever in the future is a very long time.

                -myron

                On Monday, October 12, 1998 4:33 PM, Wooten, David
                [SMTP:[email-masked]] wrote:
                > If you release the spec the way it is currently written
(even with
                > Peter's
                > proposed changes) ARP will not work over bridges.
Furthermore, you
                > can't
                > send packets on the default IP channel across a bridge,
EVER.  Not
                > now, not