[rbridge] RBridge: a case of study

[Silvano Gai]

I agree with Anoop answers

-- Silvano

> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com]
> Sent: Tuesday, October 30, 2007 6:54 PM
> To: James Carlson; Silvano Gai
> Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM
> Subject: RE: [rbridge] RBridge: a case of study
> 
> 
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org
> > [mailto:rbridge-bounces at postel.org] On Behalf Of James Carlson
> > Sent: Tuesday, October 30, 2007 2:37 PM
> > To: Silvano Gai
> > Cc: Developing a hybrid router/bridge.; Radia.Perlman at Sun.COM
> > Subject: Re: [rbridge] RBridge: a case of study
> >
> > Silvano Gai writes:
> > > Radia,
> > >
> > > I have added few slides to the example and I suggest that
> > we use it as
> > > a possible case of study for TRILL (of course, not the only one).
> > >
> > > Let's see if the solutions we have discussed work on this example.
> > >
> > > The complete case of study is at:
> > >
> > > http://www.ip6.com/acme-example-v1.ppt
> >
> > I have a few narrow questions that I think might help me
> > understand this picture a bit better.  (I probably have more
> > questions once I know the narrow answers.  ;-})
> 
> Let me take a shot at answering these.
> 
> >   1.  After the proposed fix, should VLAN 3 on Cloud L be bridged
> >       together with VLAN 3 on Cloud R, even though the backbone
itself
> >       doesn't directly carry VLAN 3?  (I.e., are TRILL packets with
> >       outer VLAN ID 7 or 8 and with inner VLAN 3 present on the
> >       backbone?)
> 
> Yes, that's pretty much what ends up happening.
> We have effectively extended the bridged LAN.
> 
> >   2.  What happened to the routing that once went on?  It was
> >       previously possible to route between these VLANs, but in the
new
> >       diagram, it's not.  Is routing between these networks
> >       unimportant, or does it take place elsewhere, or must RBridges
> >       both bridge and route in this scenario?
> 
> Routing can continue to happen wherever it was happening.
> The Rbridge by itself doesn't do routing, but there's no
> reason why one cannot build a device that does bridging,
> RBridging, and routing.
> 
> >   3.  Suppose we were to configure VLAN 7 within Cloud L.  Would you
> >       expect H1 to be able to access nodes within the backbone Cloud
G
> >       at that point?  (I'm trying to figure out whether the "X" and
> >       "Y" interfaces are of fundamentally different types or if the
> >       RBridges are just bridges.  I suspect they're different.)
> 
> This is where I think would help to introduce some
> additional terminology in the spec.  Just like MPLS
> LSRs have ingress, core, and egress functionality,
> I think we should have similar functions for RBridging.
> We could have access ports, trill ports and hybrid
> ports.  From access ports, we only accept non-trill
> encap'ed frames, from trill ports, we accept only
> trill-encap'ed frames, and finally, from hybrid ports
> we accept either.  Today we only allow hybrid ports
> and perhaps that's OK as a spec.
> 
> Anyway, back to the specifics of your question: If you
> did configure VLAN 7 within cloud L, then the RBridges
> labeled "Router 1" and "Router 2" would have 2 of their
> ports configured to be on VLAN 7 and would simply bridge
> between those ports.
> 
> Anoop