Subject: AAL1/2 transport over IP/MPLS networks

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Aug 2002 11:26:59 -0700

Hi,

Please post the attached draft as a submission to PWE3 WG.

Thanks,
Shahram Davari

---

From: "Daniel Feldman" <[email-masked]>
Date: Tue, 27 Aug 2002 23:34:04 +0200

Hello Mr. Davari,
	Do you have any intention of extending the current draft for
AAL2 CPS_packets, in which case it is possible to do AAL2 Switching +
AAL2oIP encapsulation?
	Thanks,
Daniel Feldman

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 8:27 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: [PWE3] AAL1/2 transport over IP/MPLS networks

Hi,

Thanks,
Shahram Davari

*** eSafe scanned this email for malicious content ***
*** IMPORTANT: Do not open attachments from unrecognized senders  ***

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Aug 2002 13:38:05 -0700

Hi,
 
My main goal was to use the AAL5 PDU mode. I have looked in to extending it, but found that it won't be compatible with AAL5 PDU mode. 
 
Thanks,
-Shahram

-----Original Message-----
From: Daniel Feldman [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 5:34 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

        Hello Mr. Davari, 
        Do you have any intention of extending the current draft for AAL2 CPS_packets, in which case it is possible to do AAL2 Switching + AAL2oIP encapsulation?

        Thanks, 
Daniel Feldman 

-----Original Message----- 
From: Shahram Davari [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Tuesday, August 27, 2002 8:27 PM 
To: [email-masked]' 
Cc: [email-masked]' 
Subject: [PWE3] AAL1/2 transport over IP/MPLS networks 

Hi, 

Thanks, 
Shahram Davari

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Aug 2002 16:45:32 -0400

Shahram,

The WG has been converging for some time on draft-anavi-tdmoip-04.txt for 
this application, and at this point the draft is very mature and well 
thought out, and includes support for all of the PSNs being discussed in 
the WG and takes advantage of RTP when required.  Can you justify switching 
to a brand new draft in the same space at this time?

Thanks,
Andy

-------

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Aug 2002 14:00:41 -0700

Hi Andy,
 
My perception was that there was no convergence, so I tried to break the deadlock with a draft that does not introduce any new protocol, and just reuses the AAL5 PDU mode.
 
Yours,
-Shahram

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 4:46 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

The WG has been converging for some time on draft-anavi-tdmoip-04.txt for this application, and at this point the draft is very mature and well thought out, and includes support for all of the PSNs being discussed in the WG and takes advantage of RTP when required.  Can you justify switching to a brand new draft in the same space at this time?

Thanks,
Andy

-------

Hi, 

Thanks, 
Shahram Davari

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Aug 2002 14:24:56 -0700

Andy,
 
Please note that except from the flag positions, it is essentially the same draft as draft-anavi, just made compatible with AAL5 PDU hardware/software.
 
If the work group thinks that they have converged on draft-anavi and want to make it a WG document, then I would withdraw my draft.
 
Yours,
-Shahram 

-----Original Message-----
From: Shahram Davari 
Sent: Tuesday, August 27, 2002 5:01 PM
To: 'Andrew G. Malis'
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Hi Andy,

Yours,
-Shahram

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 4:46 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Thanks,
Andy

-------

Hi, 

Thanks, 
Shahram Davari

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 27 Aug 2002 18:27:18 -0400

Shahram,

Thanks.  The deadlock isn't about the draft-anavi encapsulation, but rather 
whether to use AAL1/AAL2 vs. SONET VTs vs. raw data when carrying TDM 
across PSNs.  Your draft just introduces yet another alternative in the 
same category as draft-anavi.

Cheers,
Andy

-------

At 8/27/2002 02:24 PM -0700, Shahram Davari wrote:
>Andy,
>
>Please note that except from the flag positions, it is essentially the 
>same draft as draft-anavi, just made compatible with AAL5 PDU 
>hardware/software.
>
>If the work group thinks that they have converged on draft-anavi and want 
>to make it a WG document, then I would withdraw my draft.
>
>Yours,
>-Shahram
>>My perception was that there was no convergence, so I tried to break the 
>>deadlock with a draft that does not introduce any new protocol, and just 
>>reuses the AAL5 PDU mode.
>>
>>Yours,
>>-Shahram
>>
>>>The WG has been converging for some time on draft-anavi-tdmoip-04.txt 
>>>for this application, and at this point the draft is very mature and 
>>>well thought out, and includes support for all of the PSNs being 
>>>discussed in the WG and takes advantage of RTP when required.  Can you 
>>>justify switching to a brand new draft in the same space at this time?
>>>
>>>Thanks,
>>>Andy
>>>
>>>-------
>>>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Aug 2002 15:51:39 -0700

Andy,

I didn't say that the draft-anavi's encapsulation is the deadlock. My understanding is that there is a deadlock between choosing draft-anavi, draft-pate, draft-vainstein for doing lower rate TDM emulation over PSN.
 
What I am trying to do is to eliminate the need to choose one or the other by the WG, by introducing essentially an informational draft about how to use AAL5 PDU (without modification) to transfer AAL1/2 PDUs efficiently. It could be used by operators who have upgraded part of their ATM network to IP/MPLS, specially those that want to use boxes with AAL5 PDU mode. 
 
Although it could be leveraged to emulate TDM over PSN (in the same box) as described in draft-anavi, but you don't have to. 
 
The conclusion is that what I am proposing is there already, I am not introducing any new mode or any new protocol or any new option. Essentially there is nothing to choose, it is all informational. 

Yours,
-Shahram

 -----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 6:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Thanks.  The deadlock isn't about the draft-anavi encapsulation, but rather whether to use AAL1/AAL2 vs. SONET VTs vs. raw data when carrying TDM across PSNs.  Your draft just introduces yet another alternative in the same category as draft-anavi.

Cheers,
Andy

-------

Andy,

 
Yours,
-Shahram 

-----Original Message-----
From: Shahram Davari 
Sent: Tuesday, August 27, 2002 5:01 PM
To: 'Andrew G. Malis'
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Hi Andy,

Yours,
-Shahram

-----Original Message-----
From: Andrew G. Malis [ mailto:[email-masked] <mailto:[email-masked]> ]
Sent: Tuesday, August 27, 2002 4:46 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Thanks,
Andy

-------

Hi, 

Thanks, 
Shahram Davari

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 27 Aug 2002 19:17:12 -0400

Shahram,

            Whatever you might call it, it looks like an end-run.

            Is it intended to be an informational description of what

you do, or is it intended to be a proposal for everyone else to do

the same?  If the latter, then it is an attempt to bypass the WG

process and it will not get by...

Eric W. Gray

Systems Architect

Celox Networks, Inc.

[email-masked]

508 305 7214

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2002 6:52 PM
To: 'Andrew G. Malis'
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Andy,

I didn't say that the draft-anavi's encapsulation is the deadlock. My
understanding is that there is a deadlock between choosing draft-anavi,
draft-pate, draft-vainstein for doing lower rate TDM emulation over PSN.

What I am trying to do is to eliminate the need to choose one or the other
by the WG, by introducing essentially an informational draft about how to
use AAL5 PDU (without modification) to transfer AAL1/2 PDUs efficiently. It
could be used by operators who have upgraded part of their ATM network to
IP/MPLS, specially those that want to use boxes with AAL5 PDU mode. 

Although it could be leveraged to emulate TDM over PSN (in the same box) as
described in draft-anavi, but you don't have to. 

The conclusion is that what I am proposing is there already, I am not
introducing any new mode or any new protocol or any new option. Essentially
there is nothing to choose, it is all informational. 

Yours,

-Shahram

 -----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 6:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Thanks.  The deadlock isn't about the draft-anavi encapsulation, but rather
whether to use AAL1/AAL2 vs. SONET VTs vs. raw data when carrying TDM across
PSNs.  Your draft just introduces yet another alternative in the same
category as draft-anavi.

Cheers,
Andy

-------

Andy,
 
Please note that except from the flag positions, it is essentially the same
draft as draft-anavi, just made compatible with AAL5 PDU hardware/software.
 
If the work group thinks that they have converged on draft-anavi and want to
make it a WG document, then I would withdraw my draft.
 
Yours,
-Shahram 

-----Original Message-----
From: Shahram Davari 
Sent: Tuesday, August 27, 2002 5:01 PM
To: 'Andrew G. Malis'
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Hi Andy,

Yours,
-Shahram

-----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, August 27, 2002 4:46 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

The WG has been converging for some time on draft-anavi-tdmoip-04.txt for
this application, and at this point the draft is very mature and well
thought out, and includes support for all of the PSNs being discussed in the
WG and takes advantage of RTP when required.  Can you justify switching to a
brand new draft in the same space at this time?

Thanks,
Andy

-------

Hi, 

Thanks, 
Shahram Davari

---

From: "Gray, Eric" <[email-masked]>
Date: Tue, 27 Aug 2002 19:59:45 -0400

Lloyd,

	It's simple enough.  You attempt to pass off
as informational a description of a common way to 
do something.  "Common" in such a context is the
same as "standard".

	Calling a frying pan a feather will not make
it feel better as it hits you on the head...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Lloyd Wood [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2002 7:48 PM
To: Gray, Eric
Cc: 'Shahram Davari'; 'Andrew G. Malis'; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

> process and it will not get by...

How on earth can a submitted draft announced in this WG be an attempt
to bypass the WG process?

As far as I can see, if you want to bypass the PWE3 WG you would just
pick up your ball and run off home to the MPLS/PPVPN/L2TP WG instead.

Malis wrote:
>> this application,

You know, I'd like a second opinion from the chair/ADs/tech advisor.

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 27 Aug 2002 17:48:43 -0700

Eric,

1) I am not bypassing the WG, otherwise I would have submitted it as
individual submission.

2) Informational is informational. It does not bring any enforcement.
I am just telling people that they can do AAL1/2 transport over PSN
using existing ATM transport mode. 

3) If you have technical issues, please raise them instead.

Yours,
-Shahram

-----Original Message-----
From: Gray, Eric
To: Shahram Davari; 'Andrew G. Malis'
Cc: [email-masked]
Sent: 27/08/02 4:17 PM
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Eric W. Gray

Systems Architect

Celox Networks, Inc.

[email-masked]

508 305 7214

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, August 27, 2002 6:52 PM
To: 'Andrew G. Malis'
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Andy,

What I am trying to do is to eliminate the need to choose one or the
other by the WG, by introducing essentially an informational draft about
how to use AAL5 PDU (without modification) to transfer AAL1/2 PDUs
efficiently. It could be used by operators who have upgraded part of
their ATM network to IP/MPLS, specially those that want to use boxes
with AAL5 PDU mode. 

Although it could be leveraged to emulate TDM over PSN (in the same box)
as described in draft-anavi, but you don't have to. 

The conclusion is that what I am proposing is there already, I am not
introducing any new mode or any new protocol or any new option.
Essentially there is nothing to choose, it is all informational. 

Yours,

-Shahram

 -----Original Message-----
From: Andrew G. Malis [mailto:[email-masked]]
Sent: Tuesday, August 27, 2002 6:27 PM
To: Shahram Davari
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Thanks.  The deadlock isn't about the draft-anavi encapsulation, but
rather whether to use AAL1/AAL2 vs. SONET VTs vs. raw data when carrying
TDM across PSNs.  Your draft just introduces yet another alternative in
the same category as draft-anavi.

Cheers,
Andy

-------

Andy,

If the work group thinks that they have converged on draft-anavi and
want to make it a WG document, then I would withdraw my draft.
 
Yours,
-Shahram 

-----Original Message-----
From: Shahram Davari 
Sent: Tuesday, August 27, 2002 5:01 PM
To: 'Andrew G. Malis'
Cc: [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Hi Andy,

Yours,
-Shahram

-----Original Message-----
From: Andrew G. Malis [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, August 27, 2002 4:46 PM
To: Shahram Davari
Cc: [email-masked]
Subject: Re: [PWE3] AAL1/2 transport over IP/MPLS networks

Shahram,

Thanks,
Andy

-------

Hi, 

Thanks, 
Shahram Davari

---

From: Danny McPherson <[email-masked]>
Date: Tue, 27 Aug 2002 22:20:36 -0600

> You know, I'd like a second opinion from the chair/ADs/tech advisor.

I suppose if you're considering AAL1/AAL2-based approaches for 
TDM emulation then considering the anavi draft is the only one 
submitted to the WG at this point, one might presume some type
of convergence.

However, whether that suggests we're converging on anything or not
is indeed a different issue.  

That being the case, more feedback on pate v. anavi v. vainshtein 
and which drafts should or should not be WG items would help to 
generate consensus (and yes, I'm obviously well aware of the current
state of the pate draft).  Comments?

-danny

---

From: Shahram Davari <[email-masked]>
Date: Wed, 28 Aug 2002 05:57:41 -0700

Eric,

This draft is about transporting AAL1/2 over PSN. The discussion on TDM transport is a separate topic.

Having said that, why do you want to prevent people who already have the AAL5-PDU mode to use it
for transporting AAL1/2? Do you have a better and more efficient proposal?

Yours,
-Shahram

> From: Gray, Eric [mailto:[email-masked]]
> Sent: Tuesday, August 27, 2002 8:00 PM
> To: 'Lloyd Wood'; Gray, Eric
> Cc: Shahram Davari; 'Andrew G. Malis'; [email-masked]

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 28 Aug 2002 11:03:38 -0400

Shahram,

	I believe there is a proposal already on the
table (at least implicitly).  I would not presume to
take credit for it, so I would not say that _I_ have
another proposal.  However, the other proposal has
been on the table for some time, so the onus falls
on you to show that _your_ proposal is better (or
more efficient).

	The "other proposal" is simplicity itself.  I can
use ATM Cell Relay mode as defined in the Internet Draft: 
draft-martini-atm-encap-mpls-01.txt. This draft allows 
for transporting multiple ATM Cells in a single MPLS 
packet/frame.  The only thing left to do is for egress 
to 'shape' the cells emerging from the other end of the 
pseudo wire.  How the implementations decide what cells 
to include in which frames at pseudo wire ingress, is 
an implementation issue - just as deciding how to shape
the cells at the egress is.

	This is so simple, that nobody really needs to
write an ID for it.  I'm guessing that is why nobody
has.

	Your proposal, on the other hand, is relatively
opaque from start to end.  It uses AAL5 PDU transport
as it is apparently defined in the Internet Draft
draft-fischer-pwe3-atm-service-03 (though you have to 
follow the reference through the Applicability draft
- draft-bocci-pwe3-app-frame-over-psn-00 - to find that
out) to carry AAL1 or AAL2 frames.

	Why do we need the complexity?  

	Why would my system want to know what type of 
cells it is carrying, if it does not need to?

	More importantly, why do we need yet another way
to do this?

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Wednesday, August 28, 2002 8:58 AM
To: 'Gray, Eric'; 'Lloyd Wood'
Cc: 'Andrew G. Malis'; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Eric,

This draft is about transporting AAL1/2 over PSN. The discussion on TDM
transport is a separate topic.

Having said that, why do you want to prevent people who already have the
AAL5-PDU mode to use it
for transporting AAL1/2? Do you have a better and more efficient proposal?

Yours,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Wed, 28 Aug 2002 08:38:01 -0700

Eric,

> Sent: Wednesday, August 28, 2002 11:04 AM
> To: Shahram Davari; 'Lloyd Wood'

1) Draft-anavi is not a method to do AAL1/2 transport, rather
it is a TDM emulation method that uses AAL1/2 as an interim stage.
So for example you can't use it to connect an ATM box that carries
AAL1/2 to a PE box and transport the AAL1/2 over PSN.

2) I am not trying to compete with draft-anavi. In fact I support draft-anavi
and my draft has been written with close consultation with draft-anavi authors.
And if you spend some time to read it carefully you will see that draft-anavi
uses essentially the same method in my draft with only a flag change.

> write an ID for it.  I'm guessing that is why nobody

If that is the logic then nobody needs the drafts on AAL5
PDU and SDU mode either ! So why don't you propose to get
rid of them?

> opaque from start to end.

That is in fact the nice property of this draft.

> It uses AAL5 PDU transport

What complexity? Are you saying that AAL5 PDU mode is complex?
If so then what do you think about AAL5 SDU mode?
  
> cells it is carrying, if it does not need to?

I think you need to read  the draft more carefully. 
I have reused the AAL5 PDU mode so that if you setup the
HW/SW as mentioned the system does not need to know what
type of cell it is carrying. It could carry mix AAL1/2/3/4/5.

> 	More importantly, why do we need yet another way

See bullet 1 and 2 above.

Yours,
-Shahram

---

From: "tom k. johnson" <[email-masked]>
Date: Wed, 28 Aug 2002 11:48:11 -0400

At the risk of pouring gasoline onto a fire, I have a related question... 

Is the working group planning to support two different methods for carrying T1/E1s, one based on VT-mapping (pate) and one based on "native" emulation (vainshtein or anavi or davari)?  

Should we discuss whether or not we want to support two different (and non-interoperable) methods for carrying T1/E1s over PSNs as a part of this process?

It seems to me that one method for emulating T1/E1s would be preferable to two for many reasons, regardless of whether the method is VT-based or native.

Comments (or abuse) welcome!

-Tom

> From: Danny McPherson [mailto:[email-masked]]
> Sent: Wednesday, August 28, 2002 12:21 AM
> To: [email-masked]
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 28 Aug 2002 19:09:51 +0300

> on you to show that _your_ proposal is better (or

Hi all, 

I just wanted to let you know that Shahram and I 
are cooperating on this issue, and what Shahram
is proposing is NOT a new technique, rather a new
way of looking at TDMoIP, which has been on the
table all along.

In the TDMoIP draft we talk about transport of TDM,
using AAL1 and AAL2 techniques. Shahram's draft
simply demonstrates that the same thing can be worded
the other way around - AAL1/2 transport which can
be used for TDM.

The nice thing about this way of stating things
is that it doesn't require a completely new standards track
document. By minimal changes in the Martini ATM document
(namely re-use of the AAL5 PDU mode as an AALX PDU mode),
we can accomodate TDMoIP.

Right now there are still a few technical details that are different.
For example, 
  1) the control word is a little different 
    (TDMoIP uses the Martini ATM CW, 
     while Shahram uses the AAL5-SDU mode CW)
  2) The TDMoIP draft has an FORMID identifier and two TDM flag bits
  3) the TDMoIP AAL2 mode does not use the CPS-PDU header Start Field byte.
  4) the TDMoIP draft has its own optional OAM flow.
But all of these issues can be easily worked out.

Y(J)S

Yaakov (Jonathan) Stein        [email-masked] 
Chief Scientist                        +972 3 6455389   +972 2 5889159
RAD Data Communications   24 Raoul Wallenburg St., Tel-Aviv 69719, Israel

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 28 Aug 2002 19:23:24 +0300

> Is the working group planning to support two different 
> methods for carrying T1/E1s, one based on VT-mapping (pate) 
> and one based on "native" emulation (vainshtein or anavi or davari)?  

I am not quite sure how the VT-mapping draft (Pate)
appeared suddenly as a WG draft, but I don't recall
a round of hums at the meeting, or any ballot here on the list.

What I recall Danny saying at the meeting was that both
the Pate draft and CESoPSN had enough support to become WG items.

Danny then raised the question on the list (see his email from 15/7)
whether there was support for working on the TDMoIP draft as well, 
and received quite a few replies. On 25/7 he then concluded

  The trigger for my query regarding that particular draft was
  regarding interest in multi-vendor support and interest in 
  implementation, I think that's been demonstrated. 

>From that I understand that all three TDM drafts have significant
support in the WG. (As I mentioned in an earlier email, davari
is not a new independent standards-track draft, but rather an 
informational draft explaining how TDMoIP can be viewed
as an atm-encaps mode).

Y(J)S

---

From: "Gray, Eric" <[email-masked]>
Date: Wed, 28 Aug 2002 12:28:20 -0400

Shahram,

	See below...

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Wednesday, August 28, 2002 11:38 AM
To: 'Gray, Eric'; 'Lloyd Wood'
Cc: 'Andrew G. Malis'; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Eric,

2) I am not trying to compete with draft-anavi. In fact I support 
draft-anavi and my draft has been written with close consultation 
with draft-anavi authors. And if you spend some time to read it 
carefully you will see that draft-anavi uses essentially the same 
method in my draft with only a flag change.

Eric >> I am not referring to draft-anavi as should be obvious
Eric >> below...

Eric >> I'd be happy to, but I would be shooting myself
Eric >> in the foot.  Because AAL5 is the dominant ATM
Eric >> adaptation layer, there are many vendors whose
Eric >> boxes are optimized for AAL5 processing.
Eric >>
Eric >> It is one thing to say "we have a general approach
Eric >> and we also have one for a specific subset due to 
Eric >> considerations for existing optimizations"; it is
Eric >> quite a different thing to use this as justification
Eric >> for defining approaches for additional subsets. A
Eric >> little redundancy may be okay if it is justified,
Eric >> but it is much harder to justify complete protocol
Eric >> redundancy. 

Eric >> Obviously, I think it's okay.  But suppose for
Eric >> a moment I was not enamored with it.  Why would
Eric >> I want to support both AAL5 CPCS-SDU and AAL5 PDU?
Eric >> Therein lies the complexity...

Eric >> These do not apply because I am not talking
Eric >> about the Anavi draft.

Yours,
-Shahram

---

From: Shahram Davari <[email-masked]>
Date: Wed, 28 Aug 2002 11:41:48 -0700

Danny,

My draft has been the result of consultation with the authors
of all the other 3 drafts already available. During the last IETF meeting
all of the authors felt a way to avoid confrontation between these
drafts is to proceed with an AAL1/2 transport draft, and then add to the
applicability draft the scenarios that this could be leveraged for
TDM emulation, such as when interworking with an already existing 
AAL1/2 network such as wireless is desired.

draft-anavi authors tried to add the AAL1/2 mode as a new mode to
Martini draft, but was rejected by Luca, because he said there are
already too many modes. So the alternative that we (Yaakov and I) thought was to
come up with a method to reuse one of the ATM modes. My draft has been
written with consultation with draft-anavi authors and they fully approve it.

Again I think this way of moving forward is the best, because we are not introducing
any new mode, or new standards track. If people already have the AAL5 PDU hardware
and software or if they are interworking with an AAL1/2 network, then they may
choose to use the methods described in this draft. 

We certainly can't prevent people from using available standards and 
hardware/software to achieve a new functionality. We are just informing
them that this is possible with today's tools.

Yours,
-Shahram

---

From: "Ron Cohen" <[email-masked]>
Date: Thu, 29 Aug 2002 12:15:05 +0200

Shahram,

I think what is confusing people is that you tried to have it both ways,
that is, instead of modifying draft-anavi to be an AAL1/AAL2 emulation
proposal, that together with an NSP function of mapping TDM to AAL1/AAL2
can be used to carry TDM traffic, you didn't modify draft-anavi, but
wrote another draft.

What is even more confusing is that you say that you are coordinated
with draft-anavi authors. If you are, I suggest that you and Yaakov sit
together and decide what you want to do. If you want an AAL1/AAL2 draft,
please write a single proposal draft in this spirit, and please have the
encapsulation consistent. If Yaakov doesn't want to propose an AAL1/AAL2
emulation proposal, but rather insist that he has a TDM emulation
proposal that happens to use AAL1/AAL2 this is ok too. But then, if you
think differently, please speak up.

Regards
Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Shahram Davari
> Sent: Wednesday, August 28, 2002 8:42 PM
> To: 'Danny McPherson'
> Cc: [email-masked]
> of all the other 3 drafts already available. During the last 
> IETF meeting all of the authors felt a way to avoid 
> confrontation between these drafts is to proceed with an 
> AAL1/2 transport draft, and then add to the applicability 
> draft the scenarios that this could be leveraged for TDM 
> emulation, such as when interworking with an already existing 
> draft-anavi authors tried to add the AAL1/2 mode as a new 
> mode to Martini draft, but was rejected by Luca, because he 
> said there are already too many modes. So the alternative 
> that we (Yaakov and I) thought was to come up with a method 
> to reuse one of the ATM modes. My draft has been written with 
> consultation with draft-anavi authors and they fully approve it.
> 
> Again I think this way of moving forward is the best, because 
> we are not introducing any new mode, or new standards track. 
> If people already have the AAL5 PDU hardware and software or 
> if they are interworking with an AAL1/2 network, then they 
> may choose to use the methods described in this draft. 
> 
> hardware/software to achieve a new functionality. We are just 
> informing them that this is possible with today's tools.
> 
> Yours,
> -Shahram

---

From: Shahram Davari <[email-masked]>
Date: Thu, 29 Aug 2002 07:30:14 -0700

Sasha,

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: Thursday, August 29, 2002 11:11 AM
> To: Shahram Davari
> Cc: [email-masked]; 'Ron Cohen'; 'Danny McPherson'
> I concur with Ron regarding coordination (or lack thereof)
> between draft-anavi and draft-davari.

Thanks, we will do that in the coming days.

> 
> I would also like to drop in a technical comment on draft-davari,
> namely on "reuse" of the of the AAL5 PDU mode defined in draft-bocci.
> My understanding of this "reuse" is that you propose to treat the 
> entire AAL1/AAL2 cell stream as a _single_ _unlimited_ AAL5 PDU.
> I suspect (please correct me if I am wrong here) that this may be
> a source of problems if (otherwise, interoperable) implementations
> of draft-bocci introduce certain validity checks which look
> quite reasonable to me, e.g.:
> a) An implementation that does not allow COM-marked
>    packets to appear without a preceding BOM-marked one
>    would drop the entrire AAL1/AAL2 stream if the very
>    first packet (the only one you defined as BOM-marked)
>    has been, for whatever reason, dropped

Such implementation will not be compliant with AAL5 PDU mode.
Because AAL5 PDU mode does not require such behavior.

> b) An implementation that checks that the max. size of
>    an AAL5 PDU is not exceeded (a reasonable precaution
>    if you assume that some EOM and BOM-marked packets may 
>    be dropped) will discared all the packets once this 
>    limit has been exceeded, and, since the BOM marking 
>    is never repeated, will not ever operational.

That is why the draft says fragmentation MUST be enabled.

> 
> Can you please explain why you do not want to mark 
> all the packets  with SSM?

1) Since incoming AAL1/2 cells don't have their UU-bit=1,
the BOM followed by COM is the normal behavior of AAL5 PDU mode HW/SW.
I didn't want to change the AAL5 PDU mode.
2) I wanted to preserve the UU-bit transparency for future
proofness. (although not used by AAL1/2 at the moment). 

Yours,
-Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 29 Aug 2002 17:10:51 +0200

Shahram,

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> From: Ron Cohen [mailto:[email-masked]]
> Sent: Thursday, August 29, 2002 12:15 PM
> To: 'Shahram Davari'; 'Danny McPherson'
> Cc: [email-masked]

---

From: "Bob Barrett" <[email-masked]>
Date: Thu, 29 Aug 2002 22:53:24 +0100

Tom / Danny

I have no problem with three methods, as there are three scenarios in the
market. The same 'unique identity' issue comes up in other bodies, and the
old guard 'standards police' get all hot about it on a regular basis.
However, getting heated up about it does not change the installed base and
the requirements of the people that buy the stuff. I don't think there is a
single simple answer in PWE3 that would meet the unique identity
requirement, and the needs of the broad market. It's a catch 22 (yes, I am
almost old enough to consider myself old guard in another place).

>> quoted from one of Danny's emails
Right, and this is where the problem arises.  Progressing three
drafts and distinct methods in the WG to answer one question won't
happen, especially when the IESG folks begin pounding on me/us.
<< end quote

The method based on an ATM AAL (let the ATM guys resolve which particular
AAL) for those that have existing ATM VT-mapping expertise and are therefore
able to service the market for interoperability with the installed base of
ATM VT equipment.

The method based on an Sonet / SDH VT-mapping for those that have existing
expertise in this area and are therefore able to service the market for
interoperability with the installed base of Sonet / SDH metro / core
equipment.

However, if the WG is observing the minimal intervention approach, the
method based on emulation looks to be by far the most minimalist to
implement (if starting from a clean sheet), but it does not address any of
the backward compatibility issue in it's own right. These would become
vendor specific implementation issues within the aggregation systems.

The main market imho is the conversion process of legacy copper circuits to
PWE3 at the edge (PE) and conversion from PWE3 to legacy core switching and
cross-connect equipment in the metro / core. The issue of how this is done,
and which conversions / adaptations are done where in the network is really
a question of preference for the SP customers, and one that vendors hope to
get right.

Being a newbie I don't know how the 'voting' process works in the WG. It
looks to me like the main criteria (if not the only criterion) is an
informal consensus basis based on three implementations that work together.
In which case, so long as at least three nominally different groups
implement a draft it can become an rfc, in which case there could be as many
rfcs as there are groups of vendors with time and effort to put into drafts
and implementations.

I am sure the old hands will enlighten me if I am way off base with the
above ;-).

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of tom
k. johnson
Sent: 28 August 2002 16:48
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Is the working group planning to support two different methods for carrying
T1/E1s, one based on VT-mapping (pate) and one based on "native" emulation
(vainshtein or anavi or davari)?

Should we discuss whether or not we want to support two different (and
non-interoperable) methods for carrying T1/E1s over PSNs as a part of this
process?

It seems to me that one method for emulating T1/E1s would be preferable to
two for many reasons, regardless of whether the method is VT-based or
native.

-Tom

---

From: "tom k. johnson" <[email-masked]>
Date: Thu, 29 Aug 2002 18:46:07 -0400

Bob - 

> I have no problem with three methods, as there are three 
> scenarios in the market. 

I agree that there are different scenarios in the market, but I'm not sure that three solutions to the same basic problem is warranted.  

However, there is no doubt that each of the proposed solutions shines best in certain applications.  

- vainshtein appears to be the most easily implementable with software (and a little bit of hardware), is optimized for native T1/E1 emulation, and seems to be most in line with the PWE3 charter as I understand it.  

- anavi re-uses off the shelf AAL1/AAL2 specifications and technology which is useful in it's own right, and opens the door for service interworking between ATM circuit emulation and PWE3 circuit emulation.  

- pate is optimized for high capacity optical hand-offs, and utilizes the exact same encapsulation as the STS-1 and above circuit emulation draft.

I just wonder if multiple application-optimized but non-interoperable protocols that accomplish the exact same function from an end-user perspective (i.e. carriage of a T1 circuit through a PSN) is the best path forward.  Perhaps the answer is yes, but I just wanted to pose the question.

It seems to me that having one standard protocol for carrying T1s over PSNs has a lot of benefits, even if that protocol is not perfectly optimized for each deployment scenario.  But I'm certainly open to other views.

Thanks!

-Tom

---

From: Shahram Davari <[email-masked]>
Date: Fri, 30 Aug 2002 06:23:37 -0700

Tom,

The reason that there was no objection for example to draft-pate to become a WG
document was on the basis that it covers specific scenarios, not because it is the
most elegant, most efficient or most useful method.

Yours,
-Shahram

> From: tom k. johnson [mailto:[email-masked]]
> Sent: Thursday, August 29, 2002 6:46 PM
> To: [email-masked]; [email-masked]; [email-masked]
> I agree that there are different scenarios in the market, but 
> I'm not sure that three solutions to the same basic problem 
> is warranted.  
> 
> However, there is no doubt that each of the proposed 
> solutions shines best in certain applications.  
> 
> - vainshtein appears to be the most easily implementable with 
> software (and a little bit of hardware), is optimized for 
> native T1/E1 emulation, and seems to be most in line with the 
> PWE3 charter as I understand it.  
> 
> - anavi re-uses off the shelf AAL1/AAL2 specifications and 
> technology which is useful in it's own right, and opens the 
> door for service interworking between ATM circuit emulation 
> and PWE3 circuit emulation.  
> 
> - pate is optimized for high capacity optical hand-offs, and 
> utilizes the exact same encapsulation as the STS-1 and above 
> circuit emulation draft.
> 
> I just wonder if multiple application-optimized but 
> non-interoperable protocols that accomplish the exact same 
> function from an end-user perspective (i.e. carriage of a T1 
> circuit through a PSN) is the best path forward.  Perhaps the 
> answer is yes, but I just wanted to pose the question.
> 
> It seems to me that having one standard protocol for carrying 
> T1s over PSNs has a lot of benefits, even if that protocol is 
> not perfectly optimized for each deployment scenario.  But 
> I'm certainly open to other views.
> 
> Thanks!
> 
> -Tom

---

From: "Bob Barrett" <[email-masked]>
Date: Fri, 30 Aug 2002 19:00:14 +0100

Thanks ...

As you obviously know, we Brits don't even have a written constitution so we
tend not to bother with written rules, despite the efforts of the EU. I am
sure rfc2026 will help pass the time on my next transatlantic flight ;-).

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Lloyd
Wood
Sent: 30 August 2002 03:56
To: Bob Barrett
Cc: tom k. johnson; [email-masked]; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

On Thu, 29 Aug 2002, Bob Barrett wrote:

> Being a newbie I don't know how the 'voting' process works in the WG.

Read RFC2026.

> It

Once you've read RFC2026, you should be able to spot at least four
errors in your statement above.

L.

---

From: "Yaron Raz" <[email-masked]>
Date: Thu, 5 Sep 2002 11:26:12 +0300

I would like to back up Tom's view here.
Even when we identify 3 different scenarios, a single CES equipment may be required to support more than one standard depending on the Interface type on the other end.
For example: a T1 CES equipment may be required to support CESoPSN if the other side is also T1, SONET-VT if the other side is OC-3 and AAL1/2 if the other side is ATM based. Of course in many cases the customer wants to buy a T1 interface without specifying and commiting to the interface on the other side at the time he buys the equipment.
Having a single device support all modes makes it complex and expensive.

So, although we can justify each method by specific application it is optimized for, at the end of the day we are not promoting interoperability of CES, which is what we are here for.

-----Original Message-----
From: tom k. johnson [mailto:[email-masked]]
Sent: Friday, August 30, 2002 1:46 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks 

Bob - 

Thanks!

-Tom

---

From: [email-masked]
Date: Thu, 5 Sep 2002 11:16:32 +0100

So how do we resolve the impasse? 

My suggestion would be to use the simplest solution that meets the basic 
requirements. Features such as inter-working with other services (e.g. 
SONET, ATM) can then be handled in an NSP if required. That way we don't 
force people who don't want these features to implement them in the 
system, since they will not be part of the basic PWE3 standard. 

This promotes maximum inter-operability and simplicity of the equipment.. 
For instance it doesn't force people who want to inter-operate with SONET 
to do a double conversion to basic TDM and then into AAL1/2, or vice 
versa.

Of course, this seems to nicely favour CESoPSN, of which I am a co-author 
- but this is why I am a co-author of that draft!

The next question is: what are the basic requirements? This is what Max 
Riegel was trying to answer with his Requirement draft. Perhaps if we 
concentrated on this we would be able to come to a more objective opinion 
on which drafts actually meet the requirements.

Regards,
Tim

"Yaron Raz" <[email-masked]>
Sent by: [email-masked]
05-Sep-2002 09:26 AM

        To:     "tom k. johnson" <[email-masked]>, 
<[email-masked]>, <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: [PWE3] AAL1/2 transport over IP/MPLS networks

I would like to back up Tom's view here.
Even when we identify 3 different scenarios, a single CES equipment may be 
required to support more than one standard depending on the Interface type 
on the other end.
For example: a T1 CES equipment may be required to support CESoPSN if the 
other side is also T1, SONET-VT if the other side is OC-3 and AAL1/2 if 
the other side is ATM based. Of course in many cases the customer wants to 
buy a T1 interface without specifying and commiting to the interface on 
the other side at the time he buys the equipment.
Having a single device support all modes makes it complex and expensive.

So, although we can justify each method by specific application it is 
optimized for, at the end of the day we are not promoting interoperability 
of CES, which is what we are here for.

-----Original Message-----
From: tom k. johnson [mailto:[email-masked]]
Sent: Friday, August 30, 2002 1:46 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks 

Bob - 

> I have no problem with three methods, as there are three 

I agree that there are different scenarios in the market, but I'm not sure 
that three solutions to the same basic problem is warranted. 

However, there is no doubt that each of the proposed solutions shines best 
in certain applications. 

- vainshtein appears to be the most easily implementable with software 
(and a little bit of hardware), is optimized for native T1/E1 emulation, 
and seems to be most in line with the PWE3 charter as I understand it. 

- anavi re-uses off the shelf AAL1/AAL2 specifications and technology 
which is useful in it's own right, and opens the door for service 
interworking between ATM circuit emulation and PWE3 circuit emulation. 

- pate is optimized for high capacity optical hand-offs, and utilizes the 
exact same encapsulation as the STS-1 and above circuit emulation draft.

I just wonder if multiple application-optimized but non-interoperable 
protocols that accomplish the exact same function from an end-user 
perspective (i.e. carriage of a T1 circuit through a PSN) is the best path 
forward.  Perhaps the answer is yes, but I just wanted to pose the 
question.

It seems to me that having one standard protocol for carrying T1s over 
PSNs has a lot of benefits, even if that protocol is not perfectly 
optimized for each deployment scenario.  But I'm certainly open to other 
views.

Thanks!

-Tom

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 05 Sep 2002 12:33:29 +0200

Lets add connection monitoring (i.e. SLA verification) to this discussion as it
may help to reach a conclusion... 

A DS1 (T1), E1 or other circuit service is expected to meet the DS1/E1/.. SLAs.
To guarantee such SLAs, adequate monitoring is required. In SONET/SDH networks
this is performed by adding the VT-1.5/VC-12/.. path overhead and monitoring
this at the ingress/egress points of the network.

The CESoPSN (e.g. MPLS) service may use MPLS-OAM as defined in Rec. Y.1711 to
get a means of SLA verification, but this doesn't reach the same level as the
SONET/SDH OAM (path overhead).

But if the DS1/E1/.. service extends beyond the PSN (e.g. MPLS) network, then
using MPLS-OAM can only monitor the MPLS-segment of the DS1/E1/.. connection.
The other segment would then be monitored via e.g. SONET/SDH POH (case of
continuation via SONET/SDH network).

This break up of the DS1/E1/.. connection in two individually monitored segments
is a nightmare in network operation, and has caused such solutions to be not
acceptable (I have some experience with this).

So, if the CESoPSN (e.g. MPLS) service is limited to the MPLS network, then the
above segmentation of monitoring isn't an issue. Only the quality of MPLS-OAM
versus SONET/SDH POH based monitoring of CES service connection will play a
role.

But if the CESoPSN is just one part of the total DS1/E1/.. connection in the
transmission network, then seamless continuation of the monitoring span is a big
advantage. One may solve this by means of e.g. "service interworking" (e.g.
ATM-OAM converts into MPLS-OAM and vice versa) gateways, or by adding an
additional monitoring layer between DS1/E1/.. and PSN (e.g. MPLS).

Don't forget that also MEF is now looking into CESoETH services, which only adds
to the interworking nightmare that may grow in the networks in the coming
years...

With SONET/SDH the most common technology for transporting DS1/E1/.. signals, it
might be best that CESoPSN (and CESoETH) map the DS1/E1/.. signals via their
SONET/SDH path signals... and reach seamless interworking with SDH/SONET. 

As CESoATM is already defined and can't be adapted, there is most likely a
gateway necessary to convert CESoPSN/CESoETH to CESoATM. Assuming that the need
to interwork with SONET/SDH is the majority of cases, optimisation in the
direction of SONET/SDH seems validated.

Regards,

Maarten

---

From: "Bob Barrett" <[email-masked]>
Date: Thu, 5 Sep 2002 13:24:09 +0100

Tim

My view is that the complication sets in when the 'gusinta' interface at the
PE facing the customer is not the same as the 'gusouta' interface at the PE
facing the core e.g. T1 at the customer edge and T3 facing the core /
switch. I guess you will be on-side with this view, but it does not bed down
well with the other drafts.

Aggregation in the context of PWE3 is an important issue, but is it within
scope for PWE3? There are existing documents that define ATM and Sonet
aggregation, so my view is that it does not need to be in scope for PWE3.

There are two ways at looking at aggregation outside of PWE3:

either:

it happens at the edge, and then the resulting aggregated circuit is carried
over the PSN (gusinta=gusouta)

or:

it happens at the other side of the PSN, with individual circuits being
carried over the PSN.

All other cases e.g. aggregation at a POP can be looked at as termination of
the CES, and exit from the PSN at the POP, then aggregation logically
outside of the PSN (using current ATM or Sonet methods, whatever the
implementation and the application require), and then re-entry to the PSN of
the aggregated circuit.

We obviously want to avoid the need to go back to copper T1 and cable
interconnects for aggregation. That is why I use the phrase 'logically
outside of the PSN'. The aggregating systems can be an integrated box, with
separate logical blocks of functionality based on _current_ ATM and Sonet
rfcs, silicon etc. It can even go all in one ASIC that supports multiple rfc
protocols. Just because we want to integrate the silicon doesn't mean that
the PWE3 standard needs to re-invent and re-write all the existing standards
and functions that are required for the aggregation functions. That would
not look like minimal intervention to me, and I think wedding PWE3 to ATM or
Sonet legacy limits the future potential. I think PWE3 should be compatible
with ATM and Sonet aggregation but PWE3 does not need to (and should not)
re-define how ATM and Sonet aggregation work.

Having read Maarten Vissers [[email-masked]] email on the issue of
adequate monitoring, I would conceed that implementing a complete end to end
OAM mechanism is simpler if the circuit stays within one ecapsulation
protocol end to end.

This is probably a re-run of the architectural discussion at the start of
PWE3, but I get the feeling that the architectural picture has evolved
considerably since the start a.k.a. creeping featurism.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: 05 September 2002 11:17
To: [email-masked]
Cc: [email-masked]; [email-masked]; tom k. johnson; Yaron
Raz
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Regards,
Tim

-----Original Message-----
From: tom k. johnson [mailto:[email-masked]]
Sent: Friday, August 30, 2002 1:46 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PWE3] AAL1/2 transport over IP/MPLS networks

Bob -

Thanks!

-Tom

---

From: "tom k. johnson" <[email-masked]>
Date: Thu, 5 Sep 2002 17:34:00 -0400

Bob/Maarten - 

Excellent points.  

All of which (I assume) support the idea that whichever way we go (Vainshtein, Pate, Anavi, Davari, or some compromise between them), we should just go that one way.  Otherwise, things are going to be a real mess.

Agreed?

-Tom

> From: Bob Barrett [mailto:[email-masked]]
> Sent: Thursday, September 05, 2002 8:24 AM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; tom k. johnson; Yaron Raz
> I'm not sure
> utilizes the

---

From: "tom k. johnson" <[email-masked]>
Date: Thu, 5 Sep 2002 17:25:55 -0400

Tim - 

> My suggestion would be to use the simplest solution that 
> meets the basic requirements. Features such as inter-working with other 
> services (e.g. SONET, ATM) can then be handled in an NSP if required. That 
> way we don't force people who don't want these features to implement them in the 

I agree.  I think one simple standard should be the goal.  Otherwise, things will get very messy for both equipment vendors and service providers trying to hook up CPE to CO equipment, etc.

> Of course, this seems to nicely favour CESoPSN, 

I suspect Prayson, Yaakov, and Shahram might disagree with you on that point :-)

> of which I am a co-author 
> software 
> T1s over

---

From: "Ron Cohen" <[email-masked]>
Date: Sat, 7 Sep 2002 23:54:32 +0200

Tom,

Here is how I see things.

SONET emulation is within the charter. The solution for SONET emulation
is documented in draft-ietf-pwe3-sonet-00.txt and
draft-ietf-pwe3-sonet-vt-00.txt. The reason why it is separated into two
drafts is historical, where a TBD in the first draft was complemented in
the second. The two together provides emulation of the entire SONET
hierarchy.

Does the SONET emulation proposal answers the entire PWE3 charter for
TDM emulation? One can argue that it does, as SONET being the dominant
TDM transport technology carry all TDM circuit from T1 and up. It has
the inherit benefits of well known inband OA&M as Maarten pointed out in
a previous email.

I think that the TDM emulation as described in
draft-vainshtein-cesopsn-03.txt has merits that qualify it to become a
WG draft. It is simple to implement and has the benefit of efficiently
carrying N*DS0 circuits, etc.

In my mind deployments for high speed TDM transport or where a need
support for many TDM emulation ports will naturally pick SONET based
emulation while implementations that are targeted towards a lower rate
applications or lesser number of ports where SONET OA&M is not an issue
will likely to use the native (CESoPSN) emulation proposal.  

Regarding the AAL1/AAL2 proposal, there are two things that the WG needs
to decide. One is whether AAL1/AAL2 emulation is within the charter. If
it is, we should put it forward. If not, Yaakov is arguing that this
method has other advantages. We can figure out whether the advantages
are worth the complexity.

In any case, we can not afford to continue and halt advance of the PWE3
WG. After a long while we finally have several service specific
proposals as WG drafts, including Ethernet and SONET. All are aligned
with the charter, with the protocol layers and with the architecture
documents. We can not afford to halt progress just because there is no
agreement on how its best to run N*DS0 circuits, in AAL1/AAL2 or in the
native formats as defined in CESoPSN. 

Ron

> Behalf Of tom k. johnson
> Sent: Thursday, September 05, 2002 11:26 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; Yaron Raz
> I agree.  I think one simple standard should be the goal.  
> Otherwise, things will get very messy for both equipment 
> vendors and service providers trying to hook up CPE to CO 
> equipment, etc.
> 
> technology
> non-interoperable

---

From: "tom k. johnson" <[email-masked]>
Date: Sat, 7 Sep 2002 17:40:44 -0400

Ron - 

> will likely to use the native (CESoPSN) emulation proposal.  

I agree with you on the cases you've sited, but I wonder about the hybrid case - where one end of the PW is a "lower rate" application and the other end of the PW is a site that needs "support for many TDM emulation ports".  

How does one decide what to do?  I suspect CPE vendors would say, it's up to the site that needs "support for many TDM emulation ports" to handle native emulation; while the CO equipment vendors would say it's up to the CPE to support VT encapsulation.  

That seems like a problem to me.  I'm just wondering what the solution is...

-Tom

---

From: Shahram Davari <[email-masked]>
Date: Mon, 9 Sep 2002 06:37:36 -0700

Tom,

SONET-VT and AAL5-PDU are existing accepted modes, which are designed to carry SONET and ATM over PSN. However, they could also be used to carry T1/E1 as following:

1) T1/E1 over VT over PSN using SONET VT mode 
2) T1/E1 over AAL1/2 over PSN using AAL5 PDU mode

There is nothing to stop people from doing so. I think it is incumbent upon CESoPSN authors to show that we need yet a brand new method for carrying T1/E1.

Even assuming that CESoPSN is simpler than the above methods, there are many cases that (1) or (2) are cheaper or easier or more readily available to be used. IETF is not in the habit of telling people what they MUST or MUST not deploy in their network. 

And Ron, simplicity is not always enough. An analogy is RSVP-TE and CR-LDP, although CR-LDP is a simpler protocol, IETF is talking about de-standardizing it.

Yours,
-Shahram  

> Sent: Saturday, September 07, 2002 5:41 PM
> To: Ron Cohen; [email-masked]; [email-masked]
> I agree with you on the cases you've sited, but I wonder 
> about the hybrid case - where one end of the PW is a "lower 
> rate" application and the other end of the PW is a site that 
> needs "support for many TDM emulation ports".  
> 
> How does one decide what to do?  I suspect CPE vendors would 
> say, it's up to the site that needs "support for many TDM 
> emulation ports" to handle native emulation; while the CO 
> equipment vendors would say it's up to the CPE to support VT 
> encapsulation.  
>

---

From: Shahram Davari <[email-masked]>
Date: Tue, 10 Sep 2002 07:06:37 -0700

Sasha,

> > Sent: Thursday, August 29, 2002 4:30 PM
> > To: 'Sasha Vainshtein'
> According to the latest available revision of draft-fisher
> (which, AFAIK, defines the encapsulation of AAL5 PDUs) such
> a behavior is not prohibited either. Hence I see it as an
> implementation option which, if used, would not affect
> "real" AAL5 PDU services but would kill AAL1/AAL2 ones.

Reassembly of AAL5 PDU at the egress is not required by the
draft-bocci/fischer, and in fact causes unnecessary delay. That is why
I have mentioned in my draft that reassembly must not be done at the egress.
I have also talked to the authors of draft-bocci/fischer to add a text to
their draft to explicitly mention that no-reassembly is required for AAL5,
and implementations should have a capability to turned off the reassembly.

> I do not see your point. The check I had in mind refers to
> the PW egress and as I see it, does not contradict the 
> definitions of draft-fisher. 

As I said reassembly is not required by AAL5 PDU mode.

Yours,
-Shahram

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 10 Sep 2002 15:40:07 +0200

Shahram,
Sorry for a much delayed response.
Please see my comments inline.

With best regards,
                                   Sasha Vainshtein