RE: Review of draft-ietf-radext-vlan-02.txt

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

Yes you are missing the subtle fact that it is only possible to classify
a single port-based untagged VLAN in ingress.  There is only one PVID
per port to map incoming untagged frames to, but there may be several
untagged VLANs on egress.

Paul 

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Monday, April 03, 2006 9:09 AM
> To: Congdon, Paul T (ProCurve); Hannes.Tschofenig@gmx.net
> Cc: radiusext@ops.ietf.org
> Subject: RE: Review of draft-ietf-radext-vlan-02.txt
> 
> >I don't think you can or should define this type of 
> restriction.  It is 
> >completely valid behavior to allow multiple untagged VLANs 
> on egress in 
> >a standard 802.1Q bridge.  There are certain features (e.g. private
> >VLANs) that would like to have this type of configuration enabled.  
> >When 'ingress filters' are enabled, this is prohibited, so there are 
> >ways to avoid the concern you have without forcing the use 
> of Radius to 
> >be incompatible with the 802.1Q standard.
> 
> Here's what the Ingress-Filters attribute description says:
> 
>       The Ingress-Filters attribute corresponds to the Ingress Filter
>       per-port variable defined in [IEEE-802.1Q] clause 
> 8.4.5.  When the
>       attribute has the value "Enabled", the set of VLANs that are
>       allowed to ingress a port must match the set of VLANs that are
>       allowed to egress a port.
> 
> From this text, I'd assume that it would be legal to have 
> both Ingress-Filters "Enabled" and multiple untagged 
> Egress-VLANIDs/Names attributes.  Or am I missing something?  
> If there is a usage restriction here, I think we need to 
> describe what it is.
> 
> 
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>