Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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




Addressing the terms "does not" and "shall not"

I would interpret "shall not" as a conformance requirement.  Tests on the
MAC must be able to prove that the MAC never implements the referenced
function when it is operating as designed.

Does not has no rigorous meaning in standardize, i.e., it is not a statement
that we would write a PICS against.

I propose that the basic guidelines we should follow in using these
expressions are as follows:

If you want to see a PICS statement guaranteeing an action can not take
place, use "shall not".
If you want to provide informative explanatory text to the reader use "does
not".

Best regards,

Robert D. Love
President, Resilient Packet Ring Alliance
President, LAN Connect Consultants
7105 Leveret Circle     Raleigh, NC 27615
Phone: 919 848-6773       Mobile: 919 810-7816
email: rdlove@xxxxxxxx          Fax: 208 978-1187
----- Original Message -----
From: "Castellano, Robert" <RCastellano@xxxxxxxxx>
To: "'Peter Jones'" <PJones@xxxxxxxxxxxx>; "'Jim Mollenauer'"
<jmollenauer@xxxxxxxxxxxxxxxxxxxxx>; "'Steven Wood'" <swood@xxxxxxxxx>
Cc: "'Mike Takefman'" <tak@xxxxxxxxx>; "Raj Sharma" <raj@xxxxxxxxxxxx>;
"Jason Fan" <Jason@xxxxxxxxxxxx>; "'Tom Alexander'"
<tom_alexander@xxxxxxxxxxxxxx>; "John Lemon" <JLemon@xxxxxxxxxxxx>; "Dot17
(E-mail)" <stds-802-17@xxxxxxxx>
Sent: Tuesday, April 16, 2002 11:22 PM
Subject: RE: [RPRWG] RE: Fwd: RE: 802.1 architecture question


>
> Peter,
>
> I would even go as far as saying that a non-reflective MAC is
> required to maintain 802.1D/Q compliance.  A bridge receiving
> a packet that was sent to itself can result in frame duplication.
> Section 6.3.4 of 802.1D expressly forbids the duplication of
> frames.
>
> You are covered by saying:
>
> "The 802.17 MAC Service does not
> permit the duplication of frames. The operation of Bridges with an 802.17
> MAC does not introduce duplication of user data frames."
>
>
> thanks,
>
> robert
>
> -----Original Message-----
> From: Peter Jones [mailto:PJones@xxxxxxxxxxxx]
> Sent: Monday, April 15, 2002 8:48 PM
> To: 'Jim Mollenauer'; 'Steven Wood'
> Cc: 'Mike Takefman'; Raj Sharma; Jason Fan; 'Tom Alexander'; John Lemon;
> Dot17 (E-mail)
> Subject: [RPRWG] 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
> ______________________________________________________
>