Re: {Possible Spam} Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

[Gert Grammel <Gert.Grammel@alcatel.de>]

Curtis,

you've wrote:

     It would be best if ITU members go off and waste their own time
     pursuing ASON capabilities, just as the ATM Forum went off and wasted
     their time on Q.2931 capability in UNI 3.x, 4.x, ...

and I don't agree with that. In my view it would be best if ITU-T members were
able to understand and accept the ideas behind GMPLS and would provide valuable
input to bring this work forward.

Regards

Gert


Curtis Villamizar wrote:

> Coments inline.
>
> In message <3E679FB5.542FBF09@alcatel.de>, Gert Grammel writes:
> >
> > Mark,
> >
> > 'improving the coordination between the IETF and ITU-T' is one of the
> > things I' d like to see since years. However in my experience the true
> > barrier between both groups is not so much the technology as such, but
> > some ignorance about the core aspects in both organizations. To give a
> > balanced figure here:
> >
> >   1. You remember the thread about the non-standard SDH/SONET
> >      extensions. Here some guys active in GMPLS tried to push their
> >      ideas about transparency.  Obviously this was perceived on ITU-T
> >      side as a challenge on the purity of a standard (G.707). This one
> >      was (almost) setteled by moving all non-standard features to an
> >      informal draft.
> >
> >   2. Now it is the other way round. Somehow ITU-T extensions got
> >      accepted (agai n informational) in IETF which do not comply to
> >      the purity of RSVP-TE. Due t o the fact that this informational
> >      RFC was not reviewed in CCAMP before, it is perceived as an
> >      assault.
> >
> > So the match is tied up 1:1 but maybe it's now the right time to find
> > a solutio n on how to proceed. What I've seen so far was a complete
> > misperception of what i s required on either side and why.
> >
> >   1. ITU-T basically started by defining user services having in mind
> >      layered transport platforms like OTH and SDH/SONET. Those
> >      services can be summarized as 'Bandwidth on Demand' services
> >      (BOND). Naturally this led to a very strong focus on UNI
> >      interfaces and a kind of ignorance of networkin g protocols. You
> >      probably remember the discussions on why not using SS7? (For
> >      those not familar with the issue: SS7 is the signaling protocol
> >      between PSTN switches)
>
> SDH/SONET bandwidth on demand has never been deployed.  There is
> serious question about whether this is a viable service.  The
> technology has existed for about a decade (a little less maybe) for
> provide ATM SVC service doing essentially the same thing.  Market
> penetration after a decade is very close to zero for SVC.  Market
> penetration for ATM SPVC/PVC is small and may be shrinking.  The FR
> market seems to be shrinking as well.  FR SVC market is zero.
> SDH/SONET does not have the bandwidth on demand capability but there
> is ample evidence that implementing it would be a waste of time.
>
> ASON is a requirements document from ITU that assumes the SDH/SONET
> BOND is a viable service.  This is an enormous leap of faith given the
> trends in the market.  The IETF doesn't buy into it.
>
> And yes, most of us are familiar with SS7 and the whole SCP/STP AIN
> mess, so if you want to extend TCAP to support ASON, go right ahead.
> We in the IETF would get a real good laugh over that.
>
> >   2. IETF started with established L2/3 protocols (OSPF, RSVP-TE, ...)
> >      and extending their scope to L1 technologies namely SDH/SONET and
> >      OTH.  Naturally this led to a very strong focus on protocol
> >      consistency and a kind of ignorance on service aspects other than
> >      those already available in MPLS. You may remember here the
> >      discussion about whether UNI is useful at all some time ago.
>
> Initially IP and voice ran over TDM.  The bandwidth demands of IP were
> much less than voice a decade ago.  As IP penetration grew roughly
> exponentially through the early, mid, and most of the late 1990s, this
> reversed and IP consumed far more bandwidth than voice.  Switched
> services also grew but at a slower rate and in the late 1990s
> experienced negative growth for many SPs.  One factor may have been
> notable outages in FR (US nationwide one day at one major provider and
> intermittent for 10 days in another a few years later) shot a big hole
> in the "much more reliable than IP" story.
>
> Initially MPLS served as traffic enginnering strictly for IP.  With IP
> still growing substantially, voice growing very slowly (and losing
> revenue) and switched services growing slowly to shrinking, there was
> motivation to carry voice, switched services, and leased line services
> over the IP and/or MPLS infrastructure and decommission older
> SDH/SONET ADM and FR or ATM switches.  This led to the tunneling work.
>
> Another factor which led to GMPLS was the (unrealized) promise/hype of
> optical switching in the very late 1990s.  IP over an ATM overlay was
> a poor design and IP providers did not want to repeat that mistake so
> the control of the underlying optical domain was accommodated by what
> has evolved into GMPLS.  GMPLS was extended to accommodate TDM in
> addition to FSC, LSC and PSC.
>
> > So putting everything together means that it is required to keep
> > (IETF) protocol consistency but adding some (ITU-T) specific
> > extensions to well defined service points in the network (UNI).
> > Unfortunately service points tend to exchange messages between
> > themselves and this would mean that an intermediate protocol would
> > have had to support such kind of communication. What concerns the IETF
> > community is probably not the fact that there is a UNI somewhere, but
> > the changes and extensions to etablished protocols in order to achieve
> > a collaboration between them.
>
> ASON was never accepted by the IETF as requirements and for very good
> reason.  To say that IETF must accept the ASON requirements simply
> because they came in a liason statement and that the IETF must
> accommodate this ITU folly is absurd.
>
> > I recall that this was the basic issue with the ITU-T proposal when it
> > was presented for the first time in Yokohama. The way I've got
> > Kireeti's message there was: please authors try to let us understand
> > what problem you want to solve and tell us which kind of information
> > you have to exchange between which points to achieve it. We'll sort
> > out then in CCAMP what would be the most appropriate way to implement
> > it, while maintaining consistency in our protocols .
>
> Regardless of how this was handled in Yokohama, some of the
> fundamental premise of ASON is flawed.  It would be best if ITU
> members go off and waste their own time pursuing ASON capabilities,
> just as the ATM Forum went off and wasted their time on Q.2931
> capability in UNI 3.x, 4.x, but ITU should do so without extending
> protocols which originated in the IETF.
>
> > Although it didn't work the first time I still consider Kireeti's
> > suggestion to be a wise way to move forward and perhaps the key for
> > harmonic collaboration.
> >
> > Regards
> >
> > Gert
>
> I look forward to seeing the IETF come up with a formal statement of
> liason policy.  It would be useful to have explicitly documented that
> liason statements carry no more weight than any individual
> internet-draft submission.
>
> Curtis

--
Alcatel Optical Network Division    Gert Grammel
Network Strategy                    phone: +49 711 821 47368
Lorenzstrasse 10                    fax: +49 711 821 43169
D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de