[Chapter-delegates] MPLS and T-MPLS

[James]

What excellent discourse! Franck, always great. Narelle, inspiring! 
Awesome, even!!

Can WE, as a community, exert direct influence on Standards inclusion 
procedures or outcomes?

We probably can, but should we? Are we required to do this, by our 
Charters? Is this our calling, as a Community?

May I request that, please, with all respect and enthusiasm; let's 
decide what to do about OOXML before we really dig into this deep topic? 
Just to "clear the decks" under a relative Time Constraint ...

Who's in charge, here, anyway? :)

James Butler
Internet Society - Los Angeles Chapter
Chairman of the Board
jbutler at isoc-la.org



Franck Martin wrote:

> While it is nice for chapters to handle the local ISO regarding ooXML, 
> we could as chapters talk to the local ITU-T regarding T-MPLS?
>
> What do you think?
>
> After all, we are the Internet Society, not the Open Source Society 
> (just being cheeky here).
>
> Cheers
> PS: I'm all for ODF
>
> Narelle Clark wrote:
>
>>  
>>
>>>From: Franck Martin
>>>Sent: Thursday, 6 September 2007 5:44 AM
>>>
>>>http://www.networkworld.com/news/2007/083007-mpls.html
>>>    
>>>
>>
>>Thanks Frank!
>>
>>What a pile of silliness!!!!
>>
>>In summary, the ITU has proposed one standard for "T-MPLS" and the IETF
>>has "MPLS" and, while it's not mentioned, the IEEE has "PBT". T-MPLS is
>>supposed to integrate well with ASON and GMPLS (both unfinished optical
>>equipment standards) that will **ideally** allow you to signal all sorts
>>of exciting things to the equipment and hence get different bandwidths,
>>QoS etc on demand. The big gap with Ethernet at present in carrier
>>networks is a serious lack of OA&M features, ie operations,
>>administration and maintenance - not traditionally one of the IETF's
>>strong points.
>>
>>The commentary so far has indicated compatibility between T-MPLS and
>>MPLS, but I hadn't realised they were using the same ethertype as an
>>existing MPLS [1] type to depict something else again.
>>
>>It certainly seems the ITU has  tried to make a standard when they
>>haven't read the other standards already in place, indeed are widely
>>implemented around the world. Or at least not argued their cause through
>>the existing standards. 
>>
>>It's an entirely silly concept that 'it won't matter as T-MPLS will only
>>be used in carrier networks'. Do they think carriers don't use MPLS??
>>How funny.
>>
>>So any gains achieved by using low cost transmission gear doing a classy
>>ethernet will be completely negated by the fact you can't plug them into
>>an MPLS network without extra encapsulation and segregation... There
>>goes the lower header size of T-MPLS over PBT...[2] [3]
>>
>>
>>Narelle
>>
>>
>>
>>
>>
>>[1]
>>Personally I always thought MPLS was a bit of a kludge, but that is my
>>purist thinking preferring 'real IP addresses' (ie public) and the
>>topological elegance of a well routed network... But I suppose I'm used
>>to it now and see the many benefits of layer 3 VPNs... But that pseudo
>>wire business clearly shows someone has their OSI model upside down
>>(layer 2 over layer 3 running on another layer 2!).
>>
>>[2] 20b vs 64b in PBT
>>
>>[3] I could have completely misread all of these... LOL
>>
>>
>>Narelle Clark |   t: +61 2 8082 7035  | 
>>Vice President ISOC-AU
>> 
>>
>>"When it comes to technology, most people over-estimate it in the short
>>term and under-estimate it in the longer term."  Arthur C. Clarke [no
>>relation]
>>
>>****DISCLAIMER**** 
>>This e-mail may contain confidential information. If you are not the
>>intended recipient, please notify the sender immediately and delete this
>>e-mail from your system. You must not disclose this email to anyone
>>without express permission from the sender. The contents of all emails
>>sent to, and received from, Optus may be scanned, stored, or disclosed
>>to others by Optus at Optus' discretion. Optus has exercised care to
>>avoid errors in the information contained in this e-mail but does not
>>warrant that the information is error or omission free. 
>>  
>>
>
>-- 
>Franck Martin
>ICT Specialist
>franck at sopac.org
>SOPAC, Fiji
>GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9  D9C6 BE79 9E60 81D9 1320
>"Toute connaissance est une reponse a une question" G.Bachelard
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Chapter-delegates mailing list
>Chapter-delegates at elists.isoc.org
>http://elists.isoc.org/mailman/listinfo/chapter-delegates
>  
>