- Nsi-wg - lists.ogf.org

Re: [Nsi-wg] ietf NETCONF group
by Jerry Sobieski 27 Jun '09

27 Jun '09

Hmmm... It does sound like there is a generic NETCONF and then vendor specific agents that use it for there specific configurations. It does seem more general purpose than I had expected. Can someone explain how it differs from RPC? We should consider if the current NETCONF message formats are adequate, or whether we need a better set of semantics to serve the emerging concepts of virtualization. The existing NETCONF formats seem to provide a transparent message format, but the protocol does not capture any notion of "state" of the element or "state" of the network as a whole as particular elements are being initialized or configured... My idea would be to define a protocol that sees the network and each component as having a set of "states" (e.g. idle, configure, active/in-service, monitor, terminating, etc...), a transition diagram between states, and a set of parameters that are generic network state information and another set that may be element specific. The point being that the overall network state may be managed thru this new protocol... Perhaps this network management protocol could be autonomous - i.e. each element could discover neighbors that speak the same protocol and either locate a Master, or discover/initialize/recover themselves from such information flooding thru the neighbor elements. IMO, a generic notion of a network topology is required, and then a state of each element, netwok agent(s) that can act autonomously to configure themselves (perhaps with the help of a neighbor...) etc. As it stands, it looks like the NETCONF protocol is really a just a means to carry messages between a master and a slave, without respect to what those messages are ultimately attempting to do... Maybe this is all we need now, but we should discuss how this "network configuration process" may need to evolve in emerging (and more generalized) virtualized networks... Thoughts? jerry Bartek Belter wrote: > Hi Guy, all, > > In one of the sub-projects of GN2-AMPS we were trying to address that issue. > We defined a very simple structure, Abstract Vendor Independent XML > (AVI-XML), which is an abstraction to provide generic specification for the > configuration service. Our AMPS Configuration Service was supposed to work > with an implementation of AVI-XML designed for Premium IP only. The > assumption behind this work was to make it as flexible as possible, to allow > future extensions to support other specific configurations (e.g. Firewall > AVI-XML, etc.). > > I am trying to find the latest version of this specification, but in general > the idea was to identify the common attributes/parameters usually put in the > request and define an abstract part, where the user can put all > service-oriented data. An example (not sure about the naming, most probably > original tags have slightly different names): > > <AVI-XML> > <global-information> > ... > </global-information> > > <request-information> > ... > </request-information> > > <device> > ... > </device> > > <service> > ... > </service> > </AVI-XML> > > The "service" tag is a placeholder for further extensions. > > AVI-XML forms an interface to our software. In further steps, the > configuration service translates the Premium IP request into the XML file, > which is applied finally to the Juniper routers. > > > In summary, I must say this wasn't an attempt to standardize an interface or > protocol for the communication with the network equipment. What we were > trying to achieve was to design and develop a piece of software which > potentially could be re-used in different projects/activities to configure > "any kind" of equipment for "any kind" of services. Pragmatic approach, but > maybe too idealistic, don't you think? :-) > > > Best regards, > Bartek > >

1 0

Re: [Nsi-wg] ietf NETCONF group
by Jerry Sobieski 26 Jun '09

26 Jun '09

Hi all- I'd like to make a couple comments about this...I am not by any means an expert, but I see some issues that I wonder if anyone has considered or knows about?... From what I know of the JUNOS implementation, the NETCONF API seems completely Juniper centric. And therefore JUNOS centric. I.e. it really is focused on configuring IP routers and Juniper routers at that... I think the issue of configuring devices using automated network agents will be more useful if it can cover devices other than just routers. Certainly ethernet switches fall into this catagory (perhaps JUNOS is implemented on some of these as well), but also other network devices including SONET/SDH or DWDM devices (ala GMPLS "LSR" architecture). I also believe a generic NETCONF architecture could be useful for configuring and monitoring other devices as well such as firewalls and end-systems or even non-network devices such as instuments or sensors... And it could be used to reconfigure larger service functions such as a DHCP elements or routing domains, or policy domains if it were designed to do so as part of the architectural background. So two questions: a) Does anyone know of any NETCONF type of package that portends to doing this type of of architectural domain autoconfiguration?, and b) Should this effort to develop an automated configuration process for IP devices consider how to define a *generic* device configuration protocol that could be used to cover a broader set of cyber-devices? Thanks Jerry Bartek Belter wrote: > Hi Guy, all, > > The GN2 AMPS (Advance Multi-domain Provisioning System, a federated resource reservation system for Premium IP) also uses this API to configure Juniper routers. And indeed, as Joan Antoni pointed out, this API is used to configure a single network device, not the whole network. > > If you have valid GN2 credentials you may take a look at the page: http://wiki.geant2.net/bin/view/SA3/AmpsConfigurationService > This gives a brief overview to the part of AMPS responsible for the configuration of network elements. I can try to dig a bit more, if some of you are interested to get more detailed description. > > > Best regards, > Bartek > >

5 5

topic specific call tomorrow
by John Vollbrecht 25 Jun '09

25 Jun '09

We will have a call tomorrow at 8 ET to talk about setting up multi- domain connections. Some of this will be based on slides - starting with slide 8. It will also include some pics from Guy if he is able to send them. Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0155180

6 7

Adaptation use cases
by John Vollbrecht 24 Jun '09

24 Jun '09

NML group -- Attached are a set of use cases for adaptation. We have talked about these briefly on NSI call and they seem reasonable. We have not yet tried to deal with how to describe adaptations or include them in topology or use them in pathfinding. I hope this is useful in discussions about NML schema. Let me know if there are questions. John

1 0

Notes from call 6-24
by John Vollbrecht 24 Jun '09

24 Jun '09

Some notes on call below. We will have a "optional" next week and a regular call in two weeks. At the end of the meeting, after a number of people had already had to leave, there was some discussion of what is planned for the next meeting at OGF in Oct. The feeling among those present was that it would be good to have a first pass at an architecture document. This will be a topic for discussion in two weeks, and also for initial discussion next week. Some questions are the form of the document, the selection of topics and their current state, and what areas to focus on over the next couple months. Tentative agendas -- next week - Radek's pathfinding charts- combining with Guy's messaging and John's Path-handling diagram - initial discussion of document for next OGF two weeks - discuss document and plans for how to create it - other discussion to be determined Notes from today 1. Radek described his diagrams showing how path computation could be done in different ways. There was a lot of very good discussion to clarify. The intent of the diagrams is to show how initial paths are created. These are then used to request resources. Some questions - why does a network need to know internal paths of other networks? I think the answer was that it doesn't "have" to know, but it is allowed for this to be shared. - is this path computation part of request of separate? I believe that the intent is that it is separate, although I am still a little confused by how this works in some diagrams. - how does the ability to get "next hop" and "detailed path" play with topology sharing and path computation. Lots of discussion. I think this still needs to be worked out. Radek proposed that he modify the diagrams based on discussion to make a distinction between finding local data plane paths and general control plane paths. There was a question about how global data plane paths are found that he will consider. Radek had to leave after this discussion. 2. We had a lot of discussion about how topology is shared, and what must be shared for something to work. - Some discussion about how one finds out if a location is available. We discussed that the edgepoints would be described as URIs and that the URI would include information about the network/domain to which the edgepoint belongs. In addition a lookup service has been proposed that will allow a dns-like name to be mapped to its URI. This name might be used in the request and then NSA would use the lookup service to convert it to URI. - talked more about distinction between dataplane paths and control plane paths. They do not need to map to each other, and when finding a global route one may find a set of NSAs that can provide an interconnected dataplane path. The NSAs would then figure out the details of the route. - talked briefly about the distinction between route and topology. We referenced Radek's abstracted topology as example of topology and route being a sequence of edge points and hints about how the edgepoints are interconnected. Guy will try to fill out this distinction as part of the messaging he is working on. 3. There was some discussion about topology sharing and what is required and what is optional. Seems to be agreed that one must share edgepoints it wants others to know about. edgepoints that connect other networks are needed in topology, edgepoints that connect to end- devices are needed for reachability. It is not required that a NSA share everything with everybody. 4. At the tail end of the call we talked about the use cases I sent out. One question was whether these were intended to be controlled by NSA. The answer was that they are meant to be input to NML group in discussing adaptations, and don't have to be controlled. They do raise some interesting questions (as Jerry points out in his email earlier) that we may discuss later. There was some agreement and no disagreement that I heard for sending these to NML group for their discussion. I will send these. --- Please correct or comment on these. I am not sure I caught all the discussion. John

1 0

Multi-domain message sequence
by Guy Roberts 24 Jun '09

24 Jun '09

I have prepared an analysis of message flows for multi-domain reservations -see attached presentation. I think this raises some interesting questions (see issues section) which I would like to discuss in tomorrow's call. Guy ------------------------------------------------------------------------------------------------------------------ Guy Roberts, Ph.D Network Engineering & Planning DANTE - www.dante.net<http://www.dante.net/> Tel: +44 (0)1223 371 316 City House, 126-130 Hills Road Cambridge, CB2 1PQ, UK ------------------------------------------------------------------------------------------------------------------

2 1

Re: [Nsi-wg] call tomorrow - 6/24
by Guy Roberts 24 Jun '09

24 Jun '09

Radek, Ok, we can start with your work - I would like to understand your pathfinding diagrams. The reservation, instantiation and cancellation UML diagrams that I created ignore the issue of pathfinding - I would like integrate this. I may be a little late on the call as I have a meeting beforehand which could over run. Guy -----Original Message----- From: Radek Krzywania [mailto:radek.krzywania@man.poznan.pl] Sent: 24 June 2009 10:13 To: 'John Vollbrecht'; 'NSI WG' Subject: Re: [Nsi-wg] call tomorrow - 6/24 Hi, I will have limited time today for the call. I will be available for about 1h, till 10 ET. Best regards Radek -- ____________________________________________ Radoslaw Krzywania radek.krzywania(a)man.poznan.pl +48 61 858 20 28 Network Research and Development Department Poznan Supercomputing and Networking Center ____________________________________________ > -----Original Message----- > From: nsi-wg-bounces(a)ogf.org [mailto:nsi-wg-bounces@ogf.org] On Behalf > Of John Vollbrecht > Sent: Tuesday, June 23, 2009 6:03 PM > To: NSI WG > Subject: [Nsi-wg] call tomorrow - 6/24 > > We will have a call tomorrow (Wed 6-24) at 9 ET. > Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 > (toll free US/Canada Only) > Enter access code: 0155180 > > We can discuss agenda at the beginning. Some suggestions > > A. documents sent out yesterday > 1) revised use cases tp send to NML group - I sent yesterday > 2) Pathfinding examples from Radek > 3) request sequence diagrams from Guy > > B. Plans for document for next OGF > > C. Other issues - Joan's ideas for expanding Tomohiro's diagrams > 1) describe how NSA's interoperate > - request sequences, trust relations, topology sharing, > monitoring > > other? > > John > > > > _______________________________________________ > nsi-wg mailing list > nsi-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/nsi-wg _______________________________________________ nsi-wg mailing list nsi-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg

1 0

revised use cases (to send to NML)
by John Vollbrecht 23 Jun '09

23 Jun '09

Attached is a doc with revised use cases - revised from the set I sent out two weeks ago. I would like to send these to NML group for consideration - so hopefully we can talk about these Wed morning - June 24. John

3 5

mixed path handling pic
by John Vollbrecht 23 Jun '09

23 Jun '09

Attached is a diagram showing how chain model fits with hierarchical model. I think this goes with Radek and Guy's diagrams, for discussion tomorrow. John

1 0

action items from call today
by John Vollbrecht 23 Jun '09

23 Jun '09

The following are action items we agreed on today 1) Radek will send a set of use cases for pathfinding in different modes - distributed, central, separate requestor, -- 2) Joan may add additional use cases 3) John will do pictures for the use cases 4) Guy will include use cases in his UML diagrams 4) Guy consult with Tomohiro and Sebastien and others about diagrams 5) Joan will attempt to describe a request messages that includes anycast to start and have specific edgepoints in end result Did I miss anything? John

2 1