Re: [rsvp-dir] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03

Bob Briscoe <bob.briscoe@bt.com> Tue, 20 November 2012 21:25 UTC

Return-Path: <bob.briscoe@bt.com>
X-Original-To: rsvp-dir@ietfa.amsl.com
Delivered-To: rsvp-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9AC21F8815 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.467
X-Spam-Level:
X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OW4cNCisEBJ0 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:46 -0800 (PST)
Received: from hubrelay-rd.bt.com (hubrelay-rd.bt.com [62.239.224.99]) by ietfa.amsl.com (Postfix) with ESMTP id BFF0F21F8787 for <rsvp-dir@ietfa.amsl.com>; Tue, 20 Nov 2012 13:25:45 -0800 (PST)
Received: from EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) by EVMHR68-UKRD.bt.com (10.187.101.23) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:25:44 +0000
Received: from rdw02134app71.domain1.systemhost.net (193.113.234.138) by EVMHR02-UKBR.domain1.systemhost.net (193.113.108.41) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 20 Nov 2012 21:25:43 +0000
Received: from cbibipnt08.iuser.iroot.adidom.com (147.149.100.81) by rdw02134app71.domain1.systemhost.net (10.36.6.87) with Microsoft SMTP Server id 14.2.309.2; Tue, 20 Nov 2012 21:25:37 +0000
Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1353446735337; Tue, 20 Nov 2012 21:25:35 +0000
Received: from MUT.jungle.bt.co.uk ([10.215.130.204]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id qAKLPXVQ002786; Tue, 20 Nov 2012 21:25:33 GMT
Message-ID: <201211202125.qAKLPXVQ002786@bagheera.jungle.bt.co.uk>
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 20 Nov 2012 21:25:33 +0000
To: <karagian@cs.utwente.nl>
From: Bob Briscoe <bob.briscoe@bt.com>
In-Reply-To: <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl>
References: <87222982-329F-43DF-BFD8-9D3705AFE101@mimectl> <E728D0E3C41E644A96A7CCA61863BED4081DE009@xmb-aln-x12.cisco.com> <201211141251.qAECpsn0005426@bagheera.jungle.bt.co.uk> <FF1A9612A94D5C4A81ED7DE1039AB80F2ED8FEDF@EXMBX04.ad.utwente.nl> <201211151307.qAFD7RA0009392@bagheera.jungle.bt.co.uk> <50A51B8C.4010806@gmail.com> <201211152102.qAFL2BWE010641@bagheera.jungle.bt.co.uk> <50A56804.3090208@gmail.com> <201211162003.qAGK3C3s014269@bagheera.jungle.bt.co.uk> <3AC1435F-846D-44CB-8F60-1E43C572AA0B@mimectl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_287273207==.ALT"
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158
Cc: rsvp-dir@ietfa.amsl.com, anuragb@cisco.com, tsvwg@ietf.org, pcn@ietf.org, tom.taylor.stds@gmail.com
Subject: Re: [rsvp-dir] [PCN] Redundant aggregate reservations: draft-ietf-tsvwg-rsvp-pcn-03
X-BeenThere: rsvp-dir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RSVP directorate <rsvp-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rsvp-dir>
List-Post: <mailto:rsvp-dir@ietf.org>
List-Help: <mailto:rsvp-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rsvp-dir>, <mailto:rsvp-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2012 21:25:47 -0000

Georgios,

See the discussion with Tom - he gets what I'm saying.

Also, in my mail that started this thread (15 november 2012 14:07) I 
explained why you can get the benefits of aggregation by solely 
holding the concept of IEAs on the PCN-boundary nodes, without 
identifying an aggregate in the signalling protocol at all.

I also explained why identifying an aggregate in the signalling 
protocol led to three worse properties and nothing better.

Please argue with that, rather than talking about aggregates only in 
conceptual terms - and only in terms of whole RFCs, rather than 
specifics - that is where the problem stemmed from, I believe.



Bob

At 10:26 17/11/2012, karagian@cs.utwente.nl wrote:

>Hi Bob, Hi Tom,
>
>
>
>The solution that you are proposing, i.e., use of the e2e RSVP 
>(RFC2205), is in my opinion architecturally and conceptually wrong!
>
>The reason is the following!
>
>
>
>In PCN we need a signaling protocol that is able to: (1) to carry 
>information from PCN-egress-edge to PCN-ingress-edge and (2) the 
>carried information needs to be related to an aggregated state, 
>i.e., the ingress-egress-aggregate state.
>
>
>
>The e2e RSVP (RFC2205) can only support requirement (1), but is not 
>able to support (2), since the e2e RSVP carries information that is 
>associated with a per flow state maintained at the edges.
>
>
>
>Aggregated RSVP (RFC3175) and Generic Aggregated RSVP (RFC4860) can 
>support both requirements, since one of the features that are 
>supported by both is to carry objects that are associated to an 
>aggregated state maintained at the edges. In the context of PCN, the 
>aggregated state is the ingress egress aggregate state.
>
>
>
>Best regards,
>
>Georgios
>
>
>
>----------
>Van: Bob Briscoe [bob.briscoe@bt.com]
>Verzonden: vrijdag 16 november 2012 21:03
>To: Tom Taylor
>Cc: Karagiannis, G. (EWI); anuragb@cisco.com; tsvwg@ietf.org; 
>rsvp-dir@ietfa.amsl.com; PCN IETF list
>Onderwerp: Re: [PCN] Redundant aggregate reservations: 
>draft-ietf-tsvwg-rsvp-pcn-03
>
>Tom,
>
>The edge behaviour RFCs attempted to abstract over any signalling
>protcol, but I think they ended up being biased towards the ITU way
>of doing things, rather than an abstraction that encompassed both
>RACF and RSVP, which was probably too ambitious.
>
>Is you piggy-backing draft effectively what I am describing -
>piggy-backing on e2e signalling?
>
>I don't believe we need any more abstract drafts if that's what you
>mean - we need to focus on RSVP specifically now. We could perhaps
>re-boot from Francois's original draft.
>
>
>
>Bob
>
>At 22:09 15/11/2012, Tom Taylor wrote:
> >OK, I guess I see your point. I was too focussed on the calculations
> >that are done at the Decision Point.
> >
> >It makes me wonder if I should revive that piggy-backing edge
> >behaviour draft I once started.
> >
> >On 15/11/2012 4:02 PM, Bob Briscoe wrote:
> >>Tom,
> >>
> >>The RSVP message I'm proposing doesn't say "Never mind the SESSION in
> >>this message, I'm related to every flow with the same first hop". It
> >>says "These are the marking probabilities for the SESSION in this
> >>message". Then the PCN-ingress (not the message) infers that all other
> >>flows that share the same aggregate will share the same marking
> >>probability, because PCN marking on interior nodes is random and unbiased.
> >>
> >>It's a subtle distinction, but it preserves the semantics of RSVP
> >>messages, without the three disadvantages of setting up an RSVP
> >>aggregate that I mentioned.
> >>
> >>You will have seen from the rest of the message that I have not rejected
> >>the concept of aggregation, I am merely saying that the PCN-ingress and
> >>PCN-egress can hold the concept internally.
> >>
> >>
> >>Bob
> >>
> >>At 16:42 15/11/2012, Tom Taylor wrote:
> >>>I'm not sure the semantics of the PCN information -- particularly as
> >>>it relates to flow termination -- are correct without some sort of
> >>>concept of aggregation. Or can you really define an RSVP object that
> >>>has semantics "Never mind the SESSION in this message, I'm related to
> >>>every flow with the same first hop"?
> >...
>
>________________________________________________________________
>Bob Briscoe,                                BT Innovate & Design

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design