The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

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