Opinion for review: 2006/357 Crossbow - Network Virtualization and Resource Partitioning

[Garrett D'Amore]

James Carlson wrote:
> Kais Belgaied writes:
>   
>> 4.3 EOF of the VLAN PPA Hack
>> 	Although the committee members and reviewers agreed on the benefit of
>> 	obsoleting the VLAN PPA hack, they debated the proper timing of the
>> 	removal of the hack from OpenSolaris.
>> 	A member noted the possible disruption to users of this visible
>> 	feature, even though the release binding is minor. He suggested
>> 	considering a phased approach, with an announcement of the EOF as part
>> 	of this project, followed by another fast-track to finish the actual
>> 	removal of the feature. The project team, while open to the idea of a
>> 	two-step approach, argued that the co-existence of the old hack with
>> 	the new architecture was problematic. The project re-designed the
>> 	VLANs to be created as VNICS, which are MAC level datalinks, so that
>> 	obeservability features and resource controls can be applied to them.
>> 	Keeping the old hack will perpetuate the ambiguous behavior when
>> 	plumbing a non existing interface, result in a duplication of code in
>> 	the MAC and DLS layers. The answer was satisfactory to the committee.
>>     
>
> I wasn't available for the review, and this is obviously a late time
> to bring this up, but the answers above sound insufficient to me.
>
> Removal of support for the VLAN PPA hack in the kernel itself sounds
> feasible, but I don't agree that this should be taken as license to be
> deliberately incompatible on upgrade.  Doing so will break machines
> like jurassic.sfbay and many of our internal boot servers unless the
> administrators of those systems take deliberate -- and, per the
> opinion, apparently undocumented -- action prior to upgrade.
>
> Alternative plans that would allow removal of the kernel components
> and still preserve compatibility include at least these two
> approaches:
>
>   a) Running a one-time conversion that checks for /etc/hostname.* and
>      /etc/hostname6.* names that specify a VLAN, and automatically
>      running the necessary dladm command to create the VLAN first.
>      The scripting work in the net-physical script to accomplish this
>      is trivial, and looks something like:
>
>         while [ $# -gt 0 ]; do
> 		case $1 in
> 		*[0-9][0-9][0-9][0-9])
> 			base=`expr $1 : '\(.*[^0-9]\)'`
> 			ppa=`expr $1 : '.*\([0-9][0-9][0-9]\)$' + 0`
> 			vid=`expr $1 : '.*[^0-9]\([0-9]*\)[0-9][0-9][0-9]$'`
> 			dladm show-link $1 >/dev/null 2>&1 || \
> 				dladm create-vlan -l $base$ppa -v $vid $1
> 		esac
>                 /sbin/ifconfig $1 plumb
>
>      (There are other places this could be done, and it's unclear to
>      me how this interacts with exclusive IP stack zones.)
>
>   b) Modify ifconfig itself to recognize the VLAN naming pattern and,
>      if the device named doesn't exist, use libdladm to create it
>      first.
>
> These are cheap, easy to specify, implement, and test, and would avoid
> breaking most running systems using VLANs today.  It would leave out
> only ad-hoc snooping on unplumbed VLANs and non-IP protocols run over
> VLANs.
>
> Is there any reason to avoid at least that level of compatibility?
>
>   
ISTR that we had agreed the team would use an upgrade path akin to 
option a, during review.   I know that this topic was discussed for more 
than just a minute or two during the meeting.

    -- Garrett