Re: [CCAMP] Objective function draft

"George Swallow (swallow)" <swallow@cisco.com> Wed, 12 September 2012 13:34 UTC

Return-Path: <swallow@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C642E21F8564 for <ccamp@ietfa.amsl.com>; Wed, 12 Sep 2012 06:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level:
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 B3FJQL8BZ7gO for <ccamp@ietfa.amsl.com>; Wed, 12 Sep 2012 06:34:47 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE721F853F for <ccamp@ietf.org>; Wed, 12 Sep 2012 06:34:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34702; q=dns/txt; s=iport; t=1347456887; x=1348666487; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=hYdarQFbpDj8RvuFEY7DMX7XJWlXEodjBUQcdJFxjBs=; b=OcyWzC/0eI/2kghsTPGDGZAHw1BwopNud2Vj9QCHGhwLu2zuiQD6Kuc2 3QGNcSjU580FPYhYgx1Uj7AAT3KQJ/nWj0jnpLdr4y2Ef031ilQNDWnpN FffVv6f70+V9yGEpRGDz2Sq+84p4hBAxbgOeIgk4WzAqEnu/3oV0FX8qB w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAOOOUFCtJV2b/2dsb2JhbABFgku4dYEHgiABAQEDARIBGkwFDQEIEQECAQEBIQEGLQwUAwYIAgQBDQQBIoVvgXYGnC+gQ4sQhkIDlV+ONoFpgmaBYzQ
X-IronPort-AV: E=Sophos; i="4.80,410,1344211200"; d="scan'208,217"; a="120794582"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 12 Sep 2012 13:34:47 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8CDYkdU029316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 13:34:46 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.216]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0298.004; Wed, 12 Sep 2012 08:34:46 -0500
From: "George Swallow (swallow)" <swallow@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Julien Meuric' <julien.meuric@orange.com>
Thread-Topic: [CCAMP] Objective function draft
Thread-Index: AQHNkFOv4OOKfbxolEe2spFvFX1LfJeGIG+AgACmagA=
Date: Wed, 12 Sep 2012 13:34:45 +0000
Message-ID: <CC7605A7.8107%swallow@cisco.com>
In-Reply-To: <03d701cd9076$a5bfbf00$f13f3d00$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.131.2.24]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005
x-tm-as-result: No--28.738400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_CC7605A78107swallowciscocom_"
MIME-Version: 1.0
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Objective function draft
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Sep 2012 13:34:48 -0000

Adrian -

I think we are quite in agreement!  The only difference is that I was using PCE  in a narrower sense of an entity that also runs PCEP.  But reading the PCE architecture document, I see that you are correct.

…George



From: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Reply-To: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Date: Tuesday, September 11, 2012 7:39 PM
To: Cisco Employee <swallow@cisco.com<mailto:swallow@cisco.com>>, Julien Meuric <julien.meuric@orange.com<mailto:julien.meuric@orange.com>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] Objective function draft

<individual contributor mode>

I'm hoping that you have looked at RFC 5623 that describes some approaches to inter-layer networking using PCE.

But it seems that perhaps you are more interested in the per-domain PCE mechanism (RFC 5152) and that you have observed that the OF that would be used in each domain to select the path is not currently available because it is missing from RSVP-TE. That seems to me to be a perfectly reasonable thing to add to RSVP-TE and I think it enables and supports the work of the PEC working group without any conflict, but I would hope that you share definitions of OFs with the PCE WG.

And one last point, when you say

> even if there is no PCE

you misunderstand the PCE architecture. If you are computing a path (in an LSR) you are de facto providing PCE functionality. There is no need in the architecture (and thus the implementation) to expose an external (PCEP) interface in order to be logically providing PCE function, and this is *exactly* why you want access to the OF.

However, you would perhaps do better to absorb this ambivalence and note that you need the OF and Metric whether or not the PCE is external.

All of which you may take as general support for your idea, but a feeling that the I-D is not happily written and deviating too much from shared context with PCE.

Cheers,
Adrian

From: ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of George Swallow (swallow)
Sent: 11 September 2012 20:29
To: Julien Meuric
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: [CCAMP] Objective function draft

Julien -

Reading the CCAMP notes (which capture little of the actual discussion) I see that there may have been a perception in the room that PCE functionality at the UNI-N was assumed (actual or proxy).

This is not the case.  The reason for our draft is that with the UNI, much of the functionality that resides at the headend is moved to the UNI-N.  So the UNI-C needs a way to express an objective function even if there is no PCE.

Operationally it seems burdensome to require a PCEP at the UNI-C and a PCEP at the UNI-N, when all that is being done is enabling the UNI-N to perform what the client would do if it were connected to the network via a normal link.

Do you still object to the draft?

Thanks,

…George