Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

"So, Ning" <ning.so@verizonbusiness.com> Fri, 15 April 2011 14:45 UTC

Return-Path: <ning.so@verizonbusiness.com>
X-Original-To: ccamp@ietfc.amsl.com
Delivered-To: ccamp@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E0B82E0709 for <ccamp@ietfc.amsl.com>; Fri, 15 Apr 2011 07:45:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrZqAJZT-bRL for <ccamp@ietfc.amsl.com>; Fri, 15 Apr 2011 07:45:55 -0700 (PDT)
Received: from ashesmtp03.verizonbusiness.com (ashesmtp03.verizonbusiness.com [198.4.8.167]) by ietfc.amsl.com (Postfix) with ESMTP id E9C96E06C6 for <ccamp@ietf.org>; Fri, 15 Apr 2011 07:45:54 -0700 (PDT)
Received: from pdcismtp01.vzbi.com ([unknown] [166.40.77.67]) by firewall.verizonbusiness.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LJP002117OHHZ10@firewall.verizonbusiness.com> for ccamp@ietf.org; Fri, 15 Apr 2011 14:45:54 +0000 (GMT)
Received: from pdcismtp01.vzbi.com ([unknown] [127.0.0.1]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LJP00K5K7OIGU00@pdcismtp01.vzbi.com> for ccamp@ietf.org; Fri, 15 Apr 2011 14:45:54 +0000 (GMT)
Received: from ASHSRV140.mcilink.com ([unknown] [153.39.68.166]) by pdcismtp01.vzbi.com (Sun Java(tm) System Messaging Server 7u2-7.03 32bit (built May 29 2009)) with ESMTP id <0LJP00K6H7OHFQ00@pdcismtp01.vzbi.com> for ccamp@ietf.org; Fri, 15 Apr 2011 14:45:54 +0000 (GMT)
Received: from ASHEVS008.mcilink.com ([153.39.69.129]) by ASHSRV140.mcilink.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 14:45:53 +0000
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
Date: Fri, 15 Apr 2011 14:45:52 +0000
Message-id: <14584D6EE26B314187A4F68BA20606000729C942@ASHEVS008.mcilink.com>
In-reply-to: <4DA84B33.2000301@labn.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
Thread-index: Acv7cvofXpefnMiQQEukEomLn3Pp6AACMB4Q
References: <4D9599CB.9030503@labn.net> <6477E10CC7D76444A479B9AC31F262A9DDD135B0@ESESSCMS0365.eemea.ericsson.se> <4DA59A59.2030108@labn.net> <6477E10CC7D76444A479B9AC31F262A9DDD65CFF@ESESSCMS0365.eemea.ericsson.se> <4DA84B33.2000301@labn.net>
From: "So, Ning" <ning.so@verizonbusiness.com>
To: ccamp@ietf.org
X-OriginalArrivalTime: 15 Apr 2011 14:45:53.0931 (UTC) FILETIME=[D260F5B0:01CBFB7B]
Subject: Re: [CCAMP] poll on makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group <ccamp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ccamp>, <mailto:ccamp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ccamp>
List-Post: <mailto:ccamp@ietf.org>
List-Help: <mailto:ccamp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ccamp>, <mailto:ccamp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Apr 2011 14:45:59 -0000

Yes/support.

 
Best regards,
 
Ning So
Network Evolution Planning
Verizon, Inc.
(office) 972-729-7905
(Cell) 972-955-0914
 

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
Of Lou Berger
Sent: Friday, April 15, 2011 8:42 AM
To: Attila Takacs
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] poll on
makingdraft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document

Attila,
	So we have two points here:
1) WG procedure related

So this mail is in response to a poll. As your answer is (a).  I (as
chair) know how to interpret you position, i.e., "Yes/Support".

2) Point related to the contents of the draft.

As this is a technical point, and independent of the poll.  I'll start a
new thread on this in a separate mail.

Thanks,
Lou

On 4/14/2011 1:06 PM, Attila Takacs wrote:
> Hi Lou, all,
> It would be nice to clarify the scope of the proposed extension. 
> I would say (a) if that does not include commitment to work on the
"single sided mode". To my current understanding that operation mode is
not required for associated bidirectional LSPs. There is no discussion
in the document about which operation mode is really needed, if I'm not
mistaken similar comments were raised in Beijing, but this is not
addressed in the document. Hence my confusion.
> Thanks,
> Attila
>   
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Wednesday, April 13, 2011 2:43 PM
> To: Attila Takacs
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] poll on making 
> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
> 
> Attila,
> 	So I appreciate your comment, and would like to have this
discussion, but I think I need some clarification from the perspective
of the poll.
>  I'm unsure if you're saying:
> (a) support this document becoming a WG document and would like
>     discuss the point raised below in the context of a WG document or
> (b) do NOT support this document becoming a WG document until the
>     point you raise becomes a WG document
> 
> Can you clarify if you mean (a) or (b)?
> 
> Lou
> 
> On 4/12/2011 4:27 PM, Attila Takacs wrote:
>> Hi authors,
>>
>> You talk about two provisioning models: "single" and "double" sided
modes. 
>>
>> Double sided is clear, it uses independent signaling for the two
LSPs. 
>>
>> Single sided, if I understood correctly, somehow binds the two LSP
signaling phases together. I have some doubts that this model is needed.
It seems to complicate operation and it also begs the question why not
use bidirectional LSPs instead. 
>>
>> I think two independently signaled LSPs with the addition of the
proposed Association object would do the job addressing the associated
bidirectional LSP requirements, so that transit nodes are also aware of
the binding.
>>
>> Best regards,
>> Attila
>>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On 
>> Behalf Of Lou Berger
>> Sent: Friday, April 01, 2011 11:24 AM
>> To: ccamp@ietf.org
>> Subject: [CCAMP] poll on making
>> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document
>>
>> All,
>>
>> This is to start a two week poll on making
>> draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a ccamp working
group document. Please send mail to the list indicating "yes/support"
>> or "no/do not support".  If indicating no, please state your
technical reservations with the document.
>>
>> The poll ends Friday April 15.
>>
>> Much thanks,
>> Lou (and Deborah)
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
>>
>>
>>
>>
> 
> 
> 
> 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp