The MPLS WG Archive

[Loa Andersson <loa@pi.se>]

Bur,

no I don't think I've have a problem with the objectvity, but other
may have their own judgement :)

1. I asked Jerry if there where any requirements and problem statement
   - was pointed to less than ten lines in one of the drafts
   - at that point I SUGGESTED that it is a good idea, there is is no
     "coming along and requiring" - I was (and am) very explicit on that
     this is not a required process. I'm not going to mandate (or even being
     very push on that you do this "my way") - though I should have the
     freedom to state what I think a good way of doing it. No?
2. It is only about two weeks since Jerry proposed that this is made an
   mpls wg work. As he said himself there has been some uncertainties of 
where
   this work should go. It was the proposal that made me "come along", 
not the
   17 months.
3. Now I learn that the documents I've asked for exist. Great!
   17 months would have made them dated, so they would have to be
   republished, but not that hard!
4. ... and that a requirement has been submitted. Great :)
   Sorry I've not seen that one yet, but will be looking for it as it comes
   through the ID publishing process :). If it is already out, could you
   please point me to it! The previous mail was based on the fact that
   I was not aware of that requirment draft. How could I've been?
   And that Jim suggested that some re-work is needed.
5. Could it be that what I want to achieve is a well documented
   situation for something I think could be useful?

/Loa

GOODE, B (Bur), ALABS wrote:

>Loa, we started with a problem and a statement of requirements.  In the
>beginning, we discussed the problem and the requirements with George
>Swallow and Dave Oran 18 months ago.  At that time, there was no IETF
>process for documenting the problem and the requirements.  We started
>working on potential solutions months after we defined the problem and
>requirements.  When we felt we had a couple of potential solutions, we
>submitted them as IDs.  Three months after we submitted the drafts, and
>17 months after the first problem statement and identification of the
>requirements, you came along and demanded that we write a requirements
>document.  So we wrote a requirements document, which we have just
>submitted to the internet drafts editor.  
>
>Loa, you should ask yourself, are you trying to be objective? 
>
>Bur  
>
>  
>
>>-----Original Message-----
>>From: Loa Andersson [mailto:loa@pi.se]
>>Sent: Sunday, February 23, 2003 12:42 PM
>>To: Jim Hand
>>Cc: curtis@fictitious.org; Ash, Gerald R (Jerry), ALABS; 'raymond
>>zhang'; 'MPLS@UU.net'; 'George Swallow'; 'Loa Andersson'; GOODE, B
>>(Bur), ALABS; 'Dave Cooper'
>>Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression -
>>End-to-EndMPLS
>>
>>
>>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
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>
>>> 
>>>
>>>      
>>>
>>
>>    
>>
>
>
>  
>