John,

If I may add my $0.02 cents.

On Apr 22, 2010, at 2:03 PM, John Vollbrecht wrote:

This is very nice.

A couple comments/ suggestions/ questions

1) I think all the actions you suggest for the transport plane failure  
are actually taken in the NRM or Service plane.  I may be wrong, but  
that is what it seems to me.  If so, then I think it would be helpful  
to describe the transport device/plane signalling failure to the NRM  
at different times.  Something like this would have made it easier for  
me to follow.

I agree that transport plane failures actions are either handled by the Service Plane aka NSA (for example "reserve alternative local resources") or in the transport plane (for example switch to backup). I do not understand what you mean by "describe the transport device/plane signalling failure to the NRM" - can you please elaborate?

The intention of this section was to indicate the error cases which would result in notification to the RA and possible cancelation of a connection. There are cases highlighted where the errors are handled completely by the Service Plane or the Transport plane with no need for notification to the user/RA. 


2) I don't the understand local and remote distinction in the Service  
Plane failure discussion.  Perhaps local meaning NRM and remote  
meaning reachable through NSI?

Local implies failure of own domain's RA or PA. Remote means failure of the remote RA or PA. The two cases are diagrammatically the same - the difference is in the context.


3) I am wondering how service plane failures are discovered?  Is some  
sort of session failure?

There are a couple of assumptions here:
1. There is reliable messaging between RA and PA
2. There is a timeout if responses are not received from the RA/PA (could be after multiple tries). This timeout could be due to a management network failure between RA and PA. 
Hope this helps - thanks for your feedback.

Inder



John

On Apr 21, 2010, at 1:49 AM, Chin Guok wrote:

Hi all,

I've attached a draft of the error handling section that Inder and I  
came up with for the NSI Architecture document.

This is a rough first draft, and there are some obvious portions  
missing, but it gives an idea of where we heading.

Comments are most welcomed.

Thanks.

- Chin<NSI Error Handling Chin_Inder  
v2.docx>_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

_______________________________________________
nsi-wg mailing list
nsi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg

---
Inder Monga http://100gbs.lbl.gov
imonga@es.net
http://www.es.net
(510) 499 8065 (c)

(510) 486 6531 (o)