Subject: RE: Choice of draft(s)

From: "Bob Barrett" <[email-masked]>
Date: Wed, 11 Sep 2002 08:32:58 +0100

Shahram - to change the subject of this track to a more general question:

How many protocols can PWE3 specify?

For my two cents worth I would make the comment that the intermediate step
of ATM and Sonet VT protocols complicate the clock recovery process.
Historically the implementation of clock recovery on ATM and Sonet equipment
has been pretty crude in order to keep component cost, power consumption and
physical size down. That should change with the next round of equipment
because LIUs and framers are smaller, cheaper and have better clock
mechanisms.

If we look at just edge to edge application then there is little
justification for an intermediate step through an existing SAR / VT
protocol.

However, if we look at edge to SP switch application then there is
justification for leverageing existing SAR / VT protocols.

One thing that I think PWE3 should do is limit the granularity to a full E1
or T1 circuit. I can't see a benefit in saving DS0 bandwidth against the
complication that this brings to the scalability issue. I don't know enough
about CAS to make a valid judgement regarding the pros and cons of
extracting CAS control data from the payload. I can envisage that there may
be some elements of distributed state that might lock-up if Ethernet frames
are lost or replayed. I do know that CCS has sufficient error recovery at
layer two to cope with the odd lost Ethernet frame corrupting an HDLC
message that is split across multiple frames. Complete outages can mess up
CCS, but that's a fault of the implementation in the end systems, not the
transport.

The question is should the simpler edge to edge application, which may well
be targetted at enterprise users rather than SPs, be burdened (in the
opinion of some) with the intermediate protocol step, or should PWE3 select
one generic solution that fits both applications. The latter seems the more
logical answer, so now we are left with the question which one, ATM or Sonet
based. And if we compromise and say 'both' then the edge to edge people have
every right to say 'why not all three then'.

I don't think that _equipment_ time to market will be impacted by the choice
made by PWE3. I would think most platforms developed for this application
are sufficiently programmable to cater for any of the current drafts.

However, the time to market for _integrated_circuits_ probably will be
impacted, and this in turn will impact the time scales for scalability and
cost reduction of equipment.

Having said that, the target market is no longer moving at warp speed,
unless of course we are considering the enterprise sector :-).

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Shahram Davari
Sent: 10 September 2002 16:18
To: [email-masked]'; [email-masked]
Cc: Sasha Vainshtein
Subject: RE: [PWE3] (no subject) TDM implementation

Tim,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, September 10, 2002 11:06 AM
> To: Shahram Davari; [email-masked]
> Cc: Sasha Vainshtein
> Subject: RE: [PWE3] (no subject) TDM implementation
>
>
> Shahram,
>
> In response to your comments on implementation:
>
> > > There are
> > > off the shelf AAL1/2 and SONET-VT chips in the market.
> > > In other
> > > words the SARing could be done with off the shelf available
> > > HW, rather than writing SW for it in a CPU, which is also
> > > rate limited to a few T1/E1/DS3s.
>
> AAL1/2 SARs are commercially available, however, they don't
> do the whole
> job. You still need a CPU to strip off the ATM headers, pack
> the cells
> into packets and add the appropriate pseudo-wire headers.

Correct.

>
> Besides, are we suggesting that we fix the standard on the
> basis of which
> chips are commercially available now?
> Simplicity of implementation should not be determined by what
> one can buy
> today, since tomorrow's performance requirements will outgrow today's
> solutions. Who says tomorrow's implementation will be
> software in a CPU?

No, What I am suggesting is why invent a new protocol, when one already
exists.
It is always possible to invent a new protocol for specific scenarios
that the original protocol was not optimized for. This logic ends in
numerous protocols and their interworking nightmare.

Also the time to market is of importance. Why invent a new protocol from
scratch, when already HW/SW is available for a similar protocol that does
the job.

Yours,
-Shahram
_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 11 Sep 2002 14:09:09 +0200

Do we know the opinion of the network operators on this issue? 
Which alternative(s) would be their preference?

Can we draft a summary of the alternatives with their pros and cons, and ask the
operator community to indicate their preference?

Regards,

Maarten