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

[Peter Jones <PJones@xxxxxxxxxxxx>]

Robert,

I see what you are saying, but track through the email trail on the original
message. 

802.2 (yes I know it's old) explicitly requires the function as part of it's
check for duplicate station addresses, and a bunch of the older protocols
used to use this type of thing.

I'm very happy to make 802.17 "non-reflective" and I think it's common sense
to do this. I just wanted to make sure this wasn't an area to get tripped up
in.

As Mick Seaman said in one of his mails:
"I suspect that this defies a clear and authoritative answer since it has
been an item of dispute, to my knowledge since before I started attending
802 meetings in 1985. It is so black and white that it is hard to arrange a
win-win for the different opinions and thus it has been left unaddressed for
many years now."

Having gone through the process of talking to the 802.1 group about this,
and having had them "accept" a proposal may save an argument or two later
down the track.

regards
Peter


-----Original Message-----
From: Castellano, Robert [mailto:RCastellano@xxxxxxxxx]
Sent: Tuesday, April 16, 2002 8:23 PM
To: 'Peter Jones'; 'Jim Mollenauer'; 'Steven Wood'
Cc: 'Mike Takefman'; Raj Sharma; Jason Fan; 'Tom Alexander'; John Lemon;
Dot17 (E-mail)
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
______________________________________________________