Subject: [rbridge] Updated charter

From: fltemplin at acm.org (Fred L. Templin)
Date: Tue Feb 1 11:48:32 2005

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
[email-masked]

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue Feb 1 12:03:10 2005

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
| [email-masked]

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

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue Feb 1 14:22:35 2005

> 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.

> 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 (Erik Nordmark)
Date: Tue Feb 1 14:24:33 2005

> bullet under work items and deliverables that specifically calls for

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 (Fred L. Templin)
Date: Tue Feb 1 14:36:59 2005

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
[email-masked]

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue Feb 1 14:58:38 2005

> plug&play of bridges, and a robust protocol.

While I cannot argue with the motivation, I don't think this is a place 
where we can "eat our cake and have it too". IMO, briding dissimilar 
MTUs might be possible, but bridging different L2 address spaces implies 
a common address space, which means something very much like IP (with 
all the warts noted above).

FWIW, if we end up peeking into L3 to get this done, then we ought to 
call it a router and be done with it.

> technology i.e. something that would be reasonable to add after a 

Optimizing is one thing, but talking about specifics (involving 
flooding) or not is where the charter is getting a bit overspecific.

As to the last bullet, see RFC1812, which IMO provides exactly the L3 
operations that interconnect disparate L2s.

> protocol WG(s), so we will most likely need more detail on that front in 

Agreed. This doesn't appear to discuss the encapsulation of routing 
within the rbridge - that it is necessarily opaque to other routing 
protocols, e.g., BGP in ways unlike other routing protocols.

> items before they want to charter a WG.

Concrete list of work items, agreed.

Concrete list of approaches to those work items is the task of the WG, IMO.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050201/71f45de0/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue Feb 1 15:39:02 2005

> call it a router and be done with it.

The charter calls it neither a router nor a bridge, but a hybrid.

The solutions that have been discussed will replace the L2 headers (at 
least in some cases, and encapsulate in another L2 header in some 
cases), and not decrement the L3 TTL, which is different than a bridge 
(which doesn't replace the L2 header) and a router (which decrements TTL).

Is there a problem with the devices being hybrids?
They will preserve the behavior that an IP packet injected at one end of 
  the link will appear unmodified at the other end.

> flooding) or not is where the charter is getting a bit overspecific.

Ack. Let me see what additional comments Margaret receives from the IESG 
and IAB.

>> protocol WG(s), so we will most likely need more detail on that front 
>> in the charter.
> 
> 

Do you mean opaque to the routing protocol used to carry IP 
reachability? (where the ipvlx routing protocol carries L2 address 
reachability)
Or something different?

> Concrete list of approaches to those work items is the task of the WG, IMO.

I'll make another pass over the charter and hopefully fix this.

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue Feb 1 16:55:36 2005

Erik Nordmark wrote:
> Joe Touch wrote:
> 
>> While I cannot argue with the motivation, I don't think this is a 
>> place where we can "eat our cake and have it too". IMO, briding 
>> dissimilar MTUs might be possible, but bridging different L2 address 
>> spaces implies a common address space, which means something very much 
>> like IP (with all the warts noted above).
>>

The basis of the Internet is a single address layer that spans different 
link layers. There are numerous problems stemming from the rbridge 
basically needing to proxy the semantics of two different L2 systems.

What you're proposing is a router that doesn't decrement the TTL. That's 
not the same as a bridge that uses routing (vs. spanning tree) 
internally; the former doesn't include L2 semantics, the latter does. 
The latter presumes a single L2 semantics, which is easy to verify. The 
former (as you suggest) allows multiple L2s, but does NOT preserve L2 
semantics.

That means a lot of IP will break where/when the L2s have different 
semantics, e.g., NBMA vs. broadcast. We don't have a uniform L2 
emulation protocol on which to base an interoperability layer (the PILC 
WG noted some of its expected properties, but didn't spec it out as 
such). This work seems like it should avoid L2 translation until that 
canonical virtual L2 can be spec'd.

...
> reachability? (where the ipvlx routing protocol carries L2 address 

That the routing inside the rbridge is opaque to things outside the rbridge.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050201/6b33fc02/signature.bin

---

From: michsmit at cisco.com (Michael Smith)
Date: Tue Feb 1 17:54:20 2005

> From: Erik Nordmark
> The solutions that have been discussed will replace the L2 
> headers (at least in some cases, and encapsulate in another 
> L2 header in some cases), and not decrement the L3 TTL, which 
> is different than a bridge (which doesn't replace the L2 
> header) and a router (which decrements TTL).

Some specific examples may help clarify, but the above statement sounds like
the traditional bridge of yore i.e. bridges with ethernet and token ring
interfaces that swap MAC headers to the appropriate canonical format and
encapsulating bridging packets over ATM and Frame Relay using RFC1483 and
RFC1490.

Michael

> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed Feb 2 09:56:31 2005

...
> encapsulating bridging packets over ATM and Frame Relay using RFC1483 and

How they're encapsulated isn't important per se. Traditional bridges 
between ethernet and 802 token ring don't change the MAC header; they 
adapt between to access protocols, frame structures, etc, but the 
addresses are consistent. Or are you referring to somthing else, and if 
so, perhaps it'd be useful to understand why it's extinct at this point...

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050202/ba2d4825/signature.bin

---

From: michsmit at cisco.com (Michael Smith)
Date: Wed Feb 2 10:46:58 2005

> From: Joe Touch [mailto:[email-masked]] 
>
> Michael Smith wrote:
> >  
> >>From: Erik Nordmark
> >>
> >>Joe Touch wrote:
> ...
> headers (at 
> >>least in some cases, and encapsulate in another
> >>L2 header in some cases), and not decrement the L3 TTL, which is 
> >>different than a bridge (which doesn't replace the L2
> > Some specific examples may help clarify, but the above statement 
> > sounds like the traditional bridge of yore i.e. bridges 
> with ethernet 
> > and token ring interfaces that swap MAC headers to the appropriate 
> > canonical format and encapsulating bridging packets over 
> ATM and Frame 
> > Relay using RFC1483 and RFC1490.
> 
> How they're encapsulated isn't important per se. Traditional 
> bridges between ethernet and 802 token ring don't change the 
> MAC header; they adapt between to access protocols, frame 
> structures, etc, but the addresses are consistent. Or are you 
> referring to somthing else, and if so, perhaps it'd be useful 
> to understand why it's extinct at this point...

Yes, I was referring to traditional translational bridges which "adapt" the
headers.  AFAIK, a bridge either retains the MAC header (transparent
bridging), translates the MAC header (translational bridging), strips the
header and terminates the frame (i.e. BPDUs), or encapsulates/decapsulates
it when transporting across specific media types.  I was assuming that
"replace the MAC header" in this context was referring to translational
bridging.  If not, it would be nice to see a specific example as to what is
meant by "replace" and if it implies something beyond the capabilities just
stated.

Michael

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed Feb 2 10:56:52 2005

Michael Smith wrote:
...
> meant by "replace" and if it implies something beyond the capabilities just

Sure - translating 802 token ring to 802 ethernet is easy. IMO, they're 
effectively a single L2 by design.

Translating 802 to ATM is not.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050202/bf9aac7d/signature.bin

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed Feb 2 13:16:59 2005

> encapsulating bridging packets over ATM and Frame Relay using RFC1483 and

I guess there is a difference between the theory of bridges, captured in 
IEEE standards, and what products actually do. I don't think the IEEE 
standards talk about what bridges between e.g. Ethernet and Token Ring 
do, but I recall products doing somethings like handling bit-order 
issues with the addresses in arp packets, and the need to fragment IP 
packets due to the different MTUs.

Radia's rbridge draft (I think) talks about optimizations for IP where 
the IP packet would transit a cloud of rbridges unmodified, but where 
the L2 header might be different on exit than on entry. This isn't a 
problem for IP, since IP doesn't look at the L2 header, but can't be 
applied to non-IP (aka unknown to the rbridge) protocols.

    Erik

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Wed Feb 2 16:59:05 2005

> basically needing to proxy the semantics of two different L2 systems.

The Internet architecture assumes very little about the L2 
infrastructure. For instance, it works with L2s that preserve the same 
L2 header (Ethernet being one example) but also over L2s that only use 
local identifiers (such as DLCIs in frame relay).

I don't see how running IP over a L2 where the L2 headers are different 
when received than when transmitted will cause problems, as long as the 
protocols involved in L2 address resolution are handled correctly.

So perhaps you can list the numerous problems.

> What you're proposing is a router that doesn't decrement the TTL.

No. And I think it is in the interest of clarity, especially during 
these formative times, that we don't reuse old terms for new things.
So please call it a hybrid, a rbridge, a frobnits, but not a router or a 
bridge, since that will confuse things with the routers and bridges that 
exist today.

> That's 

What we are talking about is a hybrid, which includes L2 semantics but 
might not preserve L2 semantics when carrying IP packets.

> canonical virtual L2 can be spec'd.

I don't think anybody has argued that the protocol will support any L2. 
What's being suggested is that it support some degree of non-uniformity.
And since we are assuming that ARP/ND be used for L2 address resolution 
there is an unstated assumption that all such L2 support 
broadcast/multicast.

> That the routing inside the rbridge is opaque to things outside the 

OK, that I understand.

I think there is a range of semantics that are possible for the hybrids, 
and the WG needs to discuss them.
At one end we have what you seem to be arguing for, which I'll call 
strict IEEE 802 bridge equivalence,
This means that the cloud of interconnected hybrids behave the same way 
as an IEEE compliant bridge. I think this means that not only are the L2 
headers not modified, but also that the packets are delivered on the 
ports where an IEEE 802 bridge would deliver them (i.e. all ports for 
broadcast and multicast).

At another end of the scale we have what I'd call "IP works". In this 
case the cloud of interconnected hybrids collectively exhibit behavior 
so that IPv*/ARP/ND/DHCP etc work as expected.

Note that there are probably interesting points between these scales. 
One is what existing switch products do for multicast, which is to do 
IGMP/MLD snooping to limit the spread of multicast.
Presumably there are others as well.

    Erik

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed Feb 2 18:00:16 2005

Erik Nordmark wrote:
> Joe Touch wrote:
> 
>> The basis of the Internet is a single address layer that spans 
>> different link layers. There are numerous problems stemming from the 
>> rbridge basically needing to proxy the semantics of two different L2 
>> systems.
> 

It works fine, as you noted, over pt-pt links, but not over things that 
are intended to look like shared media, e.g., subnets.

> bridge, since that will confuse things with the routers and bridges that 

Why? It walks like a router, talks like a router, and quacks like a 
router. Examining the IP layer, changing L2 headers, etc. The only thing 
it doesn't do that a router does - so far - is decrement the TTL. Others 
would be, e.g., to limit all 1's broadcast.

>> That's not the same as a bridge that uses routing (vs. spanning tree) 
>> The latter presumes a single L2 semantics, which is easy to verify. 
>> The former (as you suggest) allows multiple L2s, but does NOT preserve 
>> L2 semantics.
> 

Huh? You're preserving L2 semantics but only for IP, which doesn't care 
(above) about such preservation?

>> emulation protocol on which to base an interoperability layer (the 
>> PILC WG noted some of its expected properties, but didn't spec it out 
>> as such). This work seems like it should avoid L2 translation until 
>> that canonical virtual L2 can be spec'd.
> 

But we were talking about such support in ways that avoided broadcast...

> broadcast and multicast).

Agreed.

> so that IPv*/ARP/ND/DHCP etc work as expected.

Why can't we call that a router that doesn't decrement TTL?

> Presumably there are others as well.

Bridges can - and do limit the spread of multicast. They do not limit 
the spread of broadcast based on L3 semantics (unless doing explicit 
proxy-arp, but that's not what we're talking about). If there's an 
intermediate point between the above two, it'd be useful to figure out 
what it IS and why it's needed before we created a WG to design it.

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050202/bd5c5938/signature.bin

---

From: fltemplin at acm.org (Fred L. Templin)
Date: Thu Feb 3 07:44:36 2005

The placeholder web page at 'ipvlx.{com,org.net}' has been updated.

Fred
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fred L. Templin
Sent: Tuesday, February 01, 2005 2:36 PM
To: [email-masked]
Subject: [rbridge] IPvLX acronym and URLs

Fred
[email-masked]

_______________________________________________
rbridge mailing list
[email-masked] http://www.postel.org/mailman/listinfo/rbridge

---

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Fri Feb 4 07:18:45 2005

> are intended to look like shared media, e.g., subnets.

And the numerous problems in that case are ....

> would be, e.g., to limit all 1's broadcast.

It might route the packet based on the L2 address instead of IP, for
instance. Hence using a different term than "router" aids in clarity IMHO.

> (above) about such preservation?

I think you need to re-read what I wrote above.

> But we were talking about such support in ways that avoided broadcast...

Who has been talking about hybrid devices which interconnect broadcast
and NMBA L2s?

> Why can't we call that a router that doesn't decrement TTL?

Because, AFAIK, it forwards packets based on L2 addresses.
(Remember, we had this mailing list discussion about packets sent to
off-subnet destinations and the interaction with redirects etc, which
resulted in at a minimum packets destined off-subnet need to be routed
based on the L2 destination.)

> proxy-arp, but that's not what we're talking about).

I'm confused. We'd talked about ARP/ND flooding a while back, and
concluded there were security and robustness issues around that, which
need considerations.
But I thought the current topic was about interconnecting different
types of L2s (with different address formats), which is orthogonal to 
any limitations on the flooding of broadcasts.

    Erik