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


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

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."



-----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
	"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.


-----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


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.


-----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
the ring, for diagnostic and network management purposes.  In fact, the
diagnostic application is more likely to exist as a client than within the
itself.  Think of traceroute in IP as an example.  Another example would be
token rotation time, used in FDDI as a priority mechanism; the token (a
packet) goes around continuously and provides information on the current

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


John Lemon wrote:

> While I agree with everything Peter writes here, I just want to be
> that this should apply only to the interaction with the client. I believe
> 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
> 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
> 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
Direct: +1 408 342 2513          Main: +1 408 342 6400
mailto:pjones@xxxxxxxxxxxx       Fax:  +1 408 863 1148