Subject: RE: [NSIS] To BB or not to BB

From: "Freytsis, Ilya" <[email-masked]>
Date: Fri, 10 May 2002 09:47:33 -0400

Georgios,

You are absolutely correct. The question is can we afford to ignore the fact
that it is a part of the reality. Are you sure that NSIS solution will get
widely accepted if it will not support this requirement? 
By the way in my opinion centralized QoS management (that is what we are
talking about here) often needed not only for bandwidth brokering. There are
other QoS parameters as delay, jitter etc. that have to be considered for
some services.

Ilya

-----Original Message-----
From: Georgios Karagiannis (ELN)
[mailto:[email-masked]]
Sent: Friday, May 10, 2002 9:36 AM
To: 'Freytsis, Ilya'; [email-masked]';
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] To BB or not to BB

Hi Ilya

This is one of the requirements that are mainly related
to bandwidth brokering scenarios and significantly
complicate the NSIS protocol.

best regards,
Georgios

-----Original Message-----
From: Freytsis, Ilya [mailto:[email-masked]]
Sent: vrijdag 10 mei 2002 15:30
To: [email-masked]'; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] To BB or not to BB

John,

I think as long as we agreed that the NSIS signaling path is allowed to
diverge from the data forwarding path everybody who cares about BBs would be
satisfied.

Ilya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, May 10, 2002 4:26 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] To BB or not to BB

Hi all,

Just a general comment about Bandwidth Brokers and NSIS.  Bandwidth
Brokers (as the are commonly defined) are actually out of scope
of NSIS.  This means we are not defining a bandwidth broker
architecture.  There was quite a bit of discussion (at a highlevel)
about this before NSIS was allowed to be chartered, and it was
said to me that bandwidth brokers are not really thought of
as part of the Internet architecture.

However, I do know that there are many folks providing bandwidth
broker solutions.  My view is that a bandwidth broker comes
dangerously close to how resources are provisioned, therefore
are out of scope of NSIS. From the charter:

 It is noted that resource reservation and traffic engineering can be
 considered as part of network administration, and therefore beyond the
 scope of the IETF to mandate a particular mechanism.

Additionally, some folks may wish to check on the TEWG
(http://www.ietf.org/html.charters/tewg-charter.html) for work on
traffic engineering.

Finally, I do think it is perfectly acceptable to have a framework
and/or solution that is friendly to bandwidth brokers, but I do not
think that a bandwidth broker centric architecture or solution is
what we should do.

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

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

---

From: [email-masked]
Date: Fri, 10 May 2002 11:30:52 -0300 (EST)

I personally cannot see the deployment of QoS-based services involving different
admnistrative domains just based on "signaling messages". Signaling is
just a
part on the e2e qos big picture. In my opinion, mehanisms for dynamic
interdomain service negotiation and provisioning are necessary (a kind of BB).
So, I don´t support the opinion that BB-like mechanisms  are out of the scope of
Internet architecture (btw, is there an Internet Architecture? RFC 1958, section
2). 

It is probably not within the scope of NSIS, but I agree with Ilya that this
group should not ignore the reality.

Regards

Carlos Kamienski