RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question

["Castellano, Robert" <RCastellano@xxxxxxxxx>]

Hi,

The criteria for having a requirement of "shall" or "shall not" should
be one of relevance/severity to having a working standard.  We don't need
positive or negative requirements for things which have nothing
to do with the standard.  "Shall Not" is an appropriate requirement
in cases where there may be a natural expectation the standard support
something that
it doesn't, or the system has a natural propensity to do something
that must be precluded.  The bridging adhoc is coming across cases
where aspects of the ring have a natural tendency to break certain
mechanisms in 802.1D/Q.   These must be clearly expressed as requirements.

802.17 is very prone to being a reflective MAC.  A bridge can very easily
put
a frame on the ring which is received by itself since it is unable to strip
packets based on source address.  802.17 is also very prone to packet
misordering
which is a function of making ringlet selection decisions during normal
operation,
protection events, and reversion.  Finally, 802.17 prone to frame
duplication
due to the circular nature of the ring medium.



802.1D standard has used the term "does not / shall not" for relevant items
that are
either not supported or precluded.  See section 6.3 of 802.1D for examples.
I clipped a couple negative requirement references from 802.1D below:

"The MAC Service does not guarantee the delivery of Service Data Units.
Frames transmitted by a source station arrive, uncorrupted, at the
destination station with high probability. The operation of a Bridge
introduces minimal additional frame loss."

"The MAC Service does not permit the reordering of frames with a given user
priority for a given..."

"The MAC Service does not permit the duplication of frames. The operation of
Bridges does not introduce duplication of user data frames."

"A Bridge shall not duplicate user data frames."


	thanks,

	robert castellano



-----Original Message-----
From: Devendra Tripathi [mailto:tripathi@xxxxxxxxxxxxx]
Sent: Monday, April 15, 2002 9:34 PM
To: Tom Alexander; 'Peter Jones'; 'Jim Mollenauer'; 'Steven Wood'
Cc: 'Mike Takefman'; Raj Sharma; Jason Fan; John Lemon; Dot17 (E-mail)
Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question



I agree, the "Shall" should be reserved for what it does and not what it
does not, unless there is clear apprehension of misinterpretation.

Regards,
Devendra Tripathi
CoVisible Solutions, Inc
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Fax: (408)226-6862

-----Original Message-----
From: owner-stds-802-17@xxxxxxxxxxxxxxxxxx
[mailto:owner-stds-802-17@xxxxxxxxxxxxxxxxxx]On Behalf Of Tom Alexander
Sent: Monday, April 15, 2002 6:08 PM
To: 'Peter Jones'; 'Jim Mollenauer'; 'Steven Wood'
Cc: 'Mike Takefman'; Raj Sharma; Jason Fan; John Lemon; Dot17 (E-mail)
Subject: [RPRWG] RE: Fwd: RE: 802.1 architecture question



Good work, Peter. Please submit a comment to that effect against D0.2
(coming out tomorrow).

By the way, it is usually unnecessary for a standard to be normative about
capabilities that it does NOT have (e.g., statements such as "The 802.17
MAC shall not accept ATM cells" are superfluous), especially when these
capabilities are not normally supported by similar standards. Thus we could
simply include a note stating that the 802.17 MAC is not reflective,
rather than a statement containing a "shall" that would automatically
generate a PICS entry.

Cheers,

- Tom

-----Original Message-----
From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
Sent: Monday, April 15, 2002 5:48 PM
To: 'Jim Mollenauer'; 'Steven Wood'
Cc: 'Mike Takefman'; Raj Sharma; Jason Fan; Tom Alexander; John Lemon;
Dot17 (E-mail)
Subject: RE: Fwd: RE: 802.1 architecture question


Jim & Steve,

Please see the attached mail from Tony Jeffree regarding the issue I was
chasing down - my work item from the last meeting.

The essence of this is that I propose the 802.17 draft states something
like:
	"802.17 MAC is NOT reflective (i.e. does not pass
	transmissions from the MAC client back to the MAC client)."

With supporting text as required.

I think this should be sufficient to let us go forward.

regards
Peter

-----Original Message-----
From: John Lemon
Sent: Friday, April 05, 2002 10:06 AM
To: 'Jim Mollenauer'
Cc: Peter Jones; 'Steven Wood'; 'Mike Takefman'; Raj Sharma; Jason Fan;
'Tom Alexander'
Subject: RE: Fwd: RE: 802.1 architecture question


Jim,

Please re-read all the attachments to see all the information Peter
collected, especially Mick's message. You really don't want to give clients
back their sourced frames in many cases, so the safe thing to do is never
give them back.

This behavior is completely different for MAC Control Sublayer originated
frames. If any diagnostics need this behavior, they can be implemented
through a request to the MAC Control Sublayer and an associated response.

jl

-----Original Message-----
From: Jim Mollenauer [mailto:jmollenauer@xxxxxxxxxxxxxxxxxxxxx]
Sent: Friday, April 05, 2002 4:50 AM
To: John Lemon
Cc: Peter Jones; 'Steven Wood'; 'Mike Takefman'; Raj Sharma; Jason Fan;
'Tom Alexander'
Subject: Re: Fwd: RE: 802.1 architecture question


I'd like to thank Peter for his hard work on this item, but John has a valid
point.  There are times when it is desirable to send a packet all the way
around
the ring, for diagnostic and network management purposes.  In fact, the
diagnostic application is more likely to exist as a client than within the
MAC
itself.  Think of traceroute in IP as an example.  Another example would be
the
token rotation time, used in FDDI as a priority mechanism; the token (a
control
packet) goes around continuously and provides information on the current
traffic
load.

My suggestion would be to set TTL to n-1 in broadcast messages (where n is
the
number of nodes on the ringlet) but to allow TTL=n in specified unicast
control
requests.  In the latter case the returned message should be sent back up to
the
client.

Jim



John Lemon wrote:

> While I agree with everything Peter writes here, I just want to be
explicit
> that this should apply only to the interaction with the client. I believe
we
> have identified at least one control message that would need to be sent to
> oneself (all the way around the ring, not a local drop off :-).
>
> jl
>
> -----Original Message-----
> From: Peter Jones
> Sent: Thursday, April 04, 2002 7:24 PM
> To: Steven Wood (E-mail)
> Cc: Mike Takefman (E-mail); jmollenauer@xxxxxxxxxxxxxxxxxxxxx; Raj
> Sharma; Jason Fan; Tom Alexander (E-mail)
> Subject: FW: Fwd: RE: 802.1 architecture question
>
> Steve,
>
> I think I'm making progress on my work item (A8: Contribution to verify
> whether or not 802.17 resolution to comment 14 is consistent with other
802
> MACs and FDDI) - it's just taken a while.
>
> It looks like the answer will be that the MAC should not pass a frame
> transmitted by the client back to the client. See below for gory details
of
> discussions. It looks like we don't have to support this - so we should
> simplify our lives and not bother.
>
> regards
> Peter
>


-------- Old History removed---


______________________________________________________
Peter Jones                      Luminous Networks
Principal Engineer               10460 Bubb Road
                                 Cupertino, CA, 95014
                                 USA
Direct: +1 408 342 2513          Main: +1 408 342 6400
mailto:pjones@xxxxxxxxxxxx       Fax:  +1 408 863 1148
______________________________________________________