- Nsi-wg - lists.ogf.org

Re: [Nsi-wg] NSI naming
by John Vollbrecht 13 May '09

13 May '09

This is good discussion. It would be good to have some goals for the two groups so that we can have standards that are in sync. I try to list a few inline below -- On May 11, 2009, at 2:30 PM, Martin Swany wrote: > Hi John, > > For, reference, we have updated the terminology > spreadsheet here: > > http://forge.gridforum.org/sf/go/doc15512?nav=1 > > I left out the cases that were OK. > >> This is a link at a level. This seems a fine name. For NSI the >> question is if the link can carry links at a different level. I >> think so - I think there is a relation which says a link at one >> layer can support multiple links at a different layer. Examples >> would be multiple VLANS over ethernet or multiple VCGs over SONET, >> or multiple waves over a fiber. > > This is definitely part of the model. As noted in later notes the concept of layer and level are close. I think for NSI we need a definition of what links over other links are called. Does the over refer to level or layer? What exactly is a level or layer. Some discussion of this has gone on informally that I know of, but noting written down. This may be the major concept to hopefully be define between us at Chapel Hill. > > >> <pastedGraphic.pdf> logical port (per layer) - G.805 calls this a >> connection point, NML and NMwg call it a port. In NSI we started >> discussion calling it a Port but switched to edge point to avoid >> the physical connotations of port. The groups should agree on this >> name or include an alias for different names if we can't agree. > > I think that the NML has agreed to call this a port. Our > naming was changed a while ago (due to ITU naming!) > in perfSONAR and I believe the NDL group has agreed. > Certainly any term carries connotations, but the pervasive > opinion is that they are more similar than they are different > and it is useful (for pathfinding) to use the same underlying > term, but specialize it for different purposes. I personally have no concern about what it is called as long as everyone agrees. However it is a group decision, so both groups need to agree. In my opinion since the G.805 doc calls it a point - I personally like having point rather than port in the name. This is a discussion also for Chapel Hill, but lower priority than the above. > > >> <pastedGraphic.pdf> concatenated series of links - Path in NML and >> NMwg, concatenated series of links in G.805. It seems to me that >> this should be a link not a path. I am not sure when some thing is >> a path rather than a link. I also think a concated series of links >> is a link (maybe it needs a name to become a link?) > > In my mind, there is often a one-to-one relationship > between paths and links and the only question as to > which you use is whether you need to see the internals > or not. I think this addresses and issue below as well. This is confusing to me. What internals does a path see or not see vs a link? Is a path resourceless? > > >> <pastedGraphic.pdf> Network Layer (topology on a single layer) - >> This seems an important concept - topology on a layer. A couple >> parts of this that I think may need definition: 1) how to tie >> together administrative domains with topology - for example one >> administrative domain may know about a subset of what another >> administrative domain knows; and 2) How do layers interact - is one >> layer carried by or used by another? >> >> <pastedGraphic.pdf> aggregated device -- called topology in NML. >> this might be a network in NSI, but I am not sure that fits well. > > I don't know that there's agreement that an aggregated > device is a topology, but it sounds like this isn't an issue I don't think this is an issue unless someone wants to use it instead of topology > > >> <pastedGraphic.pdf> domain - this seems like a network in NSI >> terms. Certainly it has a lot of the same characteristics. But >> it does not have all the characteristics - see discussion on "what >> is missing" below > > The easiest answer is that we can add characteristics and > plan to do just that as the base elements are "subclassed" > into specific uses. > > But I do understand that there is a little gray-ness between > Networks and Domains. My own take is basically this: > Networks are addressing scoped, and Domains are > administratively scoped. I take that largely from > Internet terminology and I know there are counter- > examples. So, the more complicated answer is that > there are a number of different kinds of groups and > we need to see which ones fit. > I think this is the other very high priority thing to agree on at Chapel Hill. NSI has the concept of a network which can be controlled by an NS agent. This network has a topology which to the outside world looks like a set of edgepoints (or ports). I am not sure what corresponds to in NML. Also, NSI has the concept of a link which has resource which may be an independent administrative domain from networks to which it connects. I am not sure how these all fit the definitions. >> What seems missing -- >> >> 1) The description of adapatation in general: for example in a >> concatenated series of links, each concatenated link may be carried >> on a different sort of higer layer link. A VLAN might be carried >> on an Ethernet link (as a VLAN), on a SONET link as GFP encoded >> VLAN. In this case the underlying link with its coding is carried >> over different higher layer links with their coding. > > I believe that this is a good example of where the Link/ > Path dichotomy helps. If we need to know that details of > of the different sorts of constituents, we need to access > the path object, otherwise it's just a link. Also note that > I don't really think we have any fixed notion of "higher" > and "lower" layers now. I know that we did in perfSONAR > but there were so many special cases of relationships > (L2TP, q in q, ip in ip) that we pretty much gave up. So, > I don't think there are any problems with representing > what you're talking about above, so maybe we should > try to look at specific examples? > I think we should look at examples. One such example is the one described briefly above. It might be interesting to include perfSONAR examples. > >> 2) The concept of connection oriented network: A NSI network is >> something that can create segments (aka links a lower layer) >> between edge points (aka ports). A network participates with other >> networks in a topology where the elements are networks that >> connected with links. In graph theory network would be node, and >> link an edge. > > I think that a Link represents a network connection > pretty well. Maybe the Path/Link discussion is > convincing, but I should say that's more of the perfSONAR/DCN > perspective and not that of NDL (necessarily -- I think > it's close, but I won't speak for them.) I am not sure what the Path/Link discussion is --- > > >> 3) Names for the elements within a layer that are concatenated. >> NSI calls these segments for now. The NSI topology elements are >> links and networks. Each of these elements can provide segments >> and the segments can be concatenated to create a ete segment. I >> believe that segments and links at a level are identical concepts, >> so perhaps we can come up with an alias for how to describe NSI >> segments and ete concatenated segments. > > Again, hopefully, the Path/Link concept describes this > for the complicated case. (And a simple relation works > when 4K VLAN links are carried over the same Link....) I think examples and then a specific agreement on naming - perhaps aliasing - is needed > > >> I suggest that we might want to have a call to start discussions on >> this before OGF and to try to resolve issues at OGF. There is a >> NSI call every Wed at 9ET - we could have a joint call on Wed May >> 20 if that seems reasonable. > > I can't make this slot (or would have to join late at the > very least.) > > best, > martin John Vollbrecht Senior Network Engineer, Internet2 office 734 352 4960 cell 734 395 7890

1 0

Fwd: NSI naming - spread sheet discussion
by John Vollbrecht 13 May '09

13 May '09

A rather long sequence of messages - so lists can see the discussion. John Begin forwarded message: > From: Martin Swany <swany(a)cis.udel.edu> > Date: May 12, 2009 9:24:46 AM GMT-04:00 > To: Jeroen van der Ham <vdham(a)science.uva.nl> > Cc: John Vollbrecht <jrv(a)internet2.edu>, Freek Dijkstra <fdijkstr(a)science.uva.nl > >, Aaron Brown <aaron(a)internet2.edu>, Jeff Boote > <boote(a)internet2.edu>, Andrew Lake <alake(a)internet2.edu>, Paola > Grosso <grosso(a)science.uva.nl>, Cees de Laat <delaat(a)uva.nl>, > Richard Hughes-Jones <richard.hughes-jones(a)dante.org.uk>, Guy > Roberts <guy.roberts(a)dante.org.uk> > Subject: Re: NSI naming > > Hi Jeroen, > > I'm (re-?) adding Jason to the cc list as he's right in the middle of > this discussion as well. > > I would add that I think that we are all very close on the way in > which things are related, which gives rise to layers/levels of > the network. I think that the "Relation" element that we're using > in UNIS (perfSONAR/DCN) land really makes the expressions > there start to look like the RDF 3-tuples in a way. While that > problem > is hard, I think that we've been inching closer to having a common > solution framework. > > best, > martin > > On May 12, 2009, at 4:13 AM, Jeroen van der Ham wrote: > >> Hi, >> >> I think Martin's analysis of your description is correct. >> I only want to add that you seem to be contradicting yourself >> regarding layering, and I think it is very important that we clear >> that up. >> >> Before I begin, I want to clear something up: >> Networks transport data by encapsulating it in different layers. I >> think we can all agree on that analysis, and we all know what >> layers are in general. Therefore I don't want to complicate this >> (already complex) discussion by introducing yet another term (i.e. >> "level"). >> >> Then on to your analysis: in the beginning you say that NSI wants >> to describe links at a certain layer going over links at a lower >> layer. Then later on you say that NSI operates at a single layer >> for a particular request. >> >> Current networks operate at multiple layers (Ethernet, SONET, >> Lambda, etc.). Therefore, if the NSI wants to be able to provision >> services across these networks, then it will have to handle >> multiple layers. >> >> Please realise that the NML is currently describing a layer-less >> model. Layers are not part of the model and we are only describing >> the general things that are part of every layer. So NML is >> currently not able to describe that links at one layer run over a >> link at a lower layer. >> >> As Martin said, describing layers, and the adaptations between them >> is a very very hard problem. One that the NML group will be taking >> on soon though. >> >> >> Jeroen. > --- For, reference, we have updated the terminology spreadsheet here: http://forge.gridforum.org/sf/go/doc15512?nav=1 I left out the cases that were OK. > This is a link at a level. This seems a fine name. For NSI the > question is if the link can carry links at a different level. I > think so - I think there is a relation which says a link at one > layer can support multiple links at a different layer. Examples > would be multiple VLANS over ethernet or multiple VCGs over SONET, > or multiple waves over a fiber. This is definitely part of the model. > <pastedGraphic.pdf> logical port (per layer) - G.805 calls this a > connection point, NML and NMwg call it a port. In NSI we started > discussion calling it a Port but switched to edge point to avoid the > physical connotations of port. The groups should agree on this name > or include an alias for different names if we can't agree. I think that the NML has agreed to call this a port. Our naming was changed a while ago (due to ITU naming!) in perfSONAR and I believe the NDL group has agreed. Certainly any term carries connotations, but the pervasive opinion is that they are more similar than they are different and it is useful (for pathfinding) to use the same underlying term, but specialize it for different purposes. > <pastedGraphic.pdf> concatenated series of links - Path in NML and > NMwg, concatenated series of links in G.805. It seems to me that > this should be a link not a path. I am not sure when some thing is > a path rather than a link. I also think a concated series of links > is a link (maybe it needs a name to become a link?) In my mind, there is often a one-to-one relationship between paths and links and the only question as to which you use is whether you need to see the internals or not. I think this addresses and issue below as well. > <pastedGraphic.pdf> Network Layer (topology on a single layer) - > This seems an important concept - topology on a layer. A couple > parts of this that I think may need definition: 1) how to tie > together administrative domains with topology - for example one > administrative domain may know about a subset of what another > administrative domain knows; and 2) How do layers interact - is one > layer carried by or used by another? > > <pastedGraphic.pdf> aggregated device -- called topology in NML. > this might be a network in NSI, but I am not sure that fits well. I don't know that there's agreement that an aggregated device is a topology, but it sounds like this isn't an issue > <pastedGraphic.pdf> domain - this seems like a network in NSI > terms. Certainly it has a lot of the same characteristics. But it > does not have all the characteristics - see discussion on "what is > missing" below The easiest answer is that we can add characteristics and plan to do just that as the base elements are "subclassed" into specific uses. But I do understand that there is a little gray-ness between Networks and Domains. My own take is basically this: Networks are addressing scoped, and Domains are administratively scoped. I take that largely from Internet terminology and I know there are counter- examples. So, the more complicated answer is that there are a number of different kinds of groups and we need to see which ones fit. > What seems missing -- > > 1) The description of adapatation in general: for example in a > concatenated series of links, each concatenated link may be carried > on a different sort of higer layer link. A VLAN might be carried on > an Ethernet link (as a VLAN), on a SONET link as GFP encoded VLAN. > In this case the underlying link with its coding is carried over > different higher layer links with their coding. I believe that this is a good example of where the Link/ Path dichotomy helps. If we need to know that details of of the different sorts of constituents, we need to access the path object, otherwise it's just a link. Also note that I don't really think we have any fixed notion of "higher" and "lower" layers now. I know that we did in perfSONAR but there were so many special cases of relationships (L2TP, q in q, ip in ip) that we pretty much gave up. So, I don't think there are any problems with representing what you're talking about above, so maybe we should try to look at specific examples? > 2) The concept of connection oriented network: A NSI network is > something that can create segments (aka links a lower layer) between > edge points (aka ports). A network participates with other networks > in a topology where the elements are networks that connected with > links. In graph theory network would be node, and link an edge. I think that a Link represents a network connection pretty well. Maybe the Path/Link discussion is convincing, but I should say that's more of the perfSONAR/DCN perspective and not that of NDL (necessarily -- I think it's close, but I won't speak for them.) > 3) Names for the elements within a layer that are concatenated. NSI > calls these segments for now. The NSI topology elements are links > and networks. Each of these elements can provide segments and the > segments can be concatenated to create a ete segment. I believe > that segments and links at a level are identical concepts, so > perhaps we can come up with an alias for how to describe NSI > segments and ete concatenated segments. Again, hopefully, the Path/Link concept describes this for the complicated case. (And a simple relation works when 4K VLAN links are carried over the same Link....) best, martin Hi Freek - Thanks for the comments. I did mix NML and NMwg terminology. Sorry about that, I have not been sure what the NML terminology is in a lot of cases. I am now looking at the spreadsheet you mentioned - which I attach so we are sure we are talking about the same thing. I think this is a great tool for discussing the issues. As noted at the end of the note I suggest we have a call prior to OGF to talk about this and that we try to sort these issues out at OGF. I think we are close, but I at least have some questions and issues as discussed below. I will go down the sheet with comments and what I think the item might be called in NSI. The NSI naming intends to use NML names where the underlying concepts are the same. I was trying to put these into the spreadsheet, but it doesn't seem to fit in a good way so I will just comment and try to figure out how to present it better later. This is a link at a level. This seems a fine name. For NSI the question is if the link can carry links at a different level. I think so - I think there is a relation which says a link at one layer can support multiple links at a different layer. Examples would be multiple VLANS over ethernet or multiple VCGs over SONET, or multiple waves over a fiber. logical port (per layer) - G.805 calls this a connection point, NML and NMwg call it a port. In NSI we started discussion calling it a Port but switched to edge point to avoid the physical connotations of port. The groups should agree on this name or include an alias for different names if we can't agree. End point of a connection. seems a logical port with links connected to it. I think not a new concept for NSI concatenated series of links - Path in NML and NMwg, concatenated series of links in G.805. It seems to me that this should be a link not a path. I am not sure when some thing is a path rather than a link. I also think a concated series of links is a link (maybe it needs a name to become a link?) end-to-end connection - this seems a concatenated link with links to ? I skip monitored and multipoint connection/link Network Layer (topology on a single layer) - This seems an important concept - topology on a layer. A couple parts of this that I think may need definition: 1) how to tie together administrative domains with topology - for example one administrative domain may know about a subset of what another administrative domain knows; and 2) How do layers interact - is one layer carried by or used by another? I skip partitioned device - I am not sure how it would apply for NSI aggregated device -- called topology in NML. this might be a network in NSI, but I am not sure that fits well. domain - this seems like a network in NSI terms. Certainly it has a lot of the same characteristics. But it does not have all the characteristics - see discussion on "what is missing" below I skip encapsulation of data and addition of monitoring - I do think these are adaptations. Network layer -- This seems to go with the concept of link at a layer. I think that NSI operates at a single layer for a particular request. Data encoding of a network layer. I would like to see examples of what this means. For example does it mean GFP coding of VLANS over VCGs? Also, I have a question about whether these definitions apply to data`only - in NSI discussion has been that connection capabilities should support any technology, including for example, waves carried over fiber - where waves are switched without going to digital. Physical Link - this seems a link at a layer - not special for NSI, but important for others I skip physical Interface and device Switching capability - I am not sure this is needed in NSI - see discussion below Cross connect -- this is what NSI does at edge points - connects segments from different sources to concatenate them Channel over a link - A channel seems like a NSI segment. It could be described as a link over a link at a different layer. What seems missing -- 1) The description of adapatation in general: for example in a concatenated series of links, each concatenated link may be carried on a different sort of higer layer link. A VLAN might be carried on an Ethernet link (as a VLAN), on a SONET link as GFP encoded VLAN. In this case the underlying link with its coding is carried over different higher layer links with their coding. 2) The concept of connection oriented network: A NSI network is something that can create segments (aka links a lower layer) between edge points (aka ports). A network participates with other networks in a topology where the elements are networks that connected with links. In graph theory network would be node, and link an edge. 3) Names for the elements within a layer that are concatenated. NSI calls these segments for now. The NSI topology elements are links and networks. Each of these elements can provide segments and the segments can be concatenated to create a ete segment. I believe that segments and links at a level are identical concepts, so perhaps we can come up with an alias for how to describe NSI segments and ete concatenated segments. Are there questions or corrections? Comments on how to come to understanding and consensus for this? I suggest that we might want to have a call to start discussions on this before OGF and to try to resolve issues at OGF. There is a NSI call every Wed at 9ET - we could have a joint call on Wed May 20 if that seems reasonable. John On May 7, 2009, at 10:21 AM, Freek Dijkstra wrote: > John Vollbrecht wrote: > >> Attached is a try at defining needs of NSI from NML. Some if it >> uses NMwg terminology as I understand it. >> I am thinking it would be good to sort this out and get a good >> definition by the end of OGF. > > Hi John, > > Thanks for writing this down -- a few comments. > > You mix the NMwg with the NML terminology -- the NML terminology has > improved much since the NMwg documents, and will deprecate the NMwg > schema. > > Here is a comparison table between NML and NSI, as far as we see. > NSI NML > End Device --- Node > Edgepoint --- Port > Network --- Topology (*1) > Link --- Link > Segment --- (under discussion) > Service Group --- n/a > Level --- Layer > > (*1) If I understand your "network" correctly; the term network has > different meanings. > > Segment is still under discussion. We've used the term "Channel" a > few times, but there is no group consensus. Segment refers to a > multi layer concept, which will be defines in a separate schema. > > NML hasn't defined Service Group. It seems an important concept, so > perhaps we should. > > Have you seen the terminology comparison table at > http://forge.gridforum.org/sf/go/doc15512 > > Regards, > Freek Dijkstra > Jeroen van der Ham John Vollbrecht Senior Network Engineer, Internet2 office 734 352 4960 cell 734 395 7890

1 0

Fwd: NSI naming --
by John Vollbrecht 13 May '09

13 May '09

I am forwarding this conversation and will forward some other related ones to the NSI and NML groups. -- Note that I included the original doc in the message below. - John Begin forwarded message: > From: Freek Dijkstra <fdijkstr(a)science.uva.nl> > Date: May 7, 2009 10:21:51 AM GMT-04:00 > To: John Vollbrecht <jrv(a)internet2.edu> > Cc: Martin Swany <swany(a)cis.udel.edu>, Jeroen van der Ham <vdham(a)science.uva.nl > >, Aaron Brown <aaron(a)internet2.edu>, Jeff Boote > <boote(a)internet2.edu>, Andrew Lake <alake(a)internet2.edu> > Subject: Re: NSI naming > > John Vollbrecht wrote: > >> Attached is a try at defining needs of NSI from NML. Some if it >> uses NMwg terminology as I understand it. >> I am thinking it would be good to sort this out and get a good >> definition by the end of OGF. > > Hi John, > > Thanks for writing this down -- a few comments. > > You mix the NMwg with the NML terminology -- the NML terminology has > improved much since the NMwg documents, and will deprecate the NMwg > schema. > > Here is a comparison table between NML and NSI, as far as we see. > NSI NML > End Device --- Node > Edgepoint --- Port > Network --- Topology (*1) > Link --- Link > Segment --- (under discussion) > Service Group --- n/a > Level --- Layer > > (*1) If I understand your "network" correctly; the term network has > different meanings. > > Segment is still under discussion. We've used the term "Channel" a > few times, but there is no group consensus. Segment refers to a > multi layer concept, which will be defines in a separate schema. > > NML hasn't defined Service Group. It seems an important concept, so > perhaps we should. > > Have you seen the terminology comparison table at > http://forge.gridforum.org/sf/go/doc15512 > > Regards, > Freek Dijkstra > Jeroen van der Ham John Vollbrecht Senior Network Engineer, Internet2 office 734 352 4960 cell 734 395 7890

1 0

Minutes for last conf call
by Guy Roberts 01 May '09

01 May '09

Hi All, Please find below minutes from last weeks conference call. Could you please check your contributions to the Architecture deliverable and let me know if there are any changes you would like to make. I look forward to receiving your contributions in advance of OGF26. Regards, Guy --------- Minutes NSI-WG conf call Attendees: Radek Krzywania (RK) Chin Guok (CG) Jeroen van der Ham (JH) John Vollbrecht (JV) Eduard Escalona (EE) Joan Antoni García Espín (JA) Sebastien Soudan (SS) Guy Roberts (GR) Not present, but nominated as authors: Gigi Karma-Edwards (GK) Tomohiro Kudoh (TK) Jerry Sobieski (JS) Jeff Boote (JB) Joe Mambretti (JMa) Joe Metzger (JMe) Andrew Lake (AL) Aaron Brown (AB) Pascale Primet (PP) Artur ? Mary? AP1 Chin G to follow up on authors for monitoring section AP2 John V to follow up with Aaron to see if he can lead topology sharing section. AP3 John V to follow up with JS/GK confirm lead for path computation section The purpose of this call was to assign authors to the Architecture deliverable. The author assignment is summarized here: 1. Naming and modelling This section considers the naming of network objects and the data modelling of these objects. Lead author: JH Authors: GR, JV Due date: 13 May 2. Topology sharing This section considers how topologies can be exchanged over the NSI interface. Lead author: AB (to be confirmed) Author: GR, JH, RK, JA Due date: 13 May 3. Path computation This section considers how path computation relates to the NSI interface – describes where is this function can be performed and the inputs and outputs of the path computation function. Lead author: GK/JS (to be confirmed) Author: RK, JA Due date: 13 May 4. Authentication and trust This section considers how to authenticate a user, ie how to validate users are who they claim to be. Lead author: Mary ? Author: JV Due date: 13 May 5. Authorization and policy This section considers the rights/authorizations that a user has once they have been authenticated. This section will not be covered in Chapel Hill 6. Service Discovery This section considers a service that replies to queries on resource/service availability. Lead author: EE Author: JS, JMa Due date: 6 May 7. Environments (tree/chain) This section considers the management plane/control plane architecture of the NSI, i.e. the way that the data flows over the NSI interface Lead author: RK Author: GR Due date: 6 May 8. Scheduling and job control This section considers how scheduling is supported by the NSI and associated job control flows. Lead author: TK Author: PP, SS Due date: 13 May 9. Connection Restoration This section considers how connections are restored after failure Lead author: CG Author: Artur Due date: 13 May 10. Monitoring This section considers how connection monitoring can be implemented Lead author: CG Author: AL/JB/JMe (to be confirmed) Due date: 13 May 11. Reservation This section described how a connection can be reserved and the associate parameters. Lead author: GR Author: JA, JV Due date: 13 May -- _____________________________________________________________________ ** 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.org.uk D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

2 1

Strawman architecture deliverable
by Guy Roberts 29 Apr '09

29 Apr '09

Hello all, The current strawman architecture deliverable with the changes discussed on 15th April is available here: http://forge.gridforum.org/sf/go/doc15621?nav=1 Please take a look in advance of our next conf. call on the 6th May and send any comments on the list. Conference calls will be held weekly between now and OGF26 at the usual Wednesday times. 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.org.uk D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0

NSI wg ad hoc meeting at SMM 4-27
by John Vollbrecht 24 Apr '09

24 Apr '09

There will be a ad hoc meeting for people who are able to attend of the NSI wg. The meeting is at 4pm in the Alexandria room. There will be dial up Call: +1-734-615-7474 (PSTN CALL-OUT DOES NOT WORK) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0198899 The NSI wg is chartered to standardize the interface to a dynamic circuit network agent. The work to be discussed at the meeting is the strawman architecture document to be presented at the OGF meeting the end of May. Anyone interested is invited to attend. If possible, please let me know if you plan to attend or will dial in. Information about the NSI wg and documents and email history are available at http://forge.ogf.org/sf/projects/nsi-wg John John Vollbrecht Senior Network Engineer, Internet2 office 734 352 4960 cell 734 395 7890

1 0

NSI arch - authors call
by John Vollbrecht 22 Apr '09

22 Apr '09

There will be a call tomorrow (Wed 4-22) at 9AM ET for authors and potential authors of NSI architecture document sections. The call will be to discuss who is able to participate in creating initial versions of sections of the document, and how to handle multiple versions while the sections are being created and edited. I encourage anyone who is able to help with this to join the call, with specific sections in mind or wanting to help in any way. 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 --- Some sections that need an initial version Naming and modeling Topology sharing and Path computation Authentication and Trust policy Negotiation environments where NSI is used (tree vs chain is a starting point) scheduling and job control Others might be added John John Vollbrecht Senior Network Engineer, Internet2 office 734 352 4960 cell 734 395 7890

5 5

Comments on draft OGF protocol description requested
by Ralph Niederberger 22 Apr '09

22 Apr '09

Dear all, my name is Ralph Niederberger. I am one of the chairs of the FVGA-WG at OGF. We are currently investigating in designing a new protocol for dynamic opening of ports within firewalls by authorized user applications. Sorry for crossposting to all of the infrastructure-area mailing lists, but I would like to get feedback from all of you concerning a draft protocol we are just preparing within our group. And because our area-directors did not provide me with information on an infrastructure-area mailing list, where I could send it once, I had to send it to all RG/WGs The draft description I have appended to this email. It would be very helpful, if you could comment on this proposal, so that the Firewall Virtualisation for Grid Applications - Work Group can work on your comments at the next OGF meeting. We know that there are many other developments, which already have tried to solve this issue, but have not seen any solution, which is widely used and/or provides a similar easy to use interface and broad range of usability. Our intention is to get as much as possible feedback, so that we can decide as soon as possible, if the direction we are going is the right one or if we have missed anything important. Dependent on your feedback, we would like to go for this solution or change the draft accordingly. Then we would like to start the following steps in parallel: a.) Getting in touch with IETF for standardization issues. b.) Implementation of a first very limited prototype (showing that it works as suggested). Step b could be separated into different parts: b1.) prototype implementation for linux iptables b2.) prototype in close cooperation with a Firewall developer (-> a first FiTP aware firewall). Anyone having contact to these guys would be fine. b3.) Communication prototypes for out of band signalling, i.e. for firewalls which are FiTP unaware. So the auth server has to start a subroutine for firewall configuration (via CLI, special firewall managament software, https, ...) b3 could be done for several firewall systems, e.g. Cisco Pix, Checkpoint, ... Here we would need experts having access to those kinds of firewalls within test environments. Next steps are very dependent on the outcome of steps a.) and b.) above. I would like to thank you all in advance for your feedback. best regards Ralph Niederberger -- *************************************************** Ralph Niederberger Juelich Supercomputing Centre Institute for Advanced Simulation Phone: +49 2461 61-4772 Fax: +49 2461 61-6656 E-Mail: r.niederberger(a)fz-juelich.de WWW: http://www.fz-juelich.de/jsc/ JSC is the coordinator of the John von Neumann Institute for Computing and member of the Gauss Centre for Supercomputing *************************************************** Forschungszentrum Jülich GmbH 52425 Jülich Sitz der Gesellschaft: Jülich Eingetragen im Handelsregister des Amtsgerichts Düren Nr. HR B 3498 Vorsitzende des Aufsichtsrats: MinDirig'in Bärbel Brumme-Bothe Geschäftsführung: Prof. Dr. Achim Bachem (Vorsitzender), Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr. Harald Bolt, Dr. Sebastian M. Schmidt ***************************************************

1 0

OGF26 registration
by Guy Roberts 16 Apr '09

16 Apr '09

Just a reminder that the advance registration for OGF26 ends this Friday, so don't forget to register soon! 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.org.uk D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

2 1

next conf call
by Guy Roberts 16 Apr '09

16 Apr '09

We will have an shortened conf call next week at the usual time to assign writer to the NSI architecture document. If you are interested in contributing to this document, please join in Wednesday 22nd 9am Eastern time. If you are unable to join please send me an email with your preferred contribution. Minutes for today's call will be available shortly. 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.org.uk D A N T E United Kingdom WWW: http://www.dante.net _____________________________________________________________________

1 0