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