[rbridge] RBridge: a case of study

[Eric Gray]

Donald,

	Speaking of meta-data, I find it very difficult to 
figure out who you're responding to when you use the @@@ 
and ### notation.

	It looks as if you're responding (with ###) to James 
Carlson's response to your earlier mail (with @@@), which
was itsef a reply to James' response to me.  Have I got it
figured out right?

	In any case, I have to disagree with your assertion 
that "coloring" does not make sense on a P2P link.  While
your assertion that a wire is not going to queue frames,
or make decisions based on priority, the next hop RBridge
is going to do so.

	One of the obvious examples of where either the PCP
or the VID might be useful additional information can be 
seen by analogy with what a service provider might need to
do in transporting customer frames.  An SP may have a way
to map the customer's frames to compatible PCP and VID -
used to provide some form of assured service, for example
- that is compatible with but not the same as the PCP and
VID used by the customer.  In this case, the customer's
frame PCP and VID are not useful when forwarding frames
across the SP backbone, but the customer's PCP and VID
MUST be preserved.

	I know that - thus far - we've not opened the door 
in our charter to talk about the application of RBridge
technology to anything other than enterprise networks.
Yet the analogy still applies even in the enterprise.

	Even if you feel that this technology will not be
applied to even such an enterprise, I can see little 
value in specifying "extra stuff" just to make the work
we're doing unusable for such applications.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Tuesday, November 06, 2007 4:59 PM
> To: James Carlson
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] RBridge: a case of study
> 
> See below at ### 
> 
> -----Original Message-----
> From: James Carlson [mailto:james.d.carlson at sun.com] 
> Sent: Monday, November 05, 2007 10:16 AM
> To: Eastlake III Donald-LDE008
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] RBridge: a case of study
> 
> Eastlake III Donald-LDE008 writes:
> > From: James Carlson [mailto:james.d.carlson at sun.com] 
> [...]
> > Eric Gray writes:
> [...]
> > > 2) all frames forwarded from a (physical) port on one RBridge 
> > >    to a (physical) port on another RBridge MUST have the same
> > >    VID, or 
> [...]
> > @@@ Well, I am Donald and I meant something like (2) but a bit
> narrower.
> > I would have said "all TRILL frames" because "all frames" is way too
> > inclusive. What about control frames like 802.1AB? 
> Furthermore, in the
> > case of point-to-point links between two Rbridges (i.e., no 
> bridges or
> > end station connections in between), as far as I can see there is no
> > particular utility in considering the TRILL frames to have any
> external
> > VLAN coloring and certainly no need for them to be outer 
> tagged with a
> > VLAN ID or priority.
> 
> I mostly agree with that.  In fact, I think that's a desirable end
> state for TRILL, when all other bridges are obsolete.  Having no VLAN
> tag on the outside makes a lot of sense there.
> 
> (I think omitting the priority makes a bit less sense to me, though.
> Wouldn't you want the priority value set on an 802.1q header with VLAN
> ID 0 in this case?)
> 
> ### The way I look at it, the VLAN coloring and priority of a 
> frame are
> meta data associated with the frame. The priority is used in queuing
> decisions related to processing and transmitting the frame. Just what
> Q-tag gets put on the transmitted frame depends on configuration.
> 
> ### If a link is point-to-point between Rbridges, there is no need for
> an outer VLAN ID. If it is a data frame, the actual VLAN ID 
> of the data
> is in the inner Q-tag and so easily available to the next Rbridge for
> its decision processes. Similarly, I don't see any reason for priority
> in the outer Q-tag. It's not as if a piece of wire is going to look at
> the priority and re-order frames. If it is a data frame, the actual
> priority of the data is in the inner Q-tag and so is easily 
> available to
> the next Rbridge.
> 
> ### TRILL core IS-IS frames, of course, are different. They don't have
> any inner Q-tag because the don't have any inherent VLAN coloring and
> they only go one hop anyway. An Rbridge might want to associate
> "priority 7" or whatever as meta data with the core IS-IS 
> frame while it
> is internal to the Rbridge and that could effect transmission queuing
> but there is no particular reason for there to be a priority tag on it
> over a point-to-point link. The next Rbridge will see that it 
> is a core
> IS-IS message, will probably treat it a bit differently for 
> processing,
> and give it to its core IS-IS instance.
> 
> ### Thanks,
> ### Donald
> 
> I think the question is how to get there when there are networks that
> are half-TRILL and half-otherwise.
> 
> ...
> 
> -- 
> James Carlson, Solaris Networking              
> <james.d.carlson at sun.com>
> Sun Microsystems / 35 Network Drive        71.232W   Vox +1 
> 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 
> 781 442 1677
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>