The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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