Subject: [Diffserv] RE: why i should like pibs

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 21 Mar 2002 22:13:01 +0100

All,

Let me post to these lists a similar statement as I made in the 
RAP WG meeting at this 53rd IETF, so that everyone has the same
info. Here we go. I would prefer to have andy reactions (if any)
posted to just one mailing list (the RAP wg mailing list).

When the WG completed WG Last Call and reached consensus on
the FRAMEWORK PIB, the WG chairs asked me (the primary AD
for the WG) to consider this document for Proposed Standard.
Normally I then review and ask for IETF wide Last Call and
if no valid objections are received, then I put the document
on the IESG agenda for approval.

My current evaluation however for this document at this time 
is as follows:
- If we look at the NM related activities, then we can see
  that for SNMP/MIBs, the majority of work/time/effort is
  spent in the MIB development. It also touches on virtually
  all WGs. Same will be true for COPS-PR/PIBs if we start to
  put PIBs on the standareds track. 
  This could be a VERY BIG thing. In SNMP, the real investment
  is in MIBs. This is true for MIB design (IETF), for vendor
  implementation effort, and for user deployment. If IETF 
  working groups start to develop PIBs they would be faced 
  with significant extra, and in many cases, redundant effort
- We have accepted COPS and COPS-PR 2-3 years ago as PS.
  That was the start of a duplicate approach, which only 
  provides marginal improvement in some areas, and possibly
  a negative effect in some other areas.
- We have also accepted SPPI as a duplicate approach, again
  with only marginal improvement. It allows to define PIBs,
  most of which I think can also be done with MIBs or
  better/different MIB design. 
- Note that PIBs are basically intended for configuring
  network devices and services.
- Two years back, the ADs and Diffserv WG chairs agreed to do
  a MIB and a PIB for standards track. And we agreed with the 
  RAP WG to develop a set of base PIBs for standards track.
- Meanwhile, we have seen:
  - Some key players withdrew from COPS and PIBs approach
    They claim there is no market, and with reduced budgets
    there is no place to just do multiple solutions to same
    address space.
  - In most cases, PIB development is done by different people
    than MIB development, if we're lucky they talk to each other.
  - WGs in general have very little interest in MIBs or in PIBs,
    let alone both.
  - Operators (ISPs) tell us they do not see much use for binary
    interfaces (be it SNMP/MIBs or COPS-PR/PIBs or other) to 
    configure their network devices/services. The reality is that
    they use (and expect to have to continue to use) ASCII based
    CLI-type interfaces (Maybe ASCII should read human readable)
  - We have started an effort to try and consolidate SMI and SPPI
    We may want to await the results before we invest in the
    standardization of PIBs.
  - The NM community in the IETF (lots of SNMP folk, but COPS,
    Policy WG and Operators are participating too) are trying to 
    come up with some vision/framework to address Operator (ISP)
    concerns. Discussions is only in beginning stages and not any 
    IETF sanctioned status yet.
  - IAB is planning a NM Architecture Workshop this summer (as
    announced at the IAB plenary on Wednesday March 20th)
- We (the IETF/IESG) are to decide on the first IETF produced PIBs.
  If we approve them as standards track, then:
  - I suspect we will find a lot of duplicate work, i.e. MIBs and
    PIBs, to be designed, tested, handled-for-stds-track approval
  - Vendors and users may be faced with the big duplicate investment.
    They can opt to not do so, but of course the more PIBs we approve
    as stds track, the more the pressure will be put on them.
  - We are telling the market that we cannot decide and let them do it.
    Maybe this is OK. But not in my mind, I do not think we do the
    IETF community or the world a favor by approving this duplicate
    approach

As a result, I cannot propose to the ISG to approve the FRMAEWORK-PIB
(or any PIBs for that matter) on the standards track at this point 
in time. I strongly recommend to publish them as Informational for
now. We can revisit this after we get some better architectural 
guidelines/help from the current actitivities that are taking
place in informal gatherings and the upcoming IAB NM Workshop.

I understand that this is sort of "breaking the contract" with 
the RAP WG on my part. But the situation has changed quite a bit
from 2 years ago when we started down this path (agreed on the WG
charter).

Bert 

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Mar 2002 00:15:09 +0100

"Wijnen, Bert (Bert)" wrote:
...
> In most cases, PIB development is done by different people

er, of the three authors of the diffserv MIB, two are also authors of
the diffserv PIB, one of them being the active document editor. The PIB
has been updated less frequently than the MIB, but it has been
tracking it.

>   - WGs in general have very little interest in MIBs or in PIBs,

But as you observed, diffserv was firmly requested by its ADs to develop
a MIB and a PIB in parallel, and we did so, and it was a lot of
work. 

  Brian

---

From: "Abdul Malick" <[email-masked]>
Date: Tue, 26 Mar 2002 13:22:00 +0530

Hello all,

I have a clarrification regarding the use of RSVP for DiffServ:

The rfcs 2996 and 2998 talk about the usage of RSVP in mapping IntServ over
DiffServ networks. One of the approaches is based on the BRs of the DiffServ
domain being able to understand RSVP messages and add DCLASS object(eggress
BR) in the RESV message (after mapping the InServ service to DiffServ
PHB(s)).

My doubt is, can't we use this approach for a pure DiffServ network where we
could add an object similar to the DCLASS object in the PATH message that
would allow us to signal reservations for a particular PSC or a set of PSCs.

May be this could be done as a result of the negotiation of a Pipe SLA.

Each DS domain can apply their local remarking if the DSCP values used in
the neighboring domains are known before hand. This could improve the
predictability and also avoid over provisioning and other problems that we
face with static provisioning.

Please pardon me if this has been already discussed or sounds too silly for
wasting any time on.

Expecting some reply,

Warm Regards,
Malick.

***************************************************************************
This message is proprietary to Future Software Limited (FSL) 
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information 
and should not be circulated or used for any purpose other than for 
what it is intended. 

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message. 
FSL accepts no responsibility for loss or damage arising from 
the use of the information transmitted by this email including
damage from virus.
***************************************************************************