[rbridge] per-VLAN instances of IS-IS
Eric Gray (LO/EUS)
eric.gray at ericsson.com
Tue Jun 19 05:27:25 PDT 2007
I think we strongly disagree on what it means to incorporate
something in the control protocol. From there, it is likely that
we also disagree on how best to avoid doing so.
Figuring out how to correctly carry IGMP-snooped information
in TRILL protocol is effectively the same thing as incorporating
IGMP in the control protocol.
Making a list of everything that bridges snoop and ensuring
we can also include that information in IS-IS is exactly the sort
of thing we should be trying to avoid. The good news is that it
also should be easy to avoid.
Whatever protocols we might use, TRILL is essentially a layer
two forwarding technology. The messages that layer two forwarding
technologies want to snoop are visible to the devices involved in
forwarding. Unless devices actively interfere with "normal" layer
two forwarding, "external" control messages should be no different
than any other form of data - as far as RBridges are concerned -
and should be forwarded in the same way.
We know that we're expected to preserve forwarding symmetry
- at least for the layer two encapsulation of TRILL frames. In the
same way, and for similar reasons, we may need to preserve path
congruency. This is implicit in the decision to learn from data
in the unicast case.
What we don't know is the complete list of things that depend
on our doing that. But we can compose a partial list, and it seems
to me that "snooping" (in general) is one example, OA&M may well be
another and there are bound to be more.
As for the notion of "crippling the technology and making it
very uninteresting" - well, to many people, technology becomes very
interesting when it is very complicated to make it work. For the
users of any technology, it is only truly useful when it is not very
Paraphrasing something a colleague once told me: a technology
is only really useful when the interesting thing in using it is not
about the technology, but about its use. Put another way, you know
that transportation is useful when the interesting thing about using
it is arriving at the destination - rather than the trip itself.
Uninteresting is good. Very uninteresting is very good.
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com]
> Sent: Monday, June 18, 2007 7:08 PM
> To: Eric Gray (LO/EUS)
> Cc: rbridge at postel.org; Radia Perlman
> Subject: RE: [rbridge] per-VLAN instances of IS-IS
> Importance: High
> > -----Original Message-----
> > From: Eric Gray (LO/EUS) [mailto:eric.gray at ericsson.com]
> > Sent: Monday, June 18, 2007 11:43 AM
> > To: Anoop Ghanwani
> > Cc: rbridge at postel.org; Radia Perlman
> > Subject: RE: [rbridge] per-VLAN instances of IS-IS
> > Anoop,
> > I tend to view your response below as yet another
> > reason why RBridges MUST use a common path for unicast and
> > multicast (as well as broadcast and flooded) traffic. In
> > fact, it is a very good reason to limit use of "multipathing"
> > in general.
> If we do place those constraints then it would
> cripple the technology and make it very uninteresting
> (at least to me).
> > It is not clear exactly what you mean by your reference
> > to differences between control and data paths. Control
> > messages are from one RBridge to another and - presumably -
> > follow the same path as data addressed from RBridge to
> > RBridge. That path may be different from data transitting an
> > RBridge campus, but there is no RBridge "control" traffic
> > that transits a campus.
> > Are you suggesting that IGMP should be treated as a
> > control protocol within TRILL?
> In this case, when I said control I meant IGMP (since
> that is what is being used to effect pruning). If we
> snoop on the information at the edge of the trill
> cloud and pass this information around in IS-IS, then we don't
> need to worry about treating it as a separate control
> > Nor is it very clear why this observation is specific
> > to our discussion of multicast optimization. As a general
> > rule, if there is one reasonably well know application that
> > relies on path congruency for proper operation, there are
> > probably others.
> > Do you think we should provide a logical
> > control-function "bridging" service for all such applications
> > as a result of path divergences we introduce? Should we
> > conduct a research project to determine what other "control
> > protocols" we need to include in TRILL?
> We would need to make a list of everything that bridges
> snoop on and make sure we have ways of sending that
> around in IS-IS (if we care about those functions).
> I'm not aware of anything other than IGMP that trill
> would need to worry about, though.
More information about the rbridge