Re: OPSAREA strategy

Hi All,

I have a few questions which rack me a long time 
already. Since I have experience with and connections 
to different SDOs like 3GPP and TM Forum my main 
concern is interoperability and enabling the industry-
wide usage of IETF MIBs and YANG modules.

Here are some questions I find interesting to 
consider:

- Do we want to stay in our isolated management 
world or should we make our models available also
for SDOs, which use other modeling languages?
How does an inter-SDO model inter-operability 
looks like?

- What about getting our future modeling language 
(and models) aligned or easily mappable to other 
existing modeling languages (models)?

- Do we need to align our modeling language features 
with languages from other SDOs for easy mapping of 
the models or transforming from one format to the 
other?
- How about inheriting a class from an existing model
instead of defining every resource object ourselves
in a YANG modul?

- Which strategy should be followed if TM Forum wants 
or just starts incorporating the content of IETF 
MIBs or YANG modules into SID?
- Should this be developed in a joint team with TM Forum 
or are we against such an adoption of MIB or YAM 
contents into the TMF information model?
- If we allow this who does maintain such a information 
model in the future, TMF or IETF?

- Obviously TMF SID has an industry momentum currently
since it is "trying" to cover all network types and enables 
information exchange between them.
AFAIK operators want to have an e2e management view and 
exchange of management information even between a 3G mobile 
network and an ethernet network.

- So my main concern is that our management framework is 
not well prepared for management interoperability between 
networks.
- The feedback I get from people in other SDOs is that 
they don't understand ASN.1 and avoid reading it. They 
rather prefer using UML-based models and tools.

- I believe future YANG modules of IETF should be made 
available for the wide industry usage also for those,
who are working UML-based and translate everything into 
their own language first.

Cheers,
Mehmet
 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of ext 
> Romascanu, Dan (Dan)
> Sent: Thursday, December 03, 2009 7:05 PM
> To: Andy Bierman; David Harrington
> Cc: OPS Area (E-mail)
> Subject: Re: [OPS-AREA] OPSAREA strategy
> 
> 
>  
> 
> > -----Original Message-----
> > From: [email protected] 
> > [mailto:[email protected]] On Behalf Of Andy Bierman
> > Sent: Thursday, December 03, 2009 7:52 PM
> > To: David Harrington
> > Cc: 'OPS Area (E-mail)'
> > Subject: Re: [OPS-AREA] OPSAREA strategy
> > 
> > David Harrington wrote:
> > > Agreed.
> > > 
> > > Some operators told us there was a disconnect.
> > > So we deliberately sought feedback from a wide range of 
> > operators and 
> > > found agreement there was a disconnect.
> > > And we are moving to a multi-protocol approach because 
> > operators told 
> > > us there was a disconnect.
> > > We also got some suggestions about how to proceed to 
> close the gap 
> > > between operators' needs and IETF NM solutions.
> > > But the operators haven't come home yet ...
> > > 
> > > The IETF is now faced with a problem. We now have multiple 
> > protocols, 
> > > and most defined their own information models, data 
> > modeling language 
> > > and data models, and we are not sure how to correlate information 
> > > available from different protocols. And while some in the 
> > IETF think 
> > > that is an important problem to resolve, and 
> standardization is the 
> > > obvious answer, real world operators have been using multiple 
> > > protocols successfully without vendor-neutral standards for 
> > > cross-protocol correlation.
> > > 
> > > Prior to the 2002 workshop, the OPS area led an effort to 
> meet with 
> > > operators at operator forums, such as NANOG.
> > > I recommend the OPS area drive an effort to get operator feedback 
> > > again.
> > > Let's get some feedback on IETF NM work since 2002, get 
> suggestions 
> > > from operator experience on whether and how to standardize 
> > information 
> > > across multiple NM protocols, be sure we understand 
> > operators' needs 
> > > in today's networks, and get some suggestions for 
> > operators' emerging 
> > > needs that the IETF could better address over the next 
> five to ten 
> > > years.
> > > 
> > > Let's be sure we don't move down the disconnect road again.
> > > 
> > 
> > I agree another workshop would be useful, but I think many 
> > issues are being addressed by NETCONF and YANG.
> > I prefer to just get more work done that we know needs to be done.
> > 
> > The NETMOD WG has been working with the IPFIX WG and their 
> > development of the ipfix-psamp.yang data model has been very 
> > helpful in determining requirements for 'real-world' 
> > domain-specific models.  It will be interesting to compare 
> > configuration of IPFIX via CLI vs. SNMP vs. NETCONF/YANG and 
> > evaluate the strengths and weaknesses of each one.
> > 
> > My original comment (as Balazs understood) is that we do not 
> > have any YANG infrastructure in place so domain-specific WGs 
> > like IPFIX have a reasonable chance of success using 
> > NETCONF/YANG.  Hopefully, this work will begin as soon as 
> > YANG is approved:
> >     * system group
> >     * interfaces group
> >     * entity group
> >     * access control model
> > 
> > It took many years to agree to each one of these bullets for 
> > SNMP.  I am not patient enough to spend the next 20 years 
> > reinventing what SNMP already standardized over the last 25 
> > years.  Others are looking forward to starting from scratch.  
> > That is why I think rough consensus on a 5 year 
> > multi-protocol development plan would help.
> > 
> 
> Let us be a little bit more specific here. 
> 
> How would such a 5 year plan look like? What would it include? What is
> the framework and the community it needs to get consensus from? 
> 
> Dan
> _______________________________________________
> OPS-AREA mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ops-area
>