Subject: [NSIS] QoS NSLP open issue on region scoping

From: [email-masked]
Date: Thu, 26 Feb 2004 15:16:51 +0100

Hi all,

While the discussion on the QSPEC stacking error cases finalizes, I would
like to focus attention on the second open issue, related to region
scoping. The QoS NSLP specification (-02) allows QNEs to scope their
messages, i.e. to restrict the extent to which messages may travel along
and be interpreted on the path.
Note that this is somewhat related to the QSPEC stacking discussion since
the set of QNEs that support a certain QSPEC/QoS model can be regarded as a
region. Messages can be scoped to a region implicitly (e.g. because the
last QNE of a domain is configured to terminate the session) or via the
SCOPING object.
We are looking for input to determine to what extent the concept of a scope
should generalized. At this point we have three types of scope defined:
- whole path (default)
- single hop (useful to e.g. QUERY a peer QNE)
- back to me (RII): used to scope a response so that it does not travel
beyond the requesting node.

The question is: should  the QoS NSLP specification define and support a
more generic notion of region (e.g. to implement region policies
independent from aggregation regions,...)?

Looking forward to your views.

Best regards,
Sven

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

---

From: Tschofenig Hannes <[email-masked]>
Date: Thu, 26 Feb 2004 15:26:31 +0100

hi sven, 

thanks for raising this issue. in the nat/firewall case found it interesting
to think about a "local network" only scoping. this might be useful in some
deployment environments where end-to-end nat/firewall signaling is not an
option. the receiver behind the nat scenario is another case. 

this issue was also raised by cedric's drafts. 

ciao
hannes

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Thursday, February 26, 2004 3:17 PM
> To: [email-masked]
> Cc: McDonald, Andrew; Georgios Karagiannis
> Subject: [NSIS] QoS NSLP open issue on region scoping
> 
> 
> Hi all,
>

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 27 Feb 2004 09:14:29 -0000

hi,

teeny GIMPS-specific point:

> > Should the NSLP do this itself? Or should the NTLP provide 
> > some generic functionality to do this?
> 
> NSLP has to be involved in a certain way. A simple example, 
> for the "next > node" scope, the actual next NSLP node 
> could be several NTLP hops away.
           ^^^^^^^^^^^^^^^^^

in the current GIMPS design, we are moving towards trying
to eliminate that scenario if possible, and if people don't
actually want it for some other reason. (the framework allows 
it and it is difficult to eliminate, but it does lead to a 
number of problems; cf. for example the security exchange 
around Dave Oran's mail a few days back.)

robert h.

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 27 Feb 2004 10:50:08 +0100

Hi Sven,

just a general comment regarding scoping and 
stacking of QoS objects: I'd prefer NSLP to 
leave these issues to a later stage. From an 
operational point of view, they usually don't 
add value to a service but they increase 
operational complexity and can result in 
rather intransparent service delivery. 

I'd favour the first NSLP spec to support 
globally well defined QoS models only. More 
complex solutions should be added later.

Regards, Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 27 Feb 2004 10:19:42 -0000

hi,

> From: Geib, Ruediger [mailto:[email-masked]]
> Sent: Friday, February 27, 2004 09:50
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping
> 
> 
> Hi Sven,
> 
> globally well defined QoS models only. 

Which ones would those be?
(And I assume you mean "globally well defined
and universally supported".)
This is the root of the complexity (as was
discussed in the meeting in Minneapolis IIRC.)

robert h.

> More

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 27 Feb 2004 11:58:26 +0100

Robert,

|Which ones would those be?

Assume one of those to be stacked - seriously,
I think the aspect of missing QoS models 
applies whether you assume there to be just 
one or a bunch of them.

|(And I assume you mean "globally well defined
|and universally supported".)

"Globally well defined" will do. I'm happy to 
deploy NSIS in a single domain and learn how to 
operate it before I go for interworkings, 
mappings and such things. And I doubt 
that other carriers will have a different view.

Regards, Rüdiger

---

From: [email-masked]
Date: Fri, 27 Feb 2004 12:16:16 +0100

Hi Ruediger,

Thanks for your comment (and also for expressing your opinion on the open
issue). I agree with you that we should not make the specification overly
complex. I do think that it is good to have these discussions now though,
in order to avoid confusion on what is done in QoS NSLP and what could be
done. At the very least, it won't hurt to have a list of things that we
feel are desirable, although maybe not initially or in every deployment.

Best regards,
Sven

"Geib, Ruediger" <[email-masked]> on 27/02/2004 10:50:08

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    [email-masked]
Subject:    RE: [NSIS] RE: QoS NSLP open issue on region scoping

Hi Sven,

 Regards, Rüdiger

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 27 Feb 2004 15:17:42 +0100

Hello Robert

I would prefer the globally well defined solution, 
but I'm not sure whether I'll see in my lifetime.
So I'm with you in saying that NSLP should 
allow stacking. My point is that stacking, scoping 
and other features adding complexity will add delay 
in finishing the standard while the will not be 
used during initial operation. Why not standardise 
a simple protocol first and fast, debug it during 
operation and then continue with something more 
demanding? I know that standardisation often works 
the other way around: Do a complex specification 
of which a subset will be implemented and made 
operational. Are you really sure that there's a 
carrier demand for stacking with the roll out of 
NSLP products?

Regards, Rüdiger

|> |Which ones would those be?
|> 
|> Assume one of those to be stacked - seriously,
|> I think the aspect of missing QoS models 
|> applies whether you assume there to be just 
|> one or a bunch of them.
|
|that's quite right - however, if you insist on
|no stacking and the ability to have end to end
|qos signalling (without suffering from arbitrary
|rewriting) then the likelihood of a missing qos
|model becomes larger (a more serious and hard-to-
|recover-from-problem), unless you believe there
|will be one QoS model for the whole internet
|(which I don't).

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 27 Feb 2004 14:27:56 -0000

hi,

i would not like to say how much confidence i have
or how little (although i do detect interest increasing
rather than decreasing).

the key point you raise is that of whether the flexibility
implied causes a significant delay to the completion of
the standard. at the moment, my impression is that the
additional complexity can be made small, provided that we
keep awareness of the issue (as we have on the error handling
question, where i agree, significant additional complexity
could have been introduced, but wasn't.)

i'm sure that initial implementations, tests and trials will
be done with simpler subsets; standardisation can be continued
in parallel. that's how the ietf works (at least, that's the
mythology of how the ietf works...)

r.

> Sent: Friday, February 27, 2004 14:18
> To: Hancock, Robert
> Cc: [email-masked]

---

From: Attila Báder (IJ/ETH)<[email-masked]>
Date: Fri, 27 Feb 2004 16:30:36 +0100

Hi Rüdiger and Robert,

I think everybody would like to have a simple implementation and model. The problem is that we want different ones and this is one of the reasons of generality. I also have negative feelings about complexity. Specifying individual QoS models also aims to solve this problem. 

Best regards, Attila

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Geib,
Ruediger
Sent: Friday, February 27, 2004 3:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [NSIS] RE: QoS NSLP open issue on region scoping

Hello Robert

Regards, Rüdiger

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.