Subject: Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing

From: Marcus Brunner <[email-masked]>
Date: Fri, 07 Jun 2002 17:18:39 +0200

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: Fri, 07 Jun 2002 17:34:41 +0200

Marco,

We discussed the issue of route pinning and traffic engineering in 
Helsinki. The conclusion during the meeting was that we want to add an 
assuption saying: NSIS assumes normal/standard L3 routing

Plus we add a requirement saying that NSIS protocol should not be broken by 
networks which do non-traditional L3 routing.

Does this cover your concern? Do we really need to add that NSIS must work 
with default routing changes?

Marcus

NSIS should not be broken by networks which do non-traditional L3 routing.