[AVT] I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-01.txt

["Ash, Gerald R (Jerry), ALABS" <gash@att.com>]

All,

Please review and comment on the current draft of 'Requirements for ECRTP over MPLS' http://www.ietf.org/internet-drafts/draft-ash-avt-ecrtp-over-mpls-reqs-01.txt.

The draft has been updated according to the comments received (see attached email).  Let's keep the discussion going on the list so that we can converge on this draft prior to IETF-59 (week of March 1), and meet the AVT charter item milestone:

Mar 2004 Finish requirements for ECRTP over MPLS; re-charter for subsequent work

Thanks,
Jerry

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS 
Sent: Thursday, January 22, 2004 9:24 AM
To: Lars-Erik Jonsson (LU/EAB); Colin Perkins; avt@ietf.org
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [AVT] RE: I-D ACTION:draft-ash-avt-ecrtp-over-mpls-reqs-00.txt

Colin & Lars-Erik,

Thanks very much for your comments and suggestions.  In addition to all of your editorial suggestions, the changes to the updated draft will include:

> In a number of places, the draft describes "using MPLS to route ECRTP
> compressed packets over multiple router hops". Does this mean routing
> compressed packets over an MPLS LSP? If so, I recommend clarifying the
> draft to prevent confusion with multiple IP hops.

Changed the language as suggested.
 
> I'm not sure discussion of access links is appropriate, since MPLS is
> unlikely to be used in this scenario.

We now refer to 'low-speed' links rather than 'access links'.  It's debatable how far MPLS will extend.
 
> In section 3, the requirements list ECRTP without discussion. 
> I think ECRTP is an appropriate solution, but it would be useful to 
> motivate the choice by discussing the requirements for the 
> compression. This is particularly important, since there are 
> alternative algorithms (e.g. ROHC) that may be considered.

We've added discussion as suggested.  ECRTP should be used to make ECRTP over MPLS more tolerant of packet loss, to guard against frequent resynchronizations, and to minimize the need for error recovery.  ROHC can also be considered, however ROHC does not accommodate packet reordering to protect against out-of-sequence packets, which can occur on MPLS LSPs.  We didn't change the title of the document, as suggested by L-E, since Colin specifically suggested the current title, and that also corresponds to the AVT milestone.
 
> In section 3, the draft notes that protocol extensions may be 
> required for ECRTP. Are these changes to ECRTP or a mapping of
> ECRTP onto a new "link" layer? If the latter, the draft could
> do with clarification.  The draft should discuss the type of
> extension needed for RSVP-TE and LDP, since this will feed 
> into any new work plan.

We've added text on protocol extensions required for ECRTP, RSVP-TE, and LDP

> Security considerations: Are there no issues with DoS attacks on MPLS
> routers, due to the increased number of flows?

We've added text to discuss DoS attacks in the security section.

> Before publication, the draft will need an IANA Considerations section
> (even if it just says "No IANA actions are required") and the 
> IPR boiler-plate.

We've added an IANA Considerations Section and Intellectual Property Statement Section.

Thanks,
Jerry

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