Subject: RE: RE: draft-cohen-pwe3-tdmsonetapp-00.txt

From: "Ron Cohen" <[email-masked]>
Date: Tue, 25 Jun 2002 00:06:18 +0200

Yaakov,

> Based on these WG documents, the definition of an AS
> is a document which defines the limitations of the emulated 
> service as compared to the native one.

We have tried to capture these limitations in the draft, please see
sections 1-4. If we missed any of these limitations, we would appreciate
feedback.

> The draft in the subject line is indeed an interesting one, 
> explaning how two previously unrelated TDM drafts could 
> "divide up the application space" between them, 
> in a way extremely similar to what I have been proposing all 
> along. (Please recall my summary of the Tel Aviv TDM meeting.)

I think it is a good step forward. I'm not sure what is wrong here.

Are you arguing that there is more 'application space' we have not
addressed?

Are you arguing that the AAL based encapsulation provides better
solution for the application scenarios mentioned in the draft?

We can all benefit from discussion on these points. I think that
arriving at a common encapsulation, common PWE3 control word and
understanding the implications of different application scenarios is a
good thing. If answering the questions above would lead to inclusion of
the AAL based TDM emulation within the common applicability statement
than this is fine too, and we are done.

Regards
Ron

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein
> Sent: Monday, June 24, 2002 5:12 PM
> To: [email-masked]
> Subject: [PWE3] RE: draft-cohen-pwe3-tdmsonetapp-00.txt
> 
> 
> Greetings to all the authors of the above draft.
> 
> I was going to send this email to the authors,
> but when I started typing their numerous addresses
> I decided that I might as well send to the entire PWE list.
> 
> I have a technical question regarding this draft.
> 
> In the PWE requirements document we find the following 
> explanation of an "Applicability Statement":
> 
>   5.  Faithfulness of Emulated Services
> 
>    An emulated service SHOULD be as similar to the native service as
>    possible, but it is not REQUIRED that they should be identical. The
>    applicability statement of a PWE3 service MUST report any 
> limitations
>    of the emulated service.  <snip>
> 
> Similarly, in the framework document we find:
> 
>    From the customer perspective, the PW is perceived as an unshared
>    link or circuit of the chosen service.  However, there may be
>    deficiencies that impede some applications from being carried on a
>    PW.  These limitations should be fully described in the appropriate
>    service-specific Encapsulation, Emulation and Maintenance Documents
>    (EEMDs) and Applicability Statements (ASes).
> 
> Based on these WG documents, the definition of an AS
> is a document which defines the limitations of the emulated 
> service as compared to the native one.
> 
> The draft in the subject line is indeed an interesting one, 
> explaning how two previously unrelated TDM drafts could 
> "divide up the application space" between them, 
> in a way extremely similar to what I have been proposing all 
> along. (Please recall my summary of the Tel Aviv TDM meeting.)
> 
> It is all the more interesting in that the authors of two of 
> the TDM drafts could resolve their previously unresolvable 
> differences, but didn't consider inviting the third draft 
> (actually the first draft chronologically) authors to participate.
> 
> I just don't understand how this draft is an "Applicability 
> Statement" according the meaning of that term as defined in 
> the WG documents.
> 
> Y(J)S
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>