Re: [CCAMP] OVRLY - signaling extensions

"Zhangxian (Xian)" <zhang.xian@huawei.com> Fri, 14 March 2014 02:07 UTC

Return-Path: <zhang.xian@huawei.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 B47601A0813 for <ccamp@ietfa.amsl.com>; Thu, 13 Mar 2014 19:07:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.296
X-Spam-Level:
X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, WEIRD_PORT=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 hvBz7mv07_OU for <ccamp@ietfa.amsl.com>; Thu, 13 Mar 2014 19:07:38 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DE8FF1A0821 for <ccamp@ietf.org>; Thu, 13 Mar 2014 19:07:36 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCB06959; Fri, 14 Mar 2014 02:07:28 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Mar 2014 02:06:36 +0000
Received: from SZXEMA408-HUB.china.huawei.com (10.82.72.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 14 Mar 2014 02:07:27 +0000
Received: from SZXEMA512-MBS.china.huawei.com ([169.254.8.22]) by SZXEMA408-HUB.china.huawei.com ([10.82.72.40]) with mapi id 14.03.0158.001; Fri, 14 Mar 2014 10:07:15 +0800
From: "Zhangxian (Xian)" <zhang.xian@huawei.com>
To: Rajan Rao <rrao@infinera.com>
Thread-Topic: [CCAMP] OVRLY - signaling extensions
Thread-Index: Ac85YJDrYXZOuOMaR1Gk+fcsuXhJCgBBUEbQAA/KqYAAO3CxAAA7otYAAKlXfNA=
Date: Fri, 14 Mar 2014 02:07:15 +0000
Message-ID: <C636AF2FA540124E9B9ACB5A6BECCE6B30212C37@SZXEMA512-MBS.china.huawei.com>
References: <650AA355E323C34D9D4AAEED952E053D3FC6BBEA@SV-EXDB-PROD2.infinera.com> <F82A4B6D50F9464B8EBA55651F541CF85CAD5E4C@SZXEMA504-MBS.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D3FC6D4AE@SV-EXDB-PROD2.infinera.com> <132301cf3bd5$cf0a8640$6d1f92c0$@olddog.co.uk> <650AA355E323C34D9D4AAEED952E053D3FC6DA67@SV-EXDB-PROD2.infinera.com>
In-Reply-To: <650AA355E323C34D9D4AAEED952E053D3FC6DA67@SV-EXDB-PROD2.infinera.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.104.209]
Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B30212C37SZXEMA512MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/cwKRBloWOLs6VGhfycHCnR17TsM
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] OVRLY - signaling extensions
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, 14 Mar 2014 02:07:42 -0000

Hi, Rajan,

   Reply to your questions below:

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: 2014年3月11日 8:54
To: adrian@olddog.co.uk; Fatai Zhang; 'Dieter Beller'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Adrian,

I don’t disagree with the steps you have below for  EN to PCE use case.    I don’t think CN4 is part of the path-Key.  Or is it?
Xian: CN4 is part of the Path Key. Please have a look at the example provided in Section 2.2 of RFC5520.

My question was for the case where EN doesn’t talk to PCE but CN1 does. Pl refer to slides that Dieter and Fatai used (they showed PE talking to PCE).   In this case what does CN1  report to EN1 in crankback?  Is path-key alone sufficient for EN1 to determine to go to CN4 for the first LSP setup?
Xian: Not sure what you are trying to understand here. First, to make it clear, Figure 2 in [UNI-APP] does not force EN nodes talking to Core network PCE directly (we have made it clearly in the draft text explanation), it can EN talking to its own PCE and then to the core network PCE (a standard model supported by current RFCs). Second, back to your question, If you are resorting to PCE for path computation, why there is crankback? For both first LSP setup or the second LSP setup with the constraint of diversifying with the first one, they can be done with one shot for each request.

Cheers,
Xian

Thx
Rajan

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Sunday, March 09, 2014 1:26 PM
To: Rajan Rao; 'Fatai Zhang'; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Rajan,

[co-author of draft-zhang-ccamp-gmpls-uni-app wakes from his slumber]

Of course crankback can be used, but I fail to see the topology where the path key doesn't do the job.

You referenced Figure 2 as an example. Unfortunately, you then used "CE" and "PE" in your question. Yet those terms are not used in the figure so we are left guessing what you mean.

It is possible that there is a slight confusion. Path key is used in conjunction with the identity of the domain entry point, not in isolation. Furthermore, it is used in conjunction with two points of reference to the PCE.

Let's look again at that figure.
Let's suppose that EN1 (which is dual homed) asks the PCE for a path.
Let's also assume that core path hiding is being used.
Furthermore, the single PCE can see the ENs and the core network.
The PCRsp includes an ERO that is {EN1, CN4, pathkey, EN2}
This gives EN1 everything it needs to know.
When the signaling message reaches CN4, it must expand the pathkey.
Thus CN4 must contact the PCE for help and gets in return the path {CN4, CN5, CN2, CN3, EN2}

It may help if you re-read some RFCs: 5520, 5553, 5623, 6805.

If, at the end of this, you feel that the use of the path key is not clear, this is something you could work with us to add to draft-ietf-pce-questions

Cheers,
Adrian


From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Rajan Rao
Sent: 08 March 2014 08:12
To: Fatai Zhang; Dieter Beller
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

My understanding is that a “Cookie” is a network-Id/path-id.  It won’t give info CE is looking for.   What I understood from side discussions is that Crankback will be used to convey info back to CE!!

Regards
Rajan

From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Saturday, March 08, 2014 12:34 AM
To: Rajan Rao; Dieter Beller
Cc: CCAMP
Subject: 答复: OVRLY - signaling extensions

Hi Rajan,

I would say “by cookie” if I understand your question correctly.


Thanks

Fatai



发件人: Rajan Rao [mailto:rrao@infinera.com]
发送时间: 2014年3月7日 1:33
收件人: Fatai Zhang; Dieter Beller
抄送: CCAMP
主题: OVRLY - signaling extensions

Changed the title to Overlay topic.

Dieter,  Fatai

One more question:

In case of PCE,  I assume CE is the one talking to PCE (fig-2 in uni-app draft).
In cases where CE reachability is not known & PE1 is the one talking to PCE (say CE makes a request to PE1 first),  how do you communicate PE2 info back to CE?

Thx
Rajan



From: Fatai Zhang [mailto:zhangfatai@huawei.com]
Sent: Thursday, March 06, 2014 4:49 PM
To: Dieter Beller; Rajan Rao
Cc: CCAMP
Subject: 答复: [CCAMP] Raw notes available for review/comment

Hi Rajan,

I think your question is a general question, and should be out of scope of “LSP diversity” topic, :)

However, there are lots of approaches for CE to know why “PE1” should be picked up besides the way mentioned by Dieter below, e.g, qualified TE information (besides reachability) known by CE, manual configuration, or PCE can help as described in draft-zhang-ccamp-gmpls-uni-app<http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-05.txt>.


Thanks

Fatai



发件人: CCAMP [mailto:ccamp-bounces@ietf.org] 代表 Dieter Beller
发送时间: 2014年3月7日 0:15
收件人: Rajan Rao
抄送: CCAMP
主题: Re: [CCAMP] Raw notes available for review/comment

Hi Rao,
On 06.03.2014 17:01, Rajan Rao wrote:

Authors of 'lsp-diversity',  'uni-extensions' & 'route-exclusion-pathkey'



My question on your uses cases was the following:

How does CE know which PE to talk to for the first LSP setup?  What is the assumption?
assuming that the CE does not have any information other than the destination CE is reachable via
both PEs , it will just pick one arbitrarily.


Thanks,
Dieter





Thx Lou for session notes.

Thx

Rajan



-----Original Message-----

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger

Sent: Thursday, March 06, 2014 1:30 PM

To: CCAMP

Subject: [CCAMP] Raw notes available for review/comment



All,

        Please take a look at the raw minutes in etherpad (link below) and correct as you see fit.  Note these are *unreviewed/raw* notes.



Much thanks,

Lou

Link -

http://etherpad.tools.ietf.org:9000/p/notes-ietf-89-ccamp?useMonospaceFont=true



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp



_______________________________________________

CCAMP mailing list

CCAMP@ietf.org<mailto:CCAMP@ietf.org>

https://www.ietf.org/mailman/listinfo/ccamp