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

[John E Drake <[e-mail]>]

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:[e-mail]]
> 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:[e-mail]]
> 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:[e-mail]]
> > 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
> ============================================================