Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

From: Loa Andersson <[email-masked]>
Date: Tue, 11 May 2010 15:41:09 +0200

All,

this is start a two week poll on making

http://www.ietf.org/internet-drafts/draft-asm-mpls-tp-bfd-cc-cv-04.txt

an mpls working group document.

To respond to the poll please send a mail to the mpls-tp
mailing list indicating "yes/support" or "no/do not support".

Reviews, comments on the draft, or motivation for support
or non-support should be sent to the same mailing list, but
with another subject.

The poll ends eob May 25th.

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13

---

From: Elisa Bellagamba <[email-masked]>
Date: Tue, 11 May 2010 15:51:36 +0200

Yes/Support

Ciao,
Elisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: den 11 maj 2010 15:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

-- 

Loa Andersson                         email: [email-masked]
Sr Strategy and Standards Manager            [email-masked]
Ericsson Inc                          phone: +46 10 717 52 13
                                              +46 767 72 92 13
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

---

From: venkatesan mahalingam <[email-masked]>
Date: Tue, 11 May 2010 19:28:19 +0530

Yes/Support.

Regards,
Venkat.
On Tue, May 11, 2010 at 7:21 PM, Elisa Bellagamba <
[email-masked]> wrote:

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

-- 
Best Regards,
Venkatesan Mahalingam.

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Tue, 11 May 2010 17:57:15 +0200

Yes/support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Loa Andersson
Sent: Tuesday, May 11, 2010 4:41 PM
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad
hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls
working group document

All,

/Loa

--

---

From: Autumn Liu <[email-masked]>
Date: Tue, 11 May 2010 12:05:06 -0400

yes/support

Cheers,
Autumn

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, May 11, 2010 6:41 AM
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

To respond to the poll please send a mail to the mpls-tp mailing list indicating "yes/support" or "no/do not support".

Reviews, comments on the draft, or motivation for support or non-support should be sent to the same mailing list, but with another subject.

/Loa

-- 

                                              +46 767 72 92 13 _______________________________________________

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 11 May 2010 09:17:08 -0700

yes/support

Regards,
Greg

---

From: Nitin Bahadur <[email-masked]>
Date: Tue, 11 May 2010 11:17:58 -0700

Support.

Thanks
Nitin  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv 
> an mpls working group document
> 
> All,
> 
> Reviews, comments on the draft, or motivation for support or 
> non-support should be sent to the same mailing list, but with 
> another subject.
> 
>                                               +46 767 72 92 
> 13 _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: John E Drake <[email-masked]>
Date: Tue, 11 May 2010 12:41:07 -0700

Yes

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Loa Andersson
> Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls
> working group document
> 
> All,
>

---

From: Attila Takacs <[email-masked]>
Date: Wed, 12 May 2010 12:48:48 +0200

Support.
Attila 

> Sent: Tuesday, May 11, 2010 3:41 PM

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 12 May 2010 23:44:45 +0200

no/do not support

Regards, Huub.

=================

---

From: D'Alessandro Alessandro Gerardo <[email-masked]>
Date: Thu, 13 May 2010 16:31:23 +0200

no/do not support

------------------------------------------------------------------
Telecom Italia
Alessandro D'Alessandro
Transport & OPB Innovation
Via Reiss Romoli, 274 - 10148 Torino
phone:  +39 011 228 5887
mobile: +39 335 766 9607
fax: +39 06 418 639 07

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: martedì 11 maggio 2010 15.41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 May 2010 10:57:48 -0400

yes/support

---

From: Rui Costa <[email-masked]>
Date: Thu, 13 May 2010 19:10:45 +0100

no/do not support	

Kind Regards,	
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: terça-feira, 11 de Maio de 2010 14:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 13 May 2010 13:53:58 -0500

Yes, support. 

Thanks

Regards... Zafar

---

From: Sachin Kalra <[email-masked]>
Date: Thu, 13 May 2010 15:58:51 -0400

Support

- SK

===========================================================
Sachin Kalra
Senior Software Engineer II
http://www.linkedin.com/in/skalra

OPNET Technologies, Inc. (Nasdaq: OPNT)
http://www.opnet.com

===========================================================
Register for OPNET's Online Technology Workshops
http://www.opnet.com/TechWorkshops/
===========================================================

---

From: <[email-masked]>
Date: Thu, 13 May 2010 22:40:50 +0100

I also do not support this draft.

regards, neil 

> [mailto:[email-masked]] On Behalf Of Rui Costa
> Sent: 13 May 2010 19:11
> To: Loa Andersson; [email-masked]; CCAMP WG; [email-masked]; 
> [email-masked]; MPLS-TP ad hoc team
> Subject: Re: [mpls-tp] poll on making 
> draft-asm-mpls-tp-bfd-cc-cv an mpls working group document
> 
> no/do not support	
> 
> Kind Regards,	
> Rui
>

---

From: Zhang Haiyan <[email-masked]>
Date: Fri, 14 May 2010 11:41:54 +0800

no/do not support

B.R.
Haiyan

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 14 May 2010 08:01:12 -0400

+1

---

From: [email-masked]
Date: Fri, 14 May 2010 10:50:12 -0400

No/do not support

Malcolm

Loa Andersson <[email-masked]> 
Sent by: [email-masked]
11/05/2010 09:41 AM

To
"[email-masked]" <[email-masked]>, CCAMP WG <[email-masked]>, 
[email-masked], [email-masked], MPLS-TP ad hoc team 
<[email-masked]>
cc

Subject
[mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group 
document

All,

/Loa

--

---

From: David Sinicrope <[email-masked]>
Date: Fri, 14 May 2010 10:58:44 -0400

yes/support

On 5/11/10 9:41 AM, "Loa Andersson" <[email-masked]> wrote:

All,

/Loa

--

---

From: Robert Rennison <[email-masked]>
Date: Fri, 14 May 2010 15:00:25 -0400

Yes, support

Rob Rennison

---

From: "t.petch" <[email-masked]>
Date: Fri, 14 May 2010 20:44:17 +0200

No do not support; it is not ready for prime time yet.

Tom Petch

----- Original Message -----
From: "Rui Costa" <[email-masked]>
To: "Loa Andersson" <[email-masked]>; <[email-masked]>; "CCAMP WG"
<[email-masked]>; <[email-masked]>; <[email-masked]>; "MPLS-TP ad hoc team"
<[email-masked]>
Sent: Thursday, May 13, 2010 8:10 PM
Subject: Re: [CCAMP] [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an
mpls working group document

no/do not support

Kind Regards,
Rui

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Loa Andersson
Sent: terça-feira, 11 de Maio de 2010 14:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc
team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working
group document

All,

/Loa

--

---

From: Xueqin WEI <[email-masked]>
Date: Mon, 17 May 2010 13:21:20 +0800

No/do not support 

Sincerely Yours
Xueqin Wei
2010-05-1713:20:55
-------------------------------------------------------- 
Following is your email:
Subject:poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working groupdocument
Sent:2010-05-1121:56:40
From:Loa Andersson
To:[email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP adhoc team
CC to:

All,

---

From: Cavazzoni Carlo <[email-masked]>
Date: Mon, 17 May 2010 09:33:58 +0200

no/do not support

Regards,

Carlo

------------------------------------------------------------------
Telecom Italia
Carlo Cavazzoni
Transport & OPB Innovation
Via G. Reiss Romoli, 274 10148 Torino
+39 011 2285732
+39 335 7854045
Fax: +39 06 91861099
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: 11 May 2010 15:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: Di Giglio Andrea <[email-masked]>
Date: Mon, 17 May 2010 09:37:05 +0200

no/do not support

Regards,

Andrea

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Loa Andersson
Inviato: martedì 11 maggio 2010 15.41
A: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Oggetto: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: "Diego Caviglia" <[email-masked]>
Date: Mon, 17 May 2010 09:50:33 +0200

line

Yes/Support

DIEGO CAVIGLIA 
Strategic Product Manager 

Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762
[email-masked]
www.ericsson.com 

 Ericsson

This Communication is Confidential. We only send and receive email on
the basis of the term set out at www.ericsson.com/email_disclaimer 

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

All,

/Loa

--

---

From: "Daniele Ceccarelli" <[email-masked]>
Date: Mon, 17 May 2010 15:39:10 +0200

Yes/support

Cheers
Daniele 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: martedì 11 maggio 2010 15.41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 17 May 2010 16:55:57 +0200

no/do not support

Maarten

----- Original Message -----
From: "Loa Andersson" <[email-masked]>
To: <[email-masked]>; "CCAMP WG" <[email-masked]>; <[email-masked]>;
<[email-masked]>; "MPLS-TP ad hoc team" <[email-masked]>
Sent: Tuesday, May 11, 2010 9:41 PM
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls
working group document

---

From: "Siva Sivabalan (msiva)" <[email-masked]>
Date: Mon, 17 May 2010 11:53:02 -0500

Yes, support.

Thanks,
Siva 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Rennison
Sent: May 14, 2010 3:00 PM
To: Loa Andersson; [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: Re: [CCAMP] [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cvan mpls working group document

Yes, support

Rob Rennison

> > To respond to the poll please send a mail to the mpls-tp mailing 
> > list indicating "yes/support" or "no/do not support".
> >

---

From: Sami Boutros <[email-masked]>
Date: Mon, 17 May 2010 10:26:44 -0700

Yes/support

Sami

> > From: Loa Andersson <[email-masked]>
> > Date: Tue, 11 May 2010 15:41:09 +0200
> > To: "[email-masked]" <[email-masked]>, CCAMP WG <[email-masked]>,
> > <[email-masked]>, <[email-masked]>, MPLS-TP ad hoc team
> > Subject: [mpls] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working
> > group document
> >
> > All,
> >

---

From: Yang Yang <[email-masked]>
Date: Mon, 17 May 2010 22:52:26 +0200

No / Do not Support.

Yang

---

From: Thomas Walsh <[email-masked]>
Date: Mon, 17 May 2010 16:34:25 -0400

Yes/support

Tom Walsh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, May 11, 2010 6:41 AM
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: LONG Hao <[email-masked]>
Date: Tue, 18 May 2010 10:29:49 +0800

no/do not support

Regards, LONG Hao

---

From: Pankil Shah <[email-masked]>
Date: Mon, 17 May 2010 22:48:39 -0400

Yes/support.

Pankil

---

From: Joaquim Serra <[email-masked]>
Date: Tue, 18 May 2010 14:39:43 +0100

no/do not support	

Kind Regards,	
Joaquim Serra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: terça-feira, 11 de Maio de 2010 14:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: steven Wei <[email-masked]>
Date: Tue, 18 May 2010 22:07:08 +0800

yes/support.

2010/5/11 Loa Andersson <[email-masked]>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 18 May 2010 11:03:14 -0500

Yes/support

eric

> Sent: Tuesday, May 11, 2010 9:41 AM

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 18 May 2010 13:42:04 -0400

yes/support

Regards,
Jeff

________________________________
To: Loa Andersson
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

Loa Andersson                         email: [email-masked]<mailto:[email-masked]>
Sr Strategy and Standards Manager            [email-masked]<mailto:[email-masked]>
Ericsson Inc                          phone: +46 10 717 52 13
                                            +46 767 72 92 13
_______________________________________________
mpls-tp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: András Kern <[email-masked]>
Date: Tue, 18 May 2010 19:58:29 +0200

Yes/support

/Andras

---

From: David Ward <[email-masked]>
Date: Tue, 18 May 2010 12:29:51 -0700

Loa -

The draft is a reasonable starting point to enable reuse of BFD for MPLS-TP CC/CV. The draft is not complete and has a number of open issues but, given attempts at reuse of existing technology was a goal of the MPLS-TP effort and the draft describes some simple refinements to BFD to meet the requirements; I support it's acceptance as a work item.

-DWard

---

From: David Allan I <[email-masked]>
Date: Tue, 18 May 2010 15:34:36 -0400

Hi Tom:

It would be useful if you outlined where you considered the draft to be deficient... We'd appreciate your help in getting to "ready for prime time"...

Thanks
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of t.petch
Sent: Friday, May 14, 2010 2:44 PM
To: Loa Andersson; [email-masked]
Subject: Re: [mpls-tp] [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Tom Petch

<snipped>

---

From: Eric Gray <[email-masked]>
Date: Tue, 18 May 2010 16:48:18 -0400

yes/support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, May 11, 2010 9:41 AM
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: <[email-masked]>
Date: Tue, 18 May 2010 22:23:30 +0100

Tom..my apologies for jumping-in, but to help Dave where I consider it
technically deficient (it also has bad text issues IMO):

-	A CV function needs to use the proper SA of its parent
connection....what is the proper source address of a MPLS-TP connection?
I found little to help me in George and Matthew's 'MPLS-TP identifiers'
draft...though it's a great survey of what a mess this topic is. 

Aside=> I am still no closer in understanding the difference (esp in
addressing) of (i) proper client/server LSP layering in MPLS-TP and (ii)
and sublayering in MPLS-TP...these are *very* different issues, eg wrt
the layer network access point addressing scope they draw from.

-	defects detection/handling OAM in co-ps mode layer networks
needs to be unidirectional and not request/response in nature....I think
BFD was fettled some time ago to try and emulate this requirement.

A couple of more minor points, perhaps outside the scope of this draft:
-	we should not bother with AIS/FDI in co-ps mode networks....from
an information perspective (wrt defect location) it is not necessary and
it is just something else to go wrong....don't repeat this mistake that
is in Y.1731 and some prior co-ps mode technologies. 
-	piggy-backing BDI in CV is OK when one has symmetry, ie p2p
case...but this does not work when one does not have symmetry, ie p2mp
case

One final (and rather important) general plea:
-	try and give some thought to tapping-off an end-end CV (or ad
hoc PM) flow at intermediate nodes *on the rare occasions one needs it*
instead of the truly ghastly idea of an a priori imposed TCM sublayering
structure on topology......and for goodness sake do not be hoodwinked by
appeals to E-NNIs in MPLS-TP (or indeed and non-TOS layer network, eg
Ethernet)...TCM and such non-TOS E-NNIs (and also many of the QoS
arguments) lie on a road of rich complexity for little (IMO negative)
real benefit for operators or their customers.

regards, Neil

> [mailto:[email-masked]] On Behalf Of David Allan I
> Sent: 18 May 2010 20:35
> To: t.petch; Loa Andersson; [email-masked]
> Subject: Re: [mpls-tp] [CCAMP] poll on making 
> draft-asm-mpls-tp-bfd-cc-cvan mpls working group document
> 
> Hi Tom:
> 
> It would be useful if you outlined where you considered the 
> draft to be deficient... We'd appreciate your help in getting 
> to "ready for prime time"...
> 
> Thanks
> D
> 
> [mailto:[email-masked]] On Behalf Of t.petch
> Subject: Re: [mpls-tp] [CCAMP] poll on making

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 18 May 2010 17:25:32 -0400

Loa,

While this draft may have open issues, it has the right foundation.

I support making this a WG doc.

Thanks

- Sri

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Subject: [mpls] poll on making draft-asm-mpls-tp-bfd-cc-cv an

---

From: Sriganesh Kini <[email-masked]>
Date: Tue, 18 May 2010 17:25:32 -0400

Loa,

Thanks

- Sri

---

From: <[email-masked]>
Date: Tue, 18 May 2010 22:55:35 +0100

Sri....on what basis do you make this claim, ie "has the right
foundation"?  Request/response OAM (like BFD was conceived as) is fine
for a cl-ps mode network like IP but not for a co-ps mode network (=>
wrong foundation)....here defect detection/handling needs to be
unidirectional and the CV function requires an absolute SA not some
locally generated ID (=> wrong foundation again).

regards, Neil 

> Behalf Of Sriganesh Kini
> Sent: 18 May 2010 22:26
> Subject: Re: [mpls] poll on making 
> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Loa Andersson
> > To: [email-masked]; CCAMP WG; [email-masked]; 
> [email-masked]; MPLS-TP 
> > ad hoc team
> > Subject: [mpls] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls 
> > working group document
> > 
> > All,
> > 
> mailing list 
> > indicating "yes/support" or "no/do not support".
> > 
> > non-support should be sent to the same mailing list, but 
> with another 
> > subject.
> >

---

From: [email-masked]
Date: Wed, 19 May 2010 00:32:56 +0200

Neil and all,

while I know that no one cares about reading instruction
frome wg chairs on how to repsond to polls and working
group last calls, I need to say.

Let mails where we are doing polls on making documents
working group documents be just that - responses to the
poll.

Discussions should be continued in mails where the subject
line has been changed.

This makes easier for working grou chairs to evaluate the
thread and come to conclusion whether we have a new working
group document or not.

/Loa

---

From: David Allan I <[email-masked]>
Date: Tue, 18 May 2010 20:49:29 -0400

Hi Neil:

you wrote

Tom..my apologies for jumping-in, but to help Dave where I consider it technically deficient (it also has bad text issues IMO):

Aside=> I am still no closer in understanding the difference (esp in
addressing) of (i) proper client/server LSP layering in MPLS-TP and (ii) and sublayering in MPLS-TP...these are *very* different issues, eg wrt the layer network access point addressing scope they draw from.

That is actually outside the scope of draft-asm, currently an ACH TLV is provided for to provide source identification, hence whatever is eventually decided and with luck actually does meet your  approval, will work with asm unmodified.

-       defects detection/handling OAM in co-ps mode layer networks
needs to be unidirectional and not request/response in nature....I think BFD was fettled some time ago to try and emulate this requirement.

It is only request response as far as the initial session establishment is concerned. Otherwise it is very straightforward CV> RDI< discipline. It is just it is accomplished via the session state field in the BFD PDU rather that having its' own explicit codepoints

A couple of more minor points, perhaps outside the scope of this draft:
-       we should not bother with AIS/FDI in co-ps mode networks....from
an information perspective (wrt defect location) it is not necessary and it is just something else to go wrong....don't repeat this mistake that is in Y.1731 and some prior co-ps mode technologies.

That again is out of scope of draft-asm itself.

-       piggy-backing BDI in CV is OK when one has symmetry, ie p2p
case...but this does not work when one does not have symmetry, ie p2mp case
IMO if p2mp was bi-directional RDI would be a function of rather limited utility. Currently it is out of scope of draft-asm.

One final (and rather important) general plea:
-       try and give some thought to tapping-off an end-end CV (or ad
hoc PM) flow at intermediate nodes *on the rare occasions one needs it* instead of the truly ghastly idea of an a priori imposed TCM sublayering structure on topology......and for goodness sake do not be hoodwinked by appeals to E-NNIs in MPLS-TP (or indeed and non-TOS layer network, eg Ethernet)...TCM and such non-TOS E-NNIs (and also many of the QoS
arguments) lie on a road of rich complexity for little (IMO negative) real benefit for operators or their customers.
Understood, and I have a lot of sympathy for your points in general, but other than the operation not being request response once the session was initialized, they seem to be broader issues and not necessarily within the scope of this particular draft.

best
D

> It would be useful if you outlined where you considered the draft to
> be deficient... We'd appreciate your help in getting to "ready for
> prime time"...
>
> Thanks
> D
>

---

From: <[email-masked]>
Date: Wed, 19 May 2010 07:37:48 +0100

Sorry Loa...you are right, I should have spotted that.  regards, Neil 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 18 May 2010 23:33
> To: Harrison,N,Neil,DKQ7 R
> Cc: [email-masked]; [email-masked]
> Subject: RE: [mpls] poll on making 
> frome wg chairs on how to repsond to polls and working group 
> last calls, I need to say.
> 
> working group documents be just that - responses to the poll.
> 
> >> Of Sriganesh Kini

---

From: <[email-masked]>
Date: Wed, 19 May 2010 08:16:07 +0100

Thanks Dave...appreciate your (always) well-reasoned arguments.  Some
further remarks, including an important point I missed earlier, in-line:
 
Note - changed subject line.

	From: David Allan I [mailto:[email-masked]] 
	Sent: 19 May 2010 01:49
	To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked];
[email-masked]
	Subject: RE: [mpls-tp] [CCAMP] poll on making
draft-asm-mpls-tp-bfd-cc-cvanmpls working group document

	Hi Neil:
	
	you wrote

	Tom..my apologies for jumping-in, but to help Dave where I
consider it technically deficient (it also has bad text issues IMO):
	
	-       A CV function needs to use the proper SA of its parent
	connection....what is the proper source address of a MPLS-TP
connection?
	I found little to help me in George and Matthew's 'MPLS-TP
identifiers'
	draft...though it's a great survey of what a mess this topic is.
	
	Aside=> I am still no closer in understanding the difference
(esp in
	addressing) of (i) proper client/server LSP layering in MPLS-TP
and (ii) and sublayering in MPLS-TP...these are *very* different issues,
eg wrt the layer network access point addressing scope they draw from.

	That is actually outside the scope of draft-asm, currently an
ACH TLV is provided for to provide source identification, hence whatever
is eventually decided and with luck actually does meet your  approval,
will work with asm unmodified. 
	NH=> The addressing issue is rather important IMO.  I cannot
agree that it is outside the scope of this document because the basic
argument here is that BFD can replace a correctly engineered CV
function....and in a correctly engineered CV function we require an
absolute SA of the parent connection it is active in (see Note below). 
	 
	MPLS never got its act together wrt addressing.....because at
t=0 it never saw itself as a layer network in its own right.  However,
things have changed now significantly....and largely through experience
that all 3 modes are different and there cannot be a common CP running
IP to optics.  MS PWs have also really rammed home this point. 
	 
	However, the addressing issue is still a mess IMO.  And even
though we should not be using sublayering in a transport network (nor do
we need PWs...these are simply facts, not points for debate) we have no
clarity on the point I made previously wrt the addressing of nested
sublayer LSPs and the addressing of proper client/server layer LSPs.
	 
	Note - Here is a key point I missed earlier...I should have also
made it in my response to Sri.  A co-ps mode connection is a
constraining construct for its child traffic units and OAM in both a
spatial and temporal sense.  This is not like a cl-ps network (where BFD
comes from)....traffic units and OAM cannot not exist outside a parent
connection (except under misconnectivity defects) in a co-ps mode
network.  Wrt to the temporal point, it is operationally crucial that
the defect detection OAM is activated/deactivated in sync with whatever
CP_signalling or MP_protocol sets-up/tears-down the parent connection.
So here we see yet another important departure from the the origins of
BFD as 'the right foundation'.
	
	-       defects detection/handling OAM in co-ps mode layer
networks
	needs to be unidirectional and not request/response in
nature....I think BFD was fettled some time ago to try and emulate this
requirement.
	 
	It is only request response as far as the initial session
establishment is concerned.  
	NH=> And this is wrong IMO Dave....see the point above on OAM
activation/deactivation.....BFD should not be 'its own CP/signalling OAM
act/deact protocol'.  Besides the cl-ps mode origins (where this
behaviour is correct) I guess we are creating our own config problems
here by having many options for BFD.  This is also a key reason why I
wanted a CV function to be dead simple/sparse......I am sure you should
have heard me say this before, but a critical requirement of the OAM in
a layer network is that it must be uber reliable, and reliability means
keeping things as a simple as possible.....which is also one reason (I
have many more) why I am very much against implementing shed-loads of a
priori configured TCM OAM sublayering.....just tap-off an end-2-end CV
(or PM) flow on the *rare* occasions one needs to.
	 
	 Otherwise it is very straightforward CV> RDI< discipline. It is
just it is accomplished via the session state field in the BFD PDU
rather that having its' own explicit codepoints

	A couple of more minor points, perhaps outside the scope of this
draft:
	-       we should not bother with AIS/FDI in co-ps mode
networks....from
	an information perspective (wrt defect location) it is not
necessary and it is just something else to go wrong....don't repeat this
mistake that is in Y.1731 and some prior co-ps mode technologies.
	 
	That again is out of scope of draft-asm itself. 
	NH=> OK.....but can folks please think carefully about this
point....there are scalability and reliability issues here (besides the
technical fact that it is not necessary anyway) 
	 
	-       piggy-backing BDI in CV is OK when one has symmetry, ie
p2p
	case...but this does not work when one does not have symmetry,
ie p2mp case
	
	IMO if p2mp was bi-directional RDI would be a function of rather
limited utility. Currently it is out of scope of draft-asm.

	One final (and rather important) general plea:
	-       try and give some thought to tapping-off an end-end CV
(or ad
	hoc PM) flow at intermediate nodes *on the rare occasions one
needs it* instead of the truly ghastly idea of an a priori imposed TCM
sublayering structure on topology......and for goodness sake do not be
hoodwinked by appeals to E-NNIs in MPLS-TP (or indeed and non-TOS layer
network, eg Ethernet)...TCM and such non-TOS E-NNIs (and also many of
the QoS
	arguments) lie on a road of rich complexity for little (IMO
negative) real benefit for operators or their customers.
	
	Understood, and I have a lot of sympathy for your points in
general, but other than the operation not being request response once
the session was initialized, they seem to be broader issues and not
necessarily within the scope of this particular draft. 
	NH=> Yes Dave, they are broader issues.  Quite often if one only
looks at the detail of a small part of the picture once misses a far
more important and dependent set of points....so its is often important
to place specific/localised detail in the context of a larger
picture...else mistakes continue to be made. This is why I have made
these points here...and I hope folks realise I am trying to be very
even-handed and technically accurate in my observations.... I am not
just 'having a go' at BFD here.
	 
	regards, Neil
	 
	best
	D

	> [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of David Allan I
	> It would be useful if you outlined where you considered the
draft to
	> [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of t.petch
	> No do not support; it is not ready for prime time yet.
<https://www.ietf.org/mailman/listinfo/mpls-tp>

---

From: "BRUNGARD, DEBORAH A (ATTLABS)" <[email-masked]>
Date: Wed, 19 May 2010 11:07:43 -0400

Yes/support-

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

All,

/Loa

--

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Wed, 19 May 2010 18:15:58 +0200

While draft-asm provides some useful basis, the following capabilities/technical concerns need to be addressed before progressing this draft to WG status:

- running BFD at a fixed operator's configurable rate.
- Unidirectional path support
- One mechanism that can work independently from the protection switching configuration

Italo

> Sent: martedì 11 maggio 2010 21.41

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 19 May 2010 11:19:16 -0500

+1 /Agree with Italo

Regards,
Kam

> Of BUSI, ITALO (ITALO)
> Sent: Wednesday, May 19, 2010 12:16 PM
> Cc: MPLS-TP ad hoc team
> While draft-asm provides some useful basis, the following
> capabilities/technical concerns need to be addressed before progressing
> this draft to WG status:
>

---

From: Dieter Beller <[email-masked]>
Date: Wed, 19 May 2010 18:19:50 +0200

I fully concur.

Dieter

On 19.05.2010 18:15, BUSI, ITALO (ITALO) wrote:

Italo

-----Original Message-----
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked];
MPLS-TP ad hoc team

All,

/Loa

--

Loa Andersson email:
[email-masked]

--

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 19 May 2010 18:26:17 +0200

+1 /Agree with Italo

Regards

Sergio

Sergio Belotti

System Architecture
Optics Division-Terrestrial Optics Unit
ALCATEL-LUCENT

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di BUSI, ITALO (ITALO)
Inviato: mercoledì 19 maggio 2010 18.16
A: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Oggetto: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: David Sinicrope <[email-masked]>
Date: Wed, 19 May 2010 12:40:04 -0400

Italo,
Is there any reason these issues need to be addressed before adopting the document as a WG draft?   Issues such as these frequently are addressed after a document has been accepted as a WG draft.  My understanding is that adopting the document as a WG draft simply indicates that the WG would like to pursue the approach and work the remaining issues.

-Dave

On 5/19/10 12:15 PM, "BUSI, ITALO (ITALO)" <[email-masked]> wrote:

Italo

---

From: <[email-masked]>
Date: Wed, 19 May 2010 17:52:40 +0100

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: Thomas Walsh <[email-masked]>
Date: Wed, 19 May 2010 12:59:28 -0400

I believe David is correct and the decision to adopt as a WG draft would indicate a group desire to work on the remaining issues.  

- Tom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Sinicrope
Sent: Wednesday, May 19, 2010 9:40 AM
To: BUSI, ITALO (ITALO); Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo,

-Dave

Italo

---

From: <[email-masked]>
Date: Wed, 19 May 2010 19:09:00 +0200

I concur with Italo, as those are major issues and need to be adressed before a WG adoption.

Regards,
Manuel 

> [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
> Sent: Wednesday, May 19, 2010 6:16 PM
> capabilities/technical concerns need to be addressed before 
> progressing this draft to WG status:
>

---

From: John E Drake <[email-masked]>
Date: Wed, 19 May 2010 10:45:31 -0700

Italo,

Comments inline.

Thanks,

John

> Sent: Wednesday, May 19, 2010 9:16 AM

JD:  Would you please provide a pointer to the text that you think precludes this?

> - Unidirectional path support

JD:  This is a special case of p2mp and we are waiting for the p2mp BFD I-D to be re-issued.  Whether CC/CV/RDI for p2mp is to be included in this I-D or another is an open question.

> - One mechanism that can work independently from the protection switching

JD:  I think this is a misunderstanding.  The I-D defines CC/CV/RDI for a p2p bidirectional LSP.  There are two modes, fate sharing and non-fate sharing.  The former is used by both LSPs being used to provide a 1:1 *service*.  The latter is used by both LSPs being used to provide a 1+1 *service*.

But regardless of the use to which a given LSP is being used, CC/CV/RDI is provided using one of the two modes.

---

From: "BUSI, ITALO (ITALO)" <[email-masked]>
Date: Wed, 19 May 2010 19:57:47 +0200

no/do not support

PS - Motivations for non-support discussed in previous email

---

From: John E Drake <[email-masked]>
Date: Wed, 19 May 2010 10:51:44 -0700

And in case it wasn't clear from my note, I think this is a red herring rather than a blue whale.

> Of John E Drake
> Sent: Wednesday, May 19, 2010 10:46 AM
> > Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an
> mpls
> > working group document
> >
> JD:  This is a special case of p2mp and we are waiting for the p2mp BFD I-
> D to be re-issued.  Whether CC/CV/RDI for p2mp is to be included in this
> I-D or another is an open question.
> 
> > - One mechanism that can work independently from the protection
> switching
> > configuration
> 
> JD:  I think this is a misunderstanding.  The I-D defines CC/CV/RDI for a
> p2p bidirectional LSP.  There are two modes, fate sharing and non-fate
> sharing.  The former is used by both LSPs being used to provide a 1:1
> *service*.  The latter is used by both LSPs being used to provide a 1+1
> *service*.
>

---

From: "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 19 May 2010 13:01:11 -0500

no/do not support

Regards,
Kam

---

From: "Varma, Eve L (Eve)" <[email-masked]>
Date: Wed, 19 May 2010 13:02:43 -0500

no/do not support

Best regards,
Eve

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 19 May 2010 20:04:57 +0200

Adopting a document as a WG document does not indicate that it is ready for publication. It just indicates that the WG is interested to work on this topic. 
It is natural that in such a state of the document, there are many areas on which is needed. Still this should not prevent us adopting it as a WG document. We can continue resolving the open issues and work on the document as a WG document. 
As indicated before, I support the adoption of the document as a WG document and welcome everyone to contribute to the content in order to make it a good document. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext [email-masked]
Sent: Wednesday, May 19, 2010 7:53 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: <[email-masked]>
Date: Wed, 19 May 2010 20:12:51 +0100

Thread title changed:

I find this 'it's good enough for now' argument has little to commend it.  It seems to me a device that is sometimes used to try and deflect/ignore valid technical concerns.  

I have seen no good answers to my larger concerns about where MPLS-TP is now heading.  As I noted in closing in my last response to Dave (Allan), OAM is only one DP facet of a bigger co-ps mode technology picture...and it's the bigger picture that I find sorely wanting.  Come on folks....only a madman could keep a straight-face and tell me sublayering and PWs are valid things to have in a correctly engineered co-ps transport network.  And yet here they are.....these are far more serious observations of technical failure than the OAM.

But coming back to the OAM angle.....BFD comes from a cl-ps root-stock where request/response OAM is actually a correct behaviour....noting in particular here that a cl-ps mode network technology always uses absolute addressing at the traffic unit level.  co-ps mode network are not like this....we can make them fairly close to this and in fact ideal, by adopting a cl-ps traffic unit for their basis and this means we don't need any OAM at all to avoid misconnectivity - how cool is that! ...PBB-TE was such an approach but for some reason this has not found favour with some ;-). 

So, having moved away from the ideal co-ps solution and taken the addressing short-cuts in traffic units that the label-swapping version of the co-ps mode allows (ie DA -> proxy that is only link unique and swapped per link, SA -> missing altogether), then at least we should adopt OAM that befits such a mode, ie CV....not appeal back to one that has a cl-ps antecedent.

For me the key point is solving the addressing issue and having simple/sparse uber reliable unidirectional defect detection OAM.  If we do this right then all BFD is does is replicate a properly designed CV function.....so, if we got here (and we are not as yet), all we have is a NIH scenario.  I can live with that....but as noted BFD had better use a proper SA of MPLS-TPs and not some arbitrary/locally-generated 'discriminator' (sic) that belies its cl-ps mode origins.   But right now I have no idea what a proper MPLS-TP connection SA address looks like....and in particular I have no idea how to differentiate such a beast in MPLS-TP wrt:
-	the retained/flawed sublayering case of nested LSPs
-	the (much more important IMO) client/server layering case of nested LSPs

This needs properly resolving before we should even have any further discussion on this topic IMO (this is supposed to be a *transport network* remember)....however, I am not at all confident we have the stomach to face this, let alone correctly fix it.

regards, Neil

> [mailto:[email-masked]] On Behalf Of Sprecher, 
> Nurit (NSN - IL/Hod HaSharon)
> Sent: 19 May 2010 19:05
> To: Pisica,M,Mircea,DMF R; [email-masked]; 
> [email-masked]; [email-masked]
> draft-asm-mpls-tp-bfd-cc-cv anmplsworking group document
> 
> Adopting a document as a WG document does not indicate that 
> it is ready for publication. It just indicates that the WG is 
> interested to work on this topic. 
> It is natural that in such a state of the document, there are 
> many areas on which is needed. Still this should not prevent 
> us adopting it as a WG document. We can continue resolving 
> the open issues and work on the document as a WG document. 
> As indicated before, I support the adoption of the document 
> as a WG document and welcome everyone to contribute to the 
> content in order to make it a good document. 
> Best regards,
> Nurit
> 
> [mailto:[email-masked]] On Behalf Of ext 
> [email-masked]
> draft-asm-mpls-tp-bfd-cc-cv an mplsworking group document
> 
> Valid input.
> I agree with it.
> 
> Mircea
>

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 19 May 2010 12:42:47 -0700

Dear Neil,
your concerns regarding inclusiveness of MPLS-TP are valid. I just would
note that as lately MPLS-TP is referred as "packet network", not "packet
transport network". Last paragraph of Section 3.2 of Framework of MPLS-TP in
Transport Networks notes that subset of MPLS-TP is applicable to transport
networks as defined by ITU-T. Those who would use MPLS-TP to build packet
transport with MPLS-TP will have to carefully select proper tool set.

Regards,
Greg

On Wed, May 19, 2010 at 12:12 PM, <[email-masked]> wrote:

> Thread title changed:
>
> I find this 'it's good enough for now' argument has little to commend it.
>  It seems to me a device that is sometimes used to try and deflect/ignore
> valid technical concerns.
>
> I have seen no good answers to my larger concerns about where MPLS-TP is
> now heading.  As I noted in closing in my last response to Dave (Allan), OAM
> is only one DP facet of a bigger co-ps mode technology picture...and it's
> the bigger picture that I find sorely wanting.  Come on folks....only a
> madman could keep a straight-face and tell me sublayering and PWs are valid
> things to have in a correctly engineered co-ps transport network.  And yet
> here they are.....these are far more serious observations of technical
> failure than the OAM.
>
> But coming back to the OAM angle.....BFD comes from a cl-ps root-stock
> where request/response OAM is actually a correct behaviour....noting in
> particular here that a cl-ps mode network technology always uses absolute
> addressing at the traffic unit level.  co-ps mode network are not like
> this....we can make them fairly close to this and in fact ideal, by adopting
> a cl-ps traffic unit for their basis and this means we don't need any OAM at
> all to avoid misconnectivity - how cool is that! ...PBB-TE was such an
> approach but for some reason this has not found favour with some ;-).
>
> So, having moved away from the ideal co-ps solution and taken the
> addressing short-cuts in traffic units that the label-swapping version of
> the co-ps mode allows (ie DA -> proxy that is only link unique and swapped
> per link, SA -> missing altogether), then at least we should adopt OAM that
> befits such a mode, ie CV....not appeal back to one that has a cl-ps
> antecedent.
>
> For me the key point is solving the addressing issue and having
> simple/sparse uber reliable unidirectional defect detection OAM.  If we do
> this right then all BFD is does is replicate a properly designed CV
> function.....so, if we got here (and we are not as yet), all we have is a
> NIH scenario.  I can live with that....but as noted BFD had better use a
> proper SA of MPLS-TPs and not some arbitrary/locally-generated
> 'discriminator' (sic) that belies its cl-ps mode origins.   But right now I
> have no idea what a proper MPLS-TP connection SA address looks like....and
> in particular I have no idea how to differentiate such a beast in MPLS-TP
> wrt:
> This needs properly resolving before we should even have any further
> discussion on this topic IMO (this is supposed to be a *transport network*
> remember)....however, I am not at all confident we have the stomach to face
> this, let alone correctly fix it.
>
> regards, Neil
>

---

From: George Swallow <[email-masked]>
Date: Wed, 19 May 2010 16:26:48 -0400

Italo -

On 5/19/10 12:15 PM, "BUSI, ITALO (ITALO)" <[email-masked]>
wrote:

> capabilities/technical concerns need to be addressed before progressing this
> draft to WG status:
> 

This will certainly be supported.  Perhaps we need to make that clearer.

> - Unidirectional path support

I consider unidirectional paths to be a special case of P2MP.  That will be
addressed later.

> - One mechanism that can work independently from the protection switching

Why is this a requirement?

...George

---

From: Ross Callon <[email-masked]>
Date: Wed, 19 May 2010 17:28:04 -0400

Yes / I support this becoming a working group document. 

Most of the comments that I have seen raised are things to be discussed during the normal progression of a working group document (ie, would be valid concerns if this were at working group last call, but IMHO don't make sense as a reason to slow down acceptance of this as a WG document). 

Thanks, Ross 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: 11 May 2010 09:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: Dieter Beller <[email-masked]>
Date: Wed, 19 May 2010 23:56:12 +0200

no/do not support

Dieter

On 11.05.2010 15:41, Loa Andersson wrote:

All,

/Loa

--

---

From: David Allan I <[email-masked]>
Date: Wed, 19 May 2010 18:06:09 -0400

HI Neil:

In some ways it is simply the process. As an individual draft we can only hope to attract enough comments to convert it into a decent document, but whether that actually happens is a bit hit and miss. 

As a WG document it becomes a bit more of a lightning rod for critique and improvement as the WG has formally agreed to participate in the development of the document with an RFC being the eventual target.

There are aspects of this poll that are confusing a last call or consent with simply starting somthing analogous to a "G.bfd", even no number as of yet assigned....

BR
D

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 19, 2010 3:13 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [mpls-tp] Discussion of whether to adopt draft-asm-mpls-tp-bfd-cc-cv as a mplsworking group document

Thread title changed:

regards, Neil

> [mailto:[email-masked]] On Behalf Of Sprecher, Nurit (NSN - 
> IL/Hod HaSharon)
> Sent: 19 May 2010 19:05
> To: Pisica,M,Mircea,DMF R; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv 
> anmplsworking group document
> 
> Adopting a document as a WG document does not indicate that it is 
> ready for publication. It just indicates that the WG is interested to 
> work on this topic.
> It is natural that in such a state of the document, there are many 
> areas on which is needed. Still this should not prevent us adopting it 
> as a WG document. We can continue resolving the open issues and work 
> on the document as a WG document.
> As indicated before, I support the adoption of the document as a WG 
> document and welcome everyone to contribute to the content in order to 
> make it a good document.
> Best regards,
> Nurit
> 
> mplsworking group document
> 
> Valid input.
> I agree with it.
> 
> Mircea
> 
> switching configuration

---

From: Thomas Walsh <[email-masked]>
Date: Wed, 19 May 2010 18:43:25 -0400

This is starting to look an awful lot like a majority vote as opposed to helping the chairs gauge whether there is sufficient interest in the group to work on these issues. Is this following the IETF process or is this somehow different for the MPLS-TP project?

Isn't the poll intended to gauge whether there is enough interest to work on addressing the issues as a group?  Can the chairs clarify?

Tom

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Wednesday, May 19, 2010 2:56 PM
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

no/do not support

Dieter

All,

with another subject.

/Loa

---

From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Thu, 20 May 2010 07:52:56 +0200

Yes/Support

BR,
Yaacov Weingarten
Nokia Siemens Networks
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Loa Andersson
Sent: Tuesday, May 11, 2010 16:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad
hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls
working group document

All,

/Loa

--

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 20 May 2010 08:01:24 +0200

+1
I agree with Italo

============================================
Pietro Vittorio Grandi
Terrestrial Optics Unit -  System Architecture
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: [email-masked]
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: mercoledì 19 maggio 2010 18.16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 20 May 2010 08:06:51 +0200

no/do not support

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lam, Hing-Kam (Kam)
Sent: mercoledì 19 maggio 2010 20.01
To: Loa Andersson; [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: Re: [mpls-tp] [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

no/do not support

Regards,
Kam

---

From: "Igor Umansky" <[email-masked]>
Date: Thu, 20 May 2010 10:16:51 +0300

no/do not support

Igor.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dieter Beller
Sent: Thursday, May 20, 2010 0:56
To: Loa Andersson
Cc: MPLS-TP ad hoc team; [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

no/do not support

Dieter

All,

 

 
 
/Loa

--

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 20 May 2010 09:31:03 +0200

Greg,
 
Thank you for reminding us to the scope of the MPLS-TP work being "packet
network' and that 'packet transport network' will use a subset applicable to
transport networks. 

In Figure 1 of the latest version (-12) of the framework draft it is
illustrated that the pre-RFC5654 MPLS is complemented with 
- "Additional Transport Functions" and with 
- "Post-RFC5654 non-Transport Functions".

OAM for **non-transport networks** would be an element in this latter
"Post-RFC5654 non-Transport Functions" part of MPLS, while OAM for
**transport networks** would be an element in the former "Additional
Transport Functions" part of MPLS and be part of MPLS-TP.

Without doubt, draft-bhh-mpls-tp-oam-y1731 is addressing "Additional
Transport Functions".

My question is if BFD/LSP Ping extensions are addressing "Post-RFC5654
non-Transport Functions"? 

Regards,
Maarten

  |<============================== MPLS ==============================>|
                                                     { Post-RFC5654    }
                                                     { non-Transport   }
                                                     {   Functions     }
  |<========== Pre-RFC5654 MPLS ===========>|
  {      ECMP       }
  { LDP/non-TE LSPs }
  {     IP fwd      }

                    |<======== MPLS-TP ============>|
                                       { Additional }
                                       {  Transport }
                                       {  Functions }

                        Figure 1: Scope of MPLS-TP

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Greg Mirsky
Sent: woensdag 19 mei 2010 21:43
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Discussion of whether to
adoptdraft-asm-mpls-tp-bfd-cc-cv as a mplsworking group document

Dear Neil,

Regards,
Greg

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 20 May 2010 10:16:01 +0200

no/do not support

Sergio Belotti

System Architecture

+39 039 6863033
+39 039 6863590

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Loa Andersson
Inviato: martedì 11 maggio 2010 15.41
A: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Oggetto: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: "ADDEO, CHRISTIAN (CHRISTIAN)" <[email-masked]>
Date: Thu, 20 May 2010 10:51:13 +0200

No/do not support.

Christian

All,

with another subject.

/Loa

---

From: Yuji Tochio <[email-masked]>
Date: Thu, 20 May 2010 18:38:39 +0900

No/do not support

Regards,
Yuji

---

From: "t.petch" <[email-masked]>
Date: Thu, 20 May 2010 14:25:25 +0200

----- Original Message -----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Sent: Wednesday, May 19, 2010 8:04 PM

Adopting a document as a WG document does not indicate that it is ready for
publication. It just indicates that the WG is interested to work on this topic.
It is natural that in such a state of the document, there are many areas on
which is needed. Still this should not prevent us adopting it as a WG document.
We can continue resolving the open issues and work on the document as a WG
document.

<tp>
Normally I would agree with you, but the processes of this list give me pause
and make me cautious about accepting I-Ds that still need substantial work.

When I read every e-mail posted to a list (not always straightaway:-), I expect
to know what changes there will be between one version of an I-D and the next,
even if the document itself does not contain a summary of changes nor does the
editor post an e-mail detailing the main changes.  Here, I get surprises, as,
for example, with
draft-ietf-mpls-tp-framework-11
an I-D I regard as particularly important.  [Perhaps the surprises arise
from liaisons, in the form of the marked up versions of the I-Ds in pdf format,
which never make it to the list in a more explicit form.]

And when topics are aired on the list, I may not know what the rough consensus
is; often, it does not seem to get stated and, perhaps as a result, some topics
keep resurfacing.  I don't expect always to agree with the rough consensus but
do expect to see it declared more often than it does, and for it, mostly, to be
what I would expect it to be, from reading the postings to the list (I await the
chairs' declaration on this one with interest).

So I can no longer rely on the process in the way I would wish and that makes me
cautious about adopting an I-D that needs significant work, as I think that this
one does.  Others have articulated better than I the technical issues; I would
only add that there are also a significant number of holes in the I-D (TBD, for
future study, To be added.....) that I think need filling first.

Looking back, I was much happier with the original draft-boutros-mpls-tp...; we
seem to have regressed since then.

Tom Petch
</tp>

As indicated before, I support the adoption of the document as a WG document and
welcome everyone to contribute to the content in order to make it a good
document.
Best regards,
Nurit

-----Original Message-----
ext [email-masked]
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mplsworking
group document

Valid input.
I agree with it.

Mircea

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
BUSI, ITALO (ITALO)
Sent: 19 May 2010 18:16
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls
working group document

While draft-asm provides some useful basis, the following capabilities/technical
concerns need to be addressed before progressing this draft to WG status:

- running BFD at a fixed operator's configurable rate.
- Unidirectional path support
- One mechanism that can work independently from the protection switching
configuration

Italo

---

From: David Allan I <[email-masked]>
Date: Thu, 20 May 2010 11:23:36 -0400

HI Italo

A couple of comments...

1) I have to agree with John, there is nothing in the draft that precludes operating at a fixed rate. So do you mind clarifying your concern?

2) Yes we are awaiting the p2mp BFD draft. BFD is more than just MPLS-TP, so we are unable to unilaterally dictate a solution. In the meantime we can make that it is "in-scope" clear but "for further study" at the moment. 

3) I'm not quite sure what the motivation is. Could you clarify what you are looking for in requiring a single behavior independent of the resiliency mechanisms. IMO it is possible, but is not exactly frugal of resources, which is why things are as they currently are...

Your clarifications would be useful...

Thanks
Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of BUSI, ITALO (ITALO)
Sent: Wednesday, May 19, 2010 12:16 PM
To: Loa Andersson; [email-masked]
Cc: MPLS-TP ad hoc team
Subject: Re: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

Italo

> To respond to the poll please send a mail to the mpls-tp mailing list 
> non-support should be sent to the same mailing list, but with another 
> subject.
>

---

From: Igor Bryskin <[email-masked]>
Date: Thu, 20 May 2010 15:17:39 -0400

Yes, I support.

Cheers,
Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Tuesday, May 11, 2010 9:41 AM
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [CCAMP] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--

---

From: João Vitor Mateiro <[email-masked]>
Date: Fri, 21 May 2010 10:31:24 +0100

no/do not support	

Kind Regards,	

João Mateiro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: terça-feira, 11 de Maio de 2010 14:41
To: [email-masked]; CCAMP WG; [email-masked]; [email-masked]; MPLS-TP ad hoc team
Subject: [mpls-tp] poll on making draft-asm-mpls-tp-bfd-cc-cv an mpls working group document

All,

/Loa

--