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

From: jaihyung at etri.re.kr (조재형)
Date: Thu, 17 Mar 2005 17:09:34 +0900

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20050317/b5ccda75/attachment.html

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 17 Mar 2005 07:55:50 -0800

??? wrote:
>  
> 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.
>  >
>  >These are _proposed_ applications of RSVP over 802, as well as _draft_
>  >documents, so IMO bridges lack this service right now.
>  
> The RFCs are proposed standard for resource control over bridged network.
> RFC2816 has QoS mechanism on bridge, IEEE pbridge also has class of service,
> but rbridge doesn't have such concept of service differentiation.
> simple item to add when people compare related works on bridge QoS?.

RFC2816 is an informational document, not a proposed standard.

Further, by using L3-type routing protocols, it may be possible to
support QoS inside an rbridge system as easily ;-) as it can be
supported in the rest of the Internet. What would be needed would be a
way to translate L2 QoS signalling at the rbridge edge to L3 QoS
signalling inside, and that should be in scope for this WG, though
perhaps not an initial target.

>  >> 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.
>  >
>  >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.
> 
> have you ever talked with actual industry?
> how much over-provisioning do you think you can *guarantee* reliable
> commercial service via campus network.

You need to review the rbridge document. We use the term 'campus' to
describe a cluster of rbridges. The term has nothing to do with
university deployment.

And as to what industry is doing, where can I _buy_ QoS-based service? I
can buy provisioned service, but not on-the-fly bandwidth reservation.

> the correct answer is NOT AT ALL, because you have NO such mechanism.
> in future network, people will receive TV, voice and data service via
> single integrated network.

This is a future I have been promised since 1983, when it was promised
by ISDN. Then in 1988, it was promised by BISDN/ATM. Then in 1994 it was
promised by RSVP.

When I _see_ it, I will believe it. Until then, it will remain a promise.

> ISPs will charge by usage per service.
> it is obvious that network builders will choose equipment that has
> at least a QoS solution. you can't sell anything without QoS in future 
> market.
> over-provisioning is simply not an answer to market.

It has been so far, and it is where telecom markets evolve - towards
flat-rate, because it's easier to overprovision than to reserve,
enforce, account, and charge. But that debate has been going on for 20
years (or more), and we don't need to have that here.

Rbridges support QoS as easily (or not) as any L3 system.

>  >> 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.
>  >
>  >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.
> 
> do you think network builders will replace L3 switch to rbridge
> because in-campus mobility in rbridged network is better than
> any mobility solution implemented in L3 product?

Yes.

> you haven't proposed any mobility mechanism that can convince
> people rbridge mobility is superior to mobile IP.

Moving ports on a single L2 subnet doesn't require L3 'mobility',
because as far as L3 is concerned the device hasn't moved. Using a
mobility mechanism that requires _no_ L3 support is preferred to using
(not widely-supported) L3 mobility mechanisms.

This is why large L2 subnets are being used, esp. for groups of mobile
users (wireless within a city, or on a university or corporate campus).

> The last factor determining market is always money.
> If it is not cheaper, it can't replace something.
> but if it doesn't have a function, it may still replace if it is cheaper.

Agreed, but it is not clear that issue applies here. The additional
capabilities needed for an rbridge vs conventional learning bridge are
similar to the difference between learning bridges and hubs, where a
cost differential still exists, but is both small and insufficient
affect user's choice for the additional capability a learning bridge
provides. I think we hope the same for rbridges vs. learning bridges.

>  >> It will
>  >> give great profit to ISP if rbridge has a capability to provide QoS
>  >> 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.
> 
> you keep thinking rbridge can only be bridge, but I keep saying
> rbridge must be campus backbone machine.
> you keep saying rbridge doesn't need QoS because bridges don't have.
> however I keep saying rbridge need QoS because backbone routers
> have QoS.
> and I say that if rbridge can't replace backbone routers, no market at all.

And I disagree. I think rbridges replace sets of bridges, with better
capability as a result. When they replace routers, it is because routers
were required to interconnect sets of bridges, not because routers were
desired to support QoS.

>  >> The requirements in provider network
>  >> are a lot different than campus network. It needs to be defined in this
>  >> group prior to work.
>  >
>  >I don't agree that L2 systems run as a service need fundamentally
>  >different capabilites than L2 systems run by their user organization.
> 
> read any list of functional requirements written by private organization
> and commercial providers. they are a lot different.
> it is unfortunate I can't show you evidence because most of documents
> are confidential. I hope someone in this mailing list may show some
> example.
>
>  >>>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,
>  >
>  >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
>  
> because no-one in rbridge has talked about QoS.

QoS does not require circuits. If it does, then there would be no L3
support for QoS over non-circuit technologies - such as 802.

If we want to talk about QoS, let's do that. But I still don't see a
reason to talk about circuits.

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/20050317/3889a89a/signature-0001.bin