The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

All,

it wouldn't be hard to make the point based on this discussion that I 
tried to
make when this discussion just started.

I seems like a good idea to split the docs into two
 
1. problem and requirments
2. the solution

I can't really escape the impression that what is going on here is that 
one is
looking into the solution to try to find out what the requirments really 
were.

/Loa

Jim Hand wrote:

>	Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify.  I
>will look into this.
>
>	This draft does require RSVP TE e2e over the MPLS part of the network, but
>it does not require that MPLS or RSVP TE be extended to CE's.  And it does
>not require that the original compressor and decompressor be attached to
>MPLS.
>
>	Also, it does require that routers other than MPLS "P" routers have the
>ability to support compression and decompression.   But that does not mean
>that these routers will have to *perform* compression and decompression on
>each compressed packet.  Routers that support compressed packets on both
>input links and output links should only have to perform a
>decompression/compression cycle on a small fraction of the total number of
>packets.  Most compressed packets would be switched from input to output
>without performing decompression and compression.
>
>Thanks,
>Jim
>
>  
>
>>draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls for the
>>above definition of e2e which I hope I don't have to repeat with every
>>email message.
>>
>>draft-ash-e2e-crtp-hdr-compress-00 requires either of two conditions.
>>1) e2e rsvp/te mpls (for the above definition of e2e), 2) every router
>>along the way knows how to do compression and decompression.
>>
>>Case #2 is the one that SP are saying is impractical because the PE
>>CPU is overloaded with too many PPS.  Except for this practical matter
>>case #2 is every bit as good a solution for the CE-PE links as rfc2508
>>over PPP links (with most CE-PE being PPP).  Needless to say that
>>makes case #2 completely absurd in the core (comp/decomp on oc192c
>>interfaces).
>>
>>That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e
>>rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which
>>requires e2e rsvp/te mpls plus requires every hop in the path to
>>support comp/decomp making it even worse.
>>
>>Curtis
>>
>>
>>    
>>
>>>>-----Original Message-----
>>>>From: Curtis Villamizar [mailto:curtis@fictitious.org]
>>>>Sent: Wednesday, February 19, 2003 11:25 AM
>>>>To: Ash, Gerald R (Jerry), ALABS
>>>>Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net;
>>>>        
>>>>
>>George Swallow;
>>    
>>
>>>>Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS;
>>>>Dave Cooper
>>>>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression
>>>>        
>>>>
>>>>Please correct me if I'm wrong but your drafts seem to
>>>>        
>>>>
>>require end2end
>>    
>>
>>>>MPLS where RTP/UDP/IP/MPLS normally requires just end2end
>>>>        
>>>>
>>IP.  Since
>>    
>>
>>>>you are providing new RSVP/TE objects the assumption seems to be
>>>>RSVP/TE MPLS edge to edge.  If traffic engineering is done within
>>>>regions as can be done with current RTP/UDP/IP/MPLS regardless of
>>>>whether LDP is also used, that works fine and scales
>>>>        
>>>>
>>extremely well.
>>    
>>
>>>>E2E RSVP/TE MPLS all the way to each peice of VOIP gear
>>>>        
>>>>
>>is unlikely to
>>    
>>
>>>>scale well in a single provider and is almost certain to become a
>>>>severe problem crossing SP boundaries.
>>>>
>>>>Curtis
>>>>
>>>>        
>>>>
>>>      
>>>
>
>
>
>  
>