[rbridge] Summary of "critical bits" issues

Joe Touch touch at ISI.EDU
Thu Dec 13 10:37:38 PST 2007


IMO, here are the important elements:

1. option order
	if you care about short-circuit option processing,
	which is reasonable, then we should put HBH options
	before E2E ones, and required options (i.e., discard
	if not supported) before voluntary options (i.e.,
	pass if not supported)

2. option groups

	Hop-by-hop
		examined at all rbridges

	End-to-end
		examined ONLY at ingress and egress rbridges

	Discard
		if not supported, the device discards the segment

	Pass
		if not supported, the device passes the segment

	Silent
		if not supported, the device acts as indicated
		with no further action (e.g., discard or pass)

	Noisy
		if not supported, the device sends a signal segment
		indicating the failure upstream towards the offending
		segment source; this MAY occur periodically as an
		aggregate signal

	NB: that means THREE flags in every option

Some on this list argue that the common case will be devices that
support no options, thus it would be useful to also know the following:

3. summary flag in the main header

	ALL SILENT, ALL PASS

This would be a logical OR of all equivalent bits in the options.

The cost of doing this is that:

	1. space in the main header

	2. adding/removing any option MUST update the summary flag

	COST to add: easy; just OR the extra bits

	COST to delete: expensive; MUST scan other headers
	to determine whether the summary flag changes
	i.e., every option delete is O(entire option space) in cost

Whether this summary flag represents HBH only or includes E2E, or
whether there are two flags - one for each - is also up in the air.

-------------------------

A key point here is that the summary flag makes sense ONLY if there are
SILENT, PASS options. IMO, they're useless - if an rbridge can ignore an
option and be equivalently compliant, why would it ever implement that?

I.e., I would argue that any SILENT, PASS options are thus implicitly
optional, and should be omitted from consideration anyway.

As a result, it makes no sense to me to include the summary bit(s).

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20071213/8a232a90/signature.bin


More information about the rbridge mailing list