Subject: Re: [Ieprep] Use of ToS bits for "emergency" preferential treatment

From: [email-masked]
Date: Wed, 27 Nov 2002 12:35:19 EST

In a message dated 11/26/2002 8:46:58 PM Eastern Standard Time, [email-masked] 
writes:

> That's a host requirement, not a service provider requirement.
> 
[MAP] I understand that the specific references are "Host Requirements", but 
I have to believe that the point of this JTA requirement is that the 8-bit 
field must be passed end-to-end (through "hosts", "routers", and whatever) 
unchanged.

[email-masked] writes:

> OBE
>     the 8-bit TOS field is no more
>     6 bits are the differv DSCP (see RFC 2474)
>     2 bits are ECN (see RFC 3168)
> 
[MAP] So, I would still interpret that the DoD requirement is to pass the 8 
bits unchanged, no matter what they have been renamed. Is this requirement 
wrong or impossible to meet?

In a message dated 11/26/2002 9:23:26 PM Eastern Standard Time, 
[email-masked] writes:

> Standard 3 == {RFC-1122, RFC-1123} with some updates.
> 
> Parts of STD3 are in fact badly out of date.  Several parts of it are 
> defunct,
> but there has never been enough energy in IETF to revisit the documents.
> 
[MAP] According to the official list, STD 3 consists of RFC 1122 and 1123, 
not  some additional unspecified updates. While 1122 is "updated by" 1349 and 
1123 is "updated by" 1349 and 2181, 1349 is in turn obsoleted by 2474 
(DiffServ) and 2181 does not address the TOS field. Guess this clearly points 
out one of the procedural shortcomings in the IETF which allows "out-of-date" 
and "defunct" standards to continue to exist. Looks like something that 
should be addressed by someone who cares about procedures.

In a message dated 11/26/2002 10:03:32 PM Eastern Standard Time, 
[email-masked] writes:

> Many IP routers/L3 switches can be configured to set/clear/reset the IP ToS
> or DiffServ byte, generally based on ACLs configured by the router 
> administrator.
> 
[MAP] And I suppose if they want to comply with the JTA requirement, they 
would also be capable of being configured to leave these bits alone.

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 27 Nov 2002 09:43:50 -0800 (PST)

> field must be passed end-to-end (through "hosts", "routers", and whatever)

This is the IETF.  We're a _standards body_.  We _deal in specifics_.  Not
"whatevers."  That was a host requirement.  That means that it was
required of the manufacturers of hosts and their operating systems.
There's _also_ a router requirements standard, which specifies what's
required of routers.  There's _also_ a service providers requirements
standard, which specifies what's required of service providers.

Again, you're looking at the _host_ requirements.  That specifies, as
exactly as possible, what's required of _hosts_.  No one is asking you to
believe or surmise anything that's not clearly stated in the respective
standards.

                                -Bill

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

---

From: Scott Bradner <[email-masked]>
Date: Wed, 27 Nov 2002 13:14:00 -0500 (EST)

> wrong or impossible to meet?

maybe meaningless - the two low order bits will be random and
change randomly where ECN is in used - the *function* they
seem to want (passing the QoS-related bits) is only relevent
to the high-order 6 bits

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 29 Nov 2002 17:19:22 -0500

On Wednesday, Nov 27, 2002, at 12:35 America/Montreal, [email-masked] 
wrote:
> [MAP] So, I would still interpret that the DoD requirement is to pass 
> the 8 bits unchanged, no matter what they have been renamed. Is this 
> requirement wrong or impossible to meet?

It is quite realistic as long as it is a DoD owned & DoD operated 
network, since
DoD would control the deployed network configuration.  It is quite 
unrealistic
to expect the IP ToS bits to remain unchanged whilst transiting someone
else's (e.g. a commercial ISP's, some other non-DoD private) network.

> [MAP] According to the official list, STD 3 consists of RFC 1122 and 
> 1123, not  some additional unspecified updates. While 1122 is "updated 
> by" 1349 and 1123 is "updated by" 1349 and 2181, 1349 is in turn 
> obsoleted by 2474 (DiffServ) and 2181 does not address the TOS field. 
> Guess this clearly points out one of the procedural shortcomings in 
> the IETF which allows "out-of-date" and "defunct" standards to 
> continue to exist. Looks like something that should be addressed by 
> someone who cares about procedures.

That's a fair analysis.  IETF is not at all good about keeping things 
current.
Or keeping the set of Full Standard RFCs closely aligned with the 
current technical
reality.

In fact, one of the issues in front of the IETF right now is that our 
processes
are perceived by (some, many) IETF folks as too heavy-weight.  Among 
other things,
this is perceived by (some, many) as making it too hard to get the 
really deployed
specs all the way to Full Standard RFC in a timely manner.

> [MAP] And I suppose if they want to comply with the JTA requirement, 
> they would also be capable of being configured to leave these bits 
> alone.

As far as I know, for most commercial switch/router products, leaving 
the IP ToS bits
unmodified is the default configuration.  Certainly it is the default 
for Extreme's
boxes, though we can be configured to do any number of other things if 
the network
operator chooses to deploy some other policy.

Ran
[email-masked]