Re: [CCAMP] IETF 89 Draft Agenda Posted

"Zafar Ali (zali)" <zali@cisco.com> Tue, 25 February 2014 18:01 UTC

Return-Path: <zali@cisco.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04A391A0158 for <ccamp@ietfa.amsl.com>; Tue, 25 Feb 2014 10:01:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Level:
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L39lLwZ0OXaU for <ccamp@ietfa.amsl.com>; Tue, 25 Feb 2014 10:01:09 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id A61571A0294 for <ccamp@ietf.org>; Tue, 25 Feb 2014 10:01:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2677; q=dns/txt; s=iport; t=1393351269; x=1394560869; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bwSZfYjmQPPoGQp31Eelt9/ghG0c/pSiah9RI3PLwDE=; b=H+Jj/KKuVEnolZ3HC0PWVHUwdNG3FC6eQtAHbNfyhux5pRC4bwCLeDpS 4iP5MskhdPWcFPdopz1GUoTRTItWzAs6dTlA4tiaL3AiOY5pR6nQbj1nT vtqdj4RO9rqPWcGvnTl4AHuKDABvhC/x/TNbmcfH2SoUxZun43zXG9y1i o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAEDZDFOtJV2b/2dsb2JhbABZgwaBEsFRgRgWdIIlAQEBBHkMBgEIEQMBAQEoORQJCAIEAQ0FG4dqx1kXjiJCBwaEMgEDmDSSJ4MtgWpA
X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="306431715"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 25 Feb 2014 18:01:08 +0000
Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1PI18hW026934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 18:01:08 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 12:01:08 -0600
From: "Zafar Ali (zali)" <zali@cisco.com>
To: John E Drake <jdrake@juniper.net>, Fatai Zhang <zhangfatai@huawei.com>, Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, Gert Grammel <ggrammel@juniper.net>, Lou Berger <lberger@labn.net>, CCAMP <ccamp@ietf.org>
Thread-Topic: [CCAMP] IETF 89 Draft Agenda Posted
Thread-Index: AQHPLCuRacn1lZN6r02FA/rGxEZ02Zq8VIKAgADGJoCAB+bCgIAAOokAgAAsc4CAACJNgIAAnS0AgAAJboCAACEZgIAADfkA
Date: Tue, 25 Feb 2014 18:01:07 +0000
Message-ID: <CF322F81.9C7B5%zali@cisco.com>
In-Reply-To: <8d07051bad86445d92e28aee6fe6e57c@BLUPR05MB562.namprd05.prod.outlook.com>
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.86.243.19]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <4A3F8E57B673F94E9E1298DCA804A506@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/uZntxEZ2hfgOtUMw3bC86gQXwj0
Cc: Alia Atlas <akatlas@juniper.net>
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 25 Feb 2014 18:01:12 -0000

Hi John- 

Please see in-line.

Thanks

Regards Š Zafar


-----Original Message-----
From: "jdrake@juniper.net" <jdrake@juniper.net>
Date: Tuesday, February 25, 2014 7:14 AM
To: Fatai Zhang <zhangfatai@huawei.com>, Daniele Ceccarelli
<daniele.ceccarelli@ericsson.com>, Gert Grammel <ggrammel@juniper.net>,
"lberger@labn.net" <lberger@labn.net>, "ccamp@ietf.org" <ccamp@ietf.org>
Cc: Alia Atlas <akatlas@juniper.net>
Subject: Re: [CCAMP] IETF 89 Draft Agenda Posted

>Fatai,
>
>Comments inline.
>
>Yours Irrespectively,
>
>John
>
>> -----Original Message-----
>> From: Fatai Zhang [mailto:zhangfatai@huawei.com]
>> Sent: Tuesday, February 25, 2014 2:16 AM
>> To: Daniele Ceccarelli; Gert Grammel; John E Drake; Lou Berger; CCAMP
>> Cc: Alia Atlas
>> Subject: RE: [CCAMP] IETF 89 Draft Agenda Posted
>> 
>> Hi all,
>> 
>> I think the network planning (including N node disjoint paths computed
>> concurrently) is very important (we all agree),
>
>[JD]  Concurrent disjoint path computation is not a network planning
>function.  Rather, it is a real-time service offered by the provider
>network   
>
>> but it is also very important and
>> valuable to find disjoint paths sequentially. e.g, a path without
>>protection
>> needs to be upgraded to 1:1 or 1+1 protection, in this case, it needs
>>to exclude
>> the existing path during path setup process. Another example from
>>Zafar, a
>> new service maybe needs to be disjoint from an existing one based on the
>> management purpose.
>
>[JD]  This is the point I made yesterday.  We have a multiplicity of
>solutions but we don't have an agreed upon set of diversity uses cases.

Daniele, et al can keep me honest here.


draft-ceccadedios-ccamp-overlay-use-cases has a section on it. There is
also some text which was not incorporated due to deadline pressure. Plan
is to have draft-ceccadedios-ccamp-overlay-use-cases-05 published in IETF
week. 

>In your example, I could see requesting disjoint paths initially but
>establishing them sequentially, separated by an arbitrary time interval.

Only if SP know that diversity is required at the time service(s) is(are)
created. E.g., when service X was created at time t0, it was not known
that a service Y will be deployed at time t1, requiring the diversity.
Same for upgrade of unprotected service to protected service use case
Fatai mentioned. 

Even when all diversity requirements are known at t0, where do you propose
to run the concurrent Path computation? Please take your favorite example
of remote dual homed UNI (Fig. 5 in
draft-ceccadedios-ccamp-overlay-use-cases).

><snip>