Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence of existing flow reservations and default routing

From: [email-masked]
Date: Wed, 10 Jul 2002 09:40:21 +0300

Hi Marcus,

> Probably you should ask the ADs or John. I think this was a requirement 
> from there side, that we only regard traditional routing. In view, this 
> means no load sharing, no trafic engineering. The latter might even not be 
> a problem.

I think we need to still work through this in detail, but at a high level, 
I think the issue is more about the 'explictness' of signaling off-path 
or on-path.  The basic assumption is that the signaling messages should
follow the same path as the data flow.  We may need to make some provisions
for when there might be some changes in the paths which the packets flow.
We should address this issue in the framework document.

Please note, we may want to discuss how broadly we define a path in NSIS,
for example, A needs to signal B.  Due to some layer 3 issues, it is possible
that packets travel over 3 different paths.  We could treat these
as 3 different explicit paths, or group them into 1 broadly defined path.
I think we can investigate this issue further in the framework document.

                1
          +--------+
         /      2   \
A ------+--+---------+------ B
            \        /
             +------+
                3
John

> 
> Marcus
> 
> --On Montag, 8. Juli 2002 13:39 -0500 "Schneider, Marco" 
> <[email-masked]> wrote:
> 
> > Marcus,
> >
> > Actually, during the meeting I raised my concerns and was 
> asked to post an
> > example to the mailing list which I did.
> >
> > In reponse to your question, I am not sure what "non-traditional L3
> > routing" is. I am not sure I see the relationship between 
> the two issues.
> > Can you further elaborate.
> >
> > Thanks,
> > Marco
> >
> >> -----Original Message-----
> >> From: Marcus Brunner [mailto:[email-masked]]
> >> Sent: Friday, June 07, 2002 10:35 AM
> >> To: Schneider, Marco; [email-masked]'
> >> Subject: req proposal (was Re: [NSIS] NSIS Requirement:
> >> Independence of
> >> existing flow reservations and default routing
> >>
> >>
> >> 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.
> >>
> >> --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
> >>
> >>
> 
> 
> 
> --------------------------------------
> 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
> 

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

---

From: [email-masked]
Date: Wed, 10 Jul 2002 14:23:41 +0200

Hi Marcus,

Just a single comment inline.

Sven.

Marcus Brunner <[email-masked]>@ietf.org on 10/07/2002 11:19:20

Please respond to [email-masked]

Sent by:  [email-masked]

To:   Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, [email-masked]
cc:   [email-masked], [email-masked]
Subject:  RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence
      of existing flow reservations and default routing

--On Mittwoch, 10. Juli 2002 09:15 +0200 [email-masked]
wrote:

> Hi John,
>
> I have two remarks:
> 1) Your suggestion would also allow the use of e.g. backup paths to be
> configured with the primary paths (and be treated together as a 'broader
> path'). If this is the case, we might need to take this into account in
> the signalling

I have not seen backup pathes on L3. Every thing below I assume out of
scope. L3 reroutes in failure cases.

[Sven] What if it would reshuffle the traffic over several node and link
disjoint paths (as you could typically use for loadbalancing). This is the
reason why I made the remark in the first place.

> 2) A broader definition of path could also be 'the AS-path followed by
the
> flow'. Would this definition also be acceptable?

Thats what I would go for, and that what stands in the Req draft.

Marcus

> Sven.
>
>
>
>
>
> [email-masked]@ietf.org on 10/07/2002 08:40:21
>
> Sent by:  [email-masked]
>
>
> To:   <[email-masked]>, <[email-masked]>, <[email-masked]>
> cc:
> Subject:  RE: req proposal  (was Re: [NSIS] NSIS Requirement:
Independence
>       of existing flow reservations and default routing
>
>
> Hi Marcus,
>
> follow the same path as the data flow.  We may need to make some
> provisions for when there might be some changes in the paths which the
> packets flow. We should address this issue in the framework document.
>