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

Igor Bryskin <IBryskin@advaoptical.com> Fri, 28 February 2014 22:23 UTC

Return-Path: <IBryskin@advaoptical.com>
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 414A01A0318 for <ccamp@ietfa.amsl.com>; Fri, 28 Feb 2014 14:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 OTxOO9IqKwov for <ccamp@ietfa.amsl.com>; Fri, 28 Feb 2014 14:22:58 -0800 (PST)
Received: from mail3.advaoptical.com (mail3.advaoptical.com [74.202.24.82]) by ietfa.amsl.com (Postfix) with ESMTP id 453271A0262 for <ccamp@ietf.org>; Fri, 28 Feb 2014 14:22:58 -0800 (PST)
Received: from atl-srv-mail10.atl.advaoptical.com (atl-srv-mail10.atl.advaoptical.com [172.16.5.39]) by atl-vs-fsmail.advaoptical.com (8.14.5/8.14.5) with ESMTP id s1SMMs6e011903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Feb 2014 17:22:54 -0500
Received: from ATL-SRV-MAIL10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae]) by atl-srv-mail10.atl.advaoptical.com ([fe80::c4d6:b136:bc16:77ae%17]) with mapi id 14.03.0174.001; Fri, 28 Feb 2014 17:22:54 -0500
From: Igor Bryskin <IBryskin@advaoptical.com>
To: Vishnu Pavan Beeram <vishnupavan@gmail.com>, Lou Berger <lberger@labn.net>
Thread-Topic: [CCAMP] Network Assigned Upstream Label - Draft Update
Thread-Index: AQHPMdsl0nyzjldrhEutv4HHhP94LJrGIV6AgAAgTgCABC0SgIAAghAAgAAHuACAAASEgIAAF++AgAAttwCAACGQAIAAFUmAgAAEKICAAAX0AIAABfYAgAAGWYD//7LuvQ==
Date: Fri, 28 Feb 2014 22:22:53 +0000
Message-ID: <CDAC6F6F5401B245A2C68D0CF8AFDF0A403D2C8C@atl-srv-mail10.atl.advaoptical.com>
References: <CF365D02.9E64D%zali@cisco.com> <5310F6B7.50603@labn.net> <CA+YzgTtFnZjReLfSHRT5dvrGeYkw79wwm3qxsRK1gDO2OnF6TA@mail.gmail.com> <531100B6.4050102@labn.net>, <CA+YzgTtkzkrOvnog7+=NM4M_h_rxad=26_+1m7F+VS2gePZtjA@mail.gmail.com>
In-Reply-To: <CA+YzgTtkzkrOvnog7+=NM4M_h_rxad=26_+1m7F+VS2gePZtjA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.5.47]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-02-28_04:2014-02-28, 2014-02-28, 1970-01-01 signatures=0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/MiORxEEt4vzDbQbrC2lwMYrBwKg
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 22:23:02 -0000

As you know Lou is talking about different and broader problem , which we plan to addfess ib a separate draft 
________________________________________
From: CCAMP [ccamp-bounces@ietf.org] on behalf of Vishnu Pavan Beeram [vishnupavan@gmail.com]
Sent: Friday, February 28, 2014 4:56 PM
To: Lou Berger
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Lou,

OK. We'll add some text ("informational" section) in the next version detailing how existing mechanisms can be used to let the downstream node know when the LSP is operational.

Regards,
-Pavan



On Fri, Feb 28, 2014 at 4:33 PM, Lou Berger <lberger@labn.net<mailto:lberger@labn.net>> wrote:
Pavan,
        I agree that there are existing mechanisms *could* be used, but your
document is changing the data place service model so it is the one that
needs to specify the new model...

Lou


On 02/28/2014 04:12 PM, Vishnu Pavan Beeram wrote:
> Lou, Hi!
>
> The initial version (00) had some details illustrating when the
> downstream node can send data. But we stripped that out in the current
> version because it seemed more of an implementation detail.
>
> Implementations may choose to use "Resv Conf" (as you mentioned) or a
> 2-step graceful setup procedure using ADMIN_STATUS (start with the A bit
> set; clear it when the LSP is ready for use). Either approach doesn't
> need any new protocol extensions.
>
> Regards,
> -Pavan
>
>
> On Fri, Feb 28, 2014 at 3:51 PM, Lou Berger <lberger@labn.net<mailto:lberger@labn.net>
> <mailto:lberger@labn.net<mailto:lberger@labn.net>>> wrote:
>
>     Pavan,
>             I have personally seen some instances, albeit rare,  when
>     acceptable
>     label set worked, but resulting in a fair amount of added latency in LSP
>     establishment.  So I can understand the instinct to optimize this.  --
>     And I know your use case is different.
>
>     One thing I grappled with when thinking about it at the time was to
>     figure out when the downstream node can send data.  Now it's when the
>     path message is received.  Your draft is silent on this point. Are you
>     assuming use of ResvConf as some have in the past? I think this is a
>     pretty important/fundamental point to address.
>
>     Lou
>
>     On 02/28/2014 03:36 PM, Zafar Ali (zali) wrote:
>     > Hi Pavan-
>     >
>     > This is an academic optimization. What we can do is to write a BCP or
>     > info draft based on method already documented in RFC3473 and wson
>     > signaling.
>     >
>     > Thanks
>     >
>     > Regards … Zafar
>     >
>     > From: Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>
>     <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>
>     > <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com> <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>>>
>     > Date: Friday, February 28, 2014 2:20 PM
>     > To: "lberger@labn.net<mailto:lberger@labn.net> <mailto:lberger@labn.net<mailto:lberger@labn.net>>
>     <mailto:lberger@labn.net<mailto:lberger@labn.net> <mailto:lberger@labn.net<mailto:lberger@labn.net>>>"
>     <lberger@labn.net<mailto:lberger@labn.net> <mailto:lberger@labn.net<mailto:lberger@labn.net>>
>     > <mailto:lberger@labn.net<mailto:lberger@labn.net> <mailto:lberger@labn.net<mailto:lberger@labn.net>>>>
>     > Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>
>     <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>>>" <ccamp@ietf.org<mailto:ccamp@ietf.org> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>>
>     > <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>>>>
>     > Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update
>     >
>     >     @Lou - Thanks for lending some direction to this thread (it was
>     >     going in cycles).
>     >
>     >     Zafar/Giovanni,
>     >
>     >     Do you agree that wrt alien wavelengths, "signaling a setup
>     request
>     >     without knowing what upstream-label to use" is not some remote
>     >     special case?
>     >     Yes or No?
>     >
>     >     Regards,
>     >     -Pavan
>     >
>     >     On Fri, Feb 28, 2014 at 12:19 PM, Lou Berger <lberger@labn.net<mailto:lberger@labn.net>
>     <mailto:lberger@labn.net<mailto:lberger@labn.net>>
>     >     <mailto:lberger@labn.net<mailto:lberger@labn.net> <mailto:lberger@labn.net<mailto:lberger@labn.net>>>> wrote:
>     >
>     >
>     >         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> <mailto:jdrake@juniper.net<mailto:jdrake@juniper.net>>
>     <mailto:jdrake@juniper.net<mailto:jdrake@juniper.net> <mailto:jdrake@juniper.net<mailto:jdrake@juniper.net>>>
>     >         > <mailto:jdrake@juniper.net<mailto:jdrake@juniper.net> <mailto:jdrake@juniper.net<mailto:jdrake@juniper.net>>
>     <mailto:jdrake@juniper.net<mailto:jdrake@juniper.net> <mailto: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<mailto:ccamp-bounces@ietf.org>
>     <mailto:ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> <mailto:ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>
>     <mailto:ccamp-bounces@ietf.org<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> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>>
>     <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>>>
>     <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org> <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org>>
>     >         <mailto:ccamp@ietf.org<mailto:ccamp@ietf.org> <mailto: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> <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>
>     <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com> <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>>
>     >         >> <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>
>     <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>> <mailto:vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>
>     <mailto: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<mailto:CCAMP@ietf.org> <mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org>>
>     <mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org> <mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org>>>
>     >         > https://www.ietf.org/mailman/listinfo/ccamp
>     >         >
>     >
>     >         _______________________________________________
>     >         CCAMP mailing list
>     >         CCAMP@ietf.org<mailto:CCAMP@ietf.org> <mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org>>
>     <mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org> <mailto:CCAMP@ietf.org<mailto:CCAMP@ietf.org>>>
>     >         https://www.ietf.org/mailman/listinfo/ccamp
>     >
>     >
>
>