Subject: RE: Definition of QI was: Re: [NSIS] WG requirements draft

From: [email-masked]
Date: Fri, 1 Mar 2002 22:56:02 +0200

Hi Rüdiger,

> How a network provider 
> modifies resources within his domain and at which layer 
> doesn't matter to NSIS and therefore isn't relevant for my proposal. 

Well put.

John

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

---

From: [email-masked]
Date: Fri, 1 Mar 2002 22:56:01 +0200

Hi Danny & Rüdiger,

Some comments - text clipped where appropriate.

> [DG] OK, we don't want to make the mistake of per-microflow processing
> in core routers again, I think nobody objects to that.

Agreed.

> [DG] However, I think we should make distinction between provisioning
> (making the resources available, e.g. fat-pipe set-up) and signaling
> (consuming the resources, e.g. multiplexing microflows in the pipes at
> the edges). Clearly resource provisioning may depend on the actual
> technology of the concrete network (and is an operator's policy). I
> should like to call this "local provisioning means" and the end-to-end
> NSIS signaling should, in my opinion, be independent of this local
> mechanisms. 

Provisioning, fyi, is out of scope for NSIS.  However, placing hooks
into an nsis protocol so that mechanisms could do this provisioning
is within scope.

> > If you'd like to look at it that way, it's a requirement 
> for NSIS signalling to support some kind of traffic 
> engineering. Support here is limited to control "fat pipe" 
> set up, maintenance and release.
> 
> [DG$ Here I am not sure it should be the first focus of NSIS, 
> imho, NSIS
> should have as first target the per-flow signaling and make the "local
> provisioning means" transparant for the QoS signaling.

Again, placing hooks in NSIS for TE is OK, but mandating TE or specifying
a specific form of TE is out of scope.  

John