Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps

Rajan Rao <rrao@infinera.com> Thu, 14 November 2013 19:40 UTC

Return-Path: <rrao@infinera.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 CEBF321F9A5F for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 11:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.164
X-Spam-Level:
X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[AWL=1.762, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
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 ypukcxnzECjL for <ccamp@ietfa.amsl.com>; Thu, 14 Nov 2013 11:40:31 -0800 (PST)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id BC2A311E815E for <ccamp@ietf.org>; Thu, 14 Nov 2013 11:40:23 -0800 (PST)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 11:40:23 -0800
From: Rajan Rao <rrao@infinera.com>
To: Fatai Zhang <zhangfatai@huawei.com>, "Zafar Ali (zali)" <zali@cisco.com>, Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Thread-Topic: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps
Thread-Index: AQHO39qevncxijBo0UmaV7bdN2QsUpoi71AAgABJbQCAAAUaAIAB2g/A
Date: Thu, 14 Nov 2013 19:40:22 +0000
Message-ID: <650AA355E323C34D9D4AAEED952E053D3FC14C70@SV-EXDB-PROD1.infinera.com>
References: <F82A4B6D50F9464B8EBA55651F541CF85CA8C572@SZXEMA504-MBS.china.huawei.com> <CEA883F5.83255%zali@cisco.com> <F82A4B6D50F9464B8EBA55651F541CF85CA8C650@SZXEMA504-MBS.china.huawei.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF85CA8C650@SZXEMA504-MBS.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.100.96.93]
Content-Type: multipart/related; boundary="_004_650AA355E323C34D9D4AAEED952E053D3FC14C70SVEXDBPROD1infi_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] Comment on compatibility in 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, 14 Nov 2013 19:40:35 -0000

Zafar & draft authors

Perhaps it will be useful if you clarify which of the following cases you are looking at. May be all, but it is not clear in your doc.


1.      Linear protection no APS:  SNC/I, SNC/S, SNC/N

2.      Linear protection with APS:  SNC/I, SNC/S, SNC/N

a.      Uni-dir switching & reversions

b.      Bi-dir switching & reversions

3.      Revertive and non-revertive restorations

The linear protection schemes allow independent configuration of revertive, non-revertive, WTR, etc at head & tail ends.   From the draft and this chain it appears that you are trying to cover case (1) only.   May be you should clarify which case(s) will benefit from the proposed extn’s & how.

Thx
Rajan

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Fatai Zhang
Sent: Tuesday, November 12, 2013 10:44 PM
To: Zafar Ali (zali); Dieter Beller
Cc: CCAMP
Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps

Hi Zafar,

The operator can just click a button to configure it, otherwise how the ingress knows what to tell the egress.

I don’t think it is smart to send signaling to do this.

BTW,  there were much discussion on what should be configured and what should be signalled in SG15 ITU-T.

Best Regards

Fatai

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, November 13, 2013 2:26 PM
To: Fatai Zhang; Dieter Beller
Cc: CCAMP
Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps



From: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>
Date: Tuesday, November 12, 2013 9:02 PM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, Dieter Beller <Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps

Hi Zafar,

I will NEVER say NERVER.

I think you need justify why it needs to signal the attributes, which only matter to the end-points.


Fatai-

Ingress needs to let egress node know on how it is using protection (e.g., if protection is revertive or non-revertive, etc.). See also my email in response to Deiter question.

Thanks

Regards … Zafar



Best Regards

Fatai

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, November 13, 2013 3:07 AM
To: Fatai Zhang; Dieter Beller
Cc: CCAMP
Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps


From: Fatai Zhang <zhangfatai@huawei.com<mailto:zhangfatai@huawei.com>>
Date: Monday, November 11, 2013 9:04 PM
To: Dieter Beller <Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com>>, zali <zali@cisco.com<mailto:zali@cisco.com>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps

Hi,

Moreover, this information is only make sense for the end points and no need to be signaled.



Fatai-

Are you saying that we NEVER signal any attribute that only matter to the end-point? This is a news to me.

Thanks

Regards … Zafar



Best Regards

Fatai

From:ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org> [mailto:ccamp-bounces@ietf.org] On Behalf Of Dieter Beller
Sent: Sunday, November 10, 2013 10:08 PM
To: Zafar Ali (zali)
Cc: CCAMP
Subject: Re: [CCAMP] Comment on compatibility in draft-takacs-ccamp-revertive-ps

Hi Zafar,

this draft is defining signaling extensions for the hold-off time as well as the wait-to-restore time for protected LSPs
where applicable.

There are default values set for these timers in the data plane and signaling them in the control plane makes only
sense if the timer values shall differ from the default values. Do you see a need for that? IMO, operators typically
use the defaults and do not set these values on a per connection basis.


Thanks,
Dieter


On 08.11.2013 22:11, Zafar Ali (zali) wrote:

Hi Lou-



You are right, the ctype is TBD, like I mentioned during the meeting that

we are using different ctype.



We would like to take this opportunity to solicit comments from the WG on

this draft.



Thanks



Regards Š Zafar



-----Original Message-----

From: "lberger@labn.net"<mailto:lberger@labn.net> <lberger@labn.net><mailto:lberger@labn.net>

Date: Thursday, November 7, 2013 6:17 PM

To: zali <zali@cisco.com><mailto:zali@cisco.com>, "ccamp@ietf.org"<mailto:ccamp@ietf.org> <ccamp@ietf.org><mailto:ccamp@ietf.org>

Subject: Comment on compatibility in draft-takacs-ccamp-revertive-ps



Zafar,

   My comment in today's session was that you are redefining the format of

an existing object (by adding TLVs) this breaks compatibility.  You

stated that this wasn't the case.



FWIW:



Your document says:



   0                   1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |            Length             | Class-Num(37) |   C-Type(2)   |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |S|P|N|O| Reserved  | LSP Flags |      Reserved     | Link Flags|

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |I|R|   Reserved    | Seg.Flags |           Reserved            |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  |                                                               |

  ~                           sub-TLVs                            ~

  |                                                               |

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





RFC4872 says

     0                   1                   2                   3

     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |            Length             | Class-Num(37) | C-Type (2)    |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |S|P|N|O| Reserved  | LSP Flags |     Reserved      | Link Flags|

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |                           Reserved                            |

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Perhaps you meant C-Type(TBD).  You should address compatibility

explicitly in any case.



Lou



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp

--
[cid:image001.jpg@01CEE129.300F9780]
DIETER BELLER
ALCATEL-LUCENT DEUTSCHLAND AG
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
IP ROUTING AND TRANSPORT BL
IP TRANSPORT BU

Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874
Dieter.Beller@alcatel-lucent.com<mailto:Dieter.Beller@alcatel-lucent.com>

Alcatel-Lucent Deutschland AG
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Andreas Gehe

This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.