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

From: jaihyung at etri.re.kr (CHO, JAI HYUNG)
Date: Mon, 14 Mar 2005 19:00:46 +0900

I apologize for previous mal-formatted mail.
my company mail system has recently been updated and it seems
not working well with rbridge mailing system.
please ignore previous mail of same title.
 
Jaihyung Cho
 
======================================

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 already 
selective 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 what 
other 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 connectionless 
or connection-oriented, is sufficient to provide service to both type 
of applications, I think one light-weight solution is better than 
multi-function solution.
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? 
How will rbridge provide flexible and secure platform for commercial 
service 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 solution 
to 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 way 
people 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-establishment 
of 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 technology 
the rbridge must adopt, whether header is necessary, whether TTL 
needs to be introduced, etc.. 
I'm not asking to remove TTL. I just say to discuss if we really can't 
do without TTL. 

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: Mon, 14 Mar 2005 05:13:40 -0800

> please ignore previous mail of same title.

That is the point of standards. ;-)

> Is it improving bridges or creating your own link protocol? 

It is a protocol or shim header that is local to the rbridge, and yes, 
it is created for the rbridge.

> in effect, excluding other *non-encapsulation* technology from 

The need for the header is to be INCLUSIVE, not exclusive. Here's why:

- we want to support internal links that lack loop checks (notably Ethernet)
- we want to support routing protocols that may have transient routing 
loops, and not limit ourselves to just circuit-based solutions

As others have observed, there are other ways to avoid loops than TTLs, 
but TTLs are the common, simple solution. Adding TTLs requires a header 
(shim or otherwise) inside the rbridge.

Thus the need for common support a variety of solutions means the need 
for TTLs in a common rbridge (shim) header.

> of applications, I think one light-weight solution is better than 

One byte of TTL is very lightweight. And the Internet teaches us that 
multifunction solutions are fine. Optimizing for a single solution is 
where we have typically had more problem.

> masquerading of service class? 

Please begin by explaining how any of these are currently provided by 
arbitrary link layers.

If you want to advertize either ATM or MPLS, that's fine - but that's 
not what the rbridge is solving.

> to such market requirements, I think impact to industry will be marginal.

Industry ubiquitously uses bridges. It does not ubiquitously use ATM 
(does it even use it anymore?). And it does not use MPLS to the end 
user. It isn't clear this discussion is relevant to what this WG is 
trying to achieve.

> thus removes TTL at datagrams.

You have already made the point that IF circuits are used inside 
rbridges we might not need TTLs. But we definitely want to support other 
routing protocols (whether or not we support circuits), so TTLs are 
already needed.

> I'm not asking to remove TTL. I just say to discuss if we really can't 

I am presuming that the rbridge will not fix a single interior routing 
protocol, but might support a variety (not in a single instance, but in 
different campuses, e.g.).

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.

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/20050314/3faea366/signature.bin