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

Gert Grammel <ggrammel@juniper.net> Fri, 28 February 2014 16:29 UTC

Return-Path: <ggrammel@juniper.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 550C61A00FF for <ccamp@ietfa.amsl.com>; Fri, 28 Feb 2014 08:29:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 ztNOWWcswGyy for <ccamp@ietfa.amsl.com>; Fri, 28 Feb 2014 08:29:13 -0800 (PST)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F51A00EF for <ccamp@ietf.org>; Fri, 28 Feb 2014 08:29:13 -0800 (PST)
Received: from mail196-tx2-R.bigfish.com (10.9.14.239) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Fri, 28 Feb 2014 16:29:11 +0000
Received: from mail196-tx2 (localhost [127.0.0.1]) by mail196-tx2-R.bigfish.com (Postfix) with ESMTP id 63D923E0301; Fri, 28 Feb 2014 16:29:11 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -20
X-BigFish: VPS-20(zz98dI9371Ic85ehe0eahzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24d7h2516h2545h255eh25cch9a9j1155h)
Received-SPF: pass (mail196-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=ggrammel@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(979002)(428001)(377454003)(24454002)(199002)(189002)(31966008)(93516002)(4396001)(87266001)(65816001)(33646001)(85852003)(90146001)(56816005)(74706001)(87936001)(81686001)(86362001)(46102001)(83072002)(63696002)(94946001)(80976001)(95666003)(95416001)(51856001)(83322001)(19580405001)(81542001)(53806001)(85306002)(74662001)(81342001)(54356001)(94316002)(19580395003)(15202345003)(49866001)(56776001)(77982001)(59766001)(15975445006)(16236675002)(81816001)(92566001)(76482001)(77096001)(74316001)(47976001)(2656002)(93136001)(47736001)(47446002)(74502001)(66066001)(50986001)(79102001)(80022001)(76576001)(76786001)(76796001)(74876001)(74366001)(54316002)(69226001)(24736002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB705; H:BN1PR05MB041.namprd05.prod.outlook.com; CLIP:178.239.82.32; FPR:A6CFD204.AC32DFC1.BCF1F1B3.4AE5E14D.204CF; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail196-tx2 (localhost.localdomain [127.0.0.1]) by mail196-tx2 (MessageSwitch) id 1393604948798949_20044; Fri, 28 Feb 2014 16:29:08 +0000 (UTC)
Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.228]) by mail196-tx2.bigfish.com (Postfix) with ESMTP id B4DE63A0065; Fri, 28 Feb 2014 16:29:08 +0000 (UTC)
Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Feb 2014 16:29:04 +0000
Received: from BLUPR05MB705.namprd05.prod.outlook.com (10.141.207.11) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 28 Feb 2014 16:29:03 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com (10.255.202.140) by BLUPR05MB705.namprd05.prod.outlook.com (10.141.207.11) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 28 Feb 2014 16:29:02 +0000
Received: from BN1PR05MB041.namprd05.prod.outlook.com ([169.254.6.24]) by BN1PR05MB041.namprd05.prod.outlook.com ([169.254.6.210]) with mapi id 15.00.0888.003; Fri, 28 Feb 2014 16:29:01 +0000
From: Gert Grammel <ggrammel@juniper.net>
To: "Zafar Ali (zali)" <zali@cisco.com>, Igor Bryskin <IBryskin@advaoptical.com>, Vishnu Pavan Beeram <vishnupavan@gmail.com>, Giovanni Martinelli <giomarti@cisco.com>
Thread-Topic: [CCAMP] Network Assigned Upstream Label - Draft Update
Thread-Index: AQHPMdsYpw+AFSdfok6Dw1tjVdRel5rFzY2AgAAgTQCABC0SgIAAghAAgAAHuQCAABbVgIAAB++AgAACnSWAABO+AIAABtP4
Date: Fri, 28 Feb 2014 16:29:01 +0000
Message-ID: <dc5af7f8662e44a19cb8b0e79264cfb3@BN1PR05MB041.namprd05.prod.outlook.com>
References: <c48593a147504d5386689f7590965d1f@BN1PR05MB041.namprd05.prod.outlook.com>, <CF361CE7.9E2D8%zali@cisco.com>
In-Reply-To: <CF361CE7.9E2D8%zali@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [178.239.82.32]
x-forefront-prvs: 0136C1DDA4
Content-Type: multipart/alternative; boundary="_000_dc5af7f8662e44a19cb8b0e79264cfb3BN1PR05MB041namprd05pro_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/n0epfVoGjvR2Ku87pT5f0jGfMAs
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 16:29:17 -0000

Hi Zafar,

I was responding to Giovanni's comment: GM> for the wson case the LABEL_SET might be an output from the RWA process, so the signalling likely pick up a good label first time.

So the ingress has to take an educated decision to get to a 'good label'. However in a world where the ingress has no idea of which label is available, it is not 'educated' and simply has to guess.
This is related to visibility a client may have of the network. Full, partial or none. (You can translate this into your preferred model)

Network assigned upstream labels can work well in either case as there is no pre-knowledge about labels assumed.

Gert


________________________________
From: Zafar Ali (zali) <zali@cisco.com>
Sent: Friday, February 28, 2014 5:04:34 PM
To: Gert Grammel; Igor Bryskin; Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: ccamp@ietf.org
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Gert-

What label has to do with overlay vs. peer? If so, there is a terminology document in this area that WG is working on – please contribute to it first.

Thanks

Regards … Zafar

From: Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>
Date: Friday, February 28, 2014 9:53 AM
To: "IBryskin@advaoptical.com<mailto:IBryskin@advaoptical.com>" <IBryskin@advaoptical.com<mailto:IBryskin@advaoptical.com>>, Vishnu Pavan Beeram <vishnupavan@gmail.com<mailto:vishnupavan@gmail.com>>, "Giovanni Martinelli (giomarti)" <giomarti@cisco.com<mailto:giomarti@cisco.com>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni,

In other words, ACCEPTABLE_LABEL_SET is a mechanism that can work in a peer-to-peer model where label information is shared beforehand. It is not adequate for an overlay case where no label information is shared between client and network.

Gert

________________________________
From: CCAMP <ccamp-bounces@ietf.org<mailto:ccamp-bounces@ietf.org>> on behalf of Igor Bryskin <IBryskin@advaoptical.com<mailto:IBryskin@advaoptical.com>>
Sent: Friday, February 28, 2014 3:44:33 PM
To: Vishnu Pavan Beeram; Giovanni Martinelli (giomarti)
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Hi,
It is funny that we have to go through the same arguments again and again every 4 months :=)
One point that I made when I was 4 months younger is that Acceptable Label Set is an exceptionally bad idea in the context of overlay networks (UNI, ENNI, etc.). Consider the following scenario:

1.      Ingress UNI-C guesses upstream label for its LSP L to be X;

2.      Network made its own decision that the upstream label cannot be X - has to be Y. This decision is a function of many things: selected path, capabilities of network nodes along the path, capabilities of egress UNI-C. etc. *Only when the entire tail of client LSP is established the ingress UNI-N can definitively report the acceptable upstream label;* The point is that the signaled acceptable label set cannot contain more than one value.

3.      If label Y is not acceptable for ingress UNI-C, it will have no other choice other than to guess another upstream label Z, and start the process again;

4.      This can go on for quite a while until ingress UNI-C runs out of guesses and gives up.

Cheers,
Igor

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: Friday, February 28, 2014 9:16 AM
To: Giovanni Martinelli (giomarti)
Cc: ccamp@ietf.org<mailto:ccamp@ietf.org>
Subject: Re: [CCAMP] Network Assigned Upstream Label - Draft Update

Giovanni, Hi!

Can you please elaborate on why you think the LABEL_SET having good labels help in this context/argument? If the upstream-node doesn't guess right (when picking the upstream-label), you'll get a PATH-ERR back with the ACCEPTABLE_LABEL_SET. And this would happen for every setup request. Wouldn't you call this a compromised solution?

Regards,
-Pavan

On Fri, Feb 28, 2014 at 7:54 AM, Giovanni Martinelli (giomarti) <giomarti@cisco.com<mailto:giomarti@cisco.com>> wrote:
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