January 2012 - Nsi-wg - lists.ogf.org

Presentation on Topologies
by Jeroen van der Ham 18 Jan '12

18 Jan '12

Hello, Here's a short presentation that I will give on topology representation and transformations. Jeroen.

1 1

A slightly different take on topology
by Henrik Thostrup Jensen 18 Jan '12

18 Jan '12

Hi (sorry for being a bit close to the meeting with this mail) I am probably not the only one who would like to have an NSI meeting that didn't revolve around Jeroen and Jerry debating topology description, in a not very productive fashion. Guy did a good effort trying to control this last week, but it sure is hard keeping those two under wraps :-). So far I've tried to keep (mostly) out of it, but I'll try to give my views on the topology issue. The first thing we need to figure out is what we want to do. Are we trying to solve just the VLAN problem or coming up with a solution for multilayer path finding / creation and what scope of problems are we working with. Solving the VLAN problem is quite easy IMHO. Multilayer is significantly more tricky. I've read some of the papers Jeroen has linked to. In particular the "Path selection in multi-layer networks" illustrates what it is Jeroen is aiming for (I think). The paper is quite clever and displays a couple of nice tricks that can be done to solve some seemingly impossible tasks if one has (very) detailed information (I especially liked the graph conversions). However it is very much a research paper, and I do not believe the approach will work - for several reasons. First is complexity, the proposed pathfinding algorithms is rather complex, but it could probably be implemented. Second reason is that I do not see it feasible to collect so detailed topology information, let alone load/availability information. Third reason is that the approach completely ignores any policies that may be in place in a network. E.g., NORDUnet has a policy for how to do VLAN rewriting (always on ingress), and we have no plans of letting other organizations decide how it should be done. Furthermore NORDUnet and SUNET (Swedish Reseach Network, which is operated by NORDUnet) shares some resources, and wether or not one is allowed to use these resource is highly dependant on who you are. One of the really nice things about the current NSI model is that is promotes encapsulation. This allows us to define the network we want or need without regard to the underlying physical infrastructure. Going with this direction means will be cases where there is a potential path, but we do not have the means to create it for some reason or other (policy or technical). I am okay with this, as long as it doesn't become the norm. On the other hand Jerry haven't really managed to give a coherent view of what it is he wants. I do think that Jerry has some good ideas, mostly because he realises the need for abstraction and encapsulation in the system, providing a means to actually comprehend and understand what is going on in the system (and hence build and debug it). Some of the ideas with recursive domains and hiarchial STPs are quite good, but they haven't really been fully formed yet IMHO. What is clear, is that we will probably not find our final topology model at todays meeting, especially not for multilayer. However we are very much standing still and need to move forward. Could we, as a _temporary_ solution use Tomohiros STP enumeration in the reserve request in order to specify a set of potential STPs to connect with in the reservation request. This would solve our most pressing problem (VLANs) and give us some more time to work out the multilayer pathfinding/creation (which we will need). This would not require any protocol or topology changes, but an implementation change for parsing the STPs, and it is backwards compatible. Hopefully some progress will be made in Baton Rouge (I'm not betting on it though), but we simply need to get topology out of the NSI meetings as there are also other issues we need to focus on (security comes to mind). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> NORDUnet

2 1

Today's NSI conf call
by Guy Roberts 18 Jan '12

18 Jan '12

Hi all, The following is dial-in information for Wednesday's NSI call, time: 7:00 PDT 10:00 EDT, 15:00 GMT, 16:00 CET, 24:00 JST 1. Dial Toll-Free Number: 866-740-1260 (U.S. & Canada) 2. International participants dial: Toll Number: 303-248-0285 Or International Toll-Free Number: http://www.readytalk.com/intl 3. Enter 7-digit access code 8937606, followed by "#" Agenda: * Jeroen presentation on 'topology representation and transformations' * Review the open issues in code.google http://code.google.com/p/ogf-nsi-project/issues/list * Error codes Guy _____________________________________________________________________ ** Guy Roberts, PhD Network Engineering & Planning * * Tel: +44 (0)1223 371300 * * City House Direct: +44 (0)1223 371316 * 126-130 Hills Road Fax: +44 (0)1223 371371 * Cambridge * CB2 1PQ E-mail: guy.roberts(a)dante.net<mailto:guy.roberts@dante.org.uk> D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

Re: [Nsi-wg] Issue 52 in ogf-nsi-project: time-out time - how to set timeouts
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Status: Done Comment #4 on issue 52 by guy.robe...(a)gmail.com: time-out time - how to set timeouts http://code.google.com/p/ogf-nsi-project/issues/detail?id=52 Timeouts are now discussed in the best practices appendix of the NSI CS protocol document. This issue has now been closed.

1 0

Re: [Nsi-wg] Issue 51 in ogf-nsi-project: run NTP on NSA hosts
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Summary: run NTP on NSA hosts Labels: -FoundInVersion-1.0 FoundInVersion-1.sc Comment #1 on issue 51 by guy.robe...(a)gmail.com: run NTP on NSA hosts http://code.google.com/p/ogf-nsi-project/issues/detail?id=51 Assigned to Guy Roberts to update documentation to reflect this.

1 1

Issue 50 in ogf-nsi-project: Pathfinding functionality review
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Status: New Owner: guy.robe...(a)gmail.com Labels: Type-Review Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 50 by guy.robe...(a)gmail.com: Pathfinding functionality review http://code.google.com/p/ogf-nsi-project/issues/detail?id=50 Description of Issue: Pathfinding. Currently the 'network-internal' path-finding is delegated to the network - this is not currently exported - how should this be done? TK: Static vs. dynamic information - topology is more static, connections and vlans are more dynamic. To scale well these should be handled in different ways. JS: Jeroen: Also an issue with vlan blocking found at Netherlight... this also needs to be solved. 'Label' (vlan) swapping needed based on negotiation between neighbouring networks. Jerry: negotiation in tree mode happens at RA when it has decided which connections point is needed. Jeroen: This means that we need some vlan information in NSI request. Jeroen: one STP per vlan does not scale. Jeroen: we need to have a way in the topology to express which vlans are available and which are not. Discussion of Issue: Resolution of Issue:

3 9

Re: [Nsi-wg] Issue 34 in ogf-nsi-project: time zones - document usage
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Status: Started Labels: FixedWithUpdateR6 Comment #3 on issue 34 by jmacau...(a)gmail.com: time zones - document usage http://code.google.com/p/ogf-nsi-project/issues/detail?id=34 Changed times in the form xsd:DateTime to be a new simpleType called DateTimeType that restricts dates to have a timezone or Z. This was done in update r6. Guy will need to update the CS protocol documentation to reflect the restriction. ------------------------------------------------------------------------ r6 | jmacauley(a)gmail.com | 2011-10-14 17:03:57 -0400 (Fri, 14 Oct 2011) | 1 line Changed times in the form xsd:DateTime to be a new simpleType called DateTimeType that restricts dates to have a timezone or Z as requested in issue #34. closing issue #34. ------------------------------------------------------------------------

1 2

Re: [Nsi-wg] Issue 38 in ogf-nsi-project: push/pop attributes from SOAP layer - documenation
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Labels: -Type-Defect Type-Documentation Comment #6 on issue 38 by jmacau...(a)gmail.com: push/pop attributes from SOAP layer - documenation http://code.google.com/p/ogf-nsi-project/issues/detail?id=38 Changed this to a documentation update.

1 2

Re: [Nsi-wg] Issue 23 in ogf-nsi-project: "NsiExceptionType" change to "serviceException"
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Updates: Status: Fixed Labels: FixedWithUpdateR5 Comment #4 on issue 23 by jmacau...(a)gmail.com: "NsiExceptionType" change to "serviceException" http://code.google.com/p/ogf-nsi-project/issues/detail?id=23 Renamed NsiExceptionType to ServiceExceptionType as per issue #23. Closing issue #23. ------------------------------------------------------------------------ r5 | jmacauley(a)gmail.com | 2011-10-14 16:30:54 -0400 (Fri, 14 Oct 2011) | 1 line Renamed NsiExceptionType to ServiceExceptionType as per issue #23. Renamed messageId to errorId in ServiceExceptionType as per Issue 24. Renamed ServiceException element to ServiceException as per issue #27. Closing issues #23 and #27. Updating issue 24 ------------------------------------------------------------------------

1 2

Re: [Nsi-wg] Issue 2 in ogf-nsi-project: GenericAcknowledgmentType
by ogf-nsi-project＠googlecode.com 12 Jan '12

12 Jan '12

Comment #11 on issue 2 by imo...(a)gmail.com: GenericAcknowledgmentType http://code.google.com/p/ogf-nsi-project/issues/detail?id=2 This was re-discussed on the Wed. call, with the following results: 1. Message transport layer takes care of ack retransmission in case of a packet loss. 2. Confirm/Fail message responses should be sent out without waiting on the receipt of the message ack. [comment on error recovery: if message transport layer is broken, say unidirectionally, the ack sending will eventually timeout and generate a message transport error that the NSA will need to handle] 3. From the receiving state machine perspective, receiving a confirm/fail message from a particular NSA should cancel out the need to receive an ACK. So the state machine should not only continue to process the confirm/fail message, but not gate on or wait for the ACK message. Hope this resolves this issue

1 2