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

From: jaihyung at etri.re.kr (CHO, JAI HYUNG)
Date: Mon, 14 Mar 2005 17:10:04 +0900

Dear Joe Touch I just get back to work after long-flying.Please read following in-line. >> I believe you are confining applicable routing technology just in>> link-status protocols.>>No; I am assuming that TRILL will not _force_ a single specific interior>routing protocol, but would still like to have a common encapsulation                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^>header.> By saying a "common encapsulating header", you are alreadyselective to certain technology.  I am wondering what are the actual goals of R-bridge.Is it improving bridges or creating your own link protocol? It seems your effort is more focused on justifying new header rather than seeking a solution. Unless you open discussion, you wouldn't know whatother solutions there will be. However, if anything referring the "encapsulation header" part is fixed in charter, I think it is in effect, excluding other *non-encapsulation* technology from consideration.  >> | ATM-MPLS is a circuit-oriented technology (on both counts). The current>> | charter doesn't want to assume only circuits inside an rbridge campus,>>>> which part of charter specifically exclude circuit technology inside the>> rbridge?>>"does not want to assume only circuits" does not exclude their use; it>excludes their EXCLUSIVE use. I.e., it assumes we may want to support>others, which is already true (IS-IS, as you mention).> Partly agreed..It is good to consider several dissimilar technologies together.However, I do not think rbridge should have a *generic*architecture that can do everything. If one solution, ether connectionlessor connection-oriented, is sufficient to provide service to both typeof applications, I think one light-weight solution is better thanmulti-function solution. With this regard, I would like to ask what are the service objectivesof 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 us
er ormasquerading of service class?How will rbridge provide flexible and secure platform for commercialservice flows. Traffic attributes of some applications are really dynamic.How will rbridge know such variation of user request? I think these are important requirements of NGN. Rbridge is surely an attractive, however, if rbridge does not give any solutionto such market requirements, I think impact to industry will be marginal. Note that some technology is good for flexibility but hard to guarantee anything, however, others are rigid but good for commercial service. For example, think about the way rbridge forward frames in connectionless mode or connection-oriented way... If commercial factors are equally considered, I think the waypeople think about rbridge can be a lot different. >> If some *virtual circuit* technology can be considered, there are>> several loop prevention/detection techique we can discuss.>>See above; I don't think this is relevant to whether TTLs need to be>supported. Why not? If frame forwarding in rbridge is based on pre-establishmentof virtual circuit, rather than pre-establishment of routing database,looping can be thoroughly examined at circuit establishment time, thus removes TTL at datagrams. Again, it must be an open question what forwarding technologythe rbridge must adopt, whether header is necessary, whether TTLneeds to be introduced, etc..I'm not claiming to remove TTL. I just say to discuss if we really can'tdo without TTL.

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