[rbridge] Updated charter

[touch at ISI.EDU (Joe Touch)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Fred L. Templin wrote:
| Erik,
|
| The updated Rbridge charter you posted on 1/27/05 doesn't say anything
| about MTU issues for bridging dissimilar layer 2 media. Can we have a
| bullet under work items and deliverables that specifically calls for
| work on MTU issues?
|
| Fred
| [e-mail]

That part of the proposed charter, notably:

| The working group will look into solutions that can interconnect different
| layer 2 technologies, and also look at providing support for non-IP
protocols,
| even though one can not combine those two features together; the
| interconnection of different layer 2 technologies (with different layer 2
| address formats) will most likely only work for the IP family of
protocols.

Why is interconnection of different L2 technologies either useful or
relevant? IMO, that's not a bridge anymore.

I thought the goal was to build something that looked like a bridge from
the outside. Interconnecting different L2's (different address formats,
TTLs, etc.) is a router, isn't it?

- ----

Also, some of the charter is over-specific:

| The working group will not work any layer 3 aspects except to provide
|  - Optimizations so that ARP and ND packets are not always
|    flooded everywhere
|  - Being able to carry IP multicast packets using flooding (which will
|    presumably fall out by being able to flood L2 multicast packets, so
there
|    might not be any specific work needed here).
|  - Defining the L3 operations needed to interconnect different L2
technologies

IMO, if we want to include, in general terms "optimizations to avoid
unnecessary flooding", or "ability to efficiently handle multicast",
that's good, but specifying HOW those should be achieved, or what
defined efficient, IMO is what the WG ought to decide.

Similar comments apply to the list of work items.

Joe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB/+BwE5f5cImnZrsRAjbgAJ9703XR7CGqFqkso+2kCK2/m7g7yQCg5RLI
JaxkiK8bI97zofOyoDnZcoM=
=Pb2m
-----END PGP SIGNATURE-----
From erik.nordmark at sun.com  Tue Feb  1 14:21:47 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue Feb  1 14:22:35 2005
Subject: [rbridge] Updated charter
In-Reply-To: <[e-mail]>
References: <000901c50896$e2619610$6401a8c0@grayling>
	<[e-mail]>
Message-ID: <[e-mail]>

Joe Touch wrote:
> Why is interconnection of different L2 technologies either useful or
> relevant? IMO, that's not a bridge anymore.
> 
> I thought the goal was to build something that looked like a bridge from
> the outside. Interconnecting different L2's (different address formats,
> TTLs, etc.) is a router, isn't it?

There were folks that expressed interest in this at the BoF, and I 
suspect the motivation is the same as for the rest of the work i.e. 
avoid the subnet numbering issue one has with IP routers, have the 
plug&play of bridges, and a robust protocol.


> Also, some of the charter is over-specific:
> 
> | The working group will not work any layer 3 aspects except to provide
> |  - Optimizations so that ARP and ND packets are not always
> |    flooded everywhere
> |  - Being able to carry IP multicast packets using flooding (which will
> |    presumably fall out by being able to flood L2 multicast packets, so
> there
> |    might not be any specific work needed here).
> |  - Defining the L3 operations needed to interconnect different L2
> technologies
> 
> IMO, if we want to include, in general terms "optimizations to avoid
> unnecessary flooding", or "ability to efficiently handle multicast",
> that's good, but specifying HOW those should be achieved, or what
> defined efficient, IMO is what the WG ought to decide.

Margaret has been circulating the draft charter amount the IAB and IESG 
in advance of it being on their agenda (next week).
The above items were added because Rob Austein thought the charter was 
quite nebulous on what was needed in terms of L3, so I tried to clarify 
things.

My take is that optimizing multicast delivery above just making it work, 
is something which a WG can look into once they've delivered the basic 
technology i.e. something that would be reasonable to add after a recharter.

FYI: Some more IAB/IESG comments have come in asking for more 
clarifications on the relationship between this WG and the routing 
protocol WG(s), so we will most likely need more detail on that front in 
the charter.

> Similar comments apply to the list of work items.

My experience is that the IESG wants to see a concrete list of work 
items before they want to charter a WG.

    Erik
From erik.nordmark at sun.com  Tue Feb  1 14:24:06 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue Feb  1 14:24:33 2005
Subject: [rbridge] Re: Updated charter
In-Reply-To: <000901c50896$e2619610$6401a8c0@grayling>
References: <000901c50896$e2619610$6401a8c0@grayling>
Message-ID: <[e-mail]>

Fred L. Templin wrote:
> Erik,
> 
> The updated Rbridge charter you posted on 1/27/05 doesn't say anything
> about MTU issues for bridging dissimilar layer 2 media. Can we have a
> bullet under work items and deliverables that specifically calls for
> work on MTU issues?

Perhaps it isn't a separable deliverable, but instead a goal for the 
solution to work when the MTUs are different, which might be the case 
even for L2s that use the same address format (such as one Ethernet with 
and one Ethernet without jumbo frame support)

I can add this to the charter.

    Erik
From fltemplin at acm.org  Tue Feb  1 14:36:12 2005
From: fltemplin at acm.org (Fred L. Templin)
Date: Tue Feb  1 14:36:59 2005
Subject: [rbridge] IPvLX acronym and URLs
In-Reply-To: <[e-mail]>
Message-ID: <000f01c508ae$6fa20cf0$6401a8c0@grayling>

I have reserved the acronym "IPvLX" and domain names
'ipvlx.{com,org,net}' with the intention of turning them over at any
time the chairs feel they are ready to begin using them for the WG's
efforts - just let me know when you'd like to take them over, Erik. 

Fred
[e-mail]