Re: [RPRWG] temporal ordering requirement
I see your point. I wrote it because a good few people at the meeting thought
the other way - that by putting Cisco hat you were (inadvertently) pushing
Cisco viewpoints while the microphone was with you as a chair.
I think your concern makes perfect sense. Thanks a lot for the clarification.
-Pankaj
Mike Takefman wrote:
> Pankaj,
>
> While I appreciate the sentiment, I do think its important for
> me to distinguish when I am giving an opinion as Chair (since
> I foolishly believe it carries some authority) and when I
> give a technical opinion that could have come from any individual
> representing their viewpoint (which I foolishly will carry some
> technical authority).
>
> I actually read an article on how a chair can better perform
> his/her duties. In addition to announcing on my emails which
> hat I am wearing, I will actually be buying a Cisco hat
> and should I choose to comment on something during a meeting
> I will put the cap on so people do not see the comment as
> coming from the chair.
>
> cheers,
>
> mike
>
> Pankaj K Jha wrote:
> >
> > Mike Takefman wrote:
> >
> > > Dave,
> > >
> > > (with my cisco hat on)
> > >
> >
> > Mike:
> >
> > You are as much of a technical participant as the rest of us are, so I
> > guess you don't need to keep changing hats (between Cisco & RPR) - it
> > messes up hair unnecessarily :-)
> >
> > We're discussing here as technical individuals; and we all value your
> > thoughts on issues and truly appreciate your active participation.
> >
> > Best regards,
> > Pankaj
> >
> > > 1998 802.1D shows that data frames from the same src/dst pair
> > > and with the same priority should not be mis-ordered, but data
> > > frames of different priorities or data frames from
> > > different src/dst pairs can be re-ordered.
> > >
> > > I believe the advantages of allowing higher priority traffic
> > > to get ahead of lower priority traffic is desirable to
> > > keep latency and jitter low.
> > >
> > > The issue of link aggregation or its equivalent in an RPR setting
> > > is a different issue and one worth discussion at some point
> > > in the future.
> > >
> > > mike
> > >
> > > Dave Brown wrote:
> > > >
> > > > I suggest we use the same temporal ordering requirement, that link
> > > > aggregation uses, for frames on an RPR ring.
> > > >
> > > > from 2000 802.3
> > > >
> > > > 1.4.94 Conversation: A set of MAC frames transmitted from one end
> > > > station to another, where all of the
> > > > MAC frames form an ordered sequence, and where the communicating end
> > > > stations require the ordering to
> > > > be maintained among the set of MAC frames exchanged. (See IEEE 802.3
> > > > Clause 43.)
> > > >
> > > > Dave.