[rbridge] Shared VLAN learning: What is it and why should we care?

[Silvano Gai]

Caitlin,

inline

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> Sent: Friday, March 30, 2007 1:45 PM
> To: Silvano Gai; Russ White; Radia Perlman
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Shared VLAN learning: What is it and why should
we
> care?
> 
> 
> 
> > -----Original Message-----
> > From: Silvano Gai [mailto:sgai at nuovasystems.com]
> > Sent: Friday, March 30, 2007 1:26 PM
> > To: Caitlin Bestler; Russ White; Radia Perlman
> > Cc: rbridge at postel.org
> > Subject: RE: [rbridge] Shared VLAN learning: What is it and
> > why should we care?
> >
> > Caitlin,
> >
> > You say:
> >
> > >
> > > The most recent drafts effectively block that, by only
distributing
> > > endnode discovery information within a VLAN.
> >
> > Can we agree that:
> > - FID is a concept internal to the box;
> > - FID is never present in any frame;
> > - The VID to FID mapping is internal to each box and
> > potentially different on different boxes;
> > - The VID to FID mapping is never propagated in today networks.
> >
> > If we have agreed the previous, let's consider what triggers
learning:
> > - In bridges the reception of a data frame with a {VID, MAC
> > address} pair;
> > - In Rbridges the reception of a per VLAN instance ISIS PDU
> > that contains a {VID, MAC address} pair.
> > I don't see any difference.
> >
> 
> Following the lines of the example Radia posted, endnode IP J MAC X
> was previously on VLAN A where RBridge S learned of its existence.
> 
> Now endnode IP J/MAC X is migrated to VLAN B where RBRidge T learns
> of its existence. This is an extremely plausible scenario where VLANs
> A and B represent logical functions within a company. Or it could be
as
> simple as someone carrying a laptop from a "secure" area to another
> area within the same buildig.
> 
> Meanwhile, Router Z receives an incoming packet with destination IP J.
> Since that is not in its ARP tables, it sends an ARP request.

On which VLAN does the router Z send the request?
It must be either A or B. The way this is decided is a longest prefix
match on IP J that returns a directly connected sub-interface. The VLAN
associated to that sub-interface is the one on which the ARP is sent.
If it is A, S replies.
If it is B, T replies.

What am I missing?

Two more points:

1) An endnode cannot move from one VLAN to another keeping its IP
address (excluding the Private VLAN case that was not under discussion
when this thread about SVL started).

2) IMHO ARP proxy in Rbridges creates more corner cases of the problem
that it solves. In Dinesh presentation from 03 to 04 there was a slide
about making it optional and separating it to another draft.

-- Silvano


 Both
> RBridge S and RBridge T, acting as PRoxy ARPs, will answer.
> 
> What is Router Z supposed to do? If it just accepts both ARP responses
> and only keeps the last one, it could easily forward the packet to
> VLAN A and thereby cause the connection to ultimately drop.
> 
> The root cause of this problem is that RBridge T did not share its
> discovery of IP J/MAC X with RBridge S, even though they are part
> of the same FID.
> 
> This can be done with exposing VID/FID mappings on the wire. You
> export an "discovery-only VID" list instead. But I do not see how it
> can be done if discovery announcements are shared exclusively
> within VIDs without exception.
> 
>