Subject: [PWE3] OAM Msg Mapping Drafts

From: Stewart Bryant <[email-masked]>
Date: Fri, 25 Jul 2008 15:16:34 +0100

We had hoped to resolve this face to face before
the PWE3 meeting next week but that now looks
unlikely. We are  concerned that we need to
resolve this without the issue absorbing all
of the time in the WG meeting.

In order to gauge the consensus of the WG we would
would like to ask some questions.

When considering how to approach the message mapping
document issue, we think that the most important
considerations are:

1) That we deliver a high quality document that describes
    the design to the implementors and users.

2) That the Ethernet design is fully reviewed.

3) That there is consistency between the approaches used
    for the various OAM mappings.

4) That the Ethernet design is delivered in an expedited
    manner and the ATM and FR designs are also delivered
    in a timely manner.

We have three approaches:

a) LC and publish draft-ietf-pwe3-oam-msg-map-06.txt, and

    Accept draft-mohan-pwe3-mpls-eth-oam-iwk as
    a WG document

b) LC and publish draft-ietf-pwe3-oam-msg-map-07.txt
    (i.e. Luca's rewrite) but without  the Ethernet
    section, and

    Accept draft-mohan-pwe3-mpls-eth-oam-iwk as a WG
    document

c) Use publish draft-ietf-pwe3-oam-msg-map-07.txt  as
    the basis for ongoing work.

Before any document is sent to the IESG for publication
we will ensure contributions are appropriately acknowledged
through  editorship, authorship, & acknowledgments. So
please set any such issues aside and focus on the best
document to deliver to our users.

Please also set aside the poor etiquette that has taken
place, and  focus on  how best to deliver  the required
documentation to the community. On the basis of
considerations 1..4 above, which documentation
approach, a, b or c, do you consider most likely to
achieve the goals of the WG?

Stewart & Matthew

_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: <[email-masked]>
Date: Fri, 25 Jul 2008 16:41:16 +0200

Hi all,

I strongly support approach a.

For me it is the best approach to deliver an OAM solution for PW in a timely manner, and it is fully in line with the consensus that emerged during the last meeting.

Regards,

Philippe. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Stewart Bryant
Envoyé : vendredi 25 juillet 2008 16:17
À : pwe3
Objet : [PWE3] OAM Msg Mapping Drafts

We had hoped to resolve this face to face before the PWE3 meeting next week but that now looks unlikely. We are  concerned that we need to resolve this without the issue absorbing all of the time in the WG meeting.

In order to gauge the consensus of the WG we would would like to ask some questions.

When considering how to approach the message mapping document issue, we think that the most important considerations are:

Before any document is sent to the IESG for publication we will ensure contributions are appropriately acknowledged through  editorship, authorship, & acknowledgments. So please set any such issues aside and focus on the best document to deliver to our users.

Please also set aside the poor etiquette that has taken place, and  focus on  how best to deliver  the required documentation to the community. On the basis of considerations 1..4 above, which documentation approach, a, b or c, do you consider most likely to achieve the goals of the WG?

Stewart & Matthew

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 25 Jul 2008 10:51:41 -0400

I would go for option C, but press for a LC within 30 days or go with
one of the other options if that deadline cannot be met.

	--Tom

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 25 Jul 2008 11:25:23 -0400

I would go with option (a).

Best regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stewart Bryant
Sent: July-25-08 10:17 AM
To: pwe3
Subject: [PWE3] OAM Msg Mapping Drafts

Stewart & Matthew

---

From: "David Allan" <[email-masked]>
Date: Fri, 25 Jul 2008 11:29:07 -0400

Getting past 'a' has taken years. Lets just go with 'a' and declare
victory...

Dave 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Shahram Davari
Sent: Friday, July 25, 2008 11:25 AM
To: [email-masked]; pwe3
Subject: Re: [PWE3] OAM Msg Mapping Drafts

Best regards,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: July-25-08 10:17 AM
To: pwe3
Subject: [PWE3] OAM Msg Mapping Drafts

We had hoped to resolve this face to face before the PWE3 meeting next
week but that now looks unlikely. We are  concerned that we need to
resolve this without the issue absorbing all of the time in the WG
meeting.

In order to gauge the consensus of the WG we would would like to ask
some questions.

When considering how to approach the message mapping document issue, we
think that the most important considerations are:

Before any document is sent to the IESG for publication we will ensure
contributions are appropriately acknowledged through  editorship,
authorship, & acknowledgments. So please set any such issues aside and
focus on the best document to deliver to our users.

Please also set aside the poor etiquette that has taken place, and
focus on  how best to deliver  the required documentation to the
community. On the basis of considerations 1..4 above, which
documentation approach, a, b or c, do you consider most likely to
achieve the goals of the WG?

Stewart & Matthew

---

From: "Drake, John E" <[email-masked]>
Date: Fri, 25 Jul 2008 08:36:30 -0700

a) 

>From: Stewart Bryant [mailto:[email-masked]] 
>Sent: Friday, July 25, 2008 7:17 AM
>To: pwe3
>We had hoped to resolve this face to face before the PWE3 
>meeting next week but that now looks unlikely. We are  
>concerned that we need to resolve this without the issue 
>absorbing all of the time in the WG meeting.
>
>When considering how to approach the message mapping document 
>issue, we think that the most important considerations are:
>
>Before any document is sent to the IESG for publication we 
>will ensure contributions are appropriately acknowledged 
>through  editorship, authorship, & acknowledgments. So please 
>set any such issues aside and focus on the best document to 
>deliver to our users.
>
>Please also set aside the poor etiquette that has taken place, 
>and  focus on  how best to deliver  the required documentation 
>to the community. On the basis of considerations 1..4 above, 
>which documentation approach, a, b or c, do you consider most 
>likely to achieve the goals of the WG?
>
>
>Stewart & Matthew
>
>
>
>
>
>
>

---

From: "Dinesh Mohan" <[email-masked]>
Date: Fri, 25 Jul 2008 11:39:08 -0400

I also support option a).

---
Dinesh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 25, 2008 10:41 AM
To: [email-masked]; [email-masked]
Subject: Re: [PWE3] OAM Msg Mapping Drafts

Hi all,

Regards,

Philippe. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Stewart Bryant Envoyé : vendredi 25 juillet 2008 16:17 À : pwe3 Objet : [PWE3] OAM Msg Mapping Drafts

Stewart & Matthew

---

From: "Shah, Himanshu" <[email-masked]>
Date: Fri, 25 Jul 2008 12:24:25 -0400

Option A.

/himanshu

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Stewart Bryant
> Sent: Friday, July 25, 2008 10:17 AM
> To: pwe3

---

From: "O'Connor, Don" <[email-masked]>
Date: Fri, 25 Jul 2008 11:38:18 -0500

I support option a)

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stewart Bryant
Sent: Friday, July 25, 2008 9:17 AM
To: pwe3
Subject: [PWE3] OAM Msg Mapping Drafts

Stewart & Matthew

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 25 Jul 2008 09:41:19 -0700

Given that Luca has spent time & energy to update this draft (specially
for non-Eth sections), I would opt for option (b) (Luca rewrite without
Ethernet and WG call of Ethernet draft) with proper editorship list (so
credit be given where it is due).

- Ali    

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Stewart Bryant (stbryant)
> considerations 1..4 above, which documentation approach, a, b 
> or c, do you consider most likely to achieve the goals of the WG?
> 
> 
> Stewart & Matthew
> 
> 
> 
> 
> 
> 
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 25 Jul 2008 12:48:04 -0400

Stewart,

I strongly support option a.

Thanks,
Andy

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Fri, 25 Jul 2008 12:03:27 -0500

Option a) 

> Behalf Of Stewart Bryant

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 25 Jul 2008 13:10:40 -0400

I'd like to point out that although this focus is on the eth-oam, there 
were additional updates to this "updated rev -07" version, including:

1. Update (rework/rewrite) of the L2TPv3 portions (as Luca mentioned
    with "L2TP message mapping is broken", those segments needed work). I
    made those edits (and would very much like to get feedback on them).
2. Small catch-up with some of the VCCV-related updates (e.g., there was
    no reference to VCCV-BFD, and no demarc from RFC5085, same)
3. Address 
<http://www.ietf.org/mail-archive/web/pwe3/current/msg09479.html>.
4. Others (standby state, et cetera).

As such, I'd like to request that these edits (the updates to non-eth 
portions) do not get lost in the process, and option a) seems to make 
these updates go away. As far as whether merging the eth-oam or keeping 
it in a separate document, I really do not have a preference. As long as 
the WG work is equally timely, complete and accurate, I have no 
preference as to which document contains it, and thus b) or c) would be 
fine for me.

Thanks,

--Carlos.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: "Hamid Ould-Brahim" <[email-masked]>
Date: Fri, 25 Jul 2008 13:22:11 -0400

Option a).

Hamid.

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Fri, 25 Jul 2008 12:27:24 -0500

Carlos,

It may be true that the L2TPv3 portion required improvements, but the
normal process would have been to point out on the mailing list. As far
as I know, the L2TP-related text has not changed since 2005, so there
has been ample time to fix the mistakes. Having new people identify
themselves as editors and making modifications to a document based on
the claim that the old text was "broken" is a bizarre way to update a WG
document.

I propose that you send an email to the mailing list to point out what
needs to be changed in the 06-version of the text. The editors can then
take that into consideration for the new version. 

Peter

> Behalf Of Carlos Pignataro
> Sent: Friday, July 25, 2008 1:11 PM
> To: [email-masked]
> Cc: pwe3
> I'd like to point out that although this focus is on the 
> eth-oam, there were additional updates to this "updated rev 
> -07" version, including:
> 
>     no reference to VCCV-BFD, and no demarc from RFC5085, 
> same) 3. Address 
> portions) do not get lost in the process, and option a) seems 
> to make these updates go away. As far as whether merging the 
> eth-oam or keeping it in a separate document, I really do not 
> have a preference. As long as the WG work is equally timely, 
> complete and accurate, I have no preference as to which 
> document contains it, and thus b) or c) would be fine for me.
> 
> Thanks,
> 
> --Carlos.
> 
> meeting next 
> document issue, 
> > we think that the most important considerations are:
> > 
> will ensure

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 25 Jul 2008 13:29:34 -0400

+1

Option a) 

Don  

> Behalf Of Busschbach, Peter B (Peter)
> Sent: Friday, July 25, 2008 1:27 PM
> To: Carlos Pignataro; [email-masked]
> Cc: pwe3
> place, and

---

From: <[email-masked]>
Date: Fri, 25 Jul 2008 14:00:49 -0400

I support option (a).

Thanks,
Nabil

-----Original Message-----

Stewart & Matthew

---

From: "BALUS Florin" <[email-masked]>
Date: Fri, 25 Jul 2008 16:50:24 -0500

Option a for me.

---

From: Luca Martini <[email-masked]>
Date: Fri, 25 Jul 2008 16:18:51 -0600

Clearly I vote for option C.

I have to ask the People on this thread to please read the document 
carefully.

Option A it is not possible. The document version 06  is not ready for 
LC , It needs a major rewrite.
I have only  put in about 50% of the work needed.
A new editor needs to take over and WE ( the WG ) need to finish the 
missing sections:

In Version 07 :

1) The editor list, and author's list need to be reviewed.
2) Review the rewritten L2TPv3  section. ( thanks to Carlos for the work)
3) BFD codes in section 8.3.5. needs to be reviewed ,  and update some 
text. ( some of the text is still wrong ).
4) Clear defect entry and exit criteria for static PWs using BFD need to 
be explained. Also what actions are taken at the AC.
5) The document needs an organizational re-write ( like the VCCV 
document needed ). I only did minor fixes and some removal of duplicated 
text.
6) The document still needs an complete English language review.

Note that because of  Dinesh's good writing stile, merging the ethernet 
section was not more then 1 hour of work.
It would be very simple to remove all mentions of ethernet now.

A WG last call is supposed to be issues when a document is pretty much 
completed. This document clearly needs work, and if the current editors 
no longer have time to complete the work , then new editors need to pick 
up the task.

Since the original authors actually lost the source of this draft ( the 
text in nroff, word , or xml format ), I spent over a day to reformat  
this very long document. I will gladly send the source nroff file to 
anybody who will pick up the editorial work. I do not wish to continue 
editing this document, but I want to make sure we progress this document 
in a timely manner.

Luca

---

From: "MULEY Praveen" <[email-masked]>
Date: Fri, 25 Jul 2008 17:21:40 -0500

Option 'a' for me. 

> When considering how to approach the message mapping document issue,

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 25 Jul 2008 21:04:39 -0400

Peter,

> the claim that the old text was "broken" is a bizarre way to update a WG

Luca had the editing pen token and sent me the nroff source file to 
update the l2tpv3 sections. It's not a very unusual flow from what I see 
(more so with short time), and allows for reviewing actual text on a 
draft instead of multiple line-by-line comments that focus on a section. 
However (see next comment),

> take that into consideration for the new version. 

Yes, Agreed, you are right; that's the ideal case. I'll send my comments 
to the list, and they can be incorporated if the WG finds them useful.

Thanks,

--Carlos.

---

From: "Busschbach, Peter B \(Peter\)" <[email-masked]>
Date: Fri, 25 Jul 2008 23:04:24 -0500

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Luca Martini
	Sent: Friday, July 25, 2008 6:19 PM
	To: [email-masked]
	Cc: pwe3
	Subject: Re: [PWE3] OAM Msg Mapping Drafts

>>	Option A it is not possible. The document version 06  is not
ready for LC , >>    It needs a major rewrite.

You keep making unspecific statements. Is there a working group
concensus that the document requires a major rewrite?

>>	A new editor needs to take over and WE ( the WG ) need to finish

>>    text.( some of the text is still wrong ).

In 2006, when I proposed editorial changes to Tom Nadeau who was acting
as the editor at that point, I submitted the following text:

" PE1 will exit the forward defect state if all previously 
" detected forward defects have been cleared and when all 
" previously received forward defect indications from the peer 
" PE have been revoked. If an in-band continuity verification 
" protocol such as BFD is used on the PW, PE1 may only exit the 
" PW forward defect state when it is correctly receiving the 
" associated control messages.

Had that text been adopted, section 6.1 would have applied to both
static and dynamic PWs. I propose that we adopt that text when we create
version 07.

document
>>      needed ). I only did minor fixes and some removal of duplicated
text.

Over time, the document structure has been revised significantly from
one version to the next. It is a complex subject and it is not easy to
get it in a logical order. The 06-version represents what several
authors thought was the best format. I haven't heard any complaints on
the mailing list. Please explain how you want to re-organize the text
and give people the opportunity to provide feedback, before the changes
are made.

>>    completed. This document clearly needs work, 

The document did indeed require the clean-up that you mention in your
points 1), 3) 4) and 6). Those are fairly minor, though. I don't agree
that the document requires a major overhaul. The chairs should decide
whether to go for last call. I don't understand why you believe you have
veto power. 

>>    and if the current editors no
>>    longer have time to complete the work , then new editors need to
pick up
>>    the task.

A true statement. Did you check with the current editors whether they
have time? I may have missed that email.

>>	Snipped till the end <<

---

From: Stewart Bryant <[email-masked]>
Date: Sat, 26 Jul 2008 08:22:11 +0100

Who (of the original editors) is lead editor on the document?

Stewart

---

From: Luca Martini <[email-masked]>
Date: Sat, 26 Jul 2008 15:09:45 -0600

Busschbach, Peter B (Peter) wrote:
>>> 	I have to ask the People on this thread to please read the
>>>       
> document
>   
>>>    carefully.
>>>       
> 	
>   
>>> 	2) Review the rewritten L2TPv3  section. ( thanks to Carlos for
>>>       
> the work)
>   
>>> 	3) BFD codes in section 8.3.5. needs to be reviewed ,  and
>>>       
> update some 
>   
>>> 	4) Clear defect entry and exit criteria for static PWs using BFD
>>>       
> need to
>   
this is still not enough.
For example a quote from section 5.3.4 ( ver -06 )

     A CV type of 0x08 in the OAM capabilities TLS indicates that BFD
     is used for both PW fault detection and AC/PW Fault Notification.
     In this case, all defects - including AC defects and PE internal
     failures - are signaled through BFD.

There is no specification  of what codes to use , and how to manage the 
defect states .
We added a section to explain this in ver 07, but I believe that we 
still need a more explanation  of the procedures  when code 6 and 8 are 
received.
I also believe that we need to define a new "path administratively down" 
code in this document to indicate when a port is shut down intentionally.

> and give people the opportunity to provide feedback, before the changes
Basically, there are a lot of sub-sections , that are really bullets in 
a list.
Section titles should not be bullet points example :

"8.2.4 Additional procedures for a FR PW, an ATM PW in the
      out-of-band ATM OAM over PW method, and an Ethernet PW"

what does this mean ???
There are a large number of issues of this type throughout the document. 
Even in Version 07 I have not addressed  most of these problems because 
We need to have a face to face meeting with all the editors to find a an 
agreement on how to better clarify this.

I think this section should simply be "Additional procedures" or maybe 
even merged into the other sections.

Section 5.3 is duplicated in section 5.3.2 ....
Section 9.1 has similar editorial issues as section 8.2.4...
etc .etc...

>>> 	Note that because of  Dinesh's good writing stile, merging the
>>>       
> ethernet
>   
>>> 	A WG last call is supposed to be issues when a document is
>>>       
> pretty much
>   
Who said I have veto power ????
I am trying to help move this document forward without it being rejected 
by the IESG.
The IESG does have veto power as demonstrated in the VCCV document case ....

> have time? I may have missed that email.
The set of editors I spoke with where happy to have me have the editing pen.

Note that I did not make any technical changes ( Carlos did update 
L2TPv3 ), but I believe that once the documented editorial issues are 
resolved , we still need more protocol specification.

Luca

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 28 Jul 2008 09:31:15 +0300

Stewart and all the respondents

My apologies for a late response, but I have been traveling.

I see many many votes for "a", but honestly don't understand that path at all.

I have looked over the version 6 draft, and can't imagine that anyone
really believes that it is ready for WG LC.
Has everyone forgotten what happened with the VCCV draft
that was sent to the IESG in unreadable fashion ?
Do we really want this thrown back at us with prejudice ?

On the other hand, as I remarked in a previous email,
I was quite annoyed with the process mess-up that
brought us a version 7 without Dinesh being given the time
to do a full review. Thus I understand option "b"
and even tended towards supporting it.

However, as I remarked at IETF-71, I want the Ethernet
material to go forward as quickly as possible.
Leaving the Ethernet out, means that we have to take Dinesh's
material and first make it a WG draft, then leave sufficient
time for it to be reviewed as a separate document,
and then LC it. This will take at least 2 IETFs.

Thus, I am lead, with a heavy heart, to support "c".
As in previous email, I believe that Dinesh must be given the time
needed to go over the draft and ensure that his material has
been included without being damaged in the process.
After that the author's list needs to be updated to ensure
recognition of Dinesh's contributions.
Thereafter we can LC that single draft and get this over with.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Mon, 28 Jul 2008 09:48:46 +0300

Well, perhaps I spoke too quickly.

After looking over the 07 version that Luca sent via email,
I think that changing the author's list is not enough to ready
this draft for WG LC.

Although much improved, more work is needed before this
could be sent to the IESG.

We need to expand the introductory material to explain the problem better,
fix up a lot of the wording, edit for readability, etc.
and only then go to LC.

Y(J)S

---

From: Yaakov Stein <[email-masked]>
Date: Tue, 29 Jul 2008 19:18:54 +0300

In my attempt to fit into the 5 minutes allotted,
I did not have the chance to ask the WG to accept the PW bonding draft
as a WG draft.

I hereby amend this lacuna.

Y(J)S

---

From: Lucy Yong <[email-masked]>
Date: Wed, 30 Jul 2008 05:01:25 -0500

Hi Yaakov,

I though you asked if WG would like to work on this solution?

I do not like WG to work on this because the inverse mux solution does not
work well in PSN: 
1) although PW tail end can perform traffic unit sequencing theoretically,
such process is very resource consumption due to individual path delay and
delay jitter dynamism (TDM is very consistent so it is possible to reduce
the arriving time differences among the sequenced frames at the tail end.).

2) having all the packet units in a PW at the tail end to be in the same
sequence as in the head end will cause different CoS flows in a PW to get
the same and worst performance, i.e. no CoS differenciation.

Regards,
Lucy

> Yaakov Stein
> Sent: Tuesday, July 29, 2008 11:19 AM
> To: pwe3
> Subject: [PWE3] PW bonding draft
> 
>

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 30 Jul 2008 20:21:18 +0300

Lucy

Both Stewart's "fat PW" and my PW bonding are solutions that are applicable
in certain circumstances.

I disagree that the problem is the tail end resequencing - this is actually the easiest part.
The real problems are
1) characterizing and ensuring separation of the PW components
2) performing the packet distribution algorithm at ingress.

Indeed, this solution may impact QoS, but less than not being able
to provide service at all.

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 1:01 PM
To: Yaakov Stein; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

I do not like WG to work on this because the inverse mux solution does not work well in PSN:
1) although PW tail end can perform traffic unit sequencing theoretically, such process is very resource consumption due to individual path delay and delay jitter dynamism (TDM is very consistent so it is possible to reduce the arriving time differences among the sequenced frames at the tail end.).

2) having all the packet units in a PW at the tail end to be in the same sequence as in the head end will cause different CoS flows in a PW to get the same and worst performance, i.e. no CoS differenciation.

Regards,
Lucy

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Yaakov Stein
> In my attempt to fit into the 5 minutes allotted, I did not have the
> chance to ask the WG to accept the PW bonding draft as a WG draft.
>

---

From: "HENDERICKX Wim" <[email-masked]>
Date: Wed, 30 Jul 2008 19:51:49 +0200

Yaakov,

I think what is important to state the applicability or consequences of
the solution proposed. From what I see is that PW bonding might work for
low speed pw connections, but might have issues with large bw pw.

Mainly for large bw pw the buffer requirements to accommodate this
solution can be huge. A pw service of several gbit would require a huge
amount of buffering. The solution also has an effect on the
jitter/latency for the pw connections and hence exclude it from certain
use cases.

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yaakov Stein
Sent: woensdag 30 juli 2008 19:21
To: Lucy Yong; 'pwe3'
Subject: Re: [PWE3] PW bonding draft

Lucy

Both Stewart's "fat PW" and my PW bonding are solutions that are
applicable in certain circumstances.

I disagree that the problem is the tail end resequencing - this is
actually the easiest part.
The real problems are
1) characterizing and ensuring separation of the PW components
2) performing the packet distribution algorithm at ingress.

Indeed, this solution may impact QoS, but less than not being able to
provide service at all.

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 1:01 PM
To: Yaakov Stein; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

I do not like WG to work on this because the inverse mux solution does
not work well in PSN:
1) although PW tail end can perform traffic unit sequencing
theoretically, such process is very resource consumption due to
individual path delay and delay jitter dynamism (TDM is very consistent
so it is possible to reduce the arriving time differences among the
sequenced frames at the tail end.).

2) having all the packet units in a PW at the tail end to be in the same
sequence as in the head end will cause different CoS flows in a PW to
get the same and worst performance, i.e. no CoS differenciation.

Regards,
Lucy

---

From: Yaakov Stein <[email-masked]>
Date: Wed, 30 Jul 2008 21:31:31 +0300

Indeed,

As I said, both drafts require applicability statements.

The approach I proposed is mostly for low BW access connections.
In the draft I mention xDSL - i.e. up to about 5 Mbps,
but also can work for low speed optics.

The limitation is partially the buffering
(although it only has to compensate for DIFFERENTIAL delay
which is not so bad)
but more so the state and computational load.

Y(J)S

-----Original Message-----
From: HENDERICKX Wim [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 8:52 PM
To: Yaakov Stein; Lucy Yong; pwe3
Subject: RE: [PWE3] PW bonding draft

Yaakov,

I think what is important to state the applicability or consequences of the solution proposed. From what I see is that PW bonding might work for low speed pw connections, but might have issues with large bw pw.

Mainly for large bw pw the buffer requirements to accommodate this solution can be huge. A pw service of several gbit would require a huge amount of buffering. The solution also has an effect on the jitter/latency for the pw connections and hence exclude it from certain use cases.

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: woensdag 30 juli 2008 19:21
To: Lucy Yong; 'pwe3'
Subject: Re: [PWE3] PW bonding draft

Lucy

Both Stewart's "fat PW" and my PW bonding are solutions that are applicable in certain circumstances.

Indeed, this solution may impact QoS, but less than not being able to provide service at all.

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 1:01 PM
To: Yaakov Stein; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

Regards,
Lucy

---

From: Lucy Yong <[email-masked]>
Date: Wed, 30 Jul 2008 14:51:28 -0500

Hi Yaakov,

First of all, I would like to ask if there is an issue for PSN to carry low
BW access connections. If not, why do make an effort to solve an unknown
application?
We do have problem to carry a LARGE size PW over PSN as stated in the FAT PW
draft. FAT PW provides one solutions when the PW has flow awareness. Another
solution is to transport it over a designated private link between PEs. The
later solution can apply to any PW. FAT PW just provides an alternate
solution to take advantage of multi paths for such special PWs. 

Regards,
Lucy

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: Wednesday, July 30, 2008 1:32 PM
> To: HENDERICKX Wim; Lucy Yong; pwe3
the solution
> proposed. From what I see is that PW bonding might work for low speed pw
> connections, but might have issues with large bw pw.
> 
solution can
> be huge. A pw service of several gbit would require a huge amount of
buffering.
> The solution also has an effect on the jitter/latency for the pw
connections and
> hence exclude it from certain use cases.
> 
> Cheers,
> Wim
> 
applicable in
> certain circumstances.
actually the
> easiest part.
provide
> service at all.
work
> well in PSN:
such
> process is very resource consumption due to individual path delay and
delay jitter
> dynamism (TDM is very consistent so it is possible to reduce the arriving
time
> differences among the sequenced frames at the tail end.).
> 
sequence
> as in the head end will cause different CoS flows in a PW to get the same
and
> worst performance, i.e. no CoS differenciation.
> 
> Regards,
> Lucy
> 
>

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 31 Jul 2008 11:32:27 +0300

Lucy

Yes, there ARE applications, and have been from the beginning of PWE,
where there are low BW connections (defined as only a few Mbps).

In particular, the TDM PW types have frequently been carried over such links,
and many service providers are using xDSL or PON connections for
out-of-footprint connectivity to end-points such as cellsites and SME locations.

My draft was not written as an arbitrary exercise,
but is an important element in several large-scale deployments in which I have been involved.
I have also received quite a few emails from other PWE participants who have
expressed interest in this mechanism.

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 10:51 PM
To: Yaakov Stein; 'HENDERICKX Wim'; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

First of all, I would like to ask if there is an issue for PSN to carry low BW access connections. If not, why do make an effort to solve an unknown application?
We do have problem to carry a LARGE size PW over PSN as stated in the FAT PW draft. FAT PW provides one solutions when the PW has flow awareness. Another solution is to transport it over a designated private link between PEs. The later solution can apply to any PW. FAT PW just provides an alternate solution to take advantage of multi paths for such special PWs.

Regards,
Lucy

> In the draft I mention xDSL - i.e. up to about 5 Mbps, but also can
> work for low speed optics.
>
> The limitation is partially the buffering (although it only has to
> compensate for DIFFERENTIAL delay which is not so bad) but more so the
> state and computational load.
>
> Y(J)S
>
>
the solution
> proposed. From what I see is that PW bonding might work for low speed
> pw connections, but might have issues with large bw pw.
>
solution can
buffering.
connections and
applicable in
actually the
provide
> not
work
> theoretically,
such
delay jitter
time
sequence
and

---

From: Lucy Yong <[email-masked]>
Date: Thu, 31 Jul 2008 04:05:42 -0500

Hi Yaakov,

Do these links are in PSN, or part of attachment circuit, or within Customer
domain?

Lucy

> Sent: Thursday, July 31, 2008 3:32 AM
> To: Lucy Yong; 'HENDERICKX Wim'; 'pwe3'
> but is an important element in several large-scale deployments in which I
have
> been involved.
> First of all, I would like to ask if there is an issue for PSN to carry
low BW access
> connections. If not, why do make an effort to solve an unknown
application?
> solution is to transport it over a designated private link between PEs.
The later
> solution can apply to any PW. FAT PW just provides an alternate solution
to take
> advantage of multi paths for such special PWs.
> 
> Regards,
> Lucy
>

---

From: <[email-masked]>
Date: Thu, 31 Jul 2008 11:27:01 +0200

Lucy,

As mentioned by Yakov there are some applications in which PW technology is extended in access networks over 2 Mbps LL, xDSL or PON access links, to small PE devices to support backhauling services, for example the backhauling of mobile traffics (BTS/NodeB to BSC/RNC).

Philippe.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Lucy Yong
Envoyé : jeudi 31 juillet 2008 11:06
À : 'Yaakov Stein'; 'HENDERICKX Wim'; 'pwe3'
Objet : Re: [PWE3] PW bonding draft

Hi Yaakov,

Do these links are in PSN, or part of attachment circuit, or within Customer domain?

Lucy

> My draft was not written as an arbitrary exercise, but is an important 
> element in several large-scale deployments in which I
have
> been involved.
> I have also received quite a few emails from other PWE participants 
> who
have
low BW access
application?
> We do have problem to carry a LARGE size PW over PSN as stated in the 
> FAT
PW
The later
to take
> > compensate for DIFFERENTIAL delay which is not so bad) but more so 
> > the state and computational load.
> >
> > Y(J)S
> >
> >
> > proposed. From what I see is that PW bonding might work for low 
> > speed pw connections, but might have issues with large bw pw.
> >
> > to
> > > Behalf Of Yaakov Stein
> > > In my attempt to fit into the 5 minutes allotted, I did not have 
> > > the chance to ask the WG to accept the PW bonding draft as a WG draft.
> > >

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 31 Jul 2008 12:53:12 +0300

Lucy

These are not "attachment circuits" in the sense that they are not carrying native service,
but rather they are PWE encapsulated data going over a PSN.

They are not "customer domain" in the sense that the links are under SP control.

In some cases they may be in the domain of an "access network provider"
as distinct from the "core provider", but frequently there is no such distinction.

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Thursday, July 31, 2008 12:06 PM
To: Yaakov Stein; 'HENDERICKX Wim'; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

Lucy

have
have
low BW access
application?
PW
The later
to take

---

From: "Shahram Davari" <[email-masked]>
Date: Thu, 31 Jul 2008 15:51:53 -0400

Hi Yaakov,

For the access applications other available techniques can be used such as
DSL-bonding or even PDH-VCAT.
In that sense why is the PW bonding required?

Thanks,
Shahram

-----Original Message-----
Sent: July-30-08 2:32 PM

Indeed,

Y(J)S

-----Original Message-----
From: HENDERICKX Wim [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 8:52 PM
To: Yaakov Stein; Lucy Yong; pwe3
Subject: RE: [PWE3] PW bonding draft

Yaakov,

I think what is important to state the applicability or consequences of the
solution proposed. From what I see is that PW bonding might work for low
speed pw connections, but might have issues with large bw pw.

Mainly for large bw pw the buffer requirements to accommodate this solution
can be huge. A pw service of several gbit would require a huge amount of
buffering. The solution also has an effect on the jitter/latency for the pw
connections and hence exclude it from certain use cases.

Cheers,
Wim

-----Original Message-----

Lucy

I disagree that the problem is the tail end resequencing - this is actually
the easiest part.
The real problems are
1) characterizing and ensuring separation of the PW components
2) performing the packet distribution algorithm at ingress.

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 1:01 PM
To: Yaakov Stein; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

Regards,
Lucy

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 31 Jul 2008 23:18:52 +0300

Shahram

PDH VCAT (G.7043) is not implemented in any DSLAMs that I have ever seen.

G.998.1 is only applicable for older ATM-based DSL links,
not G.SHDSLbis, ADSL2 or VDSL2.

G.998.2 (EFM bonding AKA PME aggregation)
is ONLY applicable for the DSL case,
and ONLY for Ethernet payloads.
This leaves out the low speed optics,
ATM and TDM PWs, etc.
It also tends to be implemented in ADSL DSLAMs
(which are not the ones used here).

G.998.3 (time domain inverse mux)
is a reasonable solution, but once again ONLY for the DSL case,
only for DSLAMs that support it (SHDSLbis).

Each of the G.998.x mechanisms can SOMETIMES
work, but none provide a universal solution for the problem at hand.

Y(J)S

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Thursday, July 31, 2008 10:52 PM
To: Yaakov Stein; 'HENDERICKX Wim'; 'Lucy Yong'; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

For the access applications other available techniques can be used such as DSL-bonding or even PDH-VCAT.
In that sense why is the PW bonding required?

Thanks,
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: July-30-08 2:32 PM
To: HENDERICKX Wim; Lucy Yong; pwe3
Subject: Re: [PWE3] PW bonding draft

Indeed,

The approach I proposed is mostly for low BW access connections.
In the draft I mention xDSL - i.e. up to about 5 Mbps, but also can work for low speed optics.

The limitation is partially the buffering (although it only has to compensate for DIFFERENTIAL delay which is not so bad) but more so the state and computational load.

Y(J)S

-----Original Message-----
From: HENDERICKX Wim [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 8:52 PM
To: Yaakov Stein; Lucy Yong; pwe3
Subject: RE: [PWE3] PW bonding draft

Yaakov,

Cheers,
Wim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yaakov Stein
Sent: woensdag 30 juli 2008 19:21
To: Lucy Yong; 'pwe3'
Subject: Re: [PWE3] PW bonding draft

Lucy

Y(J)S

-----Original Message-----
From: Lucy Yong [mailto:[email-masked]]
Sent: Wednesday, July 30, 2008 1:01 PM
To: Yaakov Stein; 'pwe3'
Subject: RE: [PWE3] PW bonding draft

Hi Yaakov,

Regards,
Lucy