Subject: RE: [NSIS] RE: What's in the charter of NSIS

From: "Gary Kenward"<[email-masked]>
Date: Fri, 17 May 2002 11:39:52 -0400

I think the distinction that can be made is that NSIS should be able to 
describe the QoS requirements, including resource constraining QoS 
specifications such as the Tspec. And, there should be an interaction 
with NSIS and admission control. However, there are other resources that 
may need to be provisioned for QoS such as filters, queues, etc., and we 
would really have to show a significant advantage in managing these 
resources with NSIS rather then one of the existing solutions.

Gary

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: May 17, 2002 05:54
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] RE: What's in the charter of NSIS
> 
> 
> Ruediger, John, all,
> 
> Would it be fair to say then that we can indicate in the 
> signaling that:
> a. we want to reserve resources
> b. how many we want of what type
> but
> c. without actually participating in the implementation or 
> saying how it
> must be done.
> 
> We can discuss next week if needed,
> Sven.
> 
> 
> 
> 
> 
> [email-masked] on 15/05/2002 11:57:33
>                                                               
>                                                               
>                                                               
>   To:          [email-masked]                    
>                                                               
>   cc:          [email-masked](bcc: Sven VAN DEN                
>                BOSCH/BE/ALCATEL)                              
>                                                               
>                                                               
>                                                               
>   Subject      [NSIS] RE: What's in the charter of NSIS       
>   :                                                           
>                                                               
> 
> 
> 
> 
> 
> Hi Rudiger,
> 
> > > Furthermore, maybe someone does not want IntServ exactly,
> > > but perhaps a certain characteristic of IntServ, say
> > > bandwidth.
> >
> > What happens to the remainder of IntServ in that case?
> > Would one have to signal empty parameters? No answer
> > required if this will be discussed in Helsinki!
> 
> My feeling is we should discuss what parts we signaling,
> but we de-couple the signaling from the resource reservation.
> 
> > >     Then you could have
> > >
> > >  Bandwidth Assurance over IntServ Networks
> > >  Bandwidth Assurance over MPLS Networks
> > >  Bandwidth Assurance over Over Provisioned Networks
> > >  Bandwidth Assurance over a Bandwidth Broker Network
> >
> > That BB definition issue must be settled. The "friends
> > of BB" could provide an architecture outline by now,
> > if they are not charged of entering the solution discussion.
> > It would be helpful to have such a document (and I see
> > by your other message that you aggree). Your above
> > example in my words would be:
> >
> > BW Assurancee over MPLS using a BB
> > BW Assurance over Over Provisoned Networks using a BB
> > or in general: BW Assurance over a network using a BB
> >
> > BB's of separated domains may
> > signal with each other without bothering which
> > layers/technologies are supported by the domain
> > in which each operates. This solves the problem
> > you've mentioned below (with regard to signaling):
> 
> As far as BB go, I don't think we need to completely
> ignore them, however, I don't think we can make NSIS
> a BB-centric archiecture.  What I mean is that we cannot
> mandate a BB architecure (i.e. - everyone who wants to
> use an NSIS protocol MUST deploy a bandwidth broker.)
> I see it more as something that the signaling can occur
> without a BB, but we may be able to put the correct
> hooks to allow those who want to deploy BBs to be able to
> do so.
> 
> To put it another way, I don't think that the IESG will
> let us standardize Bandwidth Brokers, nor is that something
> that I want to do.  However, it is possible that NSIS
> could support BBs, if they are present.
> 
> John
> 
> _______________________________________________
> 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: Lixia Zhang <[email-masked]>
Date: Fri, 17 May 2002 09:12:41 -0700

> resources with NSIS rather then one of the existing solutions.

Due to my teaching overload this quarter I have not been able to keep up
with the email on this list, thus I've been refraining myself from
commenting when occasionally I look up one or two msgs, since I know I wont
be able to keep up with the follow-on discussion.

But I cannot help throwing a comment on this specific one: NSIS stands for
"Next Step in Signaling", not next step in QOS.

I personally do NOT think a signaling protocol should involve itself into
the definitions of what QOS requirements should be.
QOS requirements may change over time, yet one wishes that the signaling
protocol, which is used to carry the QOS requirements, does NOT have to
change.

Besides, there WILL be other uses of a signaling protocol other than QOS
need.  My understanding is that NSIS is chartered to look into the need for
a signaling protocol, NOT the QOS requirement.

My personal 2 cents,
Lixia