Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: Bala Rajagopalan <[email-masked]>
Date: Fri, 28 Feb 2003 11:46:25 -0500

Curtis:

First, thanks for your patient response.
Needless to say, a bit of exaggeration is
necessary for humor (I hope there was some
humor in this).

I wasn't really following the thread on G.709,
so this was not the issue. There are a number
of G.xxxx documents related to ASON that use
IETF protocols and this is what I was referring
to. 

Now, I don't think that all solutions developed
outside of IETF (using IETF protocols) are clean.
However, I do think that so far, there has not
been an adequate effort in IETF to understand
the problem formulations coming from outside.
This is the crux of my message.

In this regard, yes, I do believe that you have
been prominent in rejecting the entire notion
of the UNI. I personally don't have an addiction
to UNI (or any of the G.xxxx stuff), except that 
some number of service providers
(the potential customers of the technology) wanted
this and an effort was made to deliver the features
they wanted. Is there a better way of providing
the same UNI functionality using GMPLS protocols? This
is what one would like to hear from IETF, rather than
a dismissal of the whole concept. Correct me if
I'm wrong, but the present Andersson draft, IMO, 
doesn't address this problem. 

Clearly, I won't place any bets on
the success of UNI in the market place (what
market?). Neither will I place any bets on GMPLS 
at this point in time.

Thank you.

Bala

Bala Rajagopalan
Tellium, Inc.
2 Crescent Pl.
Ocean Port, NJ 07757
USA
Ph: +1-732-923-4237
Email: [email-masked]

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Friday, February 28, 2003 11:07 AM
> To: Bala Rajagopalan
> Cc: Loa Andersson; [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> In message 
> <[email-masked]>, Bala R
> ajagopalan writes:
> > Just ran into this ID. The flow chart, as usual,
> > was too complicated for me to comprehend, to I
> > ran it through the decoder software that IESG 
> > provides to unscramble its policy statements
> > (see http://www.ietf.org/iesg/policy_faq/demystify.exe).
> > The flow chart was then rendered human-readable
> > as follows:
> 
> 
> AFAIK - When IESG members run the compiler they don't produce exe
> files.  :-)
> 
> 
> > 	MPLS and GMPLS Change Process 
> > 	-----------------------------
> > 
> >         +-------------------------+ 
> >         |   Receive New ID        | 
> >         +-------------------------+
> >                    |
> >                    | 
> >                    V
> >        +-------------------------------------+              
> >        | Briefly wonder about the resilience |         
> >        | of the MPLS/GMPLS bandwagon.        |              
>            
> >        | Start review.                       |
> >        +-------------------------------------+             
> >                   |  
> >                   |  
> >                   V
> >        +-----------------------------------+ 
> >        | Does the draft contain the term   |  Yes 
> >        | "ASON"?                           |-------> TRASH 
> >        +-----------------------------------+
> >                   |   
> >                   | No
> >                   V
> >         +----------------------------------+ 
> >         | Does the draft contain the term  |   Yes
> >         | "UNI"?                           |--------> Incinerate
> >         +----------------------------------+                    
> >  	           |
> > 	           | No 
> > 	           V
> >         +-------------------------------+   Yes, I-NNI 
> >         |   How about "NNI?"            |-----+----> TRASH 
> >         +-------------------------------+     |
> >                   |                           | E-NNI
> >                   | No                        +-----> Shred 
> > 	           V
> 
> 
> Not bad.  I think you're OK up to here.
> 
> 
> >         +-------------------------------+ 
> >         | Does the draft mention Call   |   Yes
> >         | vs Connection control?        |-------> Send a sample
> >         +-------------------------------+         of draft to CDC,
> >                   |                               incinerate rest
> >                   | No
> >                   V
> 
> 
> I think that either "call control" or "connection control" warents a
> trip to the dumpster.
> 
> 
> >         +-------------------------------+ 
> >         | Does the draft have the term  |  Yes
> >         | "G.xyz." in the title?        |---------> TRASH
> >         +-------------------------------+  
> >                   |		         
> >                   | No
> >                   V
> 
> 
> Not true.  Examples:
> 
>   2429 RTP Payload Format for the 1998 Version of ITU-T Rec. 
> H.263 Video
>        (H.263+). C. Bormann, L. Cline, G. Deisher, T. Gardos, 
> C. Maciocco,
>        D. Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu. 
> October 1998.
>        (Format: TXT=43166 bytes) (Status: PROPOSED STANDARD)
> 
>   3047 RTP Payload Format for ITU-T Recommendation G.722.1. P. Luthi.
>        January 2001. (Format: TXT=16292 bytes) (Status: 
> PROPOSED STANDARD)
> 
>   3095 RObust Header Compression (ROHC): Framework and four profiles:
>        RTP, UDP, ESP, and uncompressed. C. Bormann, C. Burmeister, M.
>        Degermark, H. Fukushima, H. Hannu, L-E. Jonsson, R. 
> Hakenberg, T.
>        Koren, K. Le, Z. Liu, A. Martensson, A. Miyazaki, K. 
> Svanbro, T.
>        Wiebke, T. Yoshimura, H. Zheng. July 2001. (Format: 
> TXT=368746 bytes)
>        (Status: PROPOSED STANDARD)
> 
>   3267 Real-Time Transport Protocol (RTP) Payload Format and File
>        Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive
>        Multi-Rate Wideband (AMR-WB) Audio Codecs. J. Sjoberg, 
> M. Westerlund,
>        A. Lakaniemi, Q. Xie. June 2002. (Format: TXT=110652 
> bytes) (Status:
>        PROPOSED STANDARD)
> 
>   3389 Real-time Transport Protocol (RTP) Payload for Comfort Noise
>        (CN). R. Zopf. September 2002. (Format: TXT=17018 
> bytes) (Status:
>        PROPOSED STANDARD)
> 
> These have plenty of G. and H. numbers in them and none of them are
> informational.  All of them make sense (for example: no severe scaling
> issues).
> 
> >         +-------------------------------+ 
> >         | Draft has progressed too far. |
> >         | Send to Curtis for review.    |
> >         +-------------------------------+
> >                   |
> >                   | 
> >                   V
> >              |            |
> >              |    TRASH   | 
> >              +------------+  
> 
> 
> I didn't realize I played such an important role in this process.  All
> this time I thought I was just making technical comments.
> 
> Sounds like you're still upset that I didn't like the OIF-UNI and/or
> you don't like technical comments regarding the feasibility of
> proposed encapsulation of G.709.  A primary point regarding OIF-UNI is
> that ATM-UNI service (ie: SVCs) never took off therefore the last
> thing we needed was a UNI for optical.  In other words, there is no
> credible requirement.
> 
> We'll have to see how the market acceptance of OIF-UNI goes.  So far
> it looks about as alive as CR-LDP did for a few years.  The market
> certainly put an end to LANE, NHRP, MPOA, and the whole idea of
> modeling ATM as a LIS.  Check the IPATM and ION archives if you'd like
> to read my comments on those standards which were strongly supported
> by SDOs outside the IETF.
> 
> I'm sorry that you don't like technical comments made about the G.709
> compressions.  Apparently some people think the IETF should just
> rubber stamp everything because it came from the ITU even if there are
> scalability issues which make deployment infeasible.
> 
> 
> > Seems a bit draconian and no wonder, people are anxious 
> > about the process and expect the worst.  Still, I believe 
> > this will help in limiting the generation of useless drafts 
> > and protocol extensions to
> > WGs within the IETF and prevent outside groups from doing the same. 
> > 
> > Regards,
> > 
> > Bala Rajagopalan
> 
> 
> The IETF can't stop other SDOs from creating useless protocols and
> protocol extensions and some have become quite good at it.  :-)
> 
> Curtis
>

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 28 Feb 2003 12:17:12 -0500

In message <[email-masked]>, Bala R
> necessary for humor (I hope there was some

Yes.  I can parse humor.  [seems like an oxymoron as stated. :) ]

> This is the crux of my message.

There are also individuals, some of whom played a key role in ASON,
who could not make a convincing argument at times in the IETF, and
have gone outside the IETF where questionable requirements will
receive less carefull scrutiny, then come back to the IETF and expect
a rubber stamp.  Some of the same people that dominated IPLDN, IPATM,
ROLC and ION within the IETF went outside IETF and gave us ASON.

To be perfectly honest with you, I personally put no more credibility
in ASON that I did in the ITU IP-QoS documents of the mid-90s.  The
ITU has stepped out of bounds (again).  They deserve to be ignored.

> doesn't address this problem. 

The ISPs certainly did not drive this.  The SPs, wannabe ISPs, maybe.
I do think the vendors pushed this and a few people at SPs, mostly in
legacy transport, were willing to stand behind it.

> market?). Neither will I place any bets on GMPLS 

OK.  I tend to agree, however GMPLS may become successful.  The future
of GMPLS is not certain, however if GMPLS dies it will be very likely
to due to core optical switching turning out to be even less useful
than currently anticipated.

Curtis

ps - for a related dose of humor see
<http://www.avici.com/technology/whitepapers/bigbangtheory.pdf>
keeping in mind that at the time of publication (April 1, 2000) it was
herassy to suggest that optical switching was going to be anything
less than enormously successful or suggest that all optical switching
would not be the dominant technology of IP backbones or suggest that
exponential growth of the Internet would not be sustained
indefinitely.