[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Call-home] Re: last call for a Call Home BoF

Wijnen, Bert (Bert) wrote:


Here is my AD-view on this:

First the NM aspects:
- The topic came up strong in the last ISMS f2f meeting in Paris.
- I (as AD, but also as an individual contributor) worry/worried that
 we might make something (like call-home) a MUST for ISMS while it
 was not a MUST in NETCONF. I think we should be conistsent in our
NM protocols and try to make sure that the same (security) infrastructure can be used for ISMS and NetConf (and others). 
- I also worry/worried about what impact it may have on SNMPv3 (hence
the discussion on authoritative (engine, information etc). I am happy to see that that is being well discussed on ISMS list 

Then the IETF-wide aspects
- I worry/worried that we might be doing a point-solution in the NM
 space, while it seems to me that the CH fiunctionality is an IETF
 wide issue.
- So I at least want to get a much better understanding of what the
 IETF-wide or Architectural aspects/possibilities are.
- Even if we decide to do a point-solution, then I still want to try
and make sure that we do so based on a well-informed set of discussions including those from other areas. So that is what the BOF (in my view) needs to address. 
The result is (as yet) unknown. It may turn out that there are
(reasonably) simple solutions at the IETF-wide level. If so, then we
(NM folk) may want to help define/specify a generic solution that
we can then also use in NM protocols.
If we need to go down the road of a point-solution, then I would hope that we at least take into consideration all the things we learn during 
the BOF.

Makes sense?


makes sense to me to do both.
Consider the high-level architectural issues for the generalized problem space, 
but don't deadlock over a long requirements definition phase.

Use the NETCONF/ISMS problem-space to create a specific/point solution
that meets the architectural needs, get it deployed, learn from the experience, 
and move on.

Andy


Bert


-----Original Message-----
From: call-home-bounces@ietf.org [mailto:call-home-bounces@ietf.org]On
Behalf Of Andy Bierman
Sent: Thursday, October 13, 2005 18:00
To: Eliot Lear
Cc: call-home@ietf.org; ops-nm@ops.ietf.org; isms@ietf.org
Subject: [Call-home] Re: last call for a Call Home BoF


Eliot Lear wrote:
After all of the mail last month, Bert is considering
allowing a BoF
on the topic of Call Home. I initially posted a note to
the call-home
mailing list announcing the possibility of a BoF. Response to that note was - well - underwhelming. If you are interested in
seeing one,
could you please reply to this email, CCing the call-home mailing list. Here is a draft agenda. It is subject to your input. 

If we do not see much input, I'm going to drop the request to Bert.

IMO there is a disconnect between the BoF charter text below and the
email discussions I (mostly) followed in the last month. I am in favor of sharply defined work that will achieve integration 
between NETCONF and ISMS through foresight and planning.  I'm
not so keen about the open-ended charter text below.

[IMO, this feature is simply defined as "the NETCONF peer
acting in the agent role initiates the session establishment".
There may be additional ISMS requirements, but I don't know.]

I suspected (back at the first NETCONF interim in Sunnyvale)
that our decision to provide this "reverse connect" feature
for BEEP only would come back to bite us -- then even more
when we picked SSH as the mandatory transport.   I think this
functionality is important enough to be available via the
mandatory transport.  (IMO the work can be done as an extension
to the 1.0 specification set.)

Beyond the firewall/NAT issues, I think there are some
important use cases for this feature, especially when
notification generator applications are introduced in NETCONF.
Issues such as mobility, scale, and auto-configuration may
make applications a lot easier to design if the agent
connects to the manager.



Eliot

Andy


Title: callhome
Period of time: 1 hour
Area: ops-nm
Expected # attendees: 40-60 (small room)
Don't conflict with: ISMS, ops-area, netconf (if there is one)


Short Description: Discussion of Architectural Issues Concerning
          protocols that could benefit from reversing
          of roles

Long Description:

Certain protocols, and in particular management protocols where
devices on either end of connection take client server roles may
be able to take advantage of "Call Home" functionality, when
traditional roles are reversed, and a server connect to a client.
Examples of existing protocols that make use of call home include
SMTP [ETRN] and COPS.  At this BoF we will look at extending such
functionality into other protocols, as well as any architectural
issues this raises.

This work stems from efforts in ISMS to extend SNMP to run over SSH,
as well as work as work that has gone on in NETCONF.
We will begin with a discussion of draft-lear-callhome-description-0[1,2].txt, which contains a description of call home, what problems it can solve, and
what some of
the architectural issues are. During the BoF we may identify additional such issues as well as protocols other than management protocols that could benefit from this work. An additional
potential
question should be whether a generic standard or process should be used to implement call home, such as rules for SSH.
There are three possible outcomes: a working group to add 
"call home"
functionality to existing protocols such as SNMP/SSH and 
NETCONF/SSH,

use of existing working groups for this purpose, or nothing.

Chair: Eliot Lear (or tbd)
Agenda:

Agenda bashing - 1 minute
Presentation of draft-lear-callhome-description-00.txt 19 minutes
Application to SNMP and open areas - 10 minutes
Discussion including architectural issues - 20 minutes
Moving Forward Options  - 10 minutes




_______________________________________________
Call-home mailing list
Call-home@ietf.org
https://www1.ietf.org/mailman/listinfo/call-home