[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: questions/comments on draft-black-radius-lanedge-00.txt
Hi Chuck,
Thanks for your responses. See my comments inline.
> > 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.
<Nagi> I believe it does make sense to consider the access devices such as
IP DSLAM since they do connect the IPoE users using 802.1x authentication. More
or less the attributes you mentioned are applicable to these devices as well.
I'll have to work out what more attributes are needed in these environments.
>
>
> > 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.
<Nagi? Do you think we need two different identifiers, NAS-Identifier and as
well as Location-ID in some cases.
>
>
> > 3) The draft proposes a new Time attribute (along with Location-ID
> > and Location Name). Why can't we use Event-TimeStamp define in RFC-2869
> > which is also in UTC format? Is there a specific reason to have a new
> attribute
> > defined here again?
> The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request
> packet attribute. Perhaps for standardization this attribute could be
> carried in either an Access-Request or an Accounting-Request packet?
<Nagi>I think it doesn't harm if we make this attribute applicable to any
packet. To be future safe, I propose to make the Event-TimeStamp attribute
applicable to any type of packet.
>
>
> > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
> > Tunnel-Type=VLAN (13), Tunnel-Medium-
> > Type=802, and Tunnel-Private-Group-ID=VLANID
> > as described in RFC 3580. I'm wondering how can a VSA which is by
> > definition an optional can replace the use of some thing that was
> standardized
> > before. I also feel that Tunnel Type usage doesn't look nice to carry
> VLAN-IDs.
> > But I suggest that we define a standard attribute to carry VLAN-ID which
> > can replace Tunnel Type usage.
>
> Since RFC-3580 is informational and regards suggested usage, it was hoped
> that a new attribute, categorized as a part of a set of "LAN Edge"
> attributes, would be a preferable solution. So the question is: should we
> overload an old attribute which was not intended to carry VLAN information
> in the first place (as in RFC-3580), or should we be redundant and define a
> new one (as in this document)? Perhaps the best option is along the lines
> of what was suggested by another reviewer here in this forum, wherein we
> create a better categorization of attributes, including common and
> domain-specific.
<Nagi> I agree with you. Though it is redundant, better define new attribute.
I disagree if you say the new one is VSA.
>
>
> > 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. :-)
<Nagi>I don't have any concerns if the message is clear to all. Paul, can we
use the terminology that we are familiar atleast inside the explanation :-)
>
>
> > 6) Section 2.3.6- How do we map the user-priority-generation-table?
> > How is a byte (rather than a bit) is useful to re-map the priorities.
>
> The idea is that we send down an entire table of prioritization mapping,
> which will tell the edge device how to map any of the incoming priorities.
> Thus if byte 0's value is 4, and byte 1's value is 2, and byte 2's value is
> 8, then incoming packets with priority 0 will be set to priority 4, incoming
> packets with priority 1 will be set to priority 2, and incoming packets with
> priority 2 will be set to priority 8, and so on. If all packets are to be
> forced to fixed priority, then all eight bytes of the table will have that
> same value.
>
> I hope that I understood your question and that this explains the intent of
> the table.
<Nagi> Yes, I got it.
>
>
> > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
> this?
> > Can't we use the Filter-ID defined in the standard. I agree that it
> doesn't
> > explicitly mean what filter it is.
>
> This is again the issue of whether to re-use an existing attribute, or
> define a new one within the domain ("LAN Edge") where it best belongs.
<Nagi> I see your point. My argument is that it is more work to the
implementors. Is it worth?
>
>
> > 8) I guess Bandwidth attributes "passes muster". I don't think the
> > standardization of these attributes cause any problem to the implementors
> > nor does it compell the radius client / proxy implementations to support
> > these attributes. In the "Table of attributes" section, we can specify if
> the
> > attribute may not be present at all.
>
> Agreed. Although your use of the phrase "passes muster" makes me wonder
> where that phrase came from. I guess it's time to visit the word-etymology
> web site...
>
>
Even I had to refer the idiom in dictionary.com but I thought that was the
common usage and borrowed it from David Nelson ;-)
David, what are your comments on both the phrase and the bandwidth attributes
:-)
Regards
Nagi.
>
>
> -----Original Message-----
> From: njonnala@sh.bel.alcatel.be [mailto:njonnala@sh.bel.alcatel.be] On
> Behalf Of nagi reddy jonnala
> Sent: Thursday, December 18, 2003 1:54 AM
> To: BLACK,CHUCK (HP-Roseville,ex1)
> Cc: radiusext@ops.ietf.org
> Subject: questions/comments on draft-black-radius-lanedge-00.txt
>
> I've read
> http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt
>
> and have some questions and comments:
>
> 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What
> exactly does a LAN Edge device mean?
>
> 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.
>
> 3) The draft proposes a new Time attribute (along with Location-ID and
> Location Name). Why can't we use Event-TimeStamp define in RFC-2869 which
> is also in UTC format? Is there a specific reason to have a new attribute
> defined here again?
>
> 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
> Tunnel-Type=VLAN (13), Tunnel-Medium-
> Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580.
> I'm wondering how can a VSA which is by definition an optional can replace
> the use of some thing that was standardized before. I also feel that Tunnel
> Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define
> a standard attribute to carry VLAN-ID which can replace Tunnel Type usage.
>
> 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?
>
> 6) Section 2.3.6- How do we map the user-priority-generation-table? How is a
> byte (rather than a bit) is useful to re-map the priorities.
>
> 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
> this? Can't we use the Filter-ID defined in the standard. I agree that it
> doesn't explicitly mean what filter it is.
>
> 8) I guess Bandwidth attributes "passes muster". I don't think the
> standardization of these attributes cause any problem to the implementors
> nor does it compell the radius client / proxy implementations to support
> these attributes. In the "Table of attributes" section, we can specify if
> the attribute may not be present at all.
>
> Comments welcome.
>
> Regards
> Nagi.
>
> --
> 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/>
--
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/>