The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <001901c2d869$8863c200$3a785b87@mt.att.com>, "Jim Hand" writes:
> Also, neither draft requires end-to-end MPLS between VoIP endpoints.  One of
> the drafts
> (http://ietf.org/internet-drafts/draft-ash-e2e-vompls-hdr-compress-00.txt)
> requires MPLS between the compressor and decompressor.  The other
> (http://ietf.org/internet-drafts/draft-ash-e2e-crtp-hdr-compress-00.txt )oes
> not require MPLS all the way between compressor and decompressor.  Neither
> draft requires that the compressor and decompressor also be VoIP endpoints.
> 
> Thanks,
> Jim Hand


Jim,

I suppose you didn't read any of this thread where I said more than
once that e2e means compressor to decompressor in this context since
it couldn't possibly mean anything else and e2e is shorter to write.
It is the only interpretation that makes any sense whatsoever so it is
sufficiently unambiguous to carry on an email conversation.

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
> >
> 
>