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

[Don Fedyk <dwfedyk@nortelnetworks.com>]

Curtis

Some comments, inline.

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.
This is not correct. I have had this discussion with the authors and 
they assure me bandwidth on demand not the expected model of deployment. 
It is not precluded true but they realize the current situation.

> 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.
We know the world is changing and that is why we are trying to reuse IP 
technology.  I think it is a big win if we reuse similar technology 
components. It won't happen overnight. But it wont happen if we don't 
move forward. There is a lot of history in optical networks and they are 
evolving and simplifying. This is similar to the early packet industry. 
We used to have many protocols for different traffic. Only with the 
advent of cheaper bandwidth could we afford IP. 
>  
<snip> History of GMPLS

> >    
> 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 don't think it is about accepting ASON per se. We would not have the 
ITU if that were true. It is about parallel requirements that can be 
solved by the same mechanisms. Is there a one to one mapping? In many 
cases yes. Are there differences yes again. Do we need the IETF to 
accept all the changes?  Well that is THE question. What would be great 
is if the IETF could accommodate, and filter the information that is 
relevant and suggest solutions to features that the IETF cannot see 
value in. That's what I saw happen in other WGs.  You know the ITU has 
taken a lot of technology from the IETF. It is common practice not to 
reinvent technology.

I can't think of system that was deployed that turned out the way 
everyone thought it would. We wouldn't be deploying IP version 6 if 
there wasn't some room for changes.   There are many profitable ATM 
networks in the world. Guess what?  There are even profitable X.25 
networks still kicking.

> > 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.
Your instance that they are all irrelevant and should go away is tiresome.

> > 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
Curtis you have proven that even the weight of any individual has a 
pretty high threshold!

Don