[CCAMP] Requirement for singled ended provisioning of associated bidirectional LSPs

Lou Berger <lberger@labn.net> Fri, 15 April 2011 13:50 UTC

Return-Path: <lberger@labn.net>
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 B3A2AE06C1 for <ccamp@ietfc.amsl.com>; Fri, 15 Apr 2011 06:50:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.086
X-Spam-Level:
X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 5rkqBQ54B2aW for <ccamp@ietfc.amsl.com>; Fri, 15 Apr 2011 06:50:46 -0700 (PDT)
Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by ietfc.amsl.com (Postfix) with SMTP id C00A5E069A for <ccamp@ietf.org>; Fri, 15 Apr 2011 06:50:36 -0700 (PDT)
Received: (qmail 28584 invoked by uid 0); 15 Apr 2011 13:50:35 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy2.bluehost.com with SMTP; 15 Apr 2011 13:50:35 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=RwhfzDbkbkthvUHPPEqcEhelyZ0duOPprpFmqsG4g6/cD2gJlcLVlvyFqUVj7eFNaPdhxJ7hf5uvzSXipfcyAAS2MOkPDikje31OC5G6aiVu0X6WrcS6fElMpFqPYszi;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from <lberger@labn.net>) id 1QAjPv-0006hT-1r; Fri, 15 Apr 2011 07:50:35 -0600
Message-ID: <4DA84D21.2040804@labn.net>
Date: Fri, 15 Apr 2011 09:50:25 -0400
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Attila Takacs <Attila.Takacs@ericsson.com>
References: <4D9599CB.9030503@labn.net> <6477E10CC7D76444A479B9AC31F262A9DDD135B0@ESESSCMS0365.eemea.ericsson.se> <4DA59A59.2030108@labn.net> <6477E10CC7D76444A479B9AC31F262A9DDD65CFF@ESESSCMS0365.eemea.ericsson.se> <4DA84B33.2000301@labn.net>
In-Reply-To: <4DA84B33.2000301@labn.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [CCAMP] Requirement for singled ended provisioning of associated bidirectional LSPs
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 13:50:50 -0000

[Subject: Was Re: [CCAMP] poll on making
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp-04 a WG document]

> 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.
>

As I (as WG member, not chair) understand it, you are questioning the
requirement for the "single sided mode".  I think this is a good
question.  As you pointed out, I believe I suggest that this question be
raised, by the authors, on the TP list.

RFC5645 seems to allow for independent provisioning of associated, but
it doesn't preclude the "single sided mode".  It also has requirements
11 and 12 which are certainly facilitated by "single sided mode".

I believe you also raise some valid issues with the current definition
of the processing rules. I'll defer my comments on this for now.

Lou

BTW This isn't the first time that "single sided mode" has been suggest.
I seem to remember discussing a proposal on this from Juha Heinanen at
the Adelaide IETF.  I also know of one vendor-specific implementation
that never made it to the field or the WG.

On 4/15/2011 9:42 AM, Lou Berger wrote:
> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>>