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

["Sadler, Jonathan B." <[e-mail]>]

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