[AVT] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt

Curtis Villamizar <curtis@workhorse.fictitious.org> Tue, 10 February 2004 08:08 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05138 for <avt-archive@odin.ietf.org>; Tue, 10 Feb 2004 03:08:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSwO-0005Fa-9V for avt-archive@odin.ietf.org; Tue, 10 Feb 2004 03:08:30 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1A88IPH020075 for avt-archive@odin.ietf.org; Tue, 10 Feb 2004 03:08:18 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqSwA-0005Am-1j; Tue, 10 Feb 2004 03:08:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqEN1-0003AF-RH for avt@optimus.ietf.org; Mon, 09 Feb 2004 11:34:51 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26397 for <avt@ietf.org>; Mon, 9 Feb 2004 11:34:48 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqEN0-0006Kg-00 for avt@ietf.org; Mon, 09 Feb 2004 11:34:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqEKW-0005uJ-00 for avt@ietf.org; Mon, 09 Feb 2004 11:32:17 -0500
Received: from workhorse.fictitious.org ([209.150.1.230]) by ietf-mx with esmtp (Exim 4.12) id 1AqEJ9-0005fU-00 for avt@ietf.org; Mon, 09 Feb 2004 11:30:51 -0500
Received: from workhorse.fictitious.org (localhost.fictitious.org [127.0.0.1]) by workhorse.fictitious.org (8.12.9p2/8.12.8) with ESMTP id i19GSwRY084489; Mon, 9 Feb 2004 11:28:59 -0500 (EST) (envelope-from curtis@workhorse.fictitious.org)
Message-Id: <200402091628.i19GSwRY084489@workhorse.fictitious.org>
To: "Ash, Gerald R (Jerry), ALABS" <gash@att.com>
cc: avt@ietf.org
Reply-To: curtis@fictitious.org
In-reply-to: Your message of "Mon, 09 Feb 2004 07:39:42 CST." <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com>
Date: Mon, 09 Feb 2004 11:28:58 -0500
From: Curtis Villamizar <curtis@workhorse.fictitious.org>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Subject: [AVT] Re: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

In message <9473683187ADC049A855ED2DA739ABCA0201F057@KCCLUST06EVS1.ugd.att.com>
, "Ash, Gerald R (Jerry), ALABS" writes:
> All,
> 
> Please review and comment on 'Protocol Extensions for ECRTP over MPLS' http:/
> /www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-protocol-00.txt. 
>  The protocol extensions enable the use of MPLS to route enhanced compressed 
> RTP (ECRTP) compressed packets over an MPLS LSP without compression/decompres
> sion cycles at each router.
> 
> The proposed extensions are based on the requirements documented in 'Requirem
> ents for ECRTP over MPLS' http://www.ietf.org/internet-drafts/draft-ash-avt-e
> crtp-over-mpls-reqs-01.txt.
> 
> Thanks,
> Jerry
> 
> 
> 	Title		: Protocol Extensions for ECRTP over MPLS
> 	Author(s)	: J. Ash
> 	Filename	: draft-ash-avt-ecrtp-over-mpls-protocol-00.txt
> 	Pages		: 0
> 	Date		: 2004-2-5


Jerry,

This looks to be a very good direction to go in.  I've dropped MPLS
from the Cc and put MPLS on the bcc so people know the discussion is
on the AVT mailing list only.

In your encapsulations you should make sure to avoid any values in the
first byte that could be mistaken as IPv4 or IPv6 or any of the
encapsulations being worked on by those working on VPN and PW.  See
"The PWE3 Control Word", Jonathan Stein, 22-Oct-02,
draft-stein-pwe3-controlword-00.txt, for some early discussion on
that.  Note though that "Payload Type" is something that many
providers require so that multipath can be used on IP traffic which
consitutes the majority of traffic yet reordering is avoided for
traffic which cannot be split based on what appears to be an IP header
and the IP src/dst pair.

It might be best to reserve a single fixed first byte for the "Packet
Type" (and I suggest you make up a name for this shim such as
SCID_Packet_Type) and use the second byte for the packet types that
you have defined.  Just as you have to get numbers for SCID_Request
Object and Header_Compression_Reply Object from IANA, you'll have to
coordinate with others over this number space, though it is less clear
if IANA is the authority on this quite yet.

Curtis

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt