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

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 9 Jul 2002 09:17:38 +0100

Hi Sven,

I'm confused by the phrase 'routing of the displaced flow'. I assumed that the whole point was to avoid displacing the flow in the first place.  

In fact, whether the path is determined by normal L3 routing or abnormal routing or any other mechanism is rather a second order problem. The fundamental aspect is that NSIS (I assume) has no role in determining that path, it takes the path as given and has to live with it.

What would be helpful for me would be if someone could give an example of how the _flow_ (not the signalling) is going to get restricted to the old path. Then we could see if any special tricks would be needed to make NSIS work after this had been done. At the moment, I can't see what they would be.

Cheers,

Robert H.

PS I'm sure that a topology aware system could do some sort of traffic engineering by setting up tunnels and so on. Whether this is a good thing to do I make no comment on; but I don't see what additional requirements would be needed to make NSIS work in such an environment. In any case, I get the feeling there's a danger that we're trying to use NSIS to recreate MPLS on the IP layer. One MPLS is enough for me...

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: 09 July 2002 08:51
> To: Hancock, Robert
> Cc: 'Schneider, Marco'; [email-masked]
> Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: 
> Independence
> ofexisting flow reservations and default routing 
> 
> 
> Hi Robert, Marco,
> 
> I am not sure that NSIS has nothing to do with the fix of the problem
> described by Marco. If you have the capability to do routing of this
> displaced flow in a non-traditional way, then wouldn't you 
> like NSIS not to
> tear down the existing reservations (I assume in your example 
> you would
> have the reservations taken down, then start new NSIS 
> signalling indicating
> the 'non-traditional' path) while you updating the 
> signalling? Of course,
> if you want to support such a function you would need to be 
> sure that the
> old path is still available. This requires the ability to distinguish
> between a failure on the old path and the availability of a new path.
> 
> CU,
> Sven.
> 
> 
> 
> 
> 
> "Hancock, Robert" <[email-masked]>@ietf.org on 09/07/2002
> 09:35:34
> 
> Sent by:  [email-masked]
> 
> 
> To:   "'Schneider, Marco'" <[email-masked]>, [email-masked]
> cc:
> Subject:  RE: req proposal  (was Re: [NSIS] NSIS Requirement: 
> Independence
>        ofexisting flow reservations and default routing
> 
> 
> Hi Marco,
> 
> I think I understand your concerns and your example. I'm 
> still not sure it
> translates into an NSIS requirement.
> 
> To paraphrase (I hope correctly) your example as you describe it:
> 1. You have a flow which is taking a certain path through the network.
> 1a. NSIS messages are following that path, and reserving 
> resources for it.
> Because there are enough resources on the particular path, 
> the reservation
> is successful.
> 2. Someone adds a new link to the network, which changes the path in
> question. The new path is incapable of carrying the flow.
> 3. The reservation is routed along the new path. It's 
> rejected (too little
> capacity) and all reservations associated with it are dropped.
> 
> Clearly, that's undesirable. However, the problem is not with the NSIS
> signalling, so NSIS can't fix it: At point (2), if you are in a normal
> connectionless network, the flow will also be routed along 
> the new path.
> NSIS is just (correctly) reflecting the fact that routing 
> hasn't found the
> real 'best' route through the network.
> 
> In other words, the real solution to the problem has to come from some
> routing trick which keeps the flow on the old path, and we referred to
> things in this class as 'non-traditional L3 routing' . If you 
> can find a
> method to do this, then we want NSIS to continue to work if 
> you are using
> it (i.e. NSIS shouldn't be broken by it). (Whether that's easy or
> impossible is another question, but that seems to be the requirement.)
> 
> Cheers,
> 
> Robert H.
> 
> > -----Original Message-----
> > From: Schneider, Marco [mailto:[email-masked]]
> > Sent: 08 July 2002 20:04
> > To: [email-masked]'; [email-masked]; [email-masked]
> > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement:
> > Independence
> > ofexisting flow reservations and default routing
> >
> >
> > John,
> >
> > As per my response to Marcus: I raised my concerns during the
> > meeting and
> > was asked to post an example, which I did.
> >
> > As for the text, I guess it is not clear to me whether this
> > addresses the
> > issue. In my opinion the example I gave does not have
> > anything to do with
> > non-traditional L3 routing.
> >
> > Marco
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Monday, June 10, 2002 8:29 AM
> > > To: [email-masked]; Schneider, Marco; [email-masked]
> > > Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement:
> > > Independence
> > > ofexisting flow reservations and default routing
> > >
> > >
> > > Hi Marco & Marcus,
> > > > 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?
> > >
> > > I agree with Marcus that this is what we are trying to say.
> > > Marco, is this
> > > text OK with you?
> > >
> > > John
> > >

========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: [email-masked]
Date: Tue, 9 Jul 2002 10:36:06 +0200

Hi Robert,

I have some comments inline.

CU,
Sven.

"Hancock, Robert" <[email-masked]> on 09/07/2002 10:17:38

To:   Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:   "'Schneider, Marco'" <[email-masked]>, [email-masked]
Subject:  RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence o
      fexisting flow reservations and default routing

Hi Sven,

I'm confused by the phrase 'routing of the displaced flow'. I assumed that
the whole point was to avoid displacing the flow in the first place.

[Sven] I think there are two possible scenarios
1) The flow is displaced and NSIS will adapt its signalling (which will
follow the new route). NSIS might need to do something during this
transient, especially since it may be used to set up reservations on the
new path (segment)
2) The flow is not displaced because it has been determined that the
reservation on the new path is not feasible or because it is undesirable to
move existing flows. In that case NSIS signalling needs to be able to
indicate that its path should not be changed (maybe it has recorded the old
path while it was being set up?)
In both cases, there seems to be a need to defer the decision to
reroute/re-reserve/re-establish until some check on the new path has been
performed. I am wondering if this could have impact on NSIS.

In fact, whether the path is determined by normal L3 routing or abnormal
routing or any other mechanism is rather a second order problem. The
fundamental aspect is that NSIS (I assume) has no role in determining that
path, it takes the path as given and has to live with it.

[Sven] Would it be possible for NSIS to record the path it has been given
at setup time and express its requirement to stay on it?

What would be helpful for me would be if someone could give an example of
how the _flow_ (not the signalling) is going to get restricted to the old
path. Then we could see if any special tricks would be needed to make NSIS
work after this had been done. At the moment, I can't see what they would
be.

[Sven] Suppose a single route towards a destination is announced and later
on another route towards that destination is announced with a QoS
attribute. Then the flow could remain on that route, although a new
(best-effort) route becomes available. Would that be a valid example?

Cheers,

Robert H.

PS I'm sure that a topology aware system could do some sort of traffic
engineering by setting up tunnels and so on. Whether this is a good thing
to do I make no comment on; but I don't see what additional requirements
would be needed to make NSIS work in such an environment. In any case, I
get the feeling there's a danger that we're trying to use NSIS to recreate
MPLS on the IP layer. One MPLS is enough for me...

Permission is hereby granted to pass the contents of this communication to
third parties and any restrictions regarding confidentiality do not apply.

(See attached file: RMRL-Disclaimer.txt)

---

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 00:04:35 +0100

hi sven,

a belated reply:

[snip]
> at setup time and express its requirement to stay on it?

[reh] OK, this is an interesting prospect, depending on 'who' NSIS should express this requirement to. Saying that NSIS should be able to do route recording and then feed this information into resource management is a requirement I can understand. (I'm not saying if I agree with it or not. It almost certainly isn't in the requirements draft at the moment.)

> (best-effort) route becomes available. Would that be a valid example?

[reh] what does 'announced' mean really? i guess it means that routers end up with forwarding entries that enable the route to be followed hop by hop in the 'right' way. well, they're available for the signalling messages as well - there's no new requirement on NSIS in this case, so far as I can see.

cf. 4.1 of our framework document: "NSIS needs to know ... how to select the outgoing interface for a signaling message, in case this needs to match the interface that will be used by the corresponding flow. This might be as simple as just allowing the IP layer to handle the message using its own routing table." [Or, it might not.] We needed that even before talking about route pinning, and I'm not sure what more could be required; doing it right is an implementation issue between NSIS and the router's forwarding engine.

see you in japan,

robert.

---

From: "Schneider, Marco" <[email-masked]>
Date: Tue, 16 Jul 2002 18:18:31 -0500

I see another alternative to route recording:

In response to NSIS signaling, routers install state that causes future
signaling to follow the same path. This could be made explicit by a field in
the protocol. The routers would also need to install state that caused the
signaled flow to continue to follow this path as well.

In the case of link failure along the existing path, a release may be
necessary followed by reinitiation of the reservation. If intermediate
routers are not NSIS aware there may be other issues with this approach.

Requirements on NSIS: possibly a bit to make this option explict and ...?

Marco

-----Original Message-----
From: Hancock, Robert [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 6:05 PM
To: [email-masked]
Cc: Schneider, Marco; [email-masked]
Subject: RE: req proposal (was Re: [NSIS] NSIS Requirement: Independence
o fexisting flow reservations and default routing 

hi sven,

a belated reply:

[snip]
> at setup time and express its requirement to stay on it?

[reh] OK, this is an interesting prospect, depending on 'who' NSIS should
express this requirement to. Saying that NSIS should be able to do route
recording and then feed this information into resource management is a
requirement I can understand. (I'm not saying if I agree with it or not. It
almost certainly isn't in the requirements draft at the moment.)

> (best-effort) route becomes available. Would that be a valid example?

[reh] what does 'announced' mean really? i guess it means that routers end
up with forwarding entries that enable the route to be followed hop by hop
in the 'right' way. well, they're available for the signalling messages as
well - there's no new requirement on NSIS in this case, so far as I can see.

cf. 4.1 of our framework document: "NSIS needs to know ... how to select the
outgoing interface for a signaling message, in case this needs to match the
interface that will be used by the corresponding flow. This might be as
simple as just allowing the IP layer to handle the message using its own
routing table." [Or, it might not.] We needed that even before talking about
route pinning, and I'm not sure what more could be required; doing it right
is an implementation issue between NSIS and the router's forwarding engine.

see you in japan,

robert.

> > > > I agree with Marcus that this is what we are trying to say.
============================================================================
============
Permission is hereby granted to pass the contents of this communication to
third parties and any restrictions regarding confidentiality do not apply.

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

---

From: [email-masked]
Date: Tue, 23 Jul 2002 15:27:23 +0300

Hi Marco,

> routers are not NSIS aware there may be other issues with 

I understand what you want to do, but this kind of thing seems rather heavy.

> Requirements on NSIS: possibly a bit to make this option 

Making a bit would be a solution, not a requirement.  A requirement would be
something like:

  An NSIS solution MAY/SHOULD be able to maintain an explicit path for packets
  to travel through.  In the case of link failure along the existing path, a 
  release may be necessary followed by reinitiation of the reservation. If 
  intermediate routers are not NSIS aware there may be other issues with 
  this approach.

John