Subject: [Tsvwg] draft-pierce-tsvwg-assured-service-req-01.txt and -arch-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 08 Nov 2004 13:38:36 +0100

draft-pierce-tsvwg-assured-service-req-01.txt:

Firstly, as I think I've said before, using the word "assured"
is very confusing, since "assured forwarding" is a term of art
in diffserv with a specific and different meaning.

> 0.   History 
>     
>    Note: This section will be deleted before progressing as an RFC. 
>     
>    This document has evolved through 3 different working groups: 
>    SIPPING, IEPREP, and TSVWG. This draft was originally submitted 
>    under SIPPING with 2 revisions and then in the IEPREP WG in order to 
>    ensure that the Assured Service requirements are considered along 
>    with those of the related IEPS discussions. It is not being 
>    submitted in TSVWG.

That "not" is a very confusing nit :-)

> 3.   High Level Requirements
...
>    ...For example, the 
>    lower precedence calls may temporarily experience reduced quality as 
>    their packets are discarded. 

As Fred Baker's critique of the MLEF proposal has pointed out,
this is probably not acceptable, for reasons he explained in detail.

 > 4.3.1.  Call Treatment
...
>    Pref-6  Preferential treatment SHOULD NOT be provided through any 
>            scheme of dedicated or pre-reserved bandwidth or resources. 

That's an implementation issue, and I think it is out of place in
a functional requirements document.

draft-pierce-tsvwg-assured-service-arch-01.txt:

> 3.   Required Architecture 
>     
>    In order to provide the security and feature control required for 
>    Assured Service as defined in [Pierce1], it is necessary to utilize 
>    the Service Provider Network Architecture in which proxies are used 
...

I'm unclear why this is *required* or *necessary*. I would have thought
it was "recommended" or "proposed" or "appropriate" or even "sufficient."

...
>    There must be an edge router, as described in [RFC 2998] and RFC 
>    [3313], generally at the boundary between the local network and the 
>    core network.

I don't see why your primary reference here is to 2998. The primary
references are probably RFC 2474 and 2475, where the boxes in question are
called "DS boundary nodes." 2998 builds on this for the specific case
of interworking with RSVP and Integrated Services, which you don't discuss
at all.

> 4.3. Function of the Edge Router 
>     
>    The edge router serves the functions of ingress router and egress 
>    router referred to in various RFCs. "Edge Router" is described in 
>    RFCs [2998], [3313], and [3521]. 

Same comment.

    Brian

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

---

From: [email-masked]
Date: Mon, 8 Nov 2004 20:50:28 EST

In a message dated 11/8/2004 2:43:39 PM Eastern Standard Time, 
[email-masked] writes:

{MAP] Yes, I understand the potential for confusion, but we can't avoid using 
good English words just because they were used in some other context or term. 
"Assured Forwarding" and "Assured Service" are two different terms, and, as 
long as they are always used in those ways, there should be no problem. If 
needed, I can add a note that "Assured Service" is not another name for "Assured 
Forwarding".

------------------------------------------------------------------------------
---------------------------------

[MAP] That was an unfortunate typo. It should say "now being submitted".

------------------------------------------------------------------------------
----------------
...

[MAP] 
Yes, that certainly may be true in many networks, but it can be a perfectly 
acceptable mechanism in other networks such as a DSN (which is intended as the 
purpose of this draft). Maybe I left it a little open about this draft 
possibly applying to other networks. I need to make it clear that the requirements 
apply to the specific network of the DOD.
------------------------------------------------------------------------------
----------------

...

[MAP] Again, this draft is intended to address a specific network in which it 
is felt that this is the requirement. A different network may choose to not 
have this requirement.

--------------------------------------------------------------------------

...

[MAP] After a lot of discussion on how to acheive security, it is concluded 
that the network that this draft is designed to address
 "must" use this architecture. Other networks may not require this.

------------------------------------------------------------------------------
------
...

[MAP] I'll look at these. They may be better references for this device. I 
suspect we're really talking about a device that performs both functions.

------------------------------------------------------------------------------
-------

Same comment.

------------------------------------------------------------------------------
-------

Thanks for the comments.

Mike