Subject: Re: [rbridge] Readiness of the VLAN Mapping Draft

From: Anil Rijhsinghani <[email-masked]>
Date: Fri, 2 Apr 2010 12:47:32 -0400

Radia,

We seem to have different approaches to solving the mapping
problem.

I believe the method in the draft needlessly requires a special device
called "cut-set Rbridge" (more than 1 if you want redundancy) and
suffers from topology restrictions, configuration requirements, and
additional fastpath processing. It also has a potentially serious multicast
flooding issue. But it's optional, so I'll live with it if I can't bring you
around to my view (and I've certainly tried:)

This by the way also makes me agree with the opinion expressed
earlier that it's best not to standardize VLAN mapping methods.

As an aside, both things you mention below are missing from the
very detailed "Frame Processing Behavior" section 4.6.2 of the protocol
draft and probably should be added: the exception to "Inner.VLAN is not
examined by a transit RBridge when it forwards a known unicast TRILL
data frame", as well as transit Rbridge filtering of multicast TRILL
frames based on inner VLAN (and multicast address?).

Regards,
Anil

---- Radia Perlman <[email-masked]> wrote: 
> On Fri, Apr 2, 2010 at 4:11 AM, Anil Rijhsinghani <[email-masked]> wrote:
> 
> > Two problems:
> > a) Transit Rbridges aren't supposed to look at the inner Vlan at all
> > (4.6.2.4)
> > b) Vlan-mapping is not needed in transit Rbridges in any case.
> >
> > Regards,
> > Anil
> >
> >
> 
> I'm very confused. Cut set RBridges *are* transit RBridges, and they
> are the ones that will need to do the VLAN mapping, on unicast as well
> as multidestination frames.
> 
> I agree that other than VLAN mapping, transit RBridges would not look
> at inner VLAN on *unicast*. However, they *would* look at inner VLAN
> on multidestination, in order to do filtering.
> 
> But cut set RBridges configured to do VLAN mapping would have to look
> at inner VLAN on both unicast and multidestination, and do the
> mapping.
> 
> Radia
> 
> 
> 
> On Fri, Apr 2, 2010 at 4:11 AM, Anil Rijhsinghani <[email-masked]> wrote:
> 
> > Two problems:
> > a) Transit Rbridges aren't supposed to look at the inner Vlan at all
> > (4.6.2.4)
> > b) Vlan-mapping is not needed in transit Rbridges in any case.
> >
> > Regards,
> > Anil
> >
> >
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/rbridge

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: JR Rivers <[email-masked]>
Date: Fri, 2 Apr 2010 11:30:13 -0700

I'll second your point.  In my experience, VLAN mapping is used at the "border" of VLAN name domains, and as such, it is not an TRILL problem, but rather a VLAN problem (it is currently deployed with 802.1 bridges).  This is an extremely complex issue with a very small use case.  Why not attack optimizations like ARP/ND and others and leave VLAN mapping until the appropriate protocol solutions become more apparent?

My $0.02,

JR

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 5 Apr 2010 15:57:16 -0400

Hi JR,

On Fri, Apr 2, 2010 at 2:30 PM, JR Rivers <[email-masked]>wrote:

>
> I'll second your point.  In my experience, VLAN mapping is used at the
> "border" of VLAN name domains, and as such, it is not an TRILL problem, but
> rather a VLAN problem (it is currently deployed with 802.1 bridges).  This
> is an extremely complex issue with a very small use case.

There seems to be some problem with using the term "VLAN mapping" or
"RBridge VLAN mapping" to name the feature described in
draft-ietf--trill-vlan-mapping. Maybe it needs to use some different term
such as "RBridge campus VLAN regions" or something. And there seems to be
disagreement on how important it is.

> Why not attack optimizations like ARP/ND and others and leave VLAN mapping
> until the appropriate protocol solutions become more apparent?
>

A brief history of this draft was that the basic approach was decided by the
TRILL WG in September 2008. At that time, it was thought that the TRILL base
protocol was almost done but that it was important to determine that the
effect in the draft-ietf--trill-vlan-mapping draft could be achieved within
a TRILL campus. Possibly, if it had been found impossible to achieve that
effect, it would have motivated some reconsideration of the base protocol.
      However, right about then the MTU problem was discovered so this draft
was put on the back burner. It was actually working group last called in
April 2009 and the potential problems with frames that cross campus region
boundaries more than once were found. These were discussed, particularly in
December 2009, with the conclusion at the time that people were not too
worried about them. In the mean time, lots of work was going on with the
base protocol fixing the MTU problem and working on getting through reviews
that were required by the TRILL Charter and IETF process.
      Although there hadn't been a formal consensus call, it hadn't seemed
necessary and the WG seemed to be in favor of the draft. I cannot recall any
complaint having been made about the use of the term "VLAN mapping". So I
thought the draft was ready for a final polishing and mostly just needed one
paragraph deleted, the one starting "Note that mappings are always
symmetric".
      When I brought this up, I didn't think there would be much controversy
or that the WG would have to do much work. Probably this draft should be
returned to the back burner pending further discussion.

Thanks,
Donald