Subject: [rbridge] text on hop-count in updated charter

From: jaihyung at etri.re.kr (CHO, JAI HYUNG)
Date: Tue, 15 Mar 2005 18:06:03 +0900

Dear Joe Touch,

>> With this regard, I would like to ask what are the service objectives 
>> of rbridge given to end-users? It seems rbridge lacks commercially 
>> meaningful benefits to end-users, such as QoS, authentication, 
>> metering & charging, etc. 
>> How will rbridge protect guaranteed flows from abusive user or 
>> masquerading of service class? 
> 
>Please begin by explaining how any of these are currently provided by 
>arbitrary link layers.
 
QoS service is the prime requisite in any of upcoming network. 
RFC2814, 2815, 2816 proposes a RSVP application over 802 networks 
(i.e. bridged local network) for resource control. 
Although not widely deployed, some company 
supports use of RSVP in local network. If you are interested, you may read
 
http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-lseframework-00.txt 
http://www.ietf.org/internet-drafts/draft-jaihyung-ccamp-arpsignal-00.txt

What rbridge lacks is the QoS service. If rbridge is aiming the place of 
next-generation bridge to replace legacy bridges, rbridge must 
include such industry requirement whether this group likes it or not. 
Otherwise, IEEE pbridge or other alternatives will be favored by market.
Contrast to original scope of work on campus network, I think rbridge 
is more meaningful to metro-Ethernet. There's clear need for L2 solution. 
rbridge may help ISPs reducing CAPEX if it is cheaper than L3 switches. 
rbridge may also help to reduce OPEX if management is simple. It will 
give great profit to ISP if rbridge has a capability to provide QoS 
service and charge per usage. The requirements in provider network 
are a lot different than campus network. It needs to be defined in this 
group prior to work.

>Further, I haven't seen anyone else mention circuits here. Circuits are 
>not used for switching packets to the endsystem (maybe that was their 
>intent, but they're used more in the core for provisioning). Rbridges 
>work more at the endsystem, where bridges work. As such, I doubt 
>circuits will be either appropriate or useful anyway.
 
I believe by now, you will notice what *virtual circuit* technology 
I am trying to say. The circuit I referred is a dynamic (on-demand) 
frame transmission path established across bridged network 
using an interactive signaling between two communicating party. 
In bridged networks, I believe ARP/ND will be best candidates to 
use for this purpose. It only differs in the way of using ARP 
compared to current rbridge design, however, it is a lot 
versatile because it can be used for QoS, authentication, 
fast-rerouting, load-sharing and traffic engineering, etc.

Dr. Jaihyung Cho
ETRI, Korea
phone :       042) 860-5514
oversea: +82-42-860-5514
fax:         +82-42-861-5550

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 15 Mar 2005 06:01:53 -0800

CHO, JAI HYUNG wrote:
> What rbridge lacks is the QoS service.

These are _proposed_ applications of RSVP over 802, as well as _draft_ 
documents, so IMO bridges lack this service right now.

> If rbridge is aiming the place of 

I don't see a screaming industry requirement for this at the 802 level, 
where overprovisioning is the norm. Note that rbridges would have much 
higher internal bandwidth, because they can use multiple internal paths 
rather than just a single spanning tree, so amplify the overprovisioning 
that is already in use.

> rbridge may also help to reduce OPEX if management is simple.

The primary reason to use an rbridge vs. an L3 device is to avoid 
renumbering while moving. If that isn't a goal, IMO, an L3 device is 
more useful because routing tables can be more easily partitioned and 
broadcasts avoided.

> It will 
> service and charge per usage.

Because they're currently providing that service and they want it to 
scale? What I see is ISPs not offering QoS - but not because bridges 
don't support it.

> The requirements in provider network 

I don't agree that L2 systems run as a service need fundamentally 
different capabilites than L2 systems run by their user organization.

> In bridged networks,

Yes - that was what ATM was supposed to be, and ATM is basically (IMO) 
dead. I don't believe it makes sense to consider MPLS for on-demand E2E 
circuits, but rather for aggregate provisioning.

Again, I haven't seen anyone else mention the use of circuits in an 
rbridge system. Even _if_ there were interest, at best an rbridge system 
would need to support circuits AND conventional L3 routing in its interior.

Joe

> I believe ARP/ND will be best candidates to 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
-------------- 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/20050315/309b45cb/signature.bin