Subject: [TSVWG] - Comments on WGLC "MLPP-that-works"

From: "Steve Silverman" <[email-masked]>
Date: Sat, 13 Aug 2005 10:07:45 -0400

This draft has been labeled " mlpp-that-works" but the draft itself
points out that it won't work for the DOD, the primary user of this
work.
Section 2.3.3, third paragraph of the draft points out
that with the type of encryptors commonly used in the DOD network,
RSVP will not work.   The RSVP messages will be encrypted and won't be
usable by the network.
A pair of "red" LANs connected by a "black" WAN, is a very common call
configuration in the DOD network.

The fifth paragraph of Section 2.2 dismisses
the Multi-Level Expedited Forwarding concept (though not by name)
saying the "technical requirement" has not been demonstrated.
Since RSVP will not work reliably across the existing or foreseeable
network, the DOD will not be able to migrate critical traffic to VoIP
for many years.
The MLEF function, which will work in conjunction
with both the existing encryptors and RSVP, would allow a much earlier
deployment of VoIP in the DOD networks.

Editorial:  Section 2.1  tenth paragraph:  "Figure X" should be
"Figure 2".

Steve Silverman
Houston Associates

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: ken carlberg <[email-masked]>
Date: Sun, 14 Aug 2005 10:07:41 -0400

> configuration in the DOD network.

my apologies if my information is out of date but I was under the  
impression that the majority of KG-xx encryptors "commonly used in  
the DoD" nets are at the link level and therefore transparent to RSVP.

and in cases where IPsec exists, the second paragraph of Section  
2.3.3 outlines what needs to be done to achieve "RSVP awareness" with  
IPsec tunnels.  the caveat being that there are limitations with  
rfc-2207, and perhaps this needs to be (re)stated in the draft.

-ken

---

From: Fred Baker <[email-masked]>
Date: Sun, 14 Aug 2005 17:23:18 -0700

That is the context of

          http://www.ietf.org/internet-drafts/draft-lefaucheur-rsvp- 
ipsec-01.txt
   "Generic Aggregate RSVP Reservations", Francois Le Faucheur, 1- 
Jul-05,
   <draft-lefaucheur-rsvp-ipsec-01.txt>

Thanks for pointing it out. Do you feel tehre is a specific statement  
that needs to be made in the mlpp-that-works draft?

On Aug 14, 2005, at 7:07 AM, ken carlberg wrote:

> 2.3.3 outlines what needs to be done to achieve "RSVP awareness"  
> with IPsec tunnels.  the caveat being that there are limitations  
> with rfc-2207, and perhaps this needs to be (re)stated in the draft.
>
> -ken
>

---

From: ken carlberg <[email-masked]>
Date: Sun, 14 Aug 2005 20:27:56 -0400

I was going to review the draft within the next few days, so if if  
something comes to mind, I'll include it then.

-ken

On Aug 14, 2005, at 8:23 PM, Fred Baker wrote:

> Thanks for pointing it out. Do you feel tehre is a specific  
> statement that needs to be made in the mlpp-that-works draft?
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 14 Aug 2005 17:33:59 -0700

Hi Steve.

On Aug 13, 2005, at 7:07 AM, Steve Silverman wrote:
> Section 2.3.3, third paragraph of the draft points out that with  
> the type of encryptors commonly used in the DOD network, RSVP will  
> not work.   The RSVP messages will be encrypted and won't be usable  
> by the network. A pair of "red" LANs connected by a "black" WAN, is  
> a very common call configuration in the DOD network.

As I'm sure you're aware, DoD is now investigating the possibilities  
with regard to the class of encryption devices you refer to. There is  
discussion of both the discovery problem and the carriage of  
preemption information across the boundary between the ciphertext  
domain and the plaintext domain. This is in part the context of

   http://www.ietf.org/internet-drafts/draft-baker-nested-vpn- 
routing-01.txt
   "Routing across Nested VPNs", Fred Baker, 19-Jul-05,
   <draft-baker-nested-vpn-routing-01.txt>

   http://www.ietf.org/internet-drafts/draft-baker-tsvwg-vpn-signaled- 
preemption-03.txt
   "QoS Signaling in a Nested Virtual Private Network", Pratik Bose,  
Fred Baker,
   19-Jul-05, <draft-baker-tsvwg-vpn-signaled-preemption-03.txt>

and of

   http://www.ietf.org/internet-drafts/draft-alexander-rtecn- 
admission-control-use-case-00.txt
   "Admission Control Use Case for Real-time ECN", Corey Alexander,  
14-Feb-05,
   <draft-alexander-rtecn-admission-control-use-case-00.txt>

   http://www.ietf.org/internet-drafts/draft-alexander-rtecn-use- 
cases-00.txt
   "Real-time ECN Use Cases", Corey Alexander, 13-Jul-05,
   <draft-alexander-rtecn-use-cases-00.txt>

   http://www.ietf.org/internet-drafts/draft-babiarz-rtecn- 
marking-00.txt
   "Discussion of Congestion Marking with RT-ECN", Jozef Babiarz, 13- 
Jul-05,
   <draft-babiarz-rtecn-marking-00.txt,.pdf>

   http://www.ietf.org/internet-drafts/draft-babiarz-tsvwg-rtecn-04.txt
   "Congestion Notification Process for Real-Time Traffic", Jozef  
Babiarz,
   18-Jul-05, <draft-babiarz-tsvwg-rtecn-04.txt>

   http://www.ietf.org/internet-drafts/draft-dudley-rtecn- 
simulation-00.txt
   "Simulation of RT-ECN based Admission Control and Preemption",  
Stephen
   Dudley, 14-Jul-05, <draft-dudley-rtecn-simulation-00.txt,.pdf>

This also is in part the context of Tony De Simone's comments in  
ieprep, and of the workshop being proposed on the use of Internet  
technology in military VPN networks.

> The fifth paragraph of Section 2.2 dismisses the Multi-Level  
> Expedited Forwarding concept (though not by name) saying the  
> "technical requirement" has not been demonstrated. Since RSVP will  
> not work reliably across the existing or foreseeable network, the  
> DOD will not be able to migrate critical traffic to VoIP for many  
> years.
>
> The MLEF function, which will work in conjunction with both the  
> existing encryptors and RSVP, would allow a much earlier deployment  
> of VoIP in the DOD networks.

Interesting. My understanding is that VoIP is that it is already in  
use in a number of bases.

> Editorial:  Section 2.1  tenth paragraph:  "Figure X" should be  

Thanks. We can change that.

---

From: Randall Stewart <[email-masked]>
Date: Tue, 16 Aug 2005 09:43:29 -0400

Steve:

I have a generic question.. that effects this document
and the SCTP document (implementors guide) that was
announced as going in to last call at the tsvwg.

Where was the email announcing last call? I did
not find it in my TSV folder....

Now this COULD very well be an email problem
on my side... did others get the LC announcment on
the TSV list?

Thanks

R
-- 
Randall Stewart
803-345-0369 <or> 815-342-5222(cell)

---

From: "Steve Silverman" <[email-masked]>
Date: Tue, 16 Aug 2005 12:34:49 -0400

I don't think there was an email WGLC. 

Steve

> -----Original Message-----
> From: Randall Stewart [mailto:[email-masked]]
> Sent: Tuesday, August 16, 2005 9:43 AM
> To: Steve Silverman
> Cc: TSVWG; Fred Baker; James M. Polk; Michael Pierce
> Subject: Re: [TSVWG] - Comments on WGLC "MLPP-that-works"
> 
> 
> Steve:
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 16 Aug 2005 11:44:56 -0500

Randy

I have not received one either, yet others are acting as if it were called 
already.

I'm confused

>on my side... did others get the LC announcment on

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.