[Nsi-wg] Message Delivery Layer

Guy Roberts Guy.Roberts at dante.net
Thu Dec 6 05:43:09 EST 2012


Jeroen,

The MTL layer looks after delivery between a pair of peering RA and PA.  My understanding is that the MDL has different role, to confirm the correct delivery to all child PAs. This allows the logic associated with checking that all child PAs have responded correctly to be removed from the state machines.  See the attached slide.

Guy

-----Original Message-----
From: nsi-wg-bounces at ogf.org [mailto:nsi-wg-bounces at ogf.org] On Behalf Of Jeroen van der Ham
Sent: 06 December 2012 10:18
To: NSI Working Group
Subject: [Nsi-wg] Message Delivery Layer

Hi all,

It seems that in the current document we have sections on the MDL and MTL. The MTL is deemed to be out of scope, and it is recommended to be "TCP/IP-HTTP-XML (such as SOAP)". Which I would scrap, and just put in SOAP, since NSI does not support any other TCP/IP-HTTP-XML stack.

Given that TCP, HTTP and SOAP already provide more than enough delivery assurance, I have to wonder why we actually need that extra conceptual layer in the Message Delivery Layer. It already is basically outsourced to those layers anyway. And for the few cases where upper layer logic is required to make sure that a request is handled correctly, we turn to the State Machine in the form of acknowledgements.

I know that the State Machine is currently still being improved. But did we also take the suggestion to make all short exchanges synchronous, and to allow optional acknowledgement for longer asynchronous exchanges? This would make it much simpler to use NSI in cases with limited connectivity (firewalls/clients/NAT etc.) 

Jeroen.


Begin forwarded message:

> From: Jeroen van der Ham <vdham at uva.nl>
> Subject: Re: [Nsi-wg] Query request
> Date: 2 November 2012 10:20:34 CET
> To: Jerry Sobieski <jerry at nordu.net>
> Cc: <nsi-wg at ogf.org>
> 
> Hi,
> 
> The NSI has chosen to use SOAP and WSDL as its message transport layer. This is a reasonably standard protocol, with support (more or less) in many different languages. For what we aim to do it is pretty good, and it has proven to work pretty well in the past few demos.
> 
> You're saying that we should not be projecting lower layer issues into the NSI layer. In my opinion this is exactly what has happened already. And it is also exactly the reason that we are having all these issues.
> 
> Reliable message transport layers are readily available off the shelf. TCP makes sure that a packet gets from the source to the destination. On top of that we're using HTTP, which also provides some additional guarantees that the message gets there, including some error codes regarding malformed messages, messages out of order, authentication errors, et cetera.
> We've used an additional SOAP layer on top, which provides you with even more guarantees.
> 
> Can someone please explain to me that in this scenario we really need to have separate confirmation messages? And even if we do, why do these messages have to be exchanged in a completely separate TCP-HTTP-SOAP session?
> 
> I understand that we have a state machine, with transition using confirmation messages. But can't we use any of the TCP/HTTP/SOAP status messages to achieve that?
> 
> Jeroen.

_______________________________________________
nsi-wg mailing list
nsi-wg at ogf.org
https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: MDL.pptx
Type: application/vnd.openxmlformats-officedocument.presentationml.presentation
Size: 44724 bytes
Desc: MDL.pptx
URL: <http://www.ogf.org/pipermail/nsi-wg/attachments/20121206/47c0588f/attachment-0001.pptx>


More information about the nsi-wg mailing list