Subject: RE: Charter questions

From: "Weiss, Walter" <[email-masked]>
Date: Tue, 22 Jan 2002 15:35:49 -0500

I have a great deal of respect for Dave H. and therefore I have to take his
opinions seriously. Dave H. has suggested that folks with a COPS bias have a
habit of encroaching on other spaces. I believe he is half right. COPS was
clearly floundering after RSVP lost its momentum and during that period, I
believe there were those who had a solution looking for a problem (quite
reminiscent to DIAMETER's early days :-)  The advent of COPS-PR in my view
was an encroachment, but it was also a wakeup call to the larger NM
community. While I was not in favor of COPS-PR early on because it
represented yet another data model, I could see how it addressed some
deficiencies with existing NM alternatives. That said, all of this was
overshadowed by Randy's observation that NM solutions (including COPS) were
not aligned with consumer requirements.
 
On to AAA and a history lesson. There are a large number of people who tried
to bring AAA into the larger NM fold. There were those who suggested that
AAA could use other protocols to satisfy current needs. There were those
that indicated that a common data model was necessary to allow multiple
protocols to work cooperatively. Then there were those (I was particularly
involved in this one) that suggested that minimally, AAA should define
structured attributes so that DIAMETER could support attributes and objects
so that the protocol could reuse structures defined in data definition
languages like SMI and SPPI. In the end, the DIAMETER proponents rebuffed
all these suggestions.
 
At this point in time two interesting things happened. First, the AAA
Architecture folks, who were very interested in authorization issues
realized that COPS and COPS-PR were much more aligned to support
authorization than DIAMETER. Second, I had a discussion with Randy, Bernard,
and David Mitton, that ultimately lead to the creation of the Access Bind
PIB. In this discussion, I argued that a flat attribute space as defined by
DIAMETER could never be used to support service authorization because
defining something like QoS semantics required not only a large number of
attributes but also specific relationships between attributes. The simple
example that comes to mind is a classifier, which is in effect a field
expression consisting of ANDs, ORs, and wildcards. The consensus was that
DIAMETER is a simple RPC mechanism, where each attribute is a parameter. As
such, DIAMETER's applicability is limited to the number of procedures
(command/attribute list pairs) that one is willing to standardize. If we
were to take the QoS structures already defined and flatten them so that
they could be expressed in DIAMETER (and FORTRAN ;-), minimally this would
require the standardization of at least a square of the number of structures
defined to date (and that does not include all the security, tunneling, etc.
structures that would also be applicable). In this discussion I suggested
the following: Since DIAMETER was not capable of supporting complex
relationships between users and related QoS/Security/Tunneling behaviors, I
and others wanted to address this with another protocol. No one had a
problem with that.
 
Most of the authors of Access Bind are active in AAA as well. In fact the
majority of the authors and the primary drivers for the PIB also participate
in the AAA Architecture group. They certainly don't qualify as COPS bigots
and they are active in both the RAP and AAA WGs. I, for one, have spoken to
both Bernard and David Mitton about what we are doing with Access Bind and
encouraged them to come to RAP and AAAArch meetings to see what we are
doing. Given this, it would be hard to argue that the AAA folks are unaware
of our activities.
 
Also, let's be clear on what the requirements for the Access Bind PIB were:
1. Leverage existing QoS definition semantics to construct user specific QoS
policies.
2. Because of the dynamic nature of both users (particularly in a mobile
environment) and services, minimize the cost of setting up policies for a
new (authenticated) user. In this particular case, both the authentication
and the policy configuration can be set up in two messages (depending on the
authentication protocol).
3. Feedback/statistics on a per policy basis, rather than per session.
4. COPS was designed to outsource questions that the switch could not
address locally. The Access Bind PIB takes advantage of this strength by
defining a PIB that outsources a new user request and provides QoS policies
to the switch as a response. This work is not only useful because of the
problems it addresses but also because it harmonizes COPS and COPS-PR, which
were previously perceived as separate protocols.
 
One more point. When this work was chartered, it was clearly argued that the
justification of the work was to avoid using multiple protocols for one
specific problem: Managing per user services on the network edge. We don't
want to use one protocol for authentication, another protocol for policy,
another protocol for statistics, etc. This approach could only works if the
data models for all three protocols are normalized and even then each
protocol adds complexity in its own right. As I said, the industry has not
removed complexity by making core routing simple. It has moved the
complexity to the edge and there is no standard other than Access Bind and
no protocol other than COPS that addresses this movement of complexity.
 
regards,
 
-Walter

-----Original Message-----
From: Harrington, David [mailto:[email-masked]]
Sent: Sunday, January 20, 2002 12:20 PM
To: 'Wijnen, Bert (Bert)'; Durham, David; [email-masked]'
Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton'
Subject: RE: Charter questions

Hi, 

I was going to just sit on the sidelines on this issue, but one of buttons
has just been pushed. 

I am an SNMP bigot, and I strongly resent that COPS has repeatedly
encroached on the functionality that is the purpose of SNMP, while the IESG
repeatedly prevented the SNMP community from doing anything other than
security, which COPS wasn't required to address. I have felt that COPS has
been trying to sell itself as the solution for everything, and that the WG
has continually expanded into new areas that really required a stretch of
the charter. As part of their sales strategy they have repeatedly attacked
SNMP. Obviously, I am not a great lover of how many members of the RAP WG
have behaved.

However, I find it interesting to have the AAA WG raise issues about COPS
moving into areas that might overlap with the charter of other WGs. I find
it particularly galling to have it suggested that RAP has not worked to
integrate with other WGs, and implicitly indicating that AAA has been so
willing.

I used to attend and contribute to the AAA WG effort until it became
extremely clear that AAA had absolutely no interest (see the footnote) in
developing an architecture that could allow for the integration of AAA and
COPS and SNMP. Both the COPS community and the SNMP communities presented
possible alternatives for accounting, pointed out the importance of trying
to better integrate the data models of the various protocols, and requested
that the architecture allow for the use of other protocols to provide
certain types of functionality. The AAA WG decided to develop an
architecture that explicitly excluded the possibility of using any other
protocol to provide accounting capability, did little to integrate the data
models, and does not allow users to determine which protocol or protocols to
use to gather accounting information. AAA insisted on reinventing the wheel,
overlapping the work already being done by other WGs.

So while I agree that the RAP WG seems to continually push the limits of the
charter rather than concentrating on their core deliverables, I feel it is
unfair to ignore their efforts to integrate with the work of other WGs,
especially the AAA WG.

dbh 

footnote: The AAA WG actually was a bit more open-minded than this appears.
A significant minority believed that work should be done to integrate with
other protocols, or at least the scope of possible integration should be
studied further. However, they were boxed in by the actions of their area
director, Randy Bush, when he took over the control of a meeting from the
chairs, and forced a vote on a question that was phrased in a highly
prejudicial way, to adopt an approach that precluded such integration.

> -----Original Message----- 
> From: Wijnen, Bert (Bert) [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Sunday, January 20, 2002 6:56 AM 
> To: Durham, David; [email-masked]' 
> Cc: 'Randy Bush'; Bernard Aboba; 'David Mitton' 
> Subject: RE: Charter questions 
> 
> 
> I have added the two AAA WG chairs. 
> Bernard/David, do you want the type of discussion on the 
> AAA mailing list as I suggest below, or would you rather 
> direct some of the AAA paritipants to the RAP WG mailing 
> list? 
> 
> Dave Durham writes: 
> > Hi Bert, 
> > 
> > I took another look at the access-bind PIB and I disagree with your 
> > assertion. 
> > 
> Pls.. read my posting again. I did not make any assertion yet. 
> I reported what type of questions were/are coming my way. 
> and I do notice that we have an explicit statement in teh charter 
> that tells us to interact with AAA WG about these types of matters. 
> 
> So I was asking: 
> 
>  So what kind of action has the WG taken or WILL the WG take 
>  in order to make sure that we do not overlap or compete 
>  in this space? 
> 
> And so it seems that you do not agree with the allegations that 
> seem implicit in the questions that are getting to me. And so 
> it seems that there is a NEED to interact with the AAA WG to 
> see where both WGs stand and how they understand each others 
> work. 
> 
> So a way to start a discussion with the AAA WG chairs, or     
> on the AAA WG list and use the following text as a way to start 
> discussion as to the matter of overlap/conflict of work. 
> 
> > The whole point of that work is about binding all those 
> > diverse signaling protocols so they may work together AND 
> > the required device resources may be properly allocated in 
> > a coordinated fashion. That certainly seems a good thing to 
> > do and within the charter of a resource allocation protocol. 
> > 
> > I hardly see how a network can work without giving some 
> > semblance as to how these many diverse signaling mechanisms 
> > (RSVP, RSVP-TE, SIP, etc.) can work together given limited 
> > and already partially provisioned network resources. 
> > Their approach in the Access-Bind PIB seems to me to be an 
> > elegant way to deal with this complex problem. 
> > 
> > -Dave 
> > 
> Bert 
>

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 22 Jan 2002 12:53:21 -0800 (PST)

> In this discussion I suggested

Diameter now does have some functionality for provisioning of tunnels and
QoS behavior on a per-user basis. Has anyone in RAP reviewed the QoS AVP
functionality? 

> Given this, it would be hard to argue that the AAA folks are unaware
> of our activities.

We certainly did talk with you about the issues you describe, and you have
fairly characterized the discussion. Note however, that those discussions
did not cross over into discussions of alternatives for network access
authentication. 

> 1. Leverage existing QoS definition semantics to construct user specific QoS

Diameter currently has an AVP that does this. 

> authentication protocol).

Are we talking about handling network access authentication and
authorization, including EAP as part of this? 

> 3. Feedback/statistics on a per policy basis, rather than per session.

Diameter does not do this. 

>handling all the policies... for the network edge. 

Presumably this also includes authentication and authorization for network
access?