Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82 (Issue 1/2)

John E Drake <jdrake@juniper.net> Wed, 21 December 2011 14:02 UTC

Return-Path: <jdrake@juniper.net>
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 CE2F821F8A64 for <ccamp@ietfa.amsl.com>; Wed, 21 Dec 2011 06:02:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.634
X-Spam-Level: *
X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
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 zOPrAaKqJKfp for <ccamp@ietfa.amsl.com>; Wed, 21 Dec 2011 06:02:49 -0800 (PST)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 1472721F888A for <ccamp@ietf.org>; Wed, 21 Dec 2011 06:02:49 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTvHm+BqUWdGskVsGYhhMDAOCnv1P5F6g@postini.com; Wed, 21 Dec 2011 06:02:49 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Wed, 21 Dec 2011 06:02:13 -0800
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>
Date: Wed, 21 Dec 2011 06:02:12 -0800
Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgUjogIE9TUEYgT1ROIGNvbnNpZGVyYXRpb25zIHA=?= =?gb2312?B?b3N0IElFVEYgODIgKElzc3VlIDEvMik=?=
Thread-Index: Acy/4fifgUnSAV/nTiOGfADH3abQrgAA+3Yg
Message-ID: <5E893DB832F57341992548CDBB333163A54B5184AE@EMBX01-HQ.jnpr.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se> <F82A4B6D50F9464B8EBA55651F541CF825CB0593@SZXEML520-MBX.china.huawei.com> <4EDE3E19.6010303@orange.com> <F82A4B6D50F9464B8EBA55651F541CF825CC18AB@SZXEML520-MBS.china.huawei.com> <4EF0A18F.4080000@orange.com> <5E893DB832F57341992548CDBB333163A54B517AFD@EMBX01-HQ.jnpr.net> <F050945A8D8E9A44A71039532BA344D819BA8E25@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <5E893DB832F57341992548CDBB333163A54B517B62@EMBX01-HQ.jnpr.net> <5292FFA96EC22A4386067E9DBCC0CD2B010A0998FB37@EX-NAP.tellabs-west.tellabsinc.net> <4EF0B788.7020700@labn.net> <5E893DB832F57341992548CDBB333163A54B517BE2@EMBX01-HQ.jnpr.net> <4EF0C99B.4020505@labn.net> <5E893DB832F57341992548CDBB333163A54B517E4F@EMBX01-HQ.jnpr.net> <4EF0EE83.3060601@labn.net> <5E893DB832F57341992548CDBB333163A54B518072@EMBX01-HQ.jnpr.net> <4EF11904.30708@labn.net> <5E893DB832F57341992548CDBB333163A54B5182B1@EMBX01-HQ.jnpr.net> <4EF1DAC1.3020606@labn.net>
In-Reply-To: <4EF1DAC1.3020606@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: CCAMP <ccamp@ietf.org>
Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogIFI6ICBPU1BGIE9UTiBjb25zaWRlcmF0aW9u?= =?gb2312?b?cyBwb3N0IElFVEYgODIgKElzc3VlIDEvMik=?=
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, 21 Dec 2011 14:02:49 -0000

Lou,

From my perspective the generalization/normalization part of the process started in Beijing and finished in Quebec, when the OTN draft was adopted as a WG draft; the OTN draft is completely consistent with the SDH/SONET GMPLS model.

You have yet to provide a technical justification for your subsequent proposal to overload the meaning of Switching Capability to delimit intra-region layer boundaries that are congruent with ODUk bandwidths and its discussion has consumed an inordinate number of cycles.

The quote that Sergio provided yesterday from G.872 provides a very succinct explanation for why your proposal is a Bad Idea(tm):  "Since the resources that support these topological components support a heterogeneous assembly of ODUs, the ODU layer is modelled as a single layer network that is independent of bit-rate.  The ODU bit-rate is a parameter that allows the number of Tributary Slots (TS) for the ODU link connection to be determined."

The editors, authors, and contributors of the have pretty firmly rejected your proposal, so my basic question is what is the *process* for closure?  Waiting for a draft to be written that contains a rehash of the points that have already been discussed does not strike me as a *process*.

Thanks,

John

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, December 21, 2011 5:10 AM
> To: John E Drake
> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP
> Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
> 
> John,
> 	I'm a little at a loss as to what you are looking for / arguing
> about
> at the moment.  I've already said that (a) that I think we should
> "table[ing] discussion on my [OTN] proposal" and (b) I (with others)
> will submit an individual draft on the general issue.
> 
> You've stated that (b) serves no purpose nor contains any technical
> content.  Given that the draft doesn't exist at the moment, I guess
> your
> statement is technically correct at this time. Once the draft is
> submitted, I'll be happy to resume this argument based on the actual
> content of the draft.
> 
> Lou
> 
> On 12/20/2011 7:17 PM, John E Drake wrote:
> >> See below for specific responses (as a WG participant).
> >> >
> >>> > > How does the existence of this draft, which will have no new
> >>> > > information, help the chairs gauge rough consensus on this
> issue in
> >>> > > the WG,
> >> >
> >> > It depends on which issue you are talking about.  If talking about
> the
> >> > general issue as discussed above, I hope it will close it for the
> >> > future.
> >> >
> >> > If talking about my (individual, not chair) proposal of using
> multiple
> >> > SC types for OTNv3, I don't think it immediately does.  What it
> will do
> >> > is provide context for that proposal.  In the interim, I recommend
> (as
> >> > a
> >> > WG participant, not chair) tabling discussion on my proposal until
> we
> >> > know which way the general issue is resolved.
> > [JD]  The only issue is your specific proposal.
> >