[Dcpel] some comments on draft-mendes-dcpel-requirements-00.txt

"Hancock, Robert" <robert.hancock@roke.co.uk> Tue, 07 March 2006 15:20 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdyp-0006YF-9I; Tue, 07 Mar 2006 10:20:07 -0500
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGdyn-0006Xt-TM for dcpel@ietf.org; Tue, 07 Mar 2006 10:20:05 -0500
Received: from rsys001x.roke.co.uk ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGdyn-0006HV-24 for dcpel@ietf.org; Tue, 07 Mar 2006 10:20:05 -0500
Received: from rsys005a.comm.ad.roke.co.uk (rsys005a []) by rsys001x.roke.co.uk (8.12.8/8.12.8) with ESMTP id k27FJcoW029291 for <dcpel@ietf.org>; Tue, 7 Mar 2006 15:19:38 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 7 Mar 2006 15:19:38 -0000
Message-ID: <A632AD91CF90F24A87C42F6B96ADE5C57EBE5F@rsys005a.comm.ad.roke.co.uk>
Thread-Topic: some comments on draft-mendes-dcpel-requirements-00.txt
Thread-Index: AcYYdS3TIGK+4Po8RAWdixxlqesEFAg0NmTAAiyauuA=
From: "Hancock, Robert" <robert.hancock@roke.co.uk>
To: <dcpel@ietf.org>
X-MailScanner-rsys001x: Found to be clean
X-MailScanner-From: robert.hancock@roke.co.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
Subject: [Dcpel] some comments on draft-mendes-dcpel-requirements-00.txt
X-BeenThere: dcpel@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mailing list for possible diffserv control plane elements WG <dcpel.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dcpel>
List-Post: <mailto:dcpel@ietf.org>
List-Help: <mailto:dcpel-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dcpel>, <mailto:dcpel-request@ietf.org?subject=subscribe>
Errors-To: dcpel-bounces@ietf.org


i've also been reading draft-mendes-dcpel-requirements-00, and
have some questions on that draft. (interestingly, not as many
as on the basics draft. maybe that's because everything i don't
understand is already covered in the basics draft.)

*) are the inter-domain aspects of the solution required to be
diffserv-independent? some parts of the requirements suggest
yes (last-but-one on page 5) whereas others seem more diffserv
specific (3rd one on page 7).

*) (1st & 3rd in section 5.3): the claims for the benefits of 
XML seem slightly out of place in a requirements proposal.

*) there seem to be several different levels of 'state' information
governing an inter-domain relationship. we have policies, 
agreements (is this a synonym for SLA?), SLSs (some people use
this as a term for a part of an SLA, is that the implication here?),
and at the end of 5.3 there is the concept of activating an
agreement (so as well as just existing or not, an agreement can
have some kind of dynamic status). is this hierarchy fixed or can
there be arbitrary levels of it? is all of it in scope for the DCPEL
inter-domain definition, or are (for example) the policies considered
a purely out-of-band/upper-layer issue?

*) (1st & 2nd in section 5.4): the assumption of a fixed/well-known
address (even if it's for a virtual entity) seems over restrictive
in a requirements document. It's a possible solution, but not the
only one. (If it's a must, then it's reasonable to ask by what 
mechanism the address becomes well known in the first place.)


robert h.

> hi,
> i've been reading draft-vandenberghe-dcpel-basics-00.txt and
> draft-mendes-dcpel-requirements-00. i have some comments/questions on
> the first. leaving aside minor comprehensibility nits, my 
> main questions
> are about trying to understand the scope in a bit more concrete terms.
> this email got rather long; sorry for that.
> r.
> 1. What is a "traffic aggregate"?
> This term is given in section 2, as the generalisation of a behaviour
> aggregate (which applies to a link) to a network. What I don't
> understand is the nature of the generalisation - does a traffic
> aggregate apply to a sequence of links along a path, or to all traffic
> within a network? (Both possibilities are listed in the previous
> section.) 
> These would seem to me to be rather different concepts, 
> especially once
> routing interactions are taken into account. The first is can 
> be defined
> quite precisely by giving a specific (ingress, egress); for 
> the second,
> is one expecting ({set of ingresses}, {set of egresses}), or {set of
> edge nodes}, or just to say 'all traffic passing a given AS'? Does a
> traffic aggregate have a direction? Would a service description
> assume/define particular traffic patterns within the 
> aggregate, or would
> arbitrary distributions be expected? If there is a change in external
> connectivity (e.g. a BGP route switches from one egress to another) is
> the definition of the aggregate supposed to change, or are 
> you supposed
> to renegotiate for a new aggregate?
> [The reason I ask is that there seems to be a big spectrum of 
> complexity
> here in the range of possible sophistication of aggregate definition.
> And I'm not sure where the scope boundary is supposed to be.]
> Section 4.1 includes the phrase "There must be a non-path-specific
> option." but I can't tell what this means - does it refer to 
> signalling
> mechanisms or to the definition of traffic aggregates themselves?
> 2. Interior vs. edge vs. exterior
> The document seems to distinguish three different aspects of 
> a DiffServ
> network, but I'm not sure how they relate and/or overlap.
> - There is a fairly consistent message that the 'internals' of the
> network should not be exposed externally
> - There is a discussion of developing or being consistent with a
> universal inter-domain interface (which would presumably be 
> independant
> of these 'internals')
> On the other hand, there are several places where it's asserted that
> certain sorts of operations should affect only edge and not interior
> nodes. This seems to be something that does more than just scope the
> problem but describes some fundamental aspect of the solution; does it
> mean that the edge nodes and interior nodes are going to be
> distinguished in some architectural sense? For example, does this
> distinction between edge and interior count as an aspect of the
> 'internals' which should not be exposed?
> 3. Role of PDBs and service descriptions
> [This may all be clear to people with a longer DS background than me.]
> I got continually confused by the relationship between PDBs and
> services. PDBs apparently define the treatment that a set of packets
> will receive from a DS domain; that sounds like a service to 
> (certainly
> in the way that IntServ talks about service elements). Elsewhere the
> document indicates that multiple services might use (implement?
> provide?) the same PDB, but with different policy constraints, which
> implies that 'service' means something more like an SLS (e.g. in the
> Tequila sense). It might be nice to have a definition of 'service' and
> some examples.
> A particular way of posing the question: would PDBs be visible in the
> inter-domain interface of a DS domain (e.g. as part of a service
> description)? If so, how would the use of PDBs to describe packet
> treatment relate to other syntax for describing packet treatment (e.g.
> ITU based)? Or are PDBs purely 'internal' language for a DCP to use in
> intra-domain communication between the various DCP elements? For
> example, the requirements draft indicates that the same inter-domain
> control interface should be applicable to non-DiffServ domains, which
> presumably wouldn't use PDBs at all.
> 4. SIP interactions
> I was confused by two aspects of the interaction with SIP.
> - SIP is mentioned as a possible instantiation of the inter-domain
> control mechanism, but I don't see how it would be relevant. 
> If the idea
> is to piggyback the DifS signalling for a given flow on the SIP
> exchanges for a flow, this would imply that there is a constraint that
> the SIP signalling path and traffic path are the same (at the domain
> level), which does not need to be true. If the idea is to have totally
> different SIP interactions, I'm not clear how much of the SIP protocol
> machinery is relevant to the DCP problem space.
> - So far as I can tell, assuming that application interactions are
> handled by 3312 (SDP preconditions) is quite valid, but also 
> means that
> there is no further relevance to the DCP work. As far as I understand,
> 3312 allows application endpoints to agree with each other which
> endpoint is taking responsibility for resource configuration, but the
> logic of the detailed interactions between the resource configuration
> and SIP/SDP signalling is internal to those endpoints. In other words,
> the fact that 3312 is being used should be entirely transparent to the
> resource configuration mechansisms between the endpoints. (But 4.2
> implies there is some specific work to be done here.)
> 5. Is development of signalling protocols in scope or not?
> 4.1.2 says that "...definition of an interdomain QoS 
> signaling protocol
> is considered as future work for the proposed DCPEL WG", but 4.2 only
> lists interworking with existing protocols. This seems contradictory.
> _______________________________________________
> Dcpel mailing list
> Dcpel@ietf.org
> https://www1.ietf.org/mailman/listinfo/dcpel

Dcpel mailing list