Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

"BRUNGARD, DEBORAH A" <db3546@att.com> Thu, 04 April 2013 14:50 UTC

Return-Path: <db3546@att.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 20C8521F940D for <ccamp@ietfa.amsl.com>; Thu, 4 Apr 2013 07:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVdozOa81GTV for <ccamp@ietfa.amsl.com>; Thu, 4 Apr 2013 07:50:04 -0700 (PDT)
Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id E572C21F8F0E for <ccamp@ietf.org>; Thu, 4 Apr 2013 07:50:02 -0700 (PDT)
Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo06.seg.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id a139d515.2aaade823940.126023.00-599.350502.nbfkord-smmo06.seg.att.com (envelope-from <db3546@att.com>); Thu, 04 Apr 2013 14:50:02 +0000 (UTC)
X-MXL-Hash: 515d931a4db3d65e-7a8d0d6dc07b88458cc1dd3c563135a97f2331a0
Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 9139d515.0.126009.00-413.350451.nbfkord-smmo06.seg.att.com (envelope-from <db3546@att.com>); Thu, 04 Apr 2013 14:50:02 +0000 (UTC)
X-MXL-Hash: 515d931a61b03905-a9f2b15954612ce46b3dbf2b24664245e9d58143
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r34Eo08J008996; Thu, 4 Apr 2013 10:50:01 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r34EnpEB008783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Apr 2013 10:49:53 -0400
Received: from MISOUT7MSGHUB9F.ITServices.sbc.com (misout7msghub9f.itservices.sbc.com [144.151.223.71]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Thu, 4 Apr 2013 15:49:32 +0100
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9F.ITServices.sbc.com ([144.151.223.71]) with mapi id 14.02.0342.003; Thu, 4 Apr 2013 10:49:32 -0400
From: "BRUNGARD, DEBORAH A" <db3546@att.com>
To: Francesco Fondelli <francesco.fondelli@gmail.com>
Thread-Topic: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps
Thread-Index: AQHOMIyU5E5gvsW8qk+nQPJ9P69loZjGEmhw
Date: Thu, 04 Apr 2013 14:49:31 +0000
Message-ID: <F64C10EAA68C8044B33656FA214632C82AAF8F@MISOUT7MSGUSR9O.ITServices.sbc.com>
References: <CABP12JwDkUkRayvoE-orb3ZNANgDpaLqQYOyOC=pL=OFYi2Dew@mail.gmail.com> <F64C10EAA68C8044B33656FA214632C82A8BB6@MISOUT7MSGUSR9O.ITServices.sbc.com> <CABP12JxWpt39JzGsh3bxzi7imvHmRA_VJoQqra2eKaEhnQ+vmw@mail.gmail.com> <CABP12JwYTC7fEuD0gZRhOC3FFPj4-_CawDi5B8jYcBg9=DHh5Q@mail.gmail.com>
In-Reply-To: <CABP12JwYTC7fEuD0gZRhOC3FFPj4-_CawDi5B8jYcBg9=DHh5Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.16.234.214]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <db3546@att.com>
X-SOURCE-IP: [144.160.20.146]
X-AnalysisOut: [v=2.0 cv=MJHXbrll c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a]
X-AnalysisOut: [=RWEAq7CW3jcA:10 a=OIZjW_EDwrwA:10 a=ofMgfj31e3cA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=IkcTkHD0fZMA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=Axtq_jpKRe8A:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8]
X-AnalysisOut: [ a=SpezpsmYVRz-eOi4vRgA:9 a=QEXdDO2ut3YA:10 a=MSl-tDqOz04A]
X-AnalysisOut: [:10 a=lZB815dzVvQA:10 a=Hz7IrDYlS0cA:10]
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps
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: Thu, 04 Apr 2013 14:50:07 -0000

Hi Francesco,

That was a fast analysis:-)

Suggest you first expand on the requirements that you want to support vs. solution. When you detail aspects of SNC/N, SNC/I, and SNC/S, you will find that you also need OAM configuration to support (N/I/S configuration (e.g. DEG, TTI)) and you will need to configure which defects contribute to a "failure". This will all need to be coordinated with the LSP OAM configuration.

Also on SNC/N, SNC/I, and SNC/S, is this for a segment or e-2-e? The draft needs more detail and alignment with GMPLS protection terminology and mechanisms.

After having a better scope of the requirements, we can discuss the solution tradeoffs. There are always multiple ways to solve, first we need to understand what is needed.

Thanks,
Deborah

-----Original Message-----
From: Francesco Fondelli [mailto:francesco.fondelli@gmail.com] 
Sent: Wednesday, April 03, 2013 12:59 PM
To: BRUNGARD, DEBORAH A
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps

Hi Deborah, all,

>   Having said that, I have no problem rewriting [4] using OAM
> configuration TLV.  It's just weird to me but I can live with it.

  sorry, I changed my mind, I cannot use the OAM TLV.  The more I read
about OAM in IETF the more I think protection switching provisioning
is completely out-of-scope.

  I spent some hours looking for the OAM definition within the
IETF context(s).  The most recent and enlightening (to me at least)
documents I found are [A] and [B].  As far as I understand, [1] is
perfectly aligned with them.  At the same time I cannot find any
support of your statement:

> Protection switching provisioning has always been treated as a
> common equipment management functionality [cut]. So it is in scope
> of OAM configuration.

  Maybe I'm just missing something big (?) Can someone shed some light on
this?

thank you
ciao
fra

[A]
http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08

[B]
http://tools.ietf.org/html/rfc6291

On Tue, Apr 2, 2013 at 11:22 AM, Francesco Fondelli
<francesco.fondelli@gmail.com> wrote:
> On Mon, Apr 1, 2013 at 8:06 PM, BRUNGARD, DEBORAH A <db3546@att.com> wrote:
>> Hi Francesco,
>
> Hi Deborah,
>
>> While these may be protection switching parameters, this draft is about configuration of these parameters. Protection switching provisioning has always been treated as a common equipment management functionality - same as performance management and fault management (refer to G.7710 section 8). So it is in scope of OAM configuration. CCAMP's OAM configuration work has been focused on PM and FM but it is generally applicable (hopefully) to any equipment management configuration.
>
>   Puzzled.  If we follow this reasoning (i.e. common equipment management
> functionalities => should use OAM framework) then almost any aspect of
> networking can be applicable to OAM and so any operation should exploit
> the OAM framework draft.
>
>   For example, G.7710 section 8.6.1 describes the provisioning
> of cross-connections but this does not imply that we are going to use the
> OAM framework to establish label binding in the next GMPLS controlled
> technology, I guess we will continue to use LABEL_REQUEST/LABEL objects
> (plus any other relevant info).
>
>> Lou's comment is that the WG has chosen the approach used in the OAM framework document for configuration. Instead of updating the protection object at this time as your draft proposes, the question is have you considered using the OAM configuration TLV? First, we need to understand why you have chosen to not use this approach. Then we can discuss pros and cons.
>
>   Well, at the beginning we did not take it into consideration
> because [4] predate [1].  Later we did not take [1] into consideration
> simply because we thought [4] was out of OAM framework scope.
>
>   Having said that, I have no problem rewriting [4] using OAM
> configuration TLV.  It's just weird to me but I can live with it.
>
>> BR-
>> Deborah
>
> thank you
> ciao
> fra
>
>>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Francesco Fondelli
>> Sent: Monday, April 01, 2013 12:20 PM
>> To: ccamp@ietf.org
>> Subject: [CCAMP] clarification about draft-takacs-ccamp-revertive-ps
>>
>> quoting item 15, from www.ietf.org/proceedings/86/minutes/minutes-86-ccamp
>>
>> Lou Berger: I think you misunderstood my comment from the last meeting. You
>> should look at leveraging the OAM configuration work which came after the
>> earlier versions of your draft.
>> Zafar Ali: this is applicable to multiple technologies.
>> Lou Berger: yes, the OAM configuration framework is also applicable to
>> multiple technologies. You need a strong reason not to follow the WG in
>> this area. Please look at the OAM configuration document
>> [draft-ietf-ccamp-oam-configuration-fwk] and either follow it or state why
>> your work is justified in not following the existing WG solution in this
>> area.
>>
>> ---
>>
>> Hi all,
>>
>>   the OAM configuration framework [1] is about OAM.  Therefore, it is used in
>> order to signal OAM functionalities: CC/CV and PM/FM in MPLS-TP [2], CC/CV
>> TTI/SAPI/DAPI in SONET/SDH/OTN [3]... while our draft [4] is about *protection
>> switching*.  HOFF, WTR and SNC sub-type are protection switching parameters.
>>
>>   I believe HOFF, WTR and SNC sub-type are outside of the OAM configuration
>> framework scope and should be signaled as any other protection switching
>> params (i.e. via PROTECTION object).
>>
>>   I hope this answer Lou question reported above (item 15, IETF 86 ccamp
>> minutes).  Authors of [4] would like to understand WG's view about this point
>> and are soliciting for comments.
>>
>> thank you
>> ciao
>> FF
>>
>> [1]
>> http://tools.ietf.org/html/draft-ietf-ccamp-oam-configuration-fwk-09
>>
>> [2]
>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-11
>>
>> [3]
>> http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-sdh-otn-oam-ext-05
>>
>> [4]
>> http://tools.ietf.org/html/draft-takacs-ccamp-revertive-ps-08
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp