Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01
fu.xihua@zte.com.cn Mon, 08 November 2010 10:49 UTC
Return-Path: <fu.xihua@zte.com.cn>
X-Original-To: ccamp@core3.amsl.com
Delivered-To: ccamp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6520D3A69AA; Mon, 8 Nov 2010 02:49:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.748
X-Spam-Level:
X-Spam-Status: No, score=-95.748 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE2drRFxOt1b; Mon, 8 Nov 2010 02:49:02 -0800 (PST)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 187E23A68BF; Mon, 8 Nov 2010 02:49:00 -0800 (PST)
Received: from [10.34.0.130] by mx5.zte.com.cn with surfront esmtp id 35101461793122; Mon, 8 Nov 2010 18:47:50 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 45979.8179521137; Mon, 8 Nov 2010 18:45:24 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id oA8AnMIQ013292; Mon, 8 Nov 2010 18:49:23 +0800 (CST) (envelope-from fu.xihua@zte.com.cn)
In-Reply-To: <D89B562FE4A5B341B18808FB8441CC7C0FEB050E@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com>
To: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <pietro_vittorio.grandi@alcatel-lucent.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFC0B72682.9A5823F1-ON482577D5.0039564C-482577D5.003B6967@zte.com.cn>
From: fu.xihua@zte.com.cn
Date: Mon, 08 Nov 2010 18:49:01 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2010-11-08 18:49:06, Serialize complete at 2010-11-08 18:49:06
Content-Type: multipart/alternative; boundary="=_alternative 003B692D482577D5_="
X-MAIL: mse2.zte.com.cn oA8AnMIQ013292
Cc: "Ashok@core3.amsl.com" <Ashok@core3.amsl.com>, Snigdho Bardalai <SBardalai@infinera.com>, "Ong, Lyndon" <Lyong@Ciena.com>, Khuzema Pithewan <kpithewan@infinera.com>, "ccamp@ietf.org" <ccamp@ietf.org>, ccamp-bounces@ietf.org
Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 08 Nov 2010 10:49:05 -0000
Hi Pietro, For your following statement, please refer to the liaison from ITU-T Q12. Operator do need the multi stage multiplexing. It focuses on how you provide the multi stage multiplexing capability in low cost. I don't agree that any routing extension drafts can force operator to use multi-stage multiplexing. But you have to provide a method to represent the multi-stage capability based on the deployed network. Termination and switching capabilities could not be understood. I don't see any text in draft-ceccarelli-ccamp-gmpls-ospf-g709-04. Could you give any example about how to use it? 4) Differentiation between termination and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator to engineer freely its network keeping into account capabilities offered by current technology. Current technology allows switching only a stage at once in the matrix. Of course this can be overcome with very costly muxponder boards that by the way could have limitations related to which containers can be terminated and which can be only adapted and sent to matrix for switching. In general a routing specification must not force an operator to use costly solutions (multi-stage multiplexing) in order to operate the network. As a consequence the routing specification must provide the means to allow manage the current technology indicating clearly which are the capabilities of each interface in terms of terminations and switching. Xihua Fu "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <pietro_vittorio.grandi@alcatel-lucent.com> ·¢¼þÈË: ccamp-bounces@ietf.org 2010-10-28 ÏÂÎç 04:30 ÊÕ¼þÈË Rajan Rao <rrao@infinera.com> ³ËÍ "ccamp@ietf.org" <ccamp@ietf.org>, Snigdho Bardalai <SBardalai@infinera.com>, "Ong, Lyndon" <Lyong@Ciena.com>, Khuzema Pithewan <kpithewan@infinera.com>, "Ashok@core3.amsl.com" <Ashok@core3.amsl.com> Ö÷Ìâ Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hello all, some considerations. 1) Draft Ashok states that Max LSP Bandwidth Number of OPU TSs = ------------------------- Min LSP Bandwidth This means that the MIN LSP Bandwidth is always set to the nominal size of 1 TS. So it can have only two values 1.25 and 2.5 Gbit/s. The min LSP bandwidth for IETF should instead provide the minimum switching capability. (see RFC4202) With the above relationship it seems that a NE that supporting ODU1 and higher rate containers and exporting interfaces with TS size = 1.25 Gbit/s should always declare a Min LSP Bandwidth = to 1.25Gbit/s that is not corresponding to a supported switching capability. This behavior is absolutely independent from the fact that ODU-flex is supported or not. 2) Snip: ¡°Not clear what the issue is. We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub¨CTLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn¡¯t become zero.¡± We would like first to observe that the ashok draft does not report this specific behavior. Secondary we would make note that with this approach the MAX-LSP bandwidth in any case should be interpreted differently when the ODU-flex capacity is exhausted. If you think to a bundle link with ODU-flex capacity, then when UDU-flex capacity is available the MAX-LSP bandwidth is used in a certain way whereas when the ODU-flex capacity is exhausted the ODU-flex TLV is no more advertised and MAX-LSP bandwidth behavior is different. we do not see a reason that motivates the introduction of this kind of complication in routing. 3) Snip: Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. The technology specific extensions should go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original GMPLS model. } The original idea for GMPLS has been already discussed in the frame work document draft-ietf-ccamp-gmpls-g709-framework-03. The framework is the only reference for requirements that have to be supported. Moreover, as required by CCAMP chair an example of the difference in efficiency between the original IETF format and the new format is shown in the draft draft-bccdg-ccamp-gmpls-ospf-agnostic. 4) Differentiation between termination and switching capabilities is a requirement contained in the framework document. The differentiation allows an operator to engineer freely its network keeping into account capabilities offered by current technology. Current technology allows switching only a stage at once in the matrix. Of course this can be overcome with very costly muxponder boards that by the way could have limitations related to which containers can be terminated and which can be only adapted and sent to matrix for switching. In general a routing specification must not force an operator to use costly solutions (multi-stage multiplexing) in order to operate the network. As a consequence the routing specification must provide the means to allow manage the current technology indicating clearly which are the capabilities of each interface in terms of terminations and switching. Pietro & Sergio ============================================ Pietro Vittorio Grandi Terrestrial Optics Unit - System Architecture Alcatel-Lucent Vimercate (Italy) Tel: +39 039 686 4930 Mail: pietro_vittorio.grandi@alcatel-lucent.com ============================================ Put your hand on a hot stove for a minute, and it seems like an hour. Sit with a pretty girl for an hour, and it seems like a minute. That's relativity. (A. Einstein) From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao Sent: marted¨¬ 26 ottobre 2010 21.15 To: Fatai Zhang; Daniele Ceccarelli Cc: ccamp@ietf.org; Snigdho Bardalai; Ong, Lyndon; Khuzema Pithewan; Ashok@core3.amsl.com Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Fatai, Please see response inline, within { } Thanks Rajan From: Fatai Zhang [mailto:zhangfatai@huawei.com] Sent: Tuesday, October 26, 2010 5:11 AM To: Rajan Rao; Daniele Ceccarelli Cc: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, You said there are three differences between two drafts. Now, we are coming much closer that there "may" be only one difference (i.e., backward compatibility) after Daniele gave some clarifications. Your draft introduces a new sub-TLV SCSI and [draft-ceccarelli] introduces Generalized-ISCD sub-TLV, so I think they have the same backward compatibility, although it seems like that your draft "could" support backward compatibility. Moreover, there are some disadvantages to use the existing ISCD +SCSI. Firstly, as Daniele already pointed it out, it is a big issue to advertise that Max LSP bandwidth is 0 in the case of non-ODUflex supported for Node B/C, however, for Node A(G.709 V1), it must always advertise a meaningful value for the Max LSP bandwidth. {Rajan] { Not clear what the issue is. We have listed 2 approaches in the slides sent out yesterday. To reiterate the case where ODUflex is not supported: With backward compatibility option, the ODUflex goes in to a separate sub¨CTLV within SCCI. If ODUflex is not supported on a link, this sub-TLV will not be included; i.e, ISCD::Max-LSP-BW is not used for ODUflex & doesn¡¯t become zero. Please clarify if you have a different case in mind. } Secondly, You have changed the meaning of "Minimum LSP Bandwidth", which will make the path computation messed. Assume OTU2 interface that supports ODU2 switching only (an example in your draft), in this case, according to the regular routing process, it will make the routing path computation function to understand that it can support ODU0 LSP. [Rajan] { No, we have not changed the meaning of ¡°Minimum LSP BW¡±. Please elaborate on what is messed. Following RFC 4202/4201 meaning, the example you have listed works as follows: MinLSP-BW = ODU1 ( G.709-v1 supports 2.5G) MaxLSP-BW = ODU2 ( Min(unreserved-BW, configured Max LSP size) as per RFC 4202) If you are computing path for an ODU0 connection, the rule would be Odu0-LSP-BW >= MinLSP-BW && <= MaxLSP-BW The computation fails for the above. Where is it messed? Please provide a concrete example. } Thirdly, it can not support priority flexibility, so it is not efficient from the routing scalability perspective. [Rajan] { The whole idea is to stay with the GMPLS architecture already in place. The technology specific extensions should go into SCSI. This has been done successfully for SONET/SDH case (Ref to examples in RFC 4202). Do not see a reason to deviation from the original GMPLS model. } Fourth, it can not differentiate termination and swiching capability for your darft. [Rajan] { We do not see a need to advertise this info. We need to understand the use cases requiring this. Are T/S bits addressing HW limitations? } I am trying to recall more reasons why we need to use a new sub-TLV rather than the existing TLV, because we had lots of discussion before IETF78th meeting through mailing list and F2F, but it is a little difficult for me to dig more things from my memory at this moment, :-)~~~~ [Rajan] { Please list the justifications for changing original GMPLS model. } Best Regards Fatai ----- Original Message ----- From: Rajan Rao To: Daniele Ceccarelli Cc: Ong, Lyndon ; ccamp@ietf.org Sent: Tuesday, October 26, 2010 7:13 AM Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Daniele, Please see response inline, within { }. Thanks Rajan -----Original Message----- From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] Sent: Friday, October 22, 2010 6:49 AM To: Rajan Rao Cc: Ong, Lyndon; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Just a couple of comments on backward compatibility and bandwidth advertisement. - Backward compatibility: no ODU advertising is definded in RFC 4202/4203, so i believe there are no backward compatibility issues. [Rajan] { Agree there is no ODU advertisement defined. The need to address backwards compatibility depends on the following: 1) are there RFC-4328 based deployments? 2) If so, what do they use for BW advertisement? Our fair guess is that ISCD is used for this as per RFC 4202/4203. There are 2 ways to address the compatibility issue ¨C either support or don¡¯t support. Based on the WG agreement we could go either way without breaking the model we have proposed. Please refer to attached slides for details. } Moreover in draft-ashok-ccamp-gmpls-ospf-g709 the MAX LSP bandwidth fields of the ISCD are used for unreserved bandwidth advertisement, this is a backward compatibility issue in my opinion. It states that: "Encoding of Max LSP Bandwidth is as follows: Max LSP Bandwidth = Unreserved-TS-Count x TS-Nominal-Rate" [Rajan] { The unit here is in Bytes/sec. The description above (& in our draft) - shows that nominal rate is dependent on specific ODU layer in question. - shows how Max LSP bandwidth number is derived at the advertising node. } Moreover it states: "If the interface does not support ODU-flex service, this value should be coded as zero". But advertising max LSP bandwidth = 0 means discarding such link in the path computation process. [Rajan] { Good question & very valid. I think you are bringing up a scenario where ODUflex is not supported but backward compatibility is required. What we need here is to separate ODUflex advertisement from ISCD::Max-LSP-BW. This can be easily accomplished with a sub-TLV for ODUflex signal type in our model. BW in bytes/sec, of course. Please refer to attached slides for details. } - Bandwidth advertisement: in the -04 version of our draft the bandwidth is advertised as follows: - Unreserved bandwidth for fixed container in number of containers - Unreserved bandwidth for oduflex in Bytes/sec - Max LSP bandwidth in Bytes/sec. [Rajan] { We believe advertising the number of containers is the right approach. This is exactly the proposal we have in our draft. Good to see that you have moved away from TS approach which had serious limitations. } Advertising the unreserved bandwidth in number of containers is the most suitable way for fixed containers (ODUk) but doesn't work with ODUflex. [Rajan] { The ODUflex uses bytes/sec in our draft. There is no disagreement here. } BR The authors -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao Sent: venerd¨¬ 15 ottobre 2010 19.13 To: Ong, Lyndon; ccamp@ietf.org Subject: Re: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Lyndon, Yes, we are aware of the existing draft. There are some fundamental differences in the model we have proposed from the existing draft. The key differences are the following: 1) This draft extends existing ISCD Vs. defining a new one - addresses backward compatibility issues (RFC 4202) 2) ODU containers are advertised instead of #TSs - simple path computation 3) Path computing node doesn't need to know per link and/or per ODU layer TS granularity - again, simple & straight forward path computation Thanks Rajan -----Original Message----- From: Ong, Lyndon [mailto:Lyong@Ciena.com] Sent: Thursday, October 14, 2010 7:45 AM To: Rajan Rao; ccamp@ietf.org Subject: RE: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi Rajan, Have you looked at draft-ceccarelli-ccamp-gmpls-ospf-g709-03.txt? It would be helpful to understand if your draft is asking for similar extensions or different functionality. Thanks, Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao Sent: Wednesday, October 13, 2010 2:40 PM To: ccamp@ietf.org Subject: [CCAMP] OSPF-TE extensions for G.709 OTN draft submitted: draft-ashok-ccamp-gmpls-ospf-g709-01 Hi, The following draft has been submitted. Please review. Comments are appreciated. https://datatracker.ietf.org/doc/draft-ashok-ccamp-gmpls-ospf-g709/ thanks Authors -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Wednesday, October 13, 2010 2:30 PM To: Rajan Rao Cc: Snigdho Bardalai; Ashok Kunjidhapatham; Khuzema Pithewan Subject: New Version Notification for draft-ashok-ccamp-gmpls-ospf-g709-01 A new version of I-D, draft-ashok-ccamp-gmpls-ospf-g709-01.txt has been successfully submitted by Rajan Rao and posted to the IETF repository. Filename: draft-ashok-ccamp-gmpls-ospf-g709 Revision: 01 Title: OSPF TE Extensions for Generalized MPLS (GMPLS) Control of G.709 Optical Transport Networks Creation_date: 2010-10-12 WG ID: Independent Submission Number_of_pages: 20 Abstract: As OTN network capabilities continue to evolve, there is an increased need to support GMPLS control for the same. [RFC4328] introduced GMPLS signaling extensions for supporting the early version of G.709 [G.709-v1]. The basic routing considerations from signaling perspective is also specified in [RFC4328]. The recent revision of ITU-T Recommendation G.709 [G.709-v3] and [GSUP.43] have introduced new ODU containers (both fixed and flexible) and additional ODU multiplexing capabilities, enabling support for optimal service aggregation. This document describes OSPF protocol extensions to support Generalized MPLS (GMPLS) control for routing services over the standardized OTU/ODU containers in support of ODU based TDM switching. Routing support for Optical Channel Layer switching (Lambda switching) is not covered in this document. The IETF Secretariat. _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp
- [CCAMP] OSPF-TE extensions for G.709 OTN draft su… Rajan Rao
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Ong, Lyndon
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Rajan Rao
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Daniele Ceccarelli
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Rajan Rao
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Fatai Zhang
- [CCAMP] R: OSPF-TE extensions for G.709 OTN draft… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Rajan Rao
- Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN d… Ashok Kunjidhapatham
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Lou Berger
- [CCAMP] R: OSPF-TE extensions for G.709 OTN draft… BELOTTI, SERGIO (SERGIO)
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
- Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN d… Lou Berger
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN - te… Rajan Rao
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN - te… John E Drake
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Rajan Rao
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN - te… GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
- Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN d… Daniele Ceccarelli
- Re: [CCAMP] R: OSPF-TE extensions for G.709 OTN d… Lou Berger
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… Rajan Rao
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… fu.xihua
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
- Re: [CCAMP] OSPF-TE extensions for G.709 OTN draf… fu.xihua