Subject: Re: Bridges and TCP/IP

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

Myron,

I'm not suggesting that the IP/1394 WG members postpone their spec until
1394.1 determines how to do bridging.  I am suggesting that the IP/1394 WG
and the 1394.1 working groups arrive at a solution to the current ARP
problem that will allow both groups to go about their business, largely
independently.  The current ARP specification will not work with any of the
schemes that have been talked about in 1394.1.  The problem is not that
1394.1 might want to use persistent node ID's (a.k.a., virtual node ID's)
but that we have no way of preventing ARP packets with an 0x3FF bus number
from getting off the local bus.  Obviously, a bus number of 0x3FF is not
useful as an address for a node that might be on another bus and can/will
actually cause problems in identifying nodes (multiple nodes will seem to
have the same address.)  Until this problem is factored so that the IP and
1394.1 folks can continue to work independently, I don't think it is useful
to have people continue to work with the current ARP specification.

David Wooten

                -----Original Message-----
                From:   Hattig, Myron [mailto:[email-masked]]
                Sent:   Friday, October 16, 1998 2:09 PM
                To:     [email-masked]'; Wooten, David
                Subject:        Re: Bridges and TCP/IP

                David,

                Here are some comments to help ensure the below responses
are clear.
                I, and many other IP/1394 WG members, are in strong favor of
bridging WG
                members and IP WG members working together through the
issues.

                This mail thread only addresses the issue of postponing the
IP/1394
                spec while the bridging work firms-up. Maybe we are having a
disconnect
                on the meaning of "postponing". By "Postponing", I meant the
IP/1394
                spec does not advance through the IETF Standardization
process until
                the bridging work is complete enough to know exactly how IP
and bridges
                will co-exists.

                "Postponing" does not mean we will not add additional
clauses to the
                current draft to fix whatever issues we know about now or
before
                the IP/1394 spec is at a stage in the IETF standardization
process in
                which it is harder to change. The comment from my original
mail:
                > Also, there may be small clause(s) added to
                > the next revision(s) of the IP/1394 Spec that will ease
this future
                > effort.
                was to support any changes required by known issues.

                More responses below.

                Wooten, David wrote:
                >
                > I strenuously object to your determination that "the
matter of postponing
                > the IP/1394 Spec to better support 1394 bridges closed."
You make not
                that
                > the 1394.1 group was currently meeting and that they were
looking at this
                > issue and that you would expect to hear from the members
of that group
                when
                > the meeting had reached some conclusion.

                Note my comment about still adding clause(s)to support
bridges.

                > Then you preemptively decide to
                > close the issue that the 1394.1 group was going to comment
on.

                We only closed the issue on indefinitely postponing the
IP/1394
                Spec while we wait for the bridging work to firm up. The
door
                remains open to solve problems when there is hope of solving

                them. If first-step recommendations come back from the
bridging
                working group that gain support of the IP/1394 WG members
then
                we will change the IP/1394 spec. A past indication of this
is
                our dialogue about the Peter's proposed change related to
help
                ARP work with bridges. Peter's suggestion was not being
strongly
                opposed by anyone.

                > This is not appropriate behavior.
                > Perhaps the 1394.1 group should form its own task
                > group to define IP over 1394 and declare the work being
done by the group
                > that you chair to be irrelevant?

                I'll follow Mike Teener's suggestion and stay away from this
type of
                dialogue.
                I'm really trying to work with the bridging group as best I
can, while doing

                what's best for the IP/1394 working group. I hope to be a
participant in the

                bridging WG soon to further both bridging and IP efforts
while avoiding this

                type of dialogue.

                Also, the determination to close the issue was not made
solely by myself nor

                lightly. I asked the opinion of several WG members and
discussed this with
                the Tony.  For the single issue that was addressed by this
email "postponing
                the IP/1394 spec", there was neither support from the
individuals polled
                nor support in responses on the reflector. Based on the
email traffic
                alone we have rough consensus as defined by the IETF. I
polled the
                individuals to make sure I was not misinterpreting the
group. Again, this
                does
                not mean that the two WGs should not work together, it just
means IP/1394
                cannot wait indefinitely for the bridging WG to finish.

                Best regards,

                -myron

                > David Wooten
                >
                > -----Original Message-----
                > From:   Hattig, Myron [SMTP:[email-masked]]
                > Sent:   Thursday, October 15, 1998 5:43 PM
                > To:     [email-masked]
                > Subject:        Re: Bridges and TCP/IP
                >
                > [WG Co-Chair Hats ON]
                >
                > Hello,
                >
                > There is WG rough consensus that the draft should not be
held up or
                > postponed until the p1394.1 WG and IP/1394 WG have a clear
understanding
                > of how both types of devices will peacefully co-exist.
Some work will
                > very likely be required in the future to modify the
IP/1394 Spec to
                > support 1394 bridges. Also, there may be small clause(s)
added to
                > the next revision(s) of the IP/1394 Spec that will ease
this future
                > effort.
                >
                > Note the p1394.1 group is meeting as this mail is being
sent, so I
                > suspect responses from the folks supporting the
postponement of the
                > IP/1394 Spec will be posted over the next week or so.
                >
                > We are now considering the matter of postponing the
IP/1394 Spec to
                > better support 1394 bridges closed.
                >
                > Tony and Myron
                >
                > [WG Co-Chair Hats OFF]

---

From: Tony Li <[email-masked]>
Date: Mon, 19 Oct 1998 12:56:55 -0700

[email-masked] (Wooten, David) writes:

> independently.

David,

Your two sentences are contradictory.  If we make changes to ARP at this
point, not only will it postpone the spec, but it will also invalidate the
existing implementations.

Further, fixing ARP is only one small fraction of the changes necessary to
operate across a bridge.  Please see my previous comment about MCAP.

Regards,
Tony

---

From: Kenji Fujisawa <[email-masked]>
Date: Mon, 26 Oct 1998 15:03:11 +0900

>The current ARP specification will not work with any of the
>schemes that have been talked about in 1394.1.

I'm not sure what was talked in P1394.1.
What do you think of following idea?

* Change the 'Unfragmented header format' to be the same as 'First
  fragment header format'.

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | lf|rsv|      buffer_size      |           ether_type          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |              dgl              |           signature           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        The uniform header format for all fragments will simplify
        the link fragmentation/reassembly and 'signature' field
        in an Async Streams will increase the capability of the
        trouble shooting.

* The egress bridge modifies the 'signature' field to be the virtual
  node id when it forwards an Async Stream packet received in a
  broadcast channel.

* Use following fields to identify the sender when handling a received
  ARP packet and reassembling received fragments.

        Async Write Packet      'source_ID' field in the 1394 header

        Async Streams Packet    'signature' field in the encapsulation
                                header

  Note that the target part in an ARP response can not be used
  when eavesdropping an ARP response since it will contain a physical
  address of the ARP requestor.

Kenji Fujisawa