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

RE: [rprsg] URGENT: Agenda almost ready



Title: RE: [rprsg] URGENT: Agenda almost ready
Harry,
 
Could you be a bit more specific regarding the multiple lambda's phy?

Best regards,
Omer.
-----------------------------
Omer Goldfisher
Director, Product Management
Corrigent Systems
126 Yigal Alon St.
Tel Aviv 67443, Israel
Tel. +972 3 695 2727
Fax. +972 3 695 3222
Tel Direct. +972 3 694 5346
E-mail: omerg@xxxxxxxxxxxxx

-----Original Message-----
From: Harry Peng [mailto:hpeng@xxxxxxxxxxxxxxxxxx]
Sent: Sunday, March 04, 2001 1:07 AM
To: stds-802-rprsg@xxxxxxxx
Subject: RE: [rprsg] URGENT: Agenda almost ready

Mike:
Good points. However, the reconciliation layer is need or not for POS depends on the MAC to PHY interface definition. I don't think that interface has been defined. It could be such that for POS

the reconciliation layer is not required.

I would like to augment to your second point that Lars has brought up in an earlier meeting that the MAC shall support multiple logical "phy clients" e.g. multiple lambda phy. This may be another objective.

..... Harry

-----Original Message-----
From: Mike Takefman [mailto:tak@xxxxxxxxx]
Sent: Thursday, March 01, 2001 2:55 PM
To: stds-802-rprsg@xxxxxxxx
Subject: Re: [rprsg] URGENT: Agenda almost ready



Devendra,

speaking as Chair ...
802.17 should standardize a MAC, and specify how to
use existing PHYs. The MAC should be PHY agnostic
to all different phys (speeds, reach, media) but we
should agree on which PHYs to specify first,
and which to defer for a while.

speaking as a Cisco engineer.
This may require a reconcilliation layer that resides in
the MAC. For example, for POS the MAC does not need any
special reconcilliation layer. It delivers packets to the
PHY. I do not know if the proponents of the use of Ethernet
PHYs requires a reconcilliation layer or not. Depending on
whose silicon one uses, a reconcilliation layer might not
be needed or it might be required.

On service interfaces I would have to think in greater
depth. I believe there is a strong requirement to
have multiple physical interfaces between the MAC and
the upper layer and for that physical interface to
support priority differentiation. Whether this translates into
multiple logical service interfaces I am not sure.

mike

Devendra Tripathi wrote:
>
> Mike,
>
> Let me trigger two questions.
>
> 1. What is our thought on scope:
>
> MAC only
>
> MAC & PHY
>
> Others ?
>
> 2. How many independent service interfaces we will have:
>
> 2 LL (control packets, Data packets) + 2 PHY (two rings)
>
> 1 LL (all packets on same service) + 2 PHY
>
> Others ?
>
> Regards,
>
> Devendra Tripathi
> VidyaWeb, Inc
> 90 Great Oaks Blvd #206
> San Jose, Ca 95119
> Tel: (408)226-6800,
> Direct: (408)363-2375
> Fax: (408)226-6862
>
> > -----Original Message-----
> > From: owner-stds-802-rprsg@xxxxxxxx
> > [mailto:owner-stds-802-rprsg@xxxxxxxx]On Behalf Of Mike Takefman
> > Sent: Tuesday, February 27, 2001 5:45 PM
> > To: pazy@xxxxxxxxxxxxxxxxxx
> > Cc: stds-802-rprsg@xxxxxxxx
> > Subject: Re: [rprsg] URGENT: Agenda almost ready
> >
> >
> >
> > Offer,
> >
> > sorry for the delay in replying.
> >
> > The primary output of the march meeting will be
> > two things.
> >
> > 1) Terms and definitions that will end up going
> > into the standard, but also serve as a level
> > set to insure when we are voting on objectives we
> > all are agreeing (or disagreeing) about the same
> > thing.
> >
> > 2) Some (or perhaps all) objectives for the RPRWG.
> > These will end up in an document for the WG.
> >
> > Now, at the last meeting we requested that people
> > start sending email to the reflector on either of
> > the above as to stimulate discussion.
> >
> > Perhaps there will be some in the next 2 weeks, if
> > not we do it all at the meeting.
> >
> > cheers,
> >
> > mike
> >
> > Offer Pazy wrote:
> > >
> > > Mike,
> > >
> > > Although not directly related to the agenda, there is something
> > missing from
> > > our planning for the March meeting: "What is the expected output of this
> > > meeting?" That is, I can gather from the topics below where
> > we'll hopefully
> > > make progress, but it would be better if we can try to commit to more
> > > concrete and deliverable (as our managers always like us to
> > commit) goals.
> > > If there was a metric for consensus, I would aim at achieving
> > something like
> > > that. But in its absence, how about a "good draft of objectives
> > document"?
> > >
> > > Offer Pazy
> > > Sr. Product Manager
> > > Native Networks
> > > 15 Gonen St.
> > > Petah Tikva 49170
> > > Israel
> > > Tel: +972 3 921-0010 Ext. 229
> > > Fax: +972 3 921-0080
> > > pazy@xxxxxxxxxxxxxxxxxx <mailto:pazy@xxxxxxxxxxxxxxxxxx>
> > > http://www.nativenetworks.com
> > >
> > > The Native Way = Ethernet Simplicity + SONET Reliability
> > >
> > > -----Original Message-----
> > > From: owner-stds-802-rprsg@xxxxxxxx
> > [mailto:owner-stds-802-rprsg@xxxxxxxx]On
> > > Behalf Of Mike Takefman
> > > Sent: Tuesday, February 20, 2001 07:29
> > > To: stds-802-rprsg@xxxxxxxx
> > > Subject: [rprsg] URGENT: Agenda almost ready
> > >
> > > People,
> > >
> > > I've got a preliminary agenda pulled together, but
> > > it is really tight. Here is the rough view,
> > > we work from 8 am to 6 pm each day.
> > >
> > > Monday AM Parallel sessions
> > >  - Performance Ad-Hoc
> > >  - Introduction to RPR for new antendees
> > >
> > > Monday Afternoon
> > >  - administrivia
> > >  - end-user presentations
> > >
> > > Tuesday
> > >   - Overall Scope / Objectives / Requirements
> > >   - Resiliency Objectives
> > >   - Interoperability Requirements
> > >
> > > Wednesday
> > >   - Bandwidth Management
> > >   - Simulation Results
> > >   - Action Items from previous meetings
> > >
> > > Thursday
> > >   - Perf Adhoc Report
> > >   - Voting Rights Administration
> > >   - Election of Officers
> > >   - Motions on Objectives
> > >   - Planning the next meeting
> > >
> > > I've had to cut people's presentations a little
> > > to include time for questions. This will force people
> > > to be concise :) I.E. a 30 minute presention is
> > > 24 minutes to talk and 6 minutes of questions.
> > >
> > > I would like schedule a meeting on tuesday
> > > night so that I can open up the schedule a
> > > little (allow for more discussion).
> > >
> > > Right now there are not many tutorials scheduled
> > > so I think we will not conflict at all.
> > >
> > > I was thinking of a session from 8pm to 10:30pm.
> > >
> > > Please respond to the reflector with your
> > > thoughts on whether this is a good or bad idea.
> > >
> > > I will send out the current schedule to all
> > > presenters tonight to make sure that I did not
> > > miss anyone. If you did not see a message from
> > > me with a pdf of the schedule then I missed you
> > > so yell.
> > >
> > > thanks,
> > >
> > > mike
> > >
> > > --
> > > Michael Takefman              tak@xxxxxxxxx
> > > Manager HW Engineering,       Cisco Systems
> > > Chair IEEE 802.17 Stds WG
> > > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > > voice: 613-271-3399       fax: 613-271-4867
> >
> > --
> > Michael Takefman              tak@xxxxxxxxx
> > Manager HW Engineering,       Cisco Systems
> > Chair IEEE 802.17 Stds WG
> > 2000 Innovation Dr, Ottawa, Canada, K2K 3E8
> > voice: 613-271-3399       fax: 613-271-4867
> >

--
Michael Takefman              tak@xxxxxxxxx
Manager HW Engineering,       Cisco Systems
Chair IEEE 802.17 Stds WG
2000 Innovation Dr, Ottawa, Canada, K2K 3E8
voice: 613-271-3399       fax: 613-271-4867