Subject: RE: [NSIS] comments on draft in-path and out of path (draft-schel en-nsis-op opsig-00.txt)

From: "Geib, Ruediger" <[email-masked]>
Date: Thu, 4 Jul 2002 16:04:34 +0200

Hi Georgios,

my comments are in line.

Regards, Rüdiger

> Comment_2 on Section 3.2.1: 
> -------------
> I do not understand this comment:
> "In these cases, a signaling unaware cloud is not anymore a 
> signaling carrier, as nothing assures it will forward the
> signal at the same place it will forward the dataflow."

On path signaling only recognizes layer 3 routing. 
I guess the authors here refer to DiffServ aware 
traffic engineering. There traffic of different 
traffic classes may be forwarded along different routes
- depending on their traffic class. Signaling messages
are probably Best Effort, so QoS enabled data will in 
fact travel a different MPLS route.
The issue is that NSIS signaling is limited to layer 3
(which I strongly appreciate). An on path solution is 
layer 2 blind while an off path based solution doesn't
have to be. That's a clear benefit if off path signaling
is used.

> Comment on Section 3.2.3
> -------------------
> You mentioned:
> "One problem of RSVP and intserv is that every router in the 
> network must implement intserv and RSVP in order to link the
> sink and the source with a chain of QoS capable routers that
> all allocate resources for the flow."
> 
> [georgios] not all routers in a communication path have to 
> implement Intserv. Actually, you mighty have domains that
> are overprovisioned and do not implement Intserv.
> What I try to say is that this issue applies to both types of 
> architectures, i.e., on path and out of path. Therefore, it
> is not fair to presented here as an on path issue!

Section 4.3.1 of the draft states that an off path QoS controller
must be topology aware and therfore tap routing. So 
overprovisioning is an option in domains using off path QoS 
controllers, while it is a requirement for a domain using on
path signaling unless all routers passed must evaluate the 
signaling information.
This too is a clear benefit of an off path solution.

>  * There may be a single point of failure
> 
>    Failure detection and error recovery are tremendously
>    important.

Good point. I support your suggestion to add this issue to 
the list of issues.

>  * Sophisticated mechanisms for discovery of the centralized
>    entities are needed. This is an addition to your 
>    Section 4.3.1.

Yes, true. AAA or COPS may be checked to look for existing 
standard methods.

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