Subject: RE: Proposed way to move forward re ATM/MPLS

From: "Khalid Ahmad"<[email-masked]>
Date: Tue, 30 Apr 2002 11:45:31 -0400

Hi Luca and pwe3 colleagues,

sorry for delay in responding to your point, but I was in ATM Forum meeting
in beautiful Prague and just got back !

Yes Luca, people keep telling me there are many implementations of draft
martini encapsulations out there, but surely this is not the issue we are
trying to resolve here.

I think the issue is how do we reconcile the different approaches that have
been followed by different bodies and come up with a reasonable and unified
solution set that meets the different requirements and design criteria that
were adopted.

I think we all know that it is possible to get 3 or 4 (or more)vendors to
implement something they have written up in a draft and it will work fine.
These days anything will "work" if one throws enough silicon or software at
it. 

But the question is whether this constitutes a generally agreed standard or
is an implementation agreement between the interested parties. I dont
believe we can make progress on this basis in pwe3, considering the
different proposals that are being discussed.

However, I think we can make progress based on the guidelines we started to
discuss in Minneapolis, by splitting up the whole ATM/MPLS interworking
problem into the the separate applications that underlie the current
proposals and use correct layering principles to design the encapsulation
protocols.

I assume correct layering means that functions pertaining to the "pseudo
wire" (interworking LSP) are grouped ahead of the functions belonging to the
service being transported, e.g. ATM service specific info such as PTI, CLP,
etc.

Based on these guidelines, I would like to propose the following approach as
a way of moving forward to resolve the various applications being addressed
in both drafts fischer and brayley, etc., and partition the work for
minimising overlaps:

1.   For the cell mode interworking we can distinguish:

1.1  Basic ATM VCC (or VPC)cell interworking application.  

This application addresses the basic mapping of VCC or VPC to the
interworking LSP (or PW in IETF terminology). Transparency and efficiency
are the main requirements here for the ATM service being transported, so
there is no need to carry redundant protocol control info (PCI),such as VPI
or VCI values, for this network application.

I propose this application can be met by the basic cell encap mechanism
described in the ATM Forums af-aic-0178 specification which was approved
last year, and is also described in drafts fischer and koleyni. This
mechanism strictly preserves layering principle and provides maximum
efficiency for single cell transfer. 

Also backwards compatibility with this spec is preserved, an important
consideration if we want to achieve harmonization across all standards
bodies working on this topic.

1.2  Port interworking application.

This application transports all ATM cells from one transmission path payload
(port) to another without identifying individual ATM VCCs or VPCs in the
multiplexed cell stream. Since there is no visibility of individual VCC or
VPC in this application this is not an ATM layer service as defined in ITU-T
I.series recommendations or ATM Forum specifications.

However, the port interworking application enables extraction of ATM idle
cells from cell stream and hence some level of concentration into an egress
transmission path (port).  It may also enable potential for additional level
of multiplex, since VPI/VCI values are carried intact. Efficiency is not a
consideration in this application since no ATM layer functions are involved.

I propose this application can be met by the basic encap mechanism described
in drafts martini or brayley, which includes the VPI+VCI+PTI+CLP fields as
is. 

This also enables backwards compatibility with the existing martini based
implementations. 

2.   For the frame mode interworking we can distinguish the following:

2.1  AAL Type 5 interworking

This application transports entire AAL5 frames (PDU) across the interworking
LSP while ensuring transparency of all ATM layer services, such as end-end
OAM functions, etc.  It also preserves both message and streaming mode of
operation for AAL Type 5 as described in ITU-T recommendation I.363.5.

The basic rationale for AAL5 interworking is enhanced efficiency over basic
cell IW as in 1.1 above for those ATM  services that use AAL5 CPCS.

I propose this application can be best met by the PDU mode encapsulation
mechanism defined by af-aic-0178 spec, which is also described in drafts
fischer or brayley.

This also follows layering guidelines (at least in draft fischer) while
achieving backwards compatibility with other forums work.

2.2  Frame mode interworking (or SDU mode IW).

This application supports only the transport of the AAL5 payload for further
efficiency and ease of service interworking, but is not transparent to all
ATM capabilities such as OAM functions or streaming mode. Its main use could
be to facilitate service IW with other payload types such as ethernet or FR
to enable any-to-any transport.

I propose this application can be met by the SDU mode encap mechanism as
described in drafts brayley or martini etc., but these may need to be
modified to ensure the layering principles are followed.  (Currently I
believe this encap places the ATM service specific PCI before the pseudowire
related functions such as sequence number and length).

If we can agree to this simple approach to partitioning the cell and frame
interworking applications we will need to work on 4 separate drafts which
will describe the application (AS part) and the related encap mechanism
optimised for that particular network application.

I understand Ghassem Koleyni has already submitted an AS draft for the basic
cell VCC mode as per 1.1 above, and is working on a PDU draft as in 2.1.
Since much of the material for all the encap protocols is already available
in the various drafts, I dont think it will be difficult to put together the
4 AS drafts based on the above.

I would like to know who would be interested in putting together AS material
for the port and SDU applications in collaboration.

I hope we can progress the ATM/MPLS work based on the above proposed
partitioning ?

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Tuesday, April 23, 2002 6:37 PM
To: Ahmad, Khalid [CAR:CS49:EXCH]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01

I would like to point out a little difference here.
There are several interoperable independent implementations of the 
draft-martini encapsulations ( some of which are currently deployed ). Can
we 
say the same about all the other drafts ?

Luca

Khalid Ahmad wrote:

> Hi Danny,
> 
> thank you for this clarification.
> 
> In that case, I look forward to continued cooperation in the ATM/MPLS 
> drafts.
> 
> Regards,
> Khalid
> 
> -----Original Message-----
> From: Danny McPherson [mailto:[email-masked]]
> Sent: Friday, April 19, 2002 11:49 AM
> To: [email-masked]
> Subject: Re: [PWE3] Proposed changes to draft kamapabhava-01
> 
> 
> 
>  > Hi Danny,
>  >
>  > I assume that your point re backwards compatibility applies equally 
> to all
>  > the pwe3 drafts, including the work we are currently doing for ATM 
> over MPLS
>  > &IP.
> 
> Yes Khalid, else we would have simply published the Martini drafts and
> been done with it.
> 
> -danny
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Architect, Level 3 Communications - Broomfield,
CO
[email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager
[email-masked]

---

From: "Khalid Ahmad"<[email-masked]>
Date: Tue, 30 Apr 2002 13:39:08 -0400

Hi Eric,

thank you for your insightful philosophical comment, but unfortunately it is
not helpful in this context. 

We have to find a pragmatic way to move forward, considering both the "real
world", as you put it, as well as the "other" standards committees (who
incidently have done implemented and deployed things such as ATM,
FR,...etc.), whose output the ADs encouraged us from the outset should be
taken into account in the pwe3 work.

That is what I am trying to do in this proposal for work plan.  In it the
real world is definitely considered !

I hope the ethos of the IETF that you mention embraces all points of view,
and not only that of a select few.

Regards,
Khalid

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Tuesday, April 30, 2002 12:19 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: Luca Martini; [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS 

Some folks seem to think that: 

- what happens in  the real  world (as  indicated by  deployed multi-vendor
  interoperable implementations) should not be considered;

- but the unimplemented and  undeployed output of other standards committees
  is of crucial importance. 

However, I don't believe this is the ethos of the IETF.

---

From: "Khalid Ahmad"<[email-masked]>
Date: Wed, 1 May 2002 14:38:03 -0400

The only way I can answer your question re bandwidth efficiency is to say
that many folks I talk to indicate that efficiency is an important objective
for them. Bandwidth may be cheap(er), but it is not free ! Why carry
redundant protocol control information if one does not need to.

But I dont understand your point that there should be a requirement that ATM
over MPLS transport be more bandwidth efficient then ATM itself. I dont
think this is what is being proposed.

For the basic ATM VCC interworking application in 1.1 there is no need to
transport the VPI/VCI fields, since the context is in the interworking
header anyway.  This enables the efficiency gain (over the port mode
encapsulation you use in draft martini), which is clearly desirable for this
application.  Of course there always is the overhead in the pw and transport
headers to be factored in any overall efficiency calculation.

I know from the many discussions I have had with colleagues in this area
that the intended applications which the initial martini encap addressed
were somewhat different to those targeted by the ATM Forum work, and this is
why I proposed to separate these two mechanisms.

This has the benefit that network applications that want additional
efficiency can use the basic one-to-one VCC mode as per af-aic-0178 or draft
fischer, wheresas applications that want to use port mode as well can use
the basic draft martini encap.  I dont think this results in much extra
complexity in todays technology, considering the benefits we derive from
separating these applications.

I have one question for clarification re your comment about agreement for 2
modes. Are you now implying that you dont see the need for port mode ?

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Tuesday, April 30, 2002 6:36 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

Khalid,

Now that I can speak more freely, I would like to ask you and the PWE3 WG
the 
following:

Is there a  requirement that ATM over MPLS transport be more bandwidth 
efficient then ATM itself ?

An ATM network is used ,to me ,  it makes a statement that efficiency is not
a 
significant design requirement. In PWE3 we should design a working solution
, 
and not strive to perfectly emulate, or improve, the transported protocol,
in 
this case ATM.

In this context what is wrong with one encapsulation that accomplishes all
this 
  at once ?
This would be the cell mode in the draft-martini-atm-encap-mpls-00.txt.

Having said that, I think that some of the encapsulation modes below have
merit 
  because of current hardware implementation constraints.
I think that we should be able to come to an agreement for 2 modes: a cell 
mode, and a packet mode.
I see no use for any more permutations for this encapsulation.

I propose that we use the draft-martini-atm-encap-mpls-00.txt cell mode with

optional concatenation of cells, and either the AAL5 SDU or PDU mode , but 
without fragmentation.
The OAM cell ordering issue is well covered by the cell transport mode.

If I offer service to my customers there is nothing that they can do in a 
network implementing any  draft-fisher modes that I cannot do with the
martini 
cell encapsulation.

Thanks.
Luca

Khalid Ahmad wrote:

> sorry for delay in responding to your point, but I was in ATM Forum 
> meeting in beautiful Prague and just got back !
> 
> martini encapsulations out there, but surely this is not the issue we 
> are trying to resolve here.
> 
> I think the issue is how do we reconcile the different approaches that 
> have been followed by different bodies and come up with a reasonable and 
> unified solution set that meets the different requirements and design 
> criteria that were adopted.
> 
> I think we all know that it is possible to get 3 or 4 (or more)vendors 
> to implement something they have written up in a draft and it will work 
> fine. These days anything will "work" if one throws enough silicon or 
> software at it.
> 
> But the question is whether this constitutes a generally agreed standard 
> or is an implementation agreement between the interested parties. I dont 
> However, I think we can make progress based on the guidelines we started 
> to discuss in Minneapolis, by splitting up the whole ATM/MPLS 
> interworking problem into the the separate applications that underlie 
> the current proposals and use correct layering principles to design the 
> encapsulation protocols.
> 
> wire" (interworking LSP) are grouped ahead of the functions belonging to 
> the service being transported, e.g. ATM service specific info such as 
> PTI, CLP, etc.
> 
> Based on these guidelines, I would like to propose the following 
> approach as a way of moving forward to resolve the various applications 
> being addressed in both drafts fischer and brayley, etc., and partition 
> the work for minimising overlaps:
> 
> interworking LSP (or PW in IETF terminology). Transparency and 
> efficiency are the main requirements here for the ATM service being 
> transported, so there is no need to carry redundant protocol control 
> info (PCI),such as VPI or VCI values, for this network application.
> 
> This application transports all ATM cells from one transmission path 
> payload (port) to another without identifying individual ATM VCCs or 
> VPCs in the multiplexed cell stream. Since there is no visibility of 
> individual VCC or VPC in this application this is not an ATM layer 
> service as defined in ITU-T I.series recommendations or ATM Forum 
> specifications.
> 
> However, the port interworking application enables extraction of ATM 
> idle cells from cell stream and hence some level of concentration into 
> an egress transmission path (port).  It may also enable potential for 
> additional level of multiplex, since VPI/VCI values are carried intact. 
> Efficiency is not a consideration in this application since no ATM layer 
> functions are involved.
> 
> I propose this application can be met by the basic encap mechanism 
> described in drafts martini or brayley, which includes the 
> VPI+VCI+PTI+CLP fields as is.
> 
> This also enables backwards compatibility with the existing martini 
> based implementations.
> 
> This application transports entire AAL5 frames (PDU) across the 
> interworking LSP while ensuring transparency of all ATM layer services, 
> such as end-end OAM functions, etc.  It also preserves both message and 
> streaming mode of operation for AAL Type 5 as described in ITU-T 
> recommendation I.363.5.
> 
> The basic rationale for AAL5 interworking is enhanced efficiency over 
> basic cell IW as in 1.1 above for those ATM  services that use AAL5 CPCS.
> 
> This application supports only the transport of the AAL5 payload for 
> further efficiency and ease of service interworking, but is not 
> transparent to all ATM capabilities such as OAM functions or streaming 
> mode. Its main use could be to facilitate service IW with other payload 
> types such as ethernet or FR to enable any-to-any transport.
> 
> believe this encap places the ATM service specific PCI before the 
> pseudowire related functions such as sequence number and length).
> 
> If we can agree to this simple approach to partitioning the cell and 
> frame interworking applications we will need to work on 4 separate 
> drafts which will describe the application (AS part) and the related 
> encap mechanism optimised for that particular network application.
> 
> I understand Ghassem Koleyni has already submitted an AS draft for the 
> basic cell VCC mode as per 1.1 above, and is working on a PDU draft as 
> in 2.1.  Since much of the material for all the encap protocols is 
> already available in the various drafts, I dont think it will be 
> difficult to put together the 4 AS drafts based on the above.
> 
> I would like to know who would be interested in putting together AS 
> material for the port and SDU applications in collaboration.
> 
> draft-martini encapsulations ( some of which are currently deployed ). 
> Can we
> Luca Martini Senior Network Architect, Level 3 Communications - 
> Broomfield, CO

---

From: [email-masked]
Date: Wed, 1 May 2002 14:51:17 -0500

Luca, etal,

	I would like to support Khalid, in that I for one consider 
transport efficiency as important. In particular, I consider it to be 
important for the VC cell relay service. 

Clearly others think it is important for other services, e.g. why create 
the AAL5 SDU mode other than for transport efficiency? Why create a port 
mode that discards idle cells rather than provide a transport of the 
entire physical layer?

For AAL5 PDU mode why eliminate fragmentation? There are 2 reasons why 
fragmentation is useful 1) the AAL5 PDU exceeds the MPLS MTU size, 2) 
support of OAM/RM cells. If I want to use these modes to support SVC 
service then both of these possibilities might occur. If for your 
applications, neither of these 2 will occur then fragmentation would not 
occur.

Robert Dianda

-----Original Message-----
From: kmad [mailto:[email-masked]]
Sent: Wednesday, May 01, 2002 1:38 PM
To: luca
Cc: pwe3
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS

Hi Luca and pwe3 colleagues, 
The only way I can answer your question re bandwidth efficiency is to 
say that many folks I talk to indicate that efficiency is an important 
objective for them. Bandwidth may be cheap(er), but it is not free ! Why 
carry redundant protocol control information if one does not need to.
But I dont understand your point that there should be a requirement that 
ATM over MPLS transport be more bandwidth efficient then ATM itself. I 
dont think this is what is being proposed.
For the basic ATM VCC interworking application in 1.1 there is no need 
to transport the VPI/VCI fields, since the context is in the 
interworking header anyway.  This enables the efficiency gain (over the 
port mode encapsulation you use in draft martini), which is clearly 
desirable for this application.  Of course there always is the overhead 
in the pw and transport headers to be factored in any overall efficiency 
calculation.
I know from the many discussions I have had with colleagues in this area 
that the intended applications which the initial martini encap addressed 
were somewhat different to those targeted by the ATM Forum work, and 
this is why I proposed to separate these two mechanisms.
This has the benefit that network applications that want additional 
efficiency can use the basic one-to-one VCC mode as per af-aic-0178 or 
draft fischer, wheresas applications that want to use port mode as well 
can use the basic draft martini encap.  I dont think this results in 
much extra complexity in todays technology, considering the benefits we 
derive from separating these applications.
I have one question for clarification re your comment about agreement 
for 2 modes. Are you now implying that you dont see the need for port 
mode ?
Regards, 
Khalid 

 
-----Original Message----- 
From: Luca Martini [mailto:[email-masked]] 
Sent: Tuesday, April 30, 2002 6:36 PM 
To: Ahmad, Khalid [CAR:CS40:EXCH] 
Cc: [email-masked] 
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS 

Khalid, 
Now that I can speak more freely, I would like to ask you and the PWE3 
WG the 
following: 
Is there a  requirement that ATM over MPLS transport be more bandwidth 
efficient then ATM itself ? 
An ATM network is used ,to me ,  it makes a statement that efficiency is 
not a 
significant design requirement. In PWE3 we should design a working 
solution , 
and not strive to perfectly emulate, or improve, the transported 
protocol, in 
this case ATM. 
In this context what is wrong with one encapsulation that accomplishes 
all this 
  at once ? 
This would be the cell mode in the draft-martini-atm-encap-mpls-00.txt. 
Having said that, I think that some of the encapsulation modes below 
have merit 
  because of current hardware implementation constraints. 
I think that we should be able to come to an agreement for 2 modes: a 
cell 
mode, and a packet mode. 
I see no use for any more permutations for this encapsulation. 
I propose that we use the draft-martini-atm-encap-mpls-00.txt cell mode 
with 
optional concatenation of cells, and either the AAL5 SDU or PDU mode , 
but 
without fragmentation. 
The OAM cell ordering issue is well covered by the cell transport mode. 
If I offer service to my customers there is nothing that they can do in 
a 
network implementing any  draft-fisher modes that I cannot do with the 
martini 
cell encapsulation. 
Thanks. 
Luca

---

From: [email-masked]
Date: Thu, 2 May 2002 05:31:51 +0100

Khalid....1st set your mail to ascii mode please as some people are having
trouble reading HTML-based mail text....I've changed the format of this
response to plain text.

Now see below please.

regards, Neil

Khalid Ahmad wrote 01 May 2002 19:38
To: Luca Martini

Hi Luca and pwe3 colleagues, 
The only way I can answer your question re bandwidth efficiency is to say
that many folks I talk to indicate that efficiency is an important objective
for them. Bandwidth may be cheap(er), but it is not free ! Why carry
redundant protocol control information if one does not need to.
=NH>
I agree BW is not free as some argue.....some exponents of this myth have
already gone bust.  We should use BW as one mechanism to remove problems or
reduce complexity as/where appropriate....and I can certainly think of some
protocols that do exactly the opposite (like LDP as a sever layer to VPNs,
where one has to over-engineer and there are still no SLA guarantees
possible.....now that is truly a waste of BW IMO).

I think the BW savings here however are small and not worth the effort.
More importantly however, how can we treat seriously *any* solutions that
have not considered the layer network behaviour, and in particular the
behaviour under fault conditions.  This seems to be a serious ommission in
all the drafts I have seen to date and I have already given postings on
this, and no doubt you will recall my ad hoc whiteboard session at SG13 also
on this.

And to be honest, I thought the arguments put forwad by Luca in his mail 30
April 2002 were on the whole very sound.
<NH=

<snip>

=NH> Port mode is very bad news....we should never support this.  Why?
Because it completely ignores the fact that what *must* be managed are the
trails of the ATM network......individual cells outside of these trails have
no 'network' sense or meaning.  You cannot treat CO pkts like CNLS
pkts.....CO pkts only have context within their parent trail, and it is the
trail object that has to be managed....and btw this is also what is missing
in the mind-set wrt MPLS LSP fault management.

Hence we get the kludge (that appeared in the orginal Brayley draft) that a
near-end ATM partition failure results in a far-end SDH FDI injection!  This
is completely unacceptable.  I now hear some want to try using ATM ILMI
together with LDP label withdraw to signal such failures....again this is an
expedient (now cross-plane) kludge that I can't support.  The only logical
way to 'do' port mode is to emulate the physical L1 (though I hate this L1
classification thing) trail.  It's all to do with network behaviour on
failure.....and if we continue to omit taking this into account we will
produce some bad standards in this area.
<NH=
<snipped to end>

---

From: Jeremy Brayley <[email-masked]>
Date: Thu, 2 May 2002 10:10:03 -0400

> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, May 01, 2002 3:51 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

Transport efficiency is important.  No doubt.  It's a fair argument in the
case of VCC cell relay.  The question is whether it is worth optimizing the
encapsulation to this extent.  

The better way to gain efficiency is to pack multiple cells into a single PW
PDU, i.e. cell mode with concatenation.  It's the PW overhead, L2 headers,
that really contributes to ineffiency in the single cell case right?
 
> applications, neither of these 2 will occur then 

Cell mode with concatentation can handle any ATM service and provide
reasonable efficiency.  

Any AAL5 mode is an optimization.  The AAL5 SDU mode happens to transmit
only those bytes that actually make sense to transmit if you are providing
any frame based service (interconnection of routers, Frame Relay using
FRF.5).  And it allows easier interworking between AAL5 and different frame
types because you don't have to SAR at the far end PE.  

Plus SDU mode may be implemented more easily than cell mode on existing
router platforms.  Yes it is more efficient than sending the whole PDU, but
this isn't the main reason to have it.

As for PDU mode and fragmentation...

The ATM Forum didn't like SDU mode because it wasn't fully transparent to
all AAL5 applications.  The SDU mode doesn't carry the UU octet.  Although
I've never heard of an application, beside the C/R bit that is already
carried in SDU mode, that requires the UU octet.  Khalid mentions the AAL5
streaming mode.  I wonder how many people even know what this is?  Doesn't
matter, if you want full transparency, use the cell mode. 

In reality the SDU mode is probably not that easy to implement on ATM
platforms because it requires SAR. 

So out comes the PDU mode.  Then someone in the ATM Forum mentions that
since the PDU mode can't ensure the ordered delivery of OAM cells, it is
pretty much useless when running OAM security applications.  

So they add fragmentation to make sure that OAM cell stay in their same
relative place in the cell stream.  Now it's a monster.  It's neither a
frame nor a cell.

The real answer should have been to punt PDU mode and run cell mode with
concatenation!  

Cell mode with concatenation allows efficiency and allows OAM cells to be in
order.  

Jeremy
 
> > have been followed by different bodies and come up with a 
> reasonable 
> and 
> > wire" (interworking LSP) are grouped ahead of the functions 
> belonging 
> to 
> > I propose this application can be met by the SDU mode encap 
> mechanism 
> as 
> >  >  > the pwe3 drafts, including the work we are currently 
> doing for 
> ATM 
> >  > over MPLS 
> >  >  > &IP. 
> >  > 
> >  > Yes Khalid, else we would have simply published the 
> Martini drafts 
> and 
> >  > been done with it. 
> >  > 
> >  > -danny 
> >  > 
> >  >

---

From: [email-masked]
Date: Thu, 2 May 2002 09:51:56 -0500

Jeremy,

> From: jbrayley [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 9:10 AM
> To: Robert.B.Dianda; kmad; luca
> Cc: pwe3

Multiple cells help for some cases but not all. The added delay may not 
be acceptable, e.g. if AAL1 is being used for voice then an extra 6ms of 
delay for each cell that is added is not tolerable. 

In the ATM Forum's present mapping, for a single cell there is no 
VPI/VCI, no length field, and no Sequence number. The potential addition 
of these fields is not a trivial amount of over head.

In some sense this single cell mode of operation could be considered a 
subset of the braylet AAL5 PDU mode with fragmentation down to a single 
cell (i.e. MTU size equals 1 cell).

> matter, if you want full transparency, use the cell mode. 

At the last meeting the ATM Forum adopted AAL5 SDU mode. I think the 
adoption was under the assumption of service interworking. One 
application that can not be supported by the SDU mode is the ATM 
signaling protocol - i.e. SSCOP. In fact, the SDU mode can only be used 
when there is some knowledge of the application using AAL5. 

Which of the above arguments for SDU mode do not apply to the PDU mode 
when fragmentation is not used (outside of transporting only the bytes 
that make sense)? 

> relative place in the cell stream.  Now it's a monster.  It's 

The existing ATM Forum frame based physical layer specification already 
specified a fragmentation option - although I believe it was added to 
address the possibility that the PDU size can exceed the MTU size. Which 
is a real issue even for SDU mode. 

> The real answer should have been to punt PDU mode and run 

Perhaps, but the existence of implementations doing a PDU mode for frame 
based physical layers I believe factored into the decision - and also 
bandwidth efficiency.
 
> Cell mode with concatenation allows efficiency and allows OAM 
<SNIP> 

Robert Dianda

---

From: Jeremy Brayley <[email-masked]>
Date: Thu, 2 May 2002 11:48:43 -0400

Robert,

> Sent: Thursday, May 02, 2002 10:52 AM
> To: [email-masked]

The ATM control word which includes the length and sequence number is not
required for cell mode.
Without it we are talking about a difference of 3 octets in the single cell
case.  A pair of MPLS labels plus L2 overhead could be anywhere from 16
octets (POS) to 26 octets (Ethernet).

I'm assuming that the PW uplink is high speed.  These 3 octets would never
cause a 6ms delay.  It takes about 10ns to send 3 octets on an OC-48. 

You don't have to use cell concatenation for every application either.

> signaling protocol - i.e. SSCOP.
 
Just curious.  Why?  Does SSCOP really use the UU octet?

>In fact, the SDU mode can 
> only be used 

Sure.  As does the PDU mode.
 
> when fragmentation is not used (outside of transporting only 

For one, a lot of ATM SARs on routers/bridges throw away the AAL5 checksum.
They even throw away the PAD and trailer in some cases. 

> is a real issue even for SDU mode. 

Yes the AAL5 PDU size can be up to 64K octets.  But most, if not all Frame
Relay and IP PDUs over AAL5 is going to be smaller than say ~9100 bytes.
This MTU size can be handled on IP/MPLS backbones.

If large AAL5 frames are a concern, then you have another reason to use cell
mode.

-Jeremy

---

From: [email-masked]
Date: Thu, 2 May 2002 11:28:45 -0500

Jeremy,

<SNIP>
> > > that really contributes to inefficiency in the single cell 
> case right?
> > 

2 issues here 1) how much overhead is too much and 2) is unused overhead 
ever desirable.

I think 3 additional octets of unneeded overhead is too much in this 
case.

> cause a 6ms delay.  It takes about 10ns to send 3 octets on an OC-48. 

The 6 ms delay I mentioned above is for each additional cell in a 
concatenated approach.

> You don't have to use cell concatenation for every application either.

Agreed. But if one is concerned about efficiency in the case where the 
cell concatenation does not make sense then efficiency in the single 
cell case is an issue.

<SNIP>

> Sure.  As does the PDU mode.

No. The PDU requires that I know the user is running AAL5. It does not 
require that I know if the user will be inserting OAM cells, it does not 
require that I know what the users max PDU size, I do not need to know 
if there is a security agent that is scrambling the cell payloads or 
not. I do not need to know if the user is using the CPCS-UU field.

<SNIP>

Robert Dianda

---

From: Jim Harford <[email-masked]>
Date: Thu, 02 May 2002 12:24:00 -0400

Jeremy,
I agree with your point that any AAL-5 mode is an optimization.  The AAL-5 
PDU mode saves almost 2% compared with concatenated cell mode, due to not 
transporting an octet of flags with each ATM cell.  The AAL-5 SDU mode 
saves even more because the AAL-5 trailer fields are not 
transported.  However, the AAL-5 PDU mode maintains the transparency of ATM 
cell relay service while AAL-5 SDU mode does not!

The ATM Forum chose to prioritize the guarantee that ATM applications would 
continue to work as more important than the efficiency delta between AAL-5 
PDU and AAL-5 SDU modes.  I believe this was the correct choice: having 
things work correctly is more important than having them efficiently misbehave.

I personally believe that the 2% gain is not worth the complexity of AAL-5 
PDU mode.  If I were building such a box, I would implement only single 
cell and concatenated cell modes.  Such an implementation decision would 
still conform to the ATM Forum spec, because single cell encapsulation is 
the only mandatory mode; the others are optional.

Jim Harford

---

From: "Khalid Ahmad"<[email-masked]>
Date: Thu, 2 May 2002 15:30:05 -0400

Hi Jeremy and pwe3 colleagues,

I think the many detailed comments I am seeing in this discussion are
essentially further evidence of what I suggested in the first place, i.e.:  

There are several possible applications for the ATM/MPLS interworking with
somewhat differing requirements, so it makes sense to use the specific
encapsulation protocols that have been optimised for each application.

I really dont see a compelling need to adopt a "one size fits all" policy
here, since people have spent a lot of time thinking about the suitable
encap mechanisms that meet the design criteria they set out to do. Moreover,
I am not convinced by the complexity argument that is being advanced, since
this is in any case relatively small compared with all the other
complexities we need to address in regards to the related control and
management aspects.

Of course there will be pros and cons of any proposed encap mechanism and we
can discuss details ad nauseum.  But at least can we agree that there are
different sets of requirements / service models/applications out there,
which are best met by specific encap mechanisms, and these have largely been
defined in the various drafts we have on the table.

If so we can then define the applications in more detail and select the most
suitable encap mechanism for each.  This does not mean that people have to
support all the applications, but can select which is most appropriate in
their network scenarios. 

This way I hope we can avoid getting bogged down in discussions about what
level of efficiency, complexity or transparency is "right", since I suspect
these things have very different significances to different people.  Its
hard to close on such subjective assesments.

I think the important thing right now is to converge on a set of specs which
meet the different requirements. We stand a much better chance of achieving
that by adopting the approach I have proposed. Lets break down the problem
and not just assume its our requirements that matter but that of others as
well.

Regards,
Khalid

-----Original Message-----
From: Jeremy Brayley [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 10:10 AM
To: [email-masked]'; Ahmad, Khalid [CAR:CS40:EXCH];
[email-masked]
Cc: [email-masked]

 

Jeremy

---

From: Danny McPherson <[email-masked]>
Date: Thu, 02 May 2002 13:48:15 -0600

> and not just assume its our requirements that matter but that of others as

This is indeed the approach that the ADs and I proposed.  So, if folks 
are planning to (re)justify something they've done please add it to the
Applicability section of the concerned draft and publish the draft 
describing the specific mode and underlying motivations.

No need to keep going in circles here..

-danny

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 15:55:28 -0400

> Sent: Wednesday, May 01, 2002 11:22 AM
> To: Jim Harford
> Cc: [email-masked]
> no, they probably won't listen to the ATM forum. After all 
> ATM is a legacy protocol.
> This is an IP world.
> 

I thought IP was the legacy protocol. At least that's what everyone
was saying when ATM was being developed. ;)

There might be a lot of IP out there, but voice and leased line still
pay the bills.

John

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 16:07:14 -0400

> Sent: Wednesday, May 01, 2002 12:12 PM
> To: Jim Harford
> Cc: Luca Martini; Khalid Ahmad; [email-masked]
> Some would  say that  it is  difficult to take  seriously a  
> community which designed cells that are too small to hold a properly 
> encapsulated TCP ack. 

So are you saying we should not take the IETF seriously? They were the
ones that defined the encapsulation of an IP packet over ATM.

Giving the IETF credit, they did define an encapsulation mode that does
allow a TCP ACK to fit into a single ATM cell. So you can't blame the
IETF, or the ATM community, if people choose to use the encapsulation
that forces a TCP ACK into two cells.

If people cared that much about the TCP ACK, they would change their ATM
link
encapsulation to Null.

BTW, making this change only results in a 2-3% improvement in efficiency.
Why,
because while TCP ACK may account for 40-50% of the packets, they only
account
for 5-10% of the bytes transmited.

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 16:11:22 -0400

But you assume that everyone will always want to have a one-to-one
mapping between a VPC/VCC and a PW LSP. If someone wants to map more
than one VPC/VCC to a PW LSP, you can't do that with af-aic-0178.000.

John

 
 
-----Original Message----- 
From: Luca Martini [mailto:[email-masked]] 
Sent: Tuesday, April 30, 2002 6:36 PM 
To: Ahmad, Khalid [CAR:CS40:EXCH] 
Cc: [email-masked] 
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS 

Khalid,

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 16:22:18 -0400

I would like to support Robert and Khalid on this one.

How can someone complain about the "Cell Tax" and TCP ACK messages
taking up two cells, then argue that efficiency of ATM over PSN
is not important?

If efficiency does not matter, then we should just use ATM. It
already supports IP, voice, TDM, video, Frame Relay, and Ethernet.
And, all of these capabilities are already deployed and proven
in operational networks.

You can't use an arguement against ATM, then turn around and say
it does not matter for IP/MPLS.

So which is it? Efficiency is important, which was a banner cry
for MPLS. Or efficiency is not important, in which case which should
just stay with ATM because it already works and supports everything
we want to carry over a packet switched network.

John

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 16:47:36 -0400

> From: Jim Harford [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 1:44 PM
> To: [email-masked]
> Cc: [email-masked]
> I believe that ABR is generally  regarded as, shall we say, 
> not having lived up to expectations.
> 
> ABR's strength was that it provided end-to-end flow control with much 
> faster feedback than TCP's sliding window.  ABR was never widely deployed 
> because ATM failed to gain market traction as an end-to-end 
> protocol.  However, my point was that one of the motivating factors behind

> the design of ABR was efficient use of links.  The ATM community is very 
> concerned about efficiency.  The market failure of ABR has nothing to do 
> with the goal of efficiency within the ATM community.
> 

The goal of ABR was to address inefficiencies that resulted due to
cell loss in the network. This was the "goodput" everyone talked about.

The increased size of buffers available on ATM switches, along with
EPD/PPD buffer management techniques deferred the necessity of using ABR
to maintain efficiency.

It is not fair to say ABR did not live up to expectations because we
ended up not needing it for the applications that were using ATM networks.

John

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 16:52:44 -0400

In an IP network running only IP protocols, there aren't any
any layer 2 control packets you need over an ATM link. Therefore,
no need for LLC/SNAP.

In an enterprise network running IPX and IP, I agree you want to
run LLC/SNAP.

John

> Sent: Thursday, May 02, 2002 4:41 PM
> To: Jim Harford
> Cc: [email-masked]
> Jim> How does  VC-based multiplexing require extra  VCs if 
> the  only layer 3
> Jim> protocol being widely used is IP? 
> 
> Traditionally  routers are  multiprotocol  systems which  
> expect to  receive
> layer 2 frames, some  of which may be layer 2 control  
> packets of some sort,
> some of  which contain layer  3 packets.  In  some of the 
> latter  cases, the
> packets are  to be  extracted and routed;  in others,  the 
> frames are  to be
> bridged.  I think  that's  why the  VC  multiplexing has  
> never proved  very
> popular. 
> 
> It's only the very recent work  on IP L2 Interworking which 
> suggests that we
> can now  get away with  an IP-only L2  infrastructure, and 
> much of  the work
> there has  to do  with handling  the L2 frames  that contain  
> L3 information
> (ARP, Inverse ARP, etc.).
>

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 17:05:49 -0400

> Sent: Thursday, May 02, 2002 4:49 PM
> To: Rutemiller, John
> Cc: [email-masked]
> John> How can  someone complain  about the "Cell  Tax" and TCP ACK
messages
> John> taking up two cells, then argue that efficiency of ATM over PSN is
not
> John> important?  
> 
> I think the argument is that if you care a lot about efficiency, then
you'll
> avoid cell mode  altogether.  On the other hand, if  you're using cell
mode,
> then you're incurring the cell tax and apparently don't care that much
about
> efficiency.  

But what if you care about efficiency, and also care about transparency?

---

From: [email-masked]
Date: Thu, 2 May 2002 16:08:24 -0500

Jeremy,

<SNIP>

> Just curious.  Why?  Does SSCOP really use the UU octet?

I just checked and no SSCOP does not use the UU octets. So there should 
be no problem supporting SSCOP.

Robert

---

From: [email-masked]
Date: Thu, 2 May 2002 16:24:18 -0500

John,

	In addition neither brayley or fischer supports multiplexing 
multiple VPCs on a PW LSP. Port mode comes the closest but it takes all 
non-idle cells and maps them into a single PW LSP.

For VCCs the VP modes would support multiplexing multiple VCs on a PW 
LSP.

However, if the capability for multiple VPCs is desired it could be 
added with yet another mapping.

Robert

> From: John.Rutemiller [mailto:[email-masked]]
> Sent: Thursday, May 02, 2002 3:11 PM
> To: pwe3
> reasonable and 
> belonging to 
> mechanism as 
> doing for ATM 
> Martini drafts and

---

From: "Khalid Ahmad"<[email-masked]>
Date: Thu, 2 May 2002 17:34:55 -0400

Hi John and pwe3 colleagues,

yes, I agree with you for the many-to-one case I think you mean. But if you
look at my original proposal in section 1.2 for the port interworking
application, I did refer to the possibility of the many-to-one multiplex
which the martini encap does make possible.

I almost named that application a "Multiplexed Interworking application" for
that reason, but then decided not to, since this mechanism has not really
been clearly defined in the pwe3 work so far.  Perhaps it constitutes a
distinctly separate application, as you pointed out in your contribution to
the ATM Forum. I have no problem with that.

Regards,
Khalid

-----Original Message-----
From: Rutemiller, John [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 4:11 PM
To: [email-masked]
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS

John

 
 
-----Original Message----- 
From: Luca Martini [mailto:[email-masked]] 
Sent: Tuesday, April 30, 2002 6:36 PM 
To: Ahmad, Khalid [CAR:CS40:EXCH] 
Cc: [email-masked] 
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS 

Khalid,

---

From: "Rutemiller, John" <[email-masked]>
Date: Thu, 2 May 2002 17:37:02 -0400

Or you can think of it this way. GR-1110-CORE specifies a
maximum delay across a switching system with STS-3c or STS-12c
interfaces as 150 usec.

If you implement PWE3 cell concatenation using this guideline to
set the maximum delay, and voice cells are arriving one
every 6 msec, then you will only ever send one cell per frame.

Even in the case of T1 circuit emulation, cells are generated once
every 243.5 usec. With a 150 usec max system delay, you will still
end up sending only one cell per frame.

John

> Sent: Thursday, May 02, 2002 5:15 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Eric,
> 	A reason to use single cell mode versus a multiple cell 
> mode or a 
> frame mode is if delay is an issue. For example, if AAL1 is 
> being used 
> for voice then for each extra cell that you encapsulate you 
> encounter an 
> additional 6 msec of delay.
> 
> 
> Robert Dianda
> 
> > From: erosen [mailto:[email-masked]]
> > Sent: Thursday, May 02, 2002 3:49 PM
> > To: John.Rutemiller
> > Cc: pwe3
> > John> How can  someone complain  about the "Cell  Tax" and 
> > TCP  ACK messages
> > John> taking up two cells, then argue that efficiency of ATM 
> > over PSN is not
> > John> important?  
> > 
> > I think the argument is that if you care a lot about 
> > efficiency, then you'll
> > avoid cell mode  altogether.  On the other hand, if  you're 
> > using cell mode,
> > then you're incurring the cell tax and apparently don't care 
> > that much about
> > efficiency.  
> > 
> > You  might not  find  this argument  persuasive,  but it  is 
> > not  internally
> > inconsistent in the way you are suggesting. 
> > 
> > 
> > 
> > 
> >

---

From: [email-masked]
Date: Thu, 2 May 2002 17:00:05 -0500

John,
	In computing the efficency do not forget that because of the SDU 
mode the Length field is required whenever the ATM Control word is 
present. So depending on the traffic mix the net result of having 
created an SDU mode could be negative.

In the ATM Forum it has been proposed to drop the length field for the 
other modes, which would eliminate this issue.

Note: in comparing the AAL5 PDU mode to multicell mode the efficiency 
trade off depends on the cell mode. With the fischer multicell mode the 
AAL5 PDU mode saves 1 byte per cell. With the brayley multicell mode the 
AAL5 PDU mode saves 4 bytes per cell.

Robert

> Sent: Thursday, May 02, 2002 3:07 PM
> To: pwe3

---

From: [email-masked]
Date: Thu, 2 May 2002 16:15:03 -0500

Eric,
	A reason to use single cell mode versus a multiple cell mode or a 
frame mode is if delay is an issue. For example, if AAL1 is being used 
for voice then for each extra cell that you encapsulate you encounter an 
additional 6 msec of delay.

Robert Dianda

---

From: "MUSTAPHA AISSAOUI" <[email-masked]>
Date: 2 May 2002 18:05:15 -0400

John,
I think the many VCCs to one PW LSP could be seen as a two step approach in the
PE. The first step is the multiplexing of the ATM VCs into a VP, and then the
second step is to take the resulting VP and ship it into a PW LSP. This VP has
the same originating and terminating point as the PW LSP.

This is allowed by the ATM Forum specification.

Regards,
Mustapha.
----------

---

From: Shahram Davari <[email-masked]>
Date: Thu, 2 May 2002 15:05:47 -0700

Rob,

I thought one of the requirements of PWE3 was to determine the processing of the payload
at the egress PE, by just looking at the PW header. If so then muxing multiple VCs in one PW
does not fulfill this requirement. 

Also what is the point of muxing VCs in a single PW? to save label? Isn't 1 million PW labels per PE-PE enough? or if you are using per-platform labels, isn't 1 million PW LSP terminations at a PE enough? 

I think you need to consider the fact that muxing multiple VCs in a single PW has the following disadvantages too:

1) You can't signal the context any more -> less BW efficiency
2) You need at least 2 lookups (VC Label + VPI/VCI) instead of one 1 lookups (VC label), in other words you are doing an MPLS switching followed by ATM switching.

Yours,
-Shahram

> Sent: Thursday, May 02, 2002 5:24 PM
> To: [email-masked]; [email-masked]

---

From: Jim Harford <[email-masked]>
Date: Thu, 02 May 2002 18:11:48 -0400

Lloyd,
I'm very confused by your notion "transparency *is* efficiency".  In the 
context of this discussion, "transparency" is the ability of the ATM-MPLS 
network interworking to hide the fact that ATM cells between two ATM 
endpoints traverse an intermediate MPLS network.  Efficiency measures the 
amount of wasted overhead internal to the MPLS network.

The user at the ATM service access point does not care about efficiency 
within the MPLS network, unless that efficiency is so bad that the carrier 
can use it as an excuse to charge more money for the ATM service.  The user 
at the ATM service access point does care to some extent about 
transparency; the amount of transparency concern varies with the 
application being run across the ATM network.

Jim Harford

At 10:30 PM 5/2/2002 +0100, Lloyd Wood wrote:
>On Thu, 2 May 2002, Rutemiller, John wrote:
>
>transparency *is* efficiency.
>
>or rather, a set of efficiencies we're not very good at measuring.
>
>L.
>
><[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 3 May 2002 11:32:53 -0400

Hi Shahram and pwe3 colleagues,

the considerations you are mentioning regarding the many-to-one multiplexing
case were discussed in the ITU-T SG 13, and were one of the main reasons it
was decided to address only the one-to-one case initially for simplicity.

At that time it was felt by most folks that there was sufficient multiplex
capability available as a result of the label stacking property of MPLS
(i.e. in the transport LSP).

OF course if people feel there is need now for this many-to-one multiplex
capability, I have no issue with it, but I think it should be treated as a
new application, separated from the simple one-to-one case.

In any case the martini/brayley encap mechanism would support this
application, with the points you mention.

Regards,
Khalid

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 6:06 PM
To: [email-masked]'; [email-masked];
[email-masked]

Rob,

I thought one of the requirements of PWE3 was to determine the processing of
the payload
at the egress PE, by just looking at the PW header. If so then muxing
multiple VCs in one PW
does not fulfill this requirement. 

Also what is the point of muxing VCs in a single PW? to save label? Isn't 1
million PW labels per PE-PE enough? or if you are using per-platform labels,
isn't 1 million PW LSP terminations at a PE enough? 

I think you need to consider the fact that muxing multiple VCs in a single
PW has the following disadvantages too:

1) You can't signal the context any more -> less BW efficiency
2) You need at least 2 lookups (VC Label + VPI/VCI) instead of one 1 lookups
(VC label), in other words you are doing an MPLS switching followed by ATM
switching.

Yours,
-Shahram

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 3 May 2002 11:39:28 -0400

Hi Jim and pwe3 colleagues,

I fully agree with you in making the distinction between transparency and
efficiency.

Both were seen as desirable design objectives for the ATM over MPLS encap
mechanisms.

Regards,
Khalid

-----Original Message-----
From: Jim Harford [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 6:12 PM
To: Lloyd Wood
Cc: [email-masked]
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS 

Lloyd,

Jim Harford

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 3 May 2002 13:31:17 -0400

I must say I find your last para below surprising, especially coming from
the ex-chair of the pwe3 WG !

At the first (which you hosted in Denver) meeting of the pwe3 when we
discussed charter and approach to work items, I remember clearly the ADs
(Scott and Alison ) saying that pwe3 should take into account the inputs
from other bodies (e.g. ITU-T, ATM Forum, etc.) to harmonize with the work
going on there.

I remember that well because I was encouraged by that statement of intent on
the part of pwe3 folks to be inclusive of all points of view, and yet define
a single set of standards for the industry.

Now you seem to be implying its O.K. to have different standards from
different bodies, presumably because people have implemented original
martini encapsulation and they maintain this fits all applications.

I understand we are all reluctant to change implementations, but does that
mean we should stop working on standards, which in the long run will help
promote market by ensuring interoperability ?

Whether or not we believe this to be the case, the ongoing discussion on the
list has demonstrated that there are different requirements or service
applications that people have in mind for ATM/MPLS, and maybe one mechanism
is not optimum for all cases.

If we can accept this, I believe we can converge on a consistant set of
drafts which describe the requirements for each application and then
identify the optimum encap for it, along the lines of my original
classification for example.

That enables backwards compatibility with both the martini encap as well as
the ATMF spec as I indicated in the proposal.  I think that is a significant
benefit, would you not agree ?

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 7:57 PM
To: Jim Harford
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

> 
> 
> Your premise is that Martini is already deployed and af-aic-0178.00 is 
> not.  I am not sure if that is fact.  Even if we were to agree on that 
> premise, it makes no sense to standardize Martini for cell mode (and 
> AAL-5 PDU mode) if the ATM Forum's version is better and does not impose 
> an unreasonable burden to implement.
> 
> But there is a more fundamental question to ask the Martini draft 
> authors: are you willing to make **any** changes?  Most standards bodies 
> make modifications to input submitted by members.  They do this because 
> the original authors don't have a monopoly on good ideas and the process 
> of compromise makes the specification acceptable to more parties.  It 
> seems that some of the Martini advocates are so far into the development 
> cycle that compromise is impossible.  In this case, the only value-add 
> of the IETF standards track is an RFC number.
> 
> Is this what the PWE3 group has devolved to?  Are we simply a rubber 
> stamp to obtain RFC numbers?
> 

no, but I would classify improvement as in the Frame-Relay header bits being

encapsulated in the right order, or a new mode of operation for ATM to
reduce 
implementation complexity, or enable a new application.

The issue I see here is that VC , and VP modes are quite efficient using
cell 
concatenation, and a single encapsulation saves significant development
cost.
( Of course SPs care , but some vendors would like the protocol to be
different 
so they can catch up in their development cycle ).

In level3's network we have  on average 12 bytes of overhead , and if we 
concatenate 12 cells , we are as efficient as ATM in the first place. I plan
to 
concatenate 100 cells, that would make it much more efficient.

It might come down to the fact that requirements are different between IETF
and 
other bodies , and we need different standards. Then I wonder which one will
be 
prevalent. >:)

Luca

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 3 May 2002 13:46:47 -0400

Hi Giles and pwe3 colleagues,

regarding your comment, I hope we dont develop international standards based
on things like the bandwidth prices in the market today !

It may be a consideration for some, but I believe standards development are
based on somewhat more fundamental principles than that.  

In most standards bodies I participate in, we are not even allowed to
mention price, for fear of anti-trust ligitation.

Regards,
Khalid

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Friday, May 03, 2002 7:14 AM
To: Jim Harford
Cc: Luca Martini; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

On Thu, 2002-05-02 at 19:19, Jim Harford wrote:
> 
> Luca,
> Please see my comments interspersed below:
> 
> At 09:22 AM 5/1/2002 -0600, Luca Martini wrote:
[snip]
> >I agree that we should try to be as efficient as ATM native networks, but

> >given the current bandwidth market I'm not sure that we need to improve
on 
> >ATM efficiency.
> >Today , a significant part of the service cost is in the edge device. The

> >bandwidth in the core is relatively cheap. For this service to be viable 
> >it has to be cheaper then a leased sonet line, otherwise there is no
point 
> >to even go further.
> >One of my major design parameters is to be able to implement this
protocol 
> >in as many devices as possible , and for the lowest cost possible. Hence,

> >having many different encapsulations, to perfectly tune efficiency , is 
> >not as important as keeping development cost down.
> 
> I have seen various studies concluding that the capitol expense of network

> elements is small compared to the recurring costs of bandwidth.  The 
> vendors' development cost is even further removed from expenses that a 
> carrier sees.  I think you are trying to optimize the wrong end of the 
> problem.  BTW, what aspect of the ATM Forum's cell mode precludes 
> implementation on a platform that can support Martini's cell mode?
[rest snipped]

how recent were these studies?

at the bandwidth prices I see in the market today I'm not so sure this
is true (in fact I am pretty sure that is isn't...)

Giles

-- 
=================================================================
Giles Heron    Principal Network Architect    PacketExchange Ltd.
ph: +44 7880 506185              "if you build it they will yawn"
=================================================================

---

From: Luca Martini <[email-masked]>
Date: Fri, 03 May 2002 13:01:11 -0600

[snip]

First , I would like to say that voice seems to survive the worst conditions without a glitch.

AT the london IETF I ran my office desk IP phone via a encrypted VPN, and the 
wireless 802.11b with 50Ms of jitter , and it run great.

There are other applications that are a lot more susceptible to jitter , like 
video.

Let's see , at DS3, if I want a maximum of 100 cell concatenated we need 942 us
or 273 us at OC3 speeds.

THis would be an upper bound on cells , and a lower bound on speed.
Please take a look at current CDVT contracts from SPs providing ATM, as an 
example http://www.wcg.com/services/enhanceddata/atm/sla-atm.html

Even with my exaggerated calculation above I'm well within typical ATM QoS 
contracts.

Luca

---

From: "Khalid Ahmad"<[email-masked]>
Date: Fri, 3 May 2002 15:16:56 -0400

Hi pwe3 colleagues,

considering that there has been significant amount of useful discussion
around this proposal over past week or so, I was wondering if it would be
helpful to have a conference call on :

Wednesday, 8 May at 12.00 noon EST

to summarize the discussion points and discuss how to progress the work.

I would like to get indication from the folks who made inputs to this thread
if they are able to participate in this call, so I can arrange bridge.

I propose 12.00 noon so colleagues from both U.S. west coast and Europe can
join in if they want. I dont anticipate we need more than 1 hr max.

I would appreciate if you can participate to this call, and let me know.

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 7:57 PM
To: Jim Harford
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

Luca

---

From: [email-masked]
Date: Fri, 3 May 2002 14:27:41 -0500

Luca,
	Yes. Voice can tolerate delay. But at some point you end up with 
delay being large enough that the end-users must say "over" ala ham 
radio. In todays public voice networks, a call can transit multiple 
networks if one network increases the delay this can impact the voice 
quality. Also, greater delay means larger buffers at the TDM/packet 
media gateways.

If a network increases its delay enough to impact voice quality users 
will not use that network. Also, a problem to be dealt with for some 
time is that while network providers transit to Voice over Packet the 
internetwork interconnect may be TDM. So the packetization delay can 
accumulate as the call transits network to network.

e.g. try placing a call with multiple networks adding 50 msec of 
additional delay.

Robert

> From: luca [mailto:[email-masked]]
> Sent: Friday, May 03, 2002 2:01 PM
> To: Robert.B.Dianda
> Cc: pwe3

---

From: Shahram Davari <[email-masked]>
Date: Fri, 3 May 2002 14:08:08 -0700

Luca,

I think your calculation is some what different from Robert's.
The 6 msec is the interval between voice cells from the same call.
You can't pack 100 of those in less than 600 mseconds.

Your calculation assumes that you can pack cells from 100 different calls.
I am wondering how? by aggregating them in one VP? or by using port mode?

-Shahram

> Sent: Friday, May 03, 2002 3:01 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: Giles Heron <[email-masked]>
Date: 04 May 2002 11:06:49 +0000

> I am wondering how? by aggregating them in one VP? or by using port mode?

I would hope you'd do one or the other...

I'm not sure how scalable it is to set up one VC for each voice call -
the label space may be 2 ^ 20, but many boxes have a much lower limit. 
And I don't think an ATM SVC signalling to LDP gateway is such a great
idea?

Giles

---

From: Giles Heron <[email-masked]>
Date: 04 May 2002 11:12:33 +0000

[rest snipped]

I beg to differ.  Standards have to be based in reality somewhere.  The
trend over time seems to be for the price of bandwidth to drop relative
to the price of switching/packet processing.  Designing standards which
ignore this, while perhaps intellectually stimulating (QoS is great fun
after all), seems to me to be something of a waste of effort.

Giles

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 May 2002 06:35:32 -0700

So are you saying that in a complexity-bandwidth compromise, we
should choose the solution that requires less complexity and more BW.

-Shahram

> Sent: Saturday, May 04, 2002 7:13 AM
> To: Khalid Ahmad
> Cc: Jim Harford; Luca Martini; [email-masked]

---

From: Giles Heron <[email-masked]>
Date: 06 May 2002 15:13:12 +0000

In general, yes - though of course if a relatively small increase in
complexity can produce a relatively large bandwidth saving then I'm all
for it...

---

From: "Khalid Ahmad"<[email-masked]>
Date: Mon, 6 May 2002 11:45:50 -0400

well Giles, I look forward to your contributions to the standards bodies
explaining us how to design protocol standards according to these principles
of market reality.

In the meantime, I hope we will continue to develop networking protocol
standards based on sound engineering principles and technical merit, and
allow the market "realities" to take care of themselves according to the
laws of economics.

Regards,
Khalid

-----Original Message-----
From: Giles Heron [mailto:[email-masked]]
Sent: Saturday, May 04, 2002 7:13 AM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: Jim Harford; Luca Martini; [email-masked]
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS

[rest snipped]

Giles

---

From: "Khalid Ahmad"<[email-masked]>
Date: Mon, 6 May 2002 12:00:18 -0400

Hi pwe3 colleagues,

following up on my earlier proposal to have a conference call for the
interested parties to ths topic this coming Wednesday 8 May at 12.00 noon
EST, I have only heard from couple of people in favour.

I would still like to hear from Luca, Jeremy and other colleagues if you
feel this would help progress some of the issues brought up in the email
discussion. I would appreciate if you could briefly RSVP.

Since time is short I provide bridge details below.  Unless you hear
otherwise from me please assume the call will go ahead as proposed.

Bridge :	+ 1 613 765 0160

Passcode:	393 4154#

I hope you can participate.

Regards,
Khalid

-----Original Message-----
From: Ahmad, Khalid [CAR:CS40:EXCH] 
Sent: Friday, May 03, 2002 3:09 PM
To: 'Luca Martini'; Jim Harford
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS

Hi pwe3 colleagues,

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 7:57 PM
To: Jim Harford
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

Luca

---

From: Giles Heron <[email-masked]>
Date: 06 May 2002 17:19:34 +0000

> allow the market "realities" to take care of themselves according to the

IMO sound engineering principles include an awareness of the likely
costs of each part of your system.

Your reality may differ.

Giles

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 May 2002 10:40:51 -0700

I think a more appropriate engineering approach would be to compare
the cost of the extra-BW usage during the life-time of the router
to the extra-cost of the router due to the increase in its complexity.

For example comparing single cell encapsulations of Fischer and Brayley,
the Fischer has ~5%  better BW utilization. Now assuming a PE router supports
2.5Gbit/s of ATM cell relay, the extra-BW required would be 125 Mbits/s ~=OC-3.
Assuming the cost of OC-3 between NY and LA to be ~200K$ a year. Source(Q1 2002):

http://www.isp-planet.com/research/2002/bw_prices.html

Assuming also the router life cycle is 1.5 years, if the savings in the router price due to less complexity is more than ~300K $ then you are right, it is better to waste BW.

BTW it also seems that the price of BW is near the bottom:

http://www.internetnews.com/isp-news/article/0,,8_1016421,00.html

-Shahram

> Sent: Monday, May 06, 2002 11:13 AM
> To: Shahram Davari
> Cc: Khalid Ahmad; Jim Harford; Luca Martini; [email-masked]

---

From: "Rutemiller, John" <[email-masked]>
Date: Mon, 6 May 2002 14:02:00 -0400

> Sent: Friday, May 03, 2002 10:25 AM
> To: Jim Harford
[SNIP]
> Since then bandwidth prices have been in freefall...
> 
> Also bear in mind that many SP backbones are heavily underused today. 
> So in adding new services using new edge boxes there may well be no
> bandwidth expense until the service takes off (at which point there will
> presumably be revenue to pay for any additional bandwidth).  In today's
> capital-constrained environment the cost of the edge boxes is likely to
> be the major factor in determining whether new services are launched at
> all :(

So you're saying I can go to Sprint or MCI or AT&T or BT or France Telecom
or NTT and buy an OC3/STM-1 service or even an OC48/STS-16 service and not
have to worry about the yearly cost of this service compared to the cost
of the equipment I put on either end?

Great!

John

---

From: "Rutemiller, John" <[email-masked]>
Date: Mon, 6 May 2002 14:07:54 -0400

> Sent: Friday, May 03, 2002 2:27 PM
> To: Rutemiller, John
> Cc: [email-masked]
> Rutemiller, John wrote:
> > There might be a lot of IP out there, but voice and leased 
> line still pay the bills.
> > 
> > John
> 
> 
> Yes, and all our voice runs over IP. :-)
> 
> Luca
> 

And how do you provide the QoS for the Voice IP? Do you over provision
the bandwidth, since there is so much of it available? Do you use MPLS
to provide traffic seperation and prority, along with over provioning?
Or, do you use ATM underneath the IP network to provide the proper QoS
separation between the voice traffic and the data traffic? Or maybe a
combination of these techniques.

John

---

From: Giles Heron <[email-masked]>
Date: 06 May 2002 19:18:35 +0000

> of the equipment I put on either end?

No - that wasn't what I said at all.

What I said was (putting this in bullets to help you understand the
logic):

1.  If backbones are underused then efficiency doesn't matter.  That
would seem fairly axiomatic - efficiency only matters once you are
starting to fill your existing pipes.

2.  Once backbones do fill up then you hopefully have revenues to pay
for upgrades.  Sure, at this point efficiency matters - but I would
guess that edge box costs would still be higher than bandwidth costs at
this point (though it depends which market you are buying bandwidth in -
certainly for transatlantic or pan-european circuits this is the case).

3.  If edge boxes are "expensive" then you are unlikely to get the
go-ahead to buy them at all - efficient or not.  As an SP I am in this
situation.  As a vendor you may not understand this reality.

Giles

---

From: "Rutemiller, John" <[email-masked]>
Date: Mon, 6 May 2002 14:24:18 -0400

> should choose the solution that requires less complexity and more BW.

You always want to go for the simplest solution, possibly at the
expense of some BW efficiency.

But it is also necessary to recognize all possible applications,
including those where BW efficiency is the driving factor.

Bandwidth may be cheap for a carrier when it owns the fiber and
transport facilities, but buying bandwidth from an IXC hasn't gotten
that cheap yet. And I don't think anyone would argue that bandwidth
is cheap if you need to hop across an ocean.

If you want to handle all cases, then either you need to one protocol
that is simple and enhance it for efficiency, or you need two protocols.

Which option shall we choose?

Many people seem to be arguing for two protocols: one as simple as
possible, the other as efficient as possible.

I would like to see only one protocol. Something that starts off simple,
then adds in the minimal amount of additional complexity needed to
increase efficiency.

John

---

From: "Rutemiller, John" <[email-masked]>
Date: Mon, 6 May 2002 15:03:19 -0400

If you have already paid for the bandwidth (you own the fiber,
and/or the transport equipment) that is underutilized, then of course
the additional cost to use something you already paid for is small.

By my point was that if you must buy that bandwidth from someone else,
it's not so cheap anymore.

And as an equipment vendor, I am well aware that some carriers (maybe
not all, such as yourself) are sensitive to the cost of bandwidth.

Isn't that why to this day people complain about the ATM cell tax and
the "wasted" bandwidth? Or was there another reason?

And as a vendor, we are aware of the importance of equipment costs to
carriers. How much carriers are willing to spend impacts that all
important margin on equipment we sell.

This is why I want to see this arguement end and converged on a single
protocol to solve this problem. It costs me less to build one protocol
that is a little more complex but will satisfy the needs of all my
customers than it is too build in two protocols to satisfy the needs
of some customers that have BW to spare, and other customers that have
requirements for efficiency.

I can keep the cost of the board I sell to you down if I build one board
for each protocol. But then my costs go up significantly.

I'm shooting for the protocol that starts off simple, and with the least
amount of effort improves the efficiency. One protocol that will satisfy
both groups of carriers.

But people are so bent on arguing for one end of the spectrum and against
the other end of the spectrum.

No one is willing to admit that there are some carries that favor
simplicity and some carriers that favor efficiency. Everyone keeps
argueing with only one set of carriers in mind.

This has got to change.

Until it does, we will continue to agrue about the encapsulation for the
foreseeable future.

But as soon at you recognize the need to support both types of carriers,
you will also recognize that there are solutions that can achieve the
desired efficiency. But still retain overall simplicity.

John

> Sent: Monday, May 06, 2002 3:19 PM
> To: Rutemiller, John
> Cc: [email-masked]

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 May 2002 11:54:50 -0700

Giles,

It seems that your main service is across Atlantic. How is that cheap for you?
Do you own the fibers and optical boxes?

-Shahram

---

From: Jim Harford <[email-masked]>
Date: Mon, 06 May 2002 15:17:12 -0400

Shahram,
I think your 5% number assumes that FIFO delivery is guaranteed by the MPLS 
network; therefore, the fields that carry the sequence number in Fischer & 
Brayley are not required.  However, the MPLS specifications do not 
guarantee FIFO delivery.  Unless there is an additional SLA from the MPLS 
network provider, the sequence number fields are required.  By my 
calculations, the difference between the encapsulations in this scenario 
now rises to ~8% (59 bytes versus 64 bytes).

Using the rest of your assumptions & math, the break-even point would be a 
difference of $480,000 in the cost of a PE router, due to 
this  "overwhelming complexity" of the Fischer approach.  Let's pretend I 
am building PE routers and I think I can sell more than 20 with an ATM-MPLS 
interworking feature.  Ignoring the time value of money (especially since I 
haven't told you how long it will take to sell 20 routers) and assuming a 
50% profit margin, that means my break-even delta development cost is 
almost 5 million dollars!

Is there anyone out there who wishes to stand up here and argue that it 
would take millions of dollars to implement Fischer instead of Brayley for 
cell mode?  The real "market reality" is that it makes no sense to throw 
away lots of dollars in bandwidth inefficiency so that some engineer in a 
cubicle can save a few weeks on his chip design.

Jim Harford

P.S. - Legal Anti-trust Disclaimer:  I am not in the router business, so I 
do not know a typical percentage of profit margin.

At 10:40 AM 5/6/2002 -0700, Shahram Davari wrote:
>Assuming also the router life cycle is 1.5 years, if the savings in the 
>router price due to less complexity is more than ~300K $ then you are 
>right, it is better to waste BW.
>

---

From: Jim Harford <[email-masked]>
Date: Mon, 06 May 2002 15:34:30 -0400

OK, I can't resist any longer ...

I hope at some point, Luca's VoIP gets converted to voice over TDM.  This 
is a requirement if he wants to call me or some other 800 million phone 
numbers worldwide.

In terms of revenue, it's a voice world, NOT IP.

Jim Harford

---

From: Shahram Davari <[email-masked]>
Date: Mon, 6 May 2002 12:35:28 -0700

Jim,

Yes, I assumed no control-words.

-Shahram

> Sent: Monday, May 06, 2002 3:17 PM
> To: Shahram Davari; 'Giles Heron'
> Cc: Khalid Ahmad; Luca Martini; [email-masked]
> >2.5Gbit/s of ATM cell relay, the extra-BW required would be 
> 125 Mbits/s 
> >~=OC-3.
> >Assuming the cost of OC-3 between NY and LA to be ~200K$ a 
> year. Source(Q1 
> >2002):
> >

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 07 May 2002 10:31:16 +0100

> should choose the solution that requires less complexity and more BW.

Within reasonable limits yes**.

Stewart

** and for reference IMHO none of the PWE3 proposals that are on the
table exceed that limit.

---

From: Giles Heron <[email-masked]>
Date: 07 May 2002 10:39:47 +0000

Hi Shahram,

in fact my main service is pan-European (though yes we also do T/A).

I can't really comment on the costs in a public forum - but no, we don't
own the fibre/optics, and yes our network is certainly "cheap".

Giles

---

From: [email-masked]
Date: Tue, 7 May 2002 13:46:00 +0100

Hi Jim please see below,  regards Neil
Jim Harford wrote 06 May 2002 20:17
> cubicle can save a few weeks on his chip design.
NH=> Jim, if we are going to take the issue of BW efficiency seriously in
this case, than perhaps we ought to look at those protocols/technologies
that are the least efficient 1st would you not agree?  What about LDP in the
context of VPNs vs FR VPNs say?.....if former have to be overengineered due
to the inability to disentangle QoS/survivability whilst latter are often
overbooked by say 6x (we can still prioritise survivability here) then we
have something >6x BW inefficiencies/costs for carriers.  I am sure there
are plenty more examples like this.  So whilst I accept we should not
squander BW, my view is that we ought not compromise
architectural/engineering common sense just for the sake of BW efficiency in
this case if there are other more BW wasteful technologies out there.  I do
however agree with your last sentiments, and I get a strong feeling that
some protocols/function decisions are taken on the basis of box costs rather
than taking into account the larger vista of overall network costs.......be
these BW or other capex/opex considerations.  Now that the BW/bubble feeding
frenzy has died down operators should hopefully be more alert to these
issues and see things as they really are.

---

From: "Khalid Ahmad"<[email-masked]>
Date: Tue, 7 May 2002 16:21:52 -0400

Hi pwe3 colleagues,

so far I have had virtually no response to my proposal to hold a conference
call tomorrrow (Wed 8 May) re this topic, as outlined below. 

Maybe most people are too busy, or not interested, or just want to continue
the discussion by email at this stage.

So I suggest to postpone this call for now. My apologies to those who did
respond for any inconvenience caused.

Regards,
Khalid

-----Original Message-----
From: Ahmad, Khalid [CAR:CS40:EXCH] 
Sent: Monday, May 06, 2002 11:52 AM
To: 'Luca Martini'; 'Jim Harford'
Cc: [email-masked]'; [email-masked]'
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS

Hi pwe3 colleagues,

Passcode:	393 4154#

Regards,
Khalid

-----Original Message-----
From: Ahmad, Khalid [CAR:CS40:EXCH] 
Sent: Friday, May 03, 2002 3:09 PM
To: 'Luca Martini'; Jim Harford
Cc: [email-masked]; [email-masked]
Subject: RE: [PWE3] Proposed way to move forward re ATM/MPLS

Hi pwe3 colleagues,

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Thursday, May 02, 2002 7:57 PM
To: Jim Harford
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

Luca

---

From: Luca Martini <[email-masked]>
Date: Tue, 07 May 2002 17:04:37 -0600

Khalid Ahmad wrote:

> explaining us how to design protocol standards according to these 
> principles of market reality.
> 

So are you proposing that we run the internet with  SNA over ATM , because

it has more technical merit ?
:-)

Engineering has to take into account financial implications.

Luca

-- 
Just say no to summer. Ski all year !
Luca Martini Senior Network Architect, Level 3 Communications - Broomfield, CO
[email-masked] | VE2WKR/W0 | Phone 720-888-1225 | pager [email-masked]

---

From: Luca Martini <[email-masked]>
Date: Tue, 07 May 2002 17:11:21 -0600

[snip]
l

> is cheap if you need to hop across an ocean.

Actually BW across the atlantic is much ceaper then within the US.
It's fierce competition. I think the pacific going to  follow that trend.

---

From: Luca Martini <[email-masked]>
Date: Tue, 07 May 2002 17:58:05 -0600

Khalid Ahmad wrote:

> regarding your comment, I hope we dont develop international standards 
> based on things like the bandwidth prices in the market today !
> 

Maybe that is why the Internet does not run ATM.
Cost and complexity are an integral part of the engineering process, I cannot 
believe that standards bodies do not take that into serious consideration.
I'm a service provider , and I want to reduce the cost of my network, while 
equipment vendors always strive to increase the cost of my network.
Adding complexity, and forcing hardware upgrades does not reduce the cost of 
providing service. Bandwidth pricing in the market today will dictate what 
technology will emerge tomorrow, ignoring this is a mistake.

Regards,
Luca

> It may be a consideration for some, but I believe standards development 
> are based on somewhat more fundamental principles than that. 
> 

>  > >given the current bandwidth market I'm not sure that we need to 
> improve on
>  > >ATM efficiency.

---

From: Luca Martini <[email-masked]>
Date: Tue, 07 May 2002 18:04:41 -0600

Khalid,

I think that we are making progress on this list, and I don't want any more 
allegations of taking any discussion off this list. ( design teams etc... )
You are welcome to call me if you want, but I think that group discussions 
should happen on PWE3 list.

Thanks.
Luca

Khalid Ahmad wrote:

> around this proposal over past week or so, I was wondering if it would 
> be helpful to have a conference call on :
> 
> I would like to get indication from the folks who made inputs to this 
> thread if they are able to participate in this call, so I can arrange 
> bridge.
> 
> I propose 12.00 noon so colleagues from both U.S. west coast and Europe 
> can join in if they want. I dont anticipate we need more than 1 hr max.
> 
> concatenate 12 cells , we are as efficient as ATM in the first place. I 
> plan to
> It might come down to the fact that requirements are different between 
> IETF and
> other bodies , and we need different standards. Then I wonder which one 
> will be
> prevalent. >:)
> 
> Luca
> 
> 
> 
>

---

From: "Khalid Ahmad"<[email-masked]>
Date: Wed, 8 May 2002 11:54:36 -0400

Hi Luca,

I agree with you that we are making progress on this list, and I am pleased
to hear you think so too.  

However, I think you misunderstand me in proposing also to discuss by
conference call.  I have no intention of taking any discussions off the list
or setting up design teams etc. My previous experience with "design teams"
in pwe3 was not good, as you well know, so I have no desire to do it again !

The conf call discussion was intended to be for anyone from pwe3 interested
in this topic.  I happen to believe it may help progress the discussion
going on by email, by clarifying some of the points raised. However, some
people think otherwise and of course they are entitled to that opinion, no
problem for me.

The real question is:  how do we converge and build concensus on the email
discussions ? I would appreciate your inputs to this.

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 8:05 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: Jim Harford; [email-masked]; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

Khalid,

Thanks.
Luca

---

From: "Khalid Ahmad"<[email-masked]>
Date: Wed, 8 May 2002 13:40:53 -0400

Hi Luca, Giles,

I hope you dont think that I am so naive as to suggest that complexity
aspects are not considered in developing standards.  Of course they are, and
complexity can translate into costs, as we all know. That was not my point. 

But the complexity-cost translations are generally very complex, involving
many factors the may be outside the domain of standardization. Consequently
it is difficult to factor in costs in such discussions, specifically in such
topics as trying to decide on protocol details. 

In my experience, standards folks do try to minimize complexity as far as
possible, while trying to satisfy many diverse requirements or applications
to end up with a minimum (ideally single) solution set.

I think this is precisely what we are trying to do in this very discussion !

In any case, I hope this discussion does not get bogged down in ATM versus
IP types of arguments.  No need for that. After all, we need both since we
are talking about ATM/ MPLS interworking.  

I hope we can keep the discussion focused on the applications we are trying
to define and converge on a commonly agreed set.

Regards,
Khalid

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Tuesday, May 07, 2002 7:58 PM
To: Ahmad, Khalid [CAR:CS40:EXCH]
Cc: Giles Heron; Jim Harford; [email-masked]
Subject: Re: [PWE3] Proposed way to move forward re ATM/MPLS

Cost and complexity are an integral part of the engineering process, I
cannot 

Regards,
Luca