- Nsi-wg - lists.ogf.org

Re: [Nsi-wg] Issue 11 in ogf-nsi-project: Explicit routing object in connection request
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Comment #2 on issue 11 by guy.robe...(a)gmail.com: Explicit routing object in connection request http://code.google.com/p/ogf-nsi-project/issues/detail?id=11 Pseudo EROs are supported by the original requestor NSA splitting the connection request into individual child requests (tree model) with explicit STPs. EROs for Network internal pathfinding is not currently supported. Chin: we have an LHC use case for Network internal EROs.

1 1

Re: [Nsi-wg] Issue 19 in ogf-nsi-project: technology specific attributes - how to use
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Owner: jeroen.v...(a)gmail.com Comment #2 on issue 19 by guy.robe...(a)gmail.com: technology specific attributes - how to use http://code.google.com/p/ogf-nsi-project/issues/detail?id=19 (No comment was entered for this change.)

1 2

Re: [Nsi-wg] Issue 49 in ogf-nsi-project: Missing information in detailed query?
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Summary: Missing information in detailed query? Comment #1 on issue 49 by guy.robe...(a)gmail.com: Missing information in detailed query? http://code.google.com/p/ogf-nsi-project/issues/detail?id=49 The basic query does not walk-the-tree. The response to the detailed query should 'walk the tree'. The returned information should include both a full list of STPs and the ability to find the segment names of a connection. summary query will give the state of the aggregator. The detailed query walk-the-tree to collect the state of all child PAs.

1 7

Re: [Nsi-wg] Issue 53 in ogf-nsi-project: confirmation messages for all state tranistions?
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Updates: Status: Fixed Comment #5 on issue 53 by jmacau...(a)gmail.com: confirmation messages for all state tranistions? http://code.google.com/p/ogf-nsi-project/issues/detail?id=53 Fixed with revision 34.

1 0

Issue 54 in ogf-nsi-project: Make it possible to go from auto-provision to scheduled
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Status: Accepted Owner: ---- Labels: Type-Enhancement Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 54 by thost...(a)gmail.com: Make it possible to go from auto-provision to scheduled http://code.google.com/p/ogf-nsi-project/issues/detail?id=54 It is not possible to go from auto-provision to scheduled in the current state machine. In case of a failed provision call, it is impossible to "release" the other connections, making it impossible to keep the state between connections consistent. As some will be in auto-provisioned and other will be in scheduled. Ignore failures, it should also be possible for a connection to go into scheduled mode from auto-provision to say that the connection shouldn't be provisioned, but the resources should still be reserved. Resolution of Issue: Allow transistion from auto-provision to scheduled and have a release request move a connection from auto-provision to scheduled.

1 3

Issue 56 in ogf-nsi-project: Overloaded usage of 'Provisioned' state
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Status: Accepted Owner: tkudoh...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.1 FixedInVersion-2.0 New issue 56 by guy.robe...(a)gmail.com: Overloaded usage of 'Provisioned' state http://code.google.com/p/ogf-nsi-project/issues/detail?id=56 Description of Issue: In the state machine defined in NSI v1.1, the 'Provisioned' state is overloaded. Two meanings are associated with this state: 1. All child NSAs have acknowledged receipt of the provision command 2. All child NSAs have confirmed provisioning complete Discussion of Issue: Should we refine the state-machine to disambiguate these two different understandings of 'Provisioned'. A proposal has been made to add a new message 'Connection-State up'. Resolution of Issue:

1 1

Issue 63 in ogf-nsi-project: Query: Need to include requester NSA information associated with a connection reservation.
by ogf-nsi-project＠googlecode.com 19 Sep '12

19 Sep '12

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.0 FixedInVersion-1.1 New issue 63 by jmacau...(a)gmail.com: Query: Need to include requester NSA information associated with a connection reservation. http://code.google.com/p/ogf-nsi-project/issues/detail?id=63 Description of Issue: When using the Query operation there is no way to determine within the QueryConfirmed the requester NSA associated with a connection reservation. This means there is no way to determine the direct parent NSA associated with a reservation. Discussion of Issue: It was agreed in the week meeting that the requesterNSA should be returned with the query result for both summary and detailed results. Resolution of Issue: RequesterNSA should be returned with the query result for both summary and detailed results.

1 1

NSIv2 Implementation plans
by Jerry Sobieski 17 Sep '12

17 Sep '12

Hi all- I need an inventory of which implementation teams will have some v2 capability that can be displayed at GLIF and SC. And a general sense of what features will be in some form demonstrable at each stage. For instance: OpenDRAC will have the alpha v2 SM ready less modify() functions by glif, and full SM and topology processing by SC. or: OpenNSA will have basic v2 (NDL) topology processing, but only bidirectional connections, and no modify by GLIF, better topo and uni/bi connections at SC. Modify by SC. (These are just examples) Consider GLIF "alpha" mode - some basic functionality, but much work still necessary. SC should be "beta" mode - more v2 features, and those features generally working pretty well. And then by TIP in mid January would be v2Q1 (Qualification) where we'll be trying to exercise and demonstrate important v2 capabilities in a convincing manner. So please let me know the following: a) Which package (OpenNSa, DRAC, OSCARS, Autobahn etc.) b) Which v2 feature(s) you are pursuing and hope to have working to some degree by GLIF, and by SC. c) When will you be able to run your v2 code on the AutoGOLE hardware? (We need to plan a migration date.) We are trying to sort out the details for topology specifics, and which capabilities we can talk about at the GLIF presentations, and which implementations can do things like PF and aggregation... NOTE: We are only expecting v2 in "alpha" version for GLIF - some basic demonstrable v2 capabilities. Our intent at GLIF is to show v2 as far along as we can. Not fake it, but where features are making progress, we'd like to show that. And we want to show that there are numerous implementations that are implementing v2. This is about presenting NSIv2 as the result of lessons learned from v1, and an express intent to round out v2 with a more mature and production capable feature set. Thanks Jerry

1 0

Re: [Nsi-wg] NSI meetings
by Guy Roberts 17 Sep '12

17 Sep '12

The schedule for OGF36 is now available here: https://www.ogf.org/gf/event_schedule/index.php?event_id=25 The NSI sessions will be on Monday afternoon and all day Wednesday. Guy -----Original Message----- From: John MacAuley [mailto:john.macauley@surfnet.nl] Sent: 16 September 2012 18:27 To: Guy Roberts Subject: NSI meetings Guy, Are we starting on the Sunday Oct 7th or the Monday Oct 8th? I am booking my flight and want to make sure I am there for the first day but not too early! John

1 0

Issue 66 in ogf-nsi-project: Remove explicit bandwidth field from WSDL
by ogf-nsi-project＠googlecode.com 17 Sep '12

17 Sep '12

Status: Accepted Owner: jmacau...(a)gmail.com Labels: Type-Defect Priority-Medium FoundInVersion-1.0 FixedInVersion-2.0 New issue 66 by jmacau...(a)gmail.com: Remove explicit bandwidth field from WSDL http://code.google.com/p/ogf-nsi-project/issues/detail?id=66 Description of Issue: Bandwidth, or capacity is a technology specific attribute part of a network Service Description. The explicit bandwidth field should be removed and an equivalent value should be specified as an attribute in the serviceAttributes field (type-value-pair). Resolution of Issue: Bandwidth field must be removed.

1 1