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

John E Drake <jdrake@juniper.net> Wed, 21 December 2011 00:18 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 B116E1F0C3F for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 16:18:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.566
X-Spam-Level: *
X-Spam-Status: No, score=1.566 tagged_above=-999 required=5 tests=[AWL=-0.883, 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 j8nq6gMRjKSS for <ccamp@ietfa.amsl.com>; Tue, 20 Dec 2011 16:18:34 -0800 (PST)
Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 96AAD1F0C38 for <ccamp@ietf.org>; Tue, 20 Dec 2011 16:18:34 -0800 (PST)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKTvElyq7avxP65XdqP3uxuTCR7DDU9meJ@postini.com; Tue, 20 Dec 2011 16:18:34 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Tue, 20 Dec 2011 16:17:13 -0800
From: John E Drake <jdrake@juniper.net>
To: Lou Berger <lberger@labn.net>
Date: Tue, 20 Dec 2011 16:17:12 -0800
Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgUjogIE9TUEYgT1ROIGNvbnNpZGVyYXRpb25zIHA=?= =?gb2312?B?b3N0IElFVEYgODIgKElzc3VlIDEvMik=?=
Thread-Index: Acy/bnCwzQPfNngISIKG5LO7WyxnlAAATjPQ
Message-ID: <5E893DB832F57341992548CDBB333163A54B5182B1@EMBX01-HQ.jnpr.net>
References: <B5630A95D803744A81C51AD4040A6DAA2293E672A9@ESESSCMS0360.eemea.ericsson.se> <F050945A8D8E9A44A71039532BA344D81918795F@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <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>
In-Reply-To: <4EF11904.30708@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 00:18:35 -0000


> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Tuesday, December 20, 2011 3:24 PM
> 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,
> 	As you probably know, each time we have new technology or a
> change/evolution in a technology the folks involved in the technology
> come up with a fairly technology-specific solution to their problem.
> Part of the WG process has always been looking at the technology
> specific extensions and figuring out what, if any, impact the
> technlogy-specific extensions should have on the common portion of
> GMPLS.  Prior to OTNv3, this can most recently be seen in both the
> ethernet and WSON WG work.  In these cases, WG participants triggered
> generalization of the proposed mechanisms.  This was even the case for
> Ethernet, where I was on the other side as an author and the WG
> prompted
> taking one document and making it 3.  IMO, as both a WG participant and
> co-chair (yes, this time I'm making a statement as a Chair!), this
> process is consistent, and required, by both the CCAMP's charter and WG
> procedural precedent.   It is also exactly what we, the co-chairs, said
> in our OTN discussion at IETF-78. (We mentioned defining new common
> mechanisms as part of the solution refinement stage.)

[JD]  As you probably know, I have been one of the most vocal proponents of generality/commonality/reuse since the beginning of GMPLS back in 1999 (or so). 

> 
> In this case the OTN documents are not proposing a new mechanism, but
> rather using a technology-specific approach.

[JD]  I really disagree with this characterization.  The correct statement would be that the decision to overload Switching Capability to delineate presumed intra-region (layer) boundaries is made on a switching technology basis.  It was done for packet switching, PSC 1-4, but was not done for SDH/SONET and is currently not done for OTN.

> Furthermore, in our
> discussions you proposed modifying/deprecating documented usage /
> meaning of SC Type.  I still see this as fitting within 'defining new
> common mechanisms as part of the solution refinement stage.'

[JD]  Absent PSC 1-4, the usage of Switching Capability has always been as I described.  Interestingly enough, PSC 1-4 makes a lot more sense than your proposal.  For PSC 1-4 at least the intra-region layer boundaries are under administrative control, while you are proposing to directly equate them with the underlying ODUk rates.  As an aside, why is this not a "technology-specific approach"?

And you have yet to articulate any reason why this is necessary.  I think the quote from Sergio this morning was a compelling and succinct rebuttal of its necessity. 

> 
> 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.  

> 
> > especially since rough consensus seems to already exist?
> > (I.e., the editors, authors, and contributors of the OTN routing
> > draft would seem to represent a substantial portion of the WG.)
> 
> Well if the WG used this as the sole measure, consensus could have been
> declared in Maastrict.

[JD]  The proposal developed in Maastricht was far more general than anything in base GMPLS.  The judgment articulated by the chairs in Beijing was that it was just too different from base GMPLs and that unfortunately it hadn't been thought of ten years earlier. 

> 
> Lou
> 
> PS I've noted where I'm speaking as an individual WG participant and
> where I'm expressing opinions as a Co-chair as this message contains
> both.

[JD]  Are you referring to this specific email or in general?