[Nsi-wg] uml proposal for STPs path object specifications...

[Jerry Sobieski]

As John V once said:  I won't die on this mountain.    I.e. Using the 
ERO to specify all the STPs in the path is still (IMO) the better way to 
do it, but this is not critical.   So we can have a vote at the call and 
decide, and move on.  I won't dwell on it:-)

THanks for considering it:-)
Jerry

On 9/10/12 5:28 AM, Guy Roberts wrote:
> Jeroen,
>
> I think that the SourceSTP and DestSTP need to be separated from the EROs for the following reasons:
>   - for unidirectional connections the source and destination need to be identified - I don't like using the idea of using a convention that the first ERO in the list source and the last destination.
>   - the two end STPs are mandatory whereas EROs are optional.
>
> Guy
>
> -----Original Message-----
> From: Jeroen van der Ham [mailto:vdham at uva.nl]
> Sent: 07 September 2012 10:04
> To: Jerry Sobieski
> Cc: Guy Roberts; nsi-wg at ogf.org
> Subject: Re: [Nsi-wg] uml proposal for STPs path object specifications...
>
> Hi,
>
> On 6 Sep 2012, at 23:56, Jerry Sobieski <jerry at nordu.net> wrote:
>> *proposal #2:*  I suggest we do away with the SourceSTP and DestSTP in the wsdl Reservation Request message.  We instead use the ERO object to contain all transit points: ERO(0) will always be the SourceSTP, and ERO(n) is the DestSTP.   This will allow the code to treat all segments the same - not have to treat the first and last segments specially in order to handle the SourceSTP and DestSTP objects.
> In NSIv1 we had a query message where the source and destination of a reservation were separate of the path. It was a bit annoying that the path description did not include them. I do agree that the path object should include both the start and destination of a connection.
>
> However, the source and destination are still important characteristics of a connection request. They are used a lot more often than just the path of the object.
>
> Optimization is good, but we should try not to make this so obfuscated that it makes it hard to do the general things with these messages.
>
> Jeroen.
>
>
>