The MPLS WG Archive

[Bala Rajagopalan <BRaja@tellium.com>]

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: braja@tellium.com


> -----Original Message-----
> From: Curtis Villamizar [mailto:curtis@fictitious.org]
> Sent: Friday, February 28, 2003 11:07 AM
> To: Bala Rajagopalan
> Cc: Loa Andersson; ccamp@ops.ietf.org; mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> 
> In message 
> <05707214338CD5119BFF0040A5B170D3028897C1@mail3.tellium.com>, 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
>