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

John E Drake <jdrake@juniper.net> Wed, 21 December 2011 17:42 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 9906021F84C5 for <ccamp@ietfa.amsl.com>; Wed, 21 Dec 2011 09:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.375
X-Spam-Level: **
X-Spam-Status: No, score=2.375 tagged_above=-999 required=5 tests=[AWL=-1.740, 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_FWDLOOK=1.666, 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 xawHMH-Wo+dG for <ccamp@ietfa.amsl.com>; Wed, 21 Dec 2011 09:42:21 -0800 (PST)
Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id D66F621F84C3 for <ccamp@ietf.org>; Wed, 21 Dec 2011 09:42:14 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKTvIadPAJxM0LT8tC7V8aPLrTMfl7Sfy9@postini.com; Wed, 21 Dec 2011 09:42:14 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 09:41:51 -0800
From: John E Drake <jdrake@juniper.net>
To: "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, Lou Berger <lberger@labn.net>
Date: Wed, 21 Dec 2011 09:40:19 -0800
Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgUjogIE9TUEYgT1ROIGNvbnNpZGVyYXRpb25zIHA=?= =?gb2312?B?b3N0IElFVEYgODIgKElzc3VlIDEvMik=?=
Thread-Index: Acy/bnCwzQPfNngISIKG5LO7WyxnlAAATjPQACIjsQAAA5Y4EA==
Message-ID: <5E893DB832F57341992548CDBB333163A54B51869D@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> <5E893DB832F57341992548CDBB333163A54B5182B1@EMBX01-HQ.jnpr.net> <5292FFA96EC22A4386067E9DBCC0CD2B010A09A517B7@EX-NAP.tellabs-west.tellabsinc.net>
In-Reply-To: <5292FFA96EC22A4386067E9DBCC0CD2B010A09A517B7@EX-NAP.tellabs-west.tellabsinc.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 17:42:22 -0000

Jonathan,

The definitions in Switching Capability and Encoding Type were attempts to be forward looking; AKA "everything but the kitchen sink" 8->.   

I think you raise a very good point regarding namespace exhaustion.

Thanks,

John

> -----Original Message-----
> From: Sadler, Jonathan B. [mailto:Jonathan.Sadler@tellabs.com]
> Sent: Wednesday, December 21, 2011 8:50 AM
> To: John E Drake; Lou Berger
> Cc: BELOTTI, SERGIO (SERGIO); CCAMP
> Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
> 
> Hi John and Lou,
> 
> I also have been participating in the GMPLS discussions from early on
> (2002).
> 
> One item that always struck me funny the way GMPLS describes (ITU-T)
> layers by a tuple of information (e.g. <SwichCap, EncodType> or
> <SwitchCap, EncodType, SigType> for SDH/OTN) where the component
> information seems to be empirically defined.  More specifically:
>  - Switching Capability defines some things based on large sweeping
> definitions but others more narrowly.  For example:
>       TDM (which encompasses SONET/SDH and ODU)
>    compared with:
>       PSCx (which looks to be used only for MPLS)
>       L2SC (which originally meant a combination of Frame Relay,
> Ethernet)
>  - Encoding type defines sub-categories of Switching Capability, but
> doesn't scope under Switching Capability.  For example:
>       ANSI/ETSI PDH - when would this be used for a SC other than TDM?
>       SONET/SDH - ditto
>       ODU - ditto (prior to use of the new 101 SC)
>    compared with:
>       Packet (This is not really descriptive)
>       Ethernet (more descriptive - looks to be a sub-category of L2SC.
> Of course, this has been deprecated.)
> 
> Signal Type is definitely a sub-space of <TDM, OTN> and <TDM, SDH>.
> 
> Regarding the issue at hand: what is probably more important is how
> well these namespaces are used.  Since each component is a 8-bit value
> (today), exhaust is a real problem - especially since there is no
> hierarchy/sub-spacing for SwitchCap and EncodType.
> 
> 
> It is because of namespace usage, I am not in favor of assigning a
> Switching capability per ODU type (i.e. ODU0, ODU1, ODU2, ODU3, ODU4).
> 
> Jonathan Sadler
> 
> 
> -----Original Message-----
> From: John E Drake [mailto:jdrake@juniper.net]
> Sent: Tuesday, December 20, 2011 6:17 PM
> To: Lou Berger
> Cc: Sadler, Jonathan B.; BELOTTI, SERGIO (SERGIO); CCAMP
> Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
> 
> 
> 
> > -----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?
> 
> ============================================================
> The information contained in this message may be privileged
> and confidential and protected from disclosure. If the reader
> of this message is not the intended recipient, or an employee
> or agent responsible for delivering this message to the
> intended recipient, you are hereby notified that any reproduction,
> dissemination or distribution of this communication is strictly
> prohibited. If you have received this communication in error,
> please notify us immediately by replying to the message and
> deleting it from your computer. Thank you. Tellabs
> ============================================================