Subject: RE: [NSIS] NSIS Requirement: Independence of existing flow reserv ations and default routing

From: "Schneider, Marco" <[email-masked]>
Date: Mon, 8 Jul 2002 13:35:14 -0500

Hi Marcus,

Sorry for the very delayed reply. Allow me to quote for an earlier reply to
Georgios:

"In my mind this requirement has do with the layering relationship between
QOS Signaling and Routing. In a hard-state solution once the QOS path is
created it does not unchange. The signaling protocol uses input from the
routing protocol to create this path. The path created is static. In an RSVP
style solution without route pinning we have a reactive distributed
algorithm that takes the default routing path as its input. While it should
be possible to do this style of path that is dynamically determined by the
default destination based routing, it must also be possible to build the
path once based upon an initial set of inputs."

The fact that one can work around the deficiencies of a protocol layering
design does not mean the design is sound. 

Regarding Item 1: take care by introducing new links into your topology,
something you might want to do on lightly loaded metworks anyway.

1) The introduction of new links should not affect existing connections. 
2) More specifically the operator should not have to be concerned with
whether addition of links could affect existing connections. 

Regarding Item 2: 
I am not sure how constraint/qos routing goes into the mechanism of
provisioning. In fact the two are unrelated in IMHO. I do agree that QOS
routing appears to be out of scope.

Marco

> -----Original Message-----
> From: Marcus Brunner [mailto:[email-masked]]
> Sent: Friday, June 07, 2002 10:19 AM
> To: Schneider, Marco; [email-masked]'
> Cc: [email-masked]'
> Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow
> reservations and default routing
> 
> 
> Marco,
> 
> IMHO the problem you have shown in the example can be solved 
> in 2 ways, and 
> both are IMO out of scope for NSIS.
> 1) take care by introducing new links into your topology, 
> something you 
> might want to do on lightly loaded metworks anyway.
> 
> 2) I think an other solution would be constraint/QoS routing, 
> which is more 
> going into the mechanis of provisioning, which is again out of scope.
> 
> 
> Marcus
> 
> 
> 
> --On Tuesday, May 28, 2002 3:17 PM -0500 "Schneider, Marco" 
> <[email-masked]> wrote:
> 
> > Hi All,
> >
> > One of the Open issues mentioned in the current 
> requirements draft is
> > Route Pinning (item 47). In the following I discuss a very strong
> > motivation for the ability to do route pinning if a soft 
> state solution
> > is used for NSIS. I have tried to express this as a 
> requirement upon NSIS
> > rather than the mechanism (route pinning being the obvious 
> one) by which
> > this requirement may be achieved.
> >
> > Requirement: NSIS must directly support the ability to 
> insulate a flow
> > reservation from changes in the default routing behaviour 
> except in those
> > cases where said changes result from loss of resources 
> (layer 3 hops,
> > capacity etc.) along the existing flow reservation path.
> >
> > For instance, utilizing traffic engineering in a layer 2 
> network (e.g.
> > MPLS or ATM) we may provision additional links or change 
> the resources
> > associated with existing links. Additionally failures in 
> the network may
> > cause changes. Such changes must not affect existing layer 
> 3 reservation
> > paths with the exception of those cases where the existing 
> reservation
> > path no longer exists or no longer has capacity to support the flow
> > reservation.
> >
> > As a simple example consider a network with two routers A 
> and B and assume
> > that the shortest path from A to B is two hops. Based upon 
> NSIS signaling,
> > as directed by default routing based upon number of hops, a 
> reservation
> > path is setup from A to B along a path of two hops, where 
> both hops have a
> > capacity of 10 and the reservation uses a capacity of 6. 
> Now let us assume
> > that a direct link with capacity 5 is provisioned between A and B
> > resulting in a new and direct default route of 1 hop. If 
> NSIS uses a soft
> > state solution without route pinning then the existing flow 
> reservation
> > will be redirected along the new link, which cannot support 
> it. Thus the
> > existing flow reservation is lost due a change in the 
> network unrelated
> > to its current path. In fact thousands of reservations may have been
> > routed along the original path and would now be disrupted. 
> Such protocol
> > behaviour is not acceptable.
> >
> > Best Regards,
> > Marco
> >
> >
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org/marcus
> 
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Marcus Brunner <[email-masked]>
Date: Tue, 09 Jul 2002 18:01:00 +0200

Marco,

see inline

--On Montag, 8. Juli 2002 13:35 -0500 "Schneider, Marco" 
<[email-masked]> wrote:

> Hi Marcus,
>
> Sorry for the very delayed reply. Allow me to quote for an earlier reply
> to Georgios:
>
> routing protocol to create this path. The path created is static. In an
> RSVP style solution without route pinning we have a reactive distributed
> algorithm that takes the default routing path as its input. While it
> should be possible to do this style of path that is dynamically
> determined by the default destination based routing, it must also be
> possible to build the path once based upon an initial set of inputs."
>

you mean the path of existing reservations should not change? Is this a 
general operator requirement? With RSVP style siganling it definitly 
affects existing pathes.

> whether addition of links could affect existing connections.

I would assume that in most cases, and done on lightly loaded networks, 
this would not affect existing services. However, this can definitly 
happen, in certqain cases. Again do you feel other operators have similar 
concerns?

> routing appears to be out of scope.

In QoS routing you choose the path not based on "normal routing", but based 
on resource availabiliy, which I relate to a function of the provisioning 
process (I agree in a sloppy way).

Marcus