Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Lou Berger <lberger@labn.net> Fri, 28 February 2014 17:20 UTC

Return-Path: <lberger@labn.net>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2ACA1A01CC for <ccamp@ietfa.amsl.com>; Fri, 28 Feb 2014 09:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.667
X-Spam-Level:
X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuciWuE6-v9b for <ccamp@ietfa.amsl.com>; Fri, 28 Feb 2014 09:20:06 -0800 (PST)
Received: from oproxy6-pub.mail.unifiedlayer.com (oproxy6-pub.mail.unifiedlayer.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id E91621A01EF for <ccamp@ietf.org>; Fri, 28 Feb 2014 09:20:05 -0800 (PST)
Received: (qmail 21535 invoked by uid 0); 28 Feb 2014 17:19:55 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.mail.unifiedlayer.com with SMTP; 28 Feb 2014 17:19:55 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Nv8t7rWX9udXv1k96CsGQyIHAswKxcg74blpoJ3FUKY=; b=C6LL0eVCvh9w4rDpEOPoEGfnd9H13ExmhDZXhrfR1Y2ObkbdEQ9LgeNt/njePT0weTHSS1rXN6Eil/GZt3Jg3/HfkEUfdsLtou78g5LoNTgQhO2bRExuedSTBMozFm3T;
Received: from box313.bluehost.com ([69.89.31.113]:49860 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from <lberger@labn.net>) id 1WJR6J-0003iT-2M; Fri, 28 Feb 2014 10:19:55 -0700
Message-ID: <5310C538.6050404@labn.net>
Date: Fri, 28 Feb 2014 12:19:52 -0500
From: Lou Berger <lberger@labn.net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Giovanni Martinelli (giomarti)" <giomarti@cisco.com>, John E Drake <jdrake@juniper.net>
References: <CA+YzgTuUQzfjnjTWdya7xgpytB+nBvY_d-Sx4faqUJY3Md9h5Q@mail.gmail.com> <CF323F23.9C8CD%zali@cisco.com> <CA+YzgTtxz-aQXx8d5EV0kP05DV9NCAdUdbAmV0pK7nECo+KvFw@mail.gmail.com> <9EF94792-38EE-4671-833A-D5FC1F7FFE3C@cisco.com> <8456f073b7914ce383016978f1f170ce@BLUPR05MB562.namprd05.prod.outlook.com> <4DC0F48B-7E11-49F3-8BD8-DA3E727E7CD7@cisco.com>
In-Reply-To: <4DC0F48B-7E11-49F3-8BD8-DA3E727E7CD7@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/AXN3YDoCBn5O_FZW-QNm0ot819M
Cc: "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
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, 28 Feb 2014 17:20:15 -0000

The use of / debate on acceptable label set goes all the way back to its
introduction.  It always came down to a trade off of what mechanism
would be sufficient for the normal ("G") cases and to what level we'd
optimize for special cases.  I think the draft implicitly revisits one
particular trade off decision and argues that what was once a special
case is now a common case -- that should be optimized.

I really think this is the first point to reach any agreement on.

I personally think that the use of a special or reserved upstream label
is a fine way, with established precedent, to indicate such special
processing. (That is, if we were to decided that such is warranted in
this case.)

Lou

On 02/28/2014 09:36 AM, Giovanni Martinelli (giomarti) wrote:
> Hi John,
> 
> yes clear,  I was just bringing back on the table discussion we got on
> the same problem. The second option in better (although contention
> window is reduced but not avoided) however we had no numbers to justify
>  that such optimization or … at least not so strong  reasons to update a
> mechanism that was proven to work.
> 
> Cheers
> G
> 
> 
> On 28 Feb 2014, at 14:10, John E Drake <jdrake@juniper.net
> <mailto:jdrake@juniper.net>> wrote:
> 
>> Giovanni,
>>  
>> Use of acceptable doubles the signaling overhead and opens up a
>> contention window:
>>  
>> 1)      Path
>> 2)      Path_err w/ acceptable label
>> 3)      Contention window
>> 4)      Path w/ acceptable label
>> 5)      Resv
>>  
>> Versus:
>>  
>> 1)      Path w/ downstream assigned label request
>> 2)      Resv w/ downstream assigned label
>>  
>> Also, it’s generally considered a bad idea™ to include error messages
>> in the normal operation of a protocol
>>  
>> Yours Irrespectively,
>>  
>> John
>>  
>> *From:* CCAMP [mailto:ccamp-bounces@ietf.org] *On Behalf Of *Giovanni
>> Martinelli (giomarti)
>> *Sent:* Friday, February 28, 2014 4:54 AM
>> *To:* Vishnu Pavan Beeram
>> *Cc:* ccamp@ietf.org <mailto:ccamp@ietf.org>
>> *Subject:* Re: [CCAMP] Network Assigned Upstream Label - Draft Update
>>  
>> Hi Vishnu,
>>  
>> On 28 Feb 2014, at 13:26, Vishnu Pavan Beeram <vishnupavan@gmail.com
>> <mailto:vishnupavan@gmail.com>> wrote:
>>
>>
>>     (2) The use of Label-Set/Acceptable Label-Set was meant to be used
>>     for exceptions. Using it always for every setup request is a
>>     compromised solution.
>>      
>>
>>  
>> At the time we discussed the wson signaling
>> (http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06), the
>> acceptable label set was considered good enough. Not sure it comes
>> into play at every request since your label_set should have reasonably
>> good labels.
>>  
>> Cheers
>> G
> 
> 
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>