[ofa-general] Re: [RFC] OpenSM and IPv6 Scalability Proposal
Jason Gunthorpe
jgunthorpe at obsidianresearch.com
Wed Jun 11 13:19:01 PDT 2008
On Sun, Jun 08, 2008 at 08:02:51AM -0700, Hal Rosenstock wrote:
> The only issues with the prefix length are the scope and PKey fields
> potentially making this non contiguous but I think the syntax can be
> extended for this if needed.
Well, I was trying to explain, that if you need this kind of function
then split the matching and tagging into two steps. Then it is no
problem and you can retain simple to use prefix matching:
> > Table 1:
> > MGID/PREFIX GROUP NAME
> > ff11:601b::/32 IPV6-SNM
> > ff1e:601b::/32 IPV6-SNM
> > ff1e:601b:89:/48 IPV6-SNM-PKEY_89
> > ff00::/8 OTHERS
> >
> > Table 2:
> > NAME MLIDS
> > IPV6-SNM 4
> > IPV6_SNM-PKEY_89 128
> > OTHERS 128
> In terms of IB routers, if an MLID was overloaded, wouldn't they
> filter on scope as well (link local scope would be filtered), right?
I expect an IB router to ignore the M-DLID entirely, it contains no
information that it needs.
> > > As PKey is part of the MGID, does this need to be addressed (and if
> > > so) how ?
> >
> > I don't think pkey needs special treatment - prefix matching takes care
> > of it. If you feel seperate allocations for each pkey may someday be
> > necessary then having a table scheme rather than a single value takes
> > care of it nicely.
>
> So you think it's "safe" to ignore the related IBA compliance ? It does
> look to me like that should be changed. I think that was also Roland's
> take a while ago.
Yes, I don't see the point of the compliance. Switch pkey filtering is
done at ingress or egress, and does not depend on the DLID. The only
way I could see this making sense is if the original author(s) had in
mind some kind of specific optimization for the switch design that
would preclude doing multicast replicating, then egress pkey checking.
At worst, I'd provide an option to treat pkey in the same manner as
MTU/SL and not worry about it unless a switch vendor comes forward to
say they need rule #10 to be followed.
Jason
More information about the general
mailing list