RE: [RPRWG] control TTL
Tom,
My problem is not with the resulting numbers. My problem is with the
process. You state: "the only means available to the editor of satisfying
that resolution was to put down "127" as the number of stations in the
objectives". This is not correct. The editor should have reflected what is
stated throughout the rest of the draft.
In the case of node numbers, the draft clearly lists 255 in clauses 8, 9,
10, 11, and E. If someone wants the number changed, they should address
those sections, not clause 1.
In the case of distance, since the draft says nothing, clause 1 should say
nothing. If people want a maximum distance specified, they should direct the
comment to the appropriate normative clause (10?), not clause 1.
And in all cases, the editor of clause 1, and you as the chief editor,
should ensure that a) contradictions are not introduced, and b) informative
clauses do not introduce new material that is effectively normative in
nature.
jl
-----Original Message-----
From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
Sent: Tuesday, June 18, 2002 7:35 PM
To: stds-802-17@xxxxxxxx
Cc: 'djz@xxxxxxxxxxx'; John Lemon; 'Anoop Ghanwani'
Subject: RE: [RPRWG] control TTL
John, David,
Both of these numbers arose out of the resolution to
comment #155 on D0.2. Specifically, the comment wanted
distance, speed and number of stations on the ring to
be part of the statement of RPR performance objectives.
The group resolution was as follows:
"Contributions are requested on the following topics:
what performance objectives (distance, speed, MAC
end-to-end delay, delay jitter, etc. for specific
configurations) should be specified? What should these
objectives be for the RPR MAC?
Recommendations: The maximum number of stations should
be defined compatible with an 8-bit TTL field, as
determined by Clauses 6 and 11. The maximum ring size
should be set to 2000 km. As for the remainder,
contributions are requested."
With regard to the distance, there is unfortunately no
clause in D0.2 where a distance is specified at all, let
alone in a normative manner. Therefore, the CRG followed
what it believed to be the stated intent of the WG, and
set the distance placeholder in D0.2 to 2000 km. There
was no intent that this should be normative; in fact, an
editor's note at the very beginning of Clause 1 explicitly
states that none of the material in the clause is
normative.
With regard to the number of stations on the ring, the
resolution simply requests that the number of stations
should be defined 'consistent with an 8-bit TTL'. It was
stated at the time that an 8-bit TTL limits one to 127
stations (< 255 nodes, each station counting as two nodes)
to cover the case of a wrapped ring. Therefore, the only
means available to the editor of satisfying that resolution
was to put down "127" as the number of stations in the
objectives.
It is entirely possible that one or both of the above
numbers is incorrect or unsatisfactory; this is why the
comment resolution group started off by requesting
contributions on the objectives. Clearly, the conversion
of the placeholders to actual numbers has had the beneficial
effect of sparking the discussions necessary to produce
such contributions!
Best regards,
- Tom A.
Chief Editor, P802.17
-----Original Message-----
From: David James [mailto:djz@xxxxxxxxxxx]
Sent: Tuesday, June 18, 2002 6:43 PM
To: John Lemon; 'Anoop Ghanwani'; stds-802-17@xxxxxxxx
Cc: Tom Alexander
Subject: RE: [RPRWG] control TTL
John,
From my recollection, there were items that affected the whole
draft, rather than specific clauses, and this was one of them.
That ad-hoc resolution group addressed this and other issues,
or so I thought. Have to ask Tom Alexander on the details.
Regardless of recollection, this number is consistent with
a past working group decision. There are painful repercussions
in having numbers set at 255, since the number of attachment
points (that can all be legally visited once) is twice the
number of stations and should be counted in the TTL field.
And, I'm most interest in what possible technical reason
could be used to justify such a large number of devices?
Particulary when each chip may be required to support
things like discovery tables. No point is having all
chips support a large theoretical maximum, when it
rarely (if ever) will be utilized.
DVJ
David V. James, PhD
Chief Architect
Network Processing Solutions
Data Communications Division
Cypress Semiconductor, Bldg #3
3901 North First Street
San Jose, CA 95134-1599
Work: +1.408.545.7560
Cell: +1.650.954.6906
Fax: +1.408.456.1962
Work: djz@xxxxxxxxxxx
Base: dvj@xxxxxxxxxxxx
> -----Original Message-----
> From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of John Lemon
> Sent: Tuesday, June 18, 2002 5:44 PM
> To: 'Anoop Ghanwani'; 'stds-802-17@xxxxxxxx'
> Cc: Tom Alexander (E-mail)
> Subject: RE: [RPRWG] control TTL
>
>
>
> The maximum number of stations on a ring is 255, not 127. I have no idea
why
> someone changed clause 1; but clauses 8, 9, 10, 11, and E all use a value
of
> 255. And the resolution of comments 155 and 431 support this. The Overview
> is informative, and is supposed to reflect a simple summary of what has
been
> decided in the normative clauses.
>
> (As an aside, while I have no problem with 2000 km as a recommended limit,
> I'm also troubled that such technical changes are being made in the
Overview
> instead of one of the normative clauses. The Overview should be reflecting
> what has been decided in the other clauses, not making its own decisions.)
>
> jl
>
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop@xxxxxxxxxxxxxx]
> Sent: Tuesday, June 18, 2002 3:47 PM
> To: 'stds-802-17@xxxxxxxx'
> Subject: [RPRWG] control TTL
>
>
>
>
> At the last meeting I had a comment requesting more
> information on why the control TTL is 2 bytes. The
> explanation provided was that 1 byte is not sufficient
> if we have 255 stations and are wrapping. With D0.3,
> the maximum number of stations is 127. So now I
> don't see a reason for a 2-byte control TTL. I'm
> about to submit another comment for this, unless I
> can be convinced of a technical reason for a 2-byte
> control TTL.
>
> -Anoop
> --
> Anoop Ghanwani - Lantern Communications - 408-521-6707
>