RE: questions/comments on draft-black-radius-lanedge-00.txt

["CONGDON,PAUL (HP-Roseville,ex1)" <paul.congdon@hp.com>]

I have a few comments and clarifications below...

> Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt
> 
> 
> Hi Nagi,
> 
> Thanks for the comments.  Here are my replies:
>  
> > 1) Do access devices (such as IP DSLAMs) come under
> > LAN Edge switches? What exactly does a LAN Edge device mean?
> 
> The intent of the document is to attempt to define the 
> delivery of 'edge'-type attributes -- VLANs, ACLs, QoS, 
> bandwidth -- for delivery via RADIUS reply to the RADIUS 
> client (NAS or switch).  Your suggestion of considering these 
> attributes for a broadband environment such as IP DSLAM is 
> interesting and, assuming those DSLAM devices support some or 
> all of those attributes, they may as well be a good fit.
>

The primary focus has been on IEEE 802 devices like Ethernet switches and
802.11 Access Points.  Thus the term 'LAN'.  We are searching for
'standardized' management controls in 802 devices that we can configure with
these attributes.  Unfortunately, many of the things we want to configure
don't have standard controls.  That said, I see no reason why other 'edge'
devices couldn't take advantage of these attributes.  The first choice,
however, is to configure 'standardized' 802 management controls.  I'm not
sure if IP DSLAMs overload these controls or not.  I'm guessing they have
their own.
 
> > 2) When do we use the Location-ID and Location-Name attributes.
> > I guess they are used in wireless networks.  Can't NAS-ID be used 
> > to identify the Location? Can you explain little further.
> 
> This document was really following the lead of the wireless 
> specification WISPr, which proposes the wireless attributes 
> for Location-ID and Location-Name.  It is possible that there 
> should be standard RADIUS attributes for these.  The 
> NAS-Identifier attribute of standard RADIUS does not define a 
> specification of the format of the string; the Location-ID 
> does specify a format 
> (isocc=<ISO_Country_Code>,cc=<E.164_Country_Code>, ...).  
> 
> I guess I'll leave it at that.  Either Location-ID or 
> NAS-Identifier is fine, as long as the format is specified so 
> that we can all agree on and use the same string.
>

We certainly want to stick with the X.500 stuff for location specification.
I think NAS-Id typically contains a domain name and doesn't have specific
location information unless the string is formatted for this.  Location-ID
seems like the best idea to get specific location data.
 
> 
> > 5) I'm trying to undertand the difference between PVID and 
> Egress-VID.
> > You mean, PVID is the default-VLAN-ID and Egree-VIDs are 
> allowed list 
> > of VLAN-IDs. Right?
> 
> You are absolutely correct.  I favored using that 
> terminology, but my friend and colleague Paul Congdon, a 
> confirmed IEEE 802 guy, favored the more technically-precise 
> but obtuse terminology you see there.  :-)
>

Actually, this isn't entirely correct.  The PVID is the default VLAN for
untagged traffic received at the port.  The Egress list contains the VLANs
that can be transmitted out of the port (in either tagged or untagged
format).  Familiarity with IEEE 802.1Q helps a lot here.  If 'Ingress
Filters' are enabled, then the egress list kind of also becomes the list of
'allowed' VLANs to be received as well.  So, to confuse everyone here, VLANs
are sort of asymmetric unless Ingress Filters are turned on.  With untagged
traffic (which is what is typically at the 'edge' anyway), it is possible to
have many VLANs egress a port, but all received untagged traffic is mapped
to a single VLAN denoted by the PVID.  Since the traffic is untagged, the
different VLANs egressing the port aren't really apparent to the end
stations on that link.  This is really just a tricky way for switches to do
some forms of filtering.  With tagged traffic, the VLANs are explicitly
labeled, so everyone knows what VLAN the frame belongs to.  When 'ingress
filters' are enabled, the tagged frames received must be members of the
VLANs that are listed on the egress list.
 
Paul

--
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/>