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

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

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
> 

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

---

From: "Hancock, Robert" <[email-masked]>
Date: Tue, 9 Jul 2002 08:35:34 +0100

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.

> From: Schneider, Marco [mailto:[email-masked]]
> Sent: 08 July 2002 20:04
> To: [email-masked]'; [email-masked]; [email-masked]

---

From: [email-masked]
Date: Tue, 9 Jul 2002 09:51:24 +0200

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.

> > I agree with Marcus that this is what we are trying to say.

(See attached file: RMRL-Disclaimer.txt)

---

From: [email-masked]
Date: Wed, 10 Jul 2002 13:35:01 +0300

Hi Marcus,

> > 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.

Agreed.

> > 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.

I think that Sven's definition is a good start.  Let's try to make
a more formal definition & stick it into the framework document (when
we have one).

thanks,
John