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

John E Drake <jdrake@juniper.net> Sat, 24 December 2011 14:51 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 84D1221F84CD for <ccamp@ietfa.amsl.com>; Sat, 24 Dec 2011 06:51:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.094
X-Spam-Level: **
X-Spam-Status: No, score=2.094 tagged_above=-999 required=5 tests=[AWL=-2.021, 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 6rj16NUhY6Zs for <ccamp@ietfa.amsl.com>; Sat, 24 Dec 2011 06:51:29 -0800 (PST)
Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 5E81A21F84CC for <ccamp@ietf.org>; Sat, 24 Dec 2011 06:51:29 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKTvXm64inUDN1EPm8qvBPb5c5mFsBku6F@postini.com; Sat, 24 Dec 2011 06:51:29 PST
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Sat, 24 Dec 2011 06:47:17 -0800
From: John E Drake <jdrake@juniper.net>
To: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>, "Sadler, Jonathan B." <Jonathan.Sadler@tellabs.com>, Lou Berger <lberger@labn.net>
Date: Sat, 24 Dec 2011 06:47:16 -0800
Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiAgUjogIE9TUEYgT1ROIGNvbnNpZGVyYXRpb25zIHA=?= =?gb2312?B?b3N0IElFVEYgODIgKElzc3VlIDEvMik=?=
Thread-Index: Acy/bnCwzQPfNngISIKG5LO7WyxnlAAATjPQACIjsQAAA5Y4EAAiN5mgAG7eMzA=
Message-ID: <5E893DB832F57341992548CDBB333163A54B644AF8@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> <5E893DB832F57341992548CDBB333163A54B51869D@EMBX01-HQ.jnpr.net> <B5630A95D803744A81C51AD4040A6DAA2294C264A0@ESESSCMS0360.eemea.ericsson.se>
In-Reply-To: <B5630A95D803744A81C51AD4040A6DAA2294C264A0@ESESSCMS0360.eemea.ericsson.se>
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: Sat, 24 Dec 2011 14:51:30 -0000

An excellent point.

> -----Original Message-----
> From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com]
> Sent: Thursday, December 22, 2011 2:05 AM
> To: John E Drake; Sadler, Jonathan B.; Lou Berger
> Cc: CCAMP
> Subject: RE: [CCAMP] 答复: R: OSPF OTN considerations post IETF 82
> (Issue 1/2)
> 
> All,
> 
> Just to add a consideration that has not been taken into account up to
> now.
> 
> We said that for congurence with RFC4203 we should reuse the different
> layers in the SC field as per PSC [1~4], but at the same time RFC4328
> defines a single ODU value, and a that time three different "layers"
> already existed: ODU1, ODU2, ODU3...so in order to be consistence with
> RFC4328 we should not use different layers in the SC field.
> 
> We already passed the brach, let's make a decision, one or the other,
> but we can no longer look back.
> 
> I agree with what Jonathan and John said before and support the single
> SC option.
> 
> I also take the opportunity of this mail to wish all of you a very
> Merry Christmas.
> 
> Daniele
> 
> >-----Original Message-----
> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
> >On Behalf Of John E Drake
> >Sent: mercoledì 21 dicembre 2011 18.40
> >To: Sadler, Jonathan B.; Lou Berger
> >Cc: CCAMP
> >Subject: Re: [CCAMP] 答复: R: OSPF OTN considerations post IETF
> >82 (Issue 1/2)
> >
> >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 ============================================================
> >_______________________________________________
> >CCAMP mailing list
> >CCAMP@ietf.org
> >https://www.ietf.org/mailman/listinfo/ccamp
> >