Subject: [rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 19 Oct 2006 11:05:22 -0700

Joe,

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Thursday, October 19, 2006 8:58 AM
> To: Silvano Gai
> Cc: Erik Nordmark; rbridge at postel.org; Radia Perlman
> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
RE:
> New fields in shim header?)
> 
> 
> 
> Silvano Gai wrote:
> ...
> >> The reason I'm asking is because I see a big difference between
asking
> >> RBridges to provide some new degree of filtering/security, and
making
> >> sure it isn't any worse than a bridged network.
> >
> > Understood, but a new standard is also a good place to improve.
> 
> The need for capabilities not in 802 now may be a good argument for
> reserved bits
> 
> Note that in hardware they too are problematic; 

I am not advocating reserved bit, I agree with you that they are
problematic and difficult to use in the future.

we'd need three types:
> 
> 	- MUST set as 0 currently; MUST ignore on receipt
> 		for optional extensions
> 	- MUST set as 0 currently; MUST silently discard if not 0
> 		for silently dropped required extensions
> 	- MUST set as 0 currently; MUST report as error if not 0
> 		for non0-silent required extensions
> 
> I'd rather see the FTAG area blocked out for those kinds of bits at
this
> time than locked into a tag that a new VLAN header might replace, e.g.
> 

The FTAG has two values:

1) for unicast traffic today 802 networks support:
  a) per VLAN spanning tree
  b) a single common spanning tree
  c) shared spanning trees

TRILL is the current equivalent of (b), (a) is pragmatically impossible,
since you don't want to run an instance of ISIS per VLAN. If we want to
support the equivalent of (c), we need to have a tag in the packet.
Without a tag in the packet the implementations are full of corner
cases. 

2) for multicast, if you want to have shared trees, you need a tag in
the packet. In particular with two or three tiers networks the best
solution is to have few shared trees rooted in the backbone. TRILL
currently does not support this.

-- Silvano

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 19 Oct 2006 11:35:45 -0700

Silvano Gai wrote:
> since you don't want to run an instance of ISIS per VLAN. 

Actually, I thought that was the plan.

> If we want to

Not if we do (b), right?

> currently does not support this.

It'd be useful to explain this further; I'm not exactly sure what you
mean. We had talked before about separate VLANs for broadcast,
multicast, and unicast groups.

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/20061019/762af3ed/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 19 Oct 2006 12:09:10 -0700

FWIW, regarding reserved bits:

Joe Touch wrote:
...
>> problematic and difficult to use in the future.

They're problematic because we typically define them as Type I (see
below), but Type I is the least useful IMO compared to Type II and III.

The only issue is that type needs to be declared in advance, or
indicated in-band (the latter as IPv6 hop options do to some extent).

I'd rather give some bits each to Types I-III and another 8 to hopcount,
 and put both source/dest in the header than add FTAGs now, i.e.:

+--------+--------+
|11122233|hhhhhhhh|
+--------+--------+
|rbridge-source   |
+--------+--------+
|rbridge-destn    |
+--------+--------+

111 = Type I reserved bits
222 = Type II reserved bits
33  = Type III reserved bits
hhhhhhh = hopcount (7 bits)

That consumes 6 bytes.

The minimum header, IMO, ought to be 3 bytes:

+--------+--------+
|rbridge-destn    |
+--------+--------+
|hhhhhhhh|
+--------+

Frankly, I'd rather see a 3-byte shim.

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/20061019/c7a6a36b/signature.bin