[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: questions/comments on draft-black-radius-lanedge-00.txt
Nagi,
Based on discussions within and outside of IETF, I believe that both
LocationId and NAS-Identifier are useful. In the case of LocationId, the
contents of the field will be standardized, increasing the opportunities
for interoperability and the richness of the information conveyed. While
something similar could be done with NAS-Identifier, it would likely not
be interoperable.
Regards,
Ed
Ed Van Horne
Building Broadband Solutions Unit - San Diego
Cisco Systems
10935 Vista Sorrento Parkway
San Diego, CA 92130
858.526.1152
-----Original Message-----
From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
On Behalf Of nagi reddy jonnala
Sent: Thursday, December 18, 2003 10:16 AM
To: BLACK,CHUCK (HP-Roseville,ex1)
Cc: radiusext@ops.ietf.org
Subject: 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/>
--
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/>