[rbridge] Updated charter

[touch at ISI.EDU (Joe Touch)]

Erik Nordmark wrote:
> 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.

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.

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

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.

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

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.

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

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  Tue Feb  1 15:37:05 2005
From: erik.nordmark at sun.com (Erik Nordmark)
Date: Tue Feb  1 15:39:02 2005
Subject: [rbridge] Updated charter
In-Reply-To: <[e-mail]>
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>

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

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.


> Optimizing is one thing, but talking about specifics (involving 
> 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.

> As to the last bullet, see RFC1812, which IMO provides exactly the L3 
> operations that interconnect disparate L2s.
> 
>> 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.
> 
> 
> 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.

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 work items, agreed.
> 
> 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  Tue Feb  1 16:54:01 2005
From: touch at ISI.EDU (Joe Touch)
Date: Tue Feb  1 16:55:36 2005
Subject: [rbridge] Updated charter
In-Reply-To: <[e-mail]>
References: <000901c50896$e2619610$6401a8c0@grayling>	<[e-mail]>	<[e-mail]>	<[e-mail]>
	<[e-mail]>
Message-ID: <[e-mail]>



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

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.

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

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  Tue Feb  1 17:50:49 2005
From: michsmit at cisco.com (Michael Smith)
Date: Tue Feb  1 17:54:20 2005
Subject: [rbridge] Updated charter
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>

 

> From: Erik Nordmark
> 
> 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).
> > 
> > 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.
> 
> 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).

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

> 
> 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.
> 
> 
> > Optimizing is one thing, but talking about specifics (involving 
> > 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.
> 
> > As to the last bullet, see RFC1812, which IMO provides 
> exactly the L3 
> > operations that interconnect disparate L2s.
> > 
> >> 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.
> > 
> > 
> > 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.
> 
> 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 work items, agreed.
> > 
> > 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
> _______________________________________________
> rbridge mailing list
> [e-mail]
> http://www.postel.org/mailman/listinfo/rbridge
From marcelo at it.uc3m.es  Wed Feb  2 05:33:58 2005
From: marcelo at it.uc3m.es (marcelo bagnulo braun)
Date: Wed Feb  2 05:34:50 2005
Subject: [rbridge] What should be the goal in terms of security?
Message-ID: <[e-mail]>

Hi all,

after all the discussion about ARP and flooding and so on, i guess that 
an important point should be to clearly define what is the goal of the 
rbridge solution in terms of security. I mean it seems to me that the 
security provided by a router and the security provided by a bridge are 
quite different. I mean, in arp, hijacking a link layer address seems 
to be an important vulnerability, since it may allow sniffing and 
spoofing any interface of the cloud. Besides, the potential DOS attakcs 
that may result because of broacasts used for discovery may be 
important. All this issues are not present in a routed network AFAICT.

So i guess that the first question is: an rbridge solution should 
provide the level of security of a bridged network or the level of 
security of a routed network?

If the goal is to replace routers by rbridges, i would say that the 
routed network security level is required....

any thoughts...?

marcelo