[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> 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.
> 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?
> 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.
> 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. :-)
> 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.
> 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.
> 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...
Thanks again for the comments,
/chuck
-----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/>