Subject: [NSIS] making progress on QoS NSLPs

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 11 Jul 2003 15:41:42 +0200

John, all,

after having read draft-buchli-nsis-nslp and draft-mcdonald-nsis-qos-nslp I asked myself whether we shouldn't draft QoS-NSLP requirements before we start to work on solutions. If we can agree to proceed with a QoS NSLP requirements draft, I'd further appreciate to separate "mandatory" and "nice to have" features.

Some impressions I've collected:
draft-buchli-nsis-nslp is rather general and leaves open many questions (security and aggregation, to name two).
draft-mcdonald-nsis-qos-nslp suggests a flexible (and complex) generic qos signaling protocol. It contains information on security (relation to the remainder of the document is not clear) and aggregation (suggests e.g. IP in IP tunnels, if I got that correctly). It supports options like service & resource negotiation and service mapping. I'd prefer to see some application developer/ISP demand for these before they get part of a protocol. This is not to say that I'd object to a protocol which may be extended to support them.

I'm currently not looking for a detailed discussion on either document. I'm aware of the westberg-nslp draft which I'll try to read before the meeting.

Regards & see you in Vienna, 

Rüdiger  

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

---

From: [email-masked]
Date: Fri, 11 Jul 2003 17:04:19 +0300

Hi Rüdiger,
I ugh that may be a good point. Let's discuss this in Veinna. I favour focussing on a limited set of features.

John

-- original message --
Subject:	[NSIS] making progress on QoS NSLPs
From:	"ext Geib, Ruediger" <[email-masked]>
Date:		11th July 2003 3:41:42 pm

John, all,

Rüdiger

---

From: "Hancock, Robert" <[email-masked]>
Date: Fri, 11 Jul 2003 17:25:18 +0100

john, ruediger,

I also suspect it's a bit late for a starting a detailed
discussion on the mailing list. However, some of the points here
are interesting because they match the open issues which we
have been identifying internally.

The main issue raised is about flexibility/genericity. I'd stress
that in draft-mcdonald-nsis-qos-nslp we didn't set out to build
a complex protocol, we set out to build a simple protocol that
could be used in complex ways if network engineers wanted to do
so. So, there's no protocol element specifically for service mapping
or negotiation (for example), and only minimal resource negotiation;
however, if you want to use these facilities in a complex way, that's
up to the definition of the QoS model in use and the energy of the
implementor. In layering terms, this means we have a 'thin' (and
flexible) NSLP, which could support thin or thick QoS models.
Other people have taken the opposite approach, of having an NSLP
which defines a more detailed and rich abstraction of QoS signalling,
and a thinner QoS model definition above.

What would I say are the major sources of complexity? In order, they
are probably:

*) the fact that we don't want to hard code a definition of what QoS
is and how it should be requested and reserved (what we call a
"QoS model" in the draft). The unknown nature of the QoS model prevents
us leaving things out. For example, if we knew that QoS was always
described by something with the properties of a 2205 Tspec and that
the signalling pattern was OPWA (like RSVP) or just one-pass sender
initiated, this would make the description of possible protocol operation
*far* simpler (even though the protocol itself might not change much). Not
specfiying a single QoS model is I think a (sensible) charter
restriction, but the consequence is flexibility (and maybe complexity)
in the protocol.

*) supporting sender and receiver initiation and proxy operation. This
comes basically from the requirements.

*) supporting stateless interior nodes robustly. 

Aggregation (we looked at general tunnel support as well as 3175-style
aggregation) as well as route change support in the end didn't seem so
complex - what is in the draft are examples of how the base protocol can be
used
to support these functions, there is very little specific needed for them.

BTW, I'm not really clear why we would want something different from 
the current WG document as a requirements draft for the QoS NSLP. After all,
one of the main complaints about the overall req. draft was that it was too
specific
to QoS in the first place.

[I recall, after our 20-hour side meeting on NSIS requirements 
at IETF#53, joking that we might still be having the same discussion the
next time we were back in Minneapolis. Maybe that was premature.]

cheers,

robert h.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, July 11, 2003 15:04
> To: ext Geib, Ruediger
> Cc: [email-masked]
> Subject: RE: [NSIS] making progress on QoS NSLPs
> 
> 
> 
> Hi Rüdiger,
> I ugh that may be a good point. Let's discuss this in Veinna. 
> I favour focussing on a limited set of features.
> 
> John
> 
> -- original message --
> after having read draft-buchli-nsis-nslp and 
> draft-mcdonald-nsis-qos-nslp I asked myself whether we 
> shouldn't draft QoS-NSLP requirements before we start to work 
> on solutions. If we can agree to proceed with a QoS NSLP 
> requirements draft, I'd further appreciate to separate 
> "mandatory" and "nice to have" features.
> 
> draft-buchli-nsis-nslp is rather general and leaves open many 
> questions (security and aggregation, to name two).
> draft-mcdonald-nsis-qos-nslp suggests a flexible (and 
> complex) generic qos signaling protocol. It contains 
> information on security (relation to the remainder of the 
> document is not clear) and aggregation (suggests e.g. IP in 
> IP tunnels, if I got that correctly). It supports options 
> like service & resource negotiation and service mapping. I'd 
> prefer to see some application developer/ISP demand for these 
> before they get part of a protocol. This is not to say that 
> I'd object to a protocol which may be extended to support them.
> 
> I'm currently not looking for a detailed discussion on either 
> document. I'm aware of the westberg-nslp draft which I'll try 
> to read before the meeting.
>

---

From: [email-masked]
Date: Fri, 11 Jul 2003 19:28:26 +0300

Robert,

> specific to QoS in the first place.

What I think is that the documenting process of the Q-NSLP should
have in the introduction a crisp set of features that it supports.
I don't think a seperate draft will serve any purpose.

John
�Ȭ����x%��g�+"z��m��?�0�'�~���f��f��X��)ߣ��