Re: [CCAMP] OVRLY - signaling extensions

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 09 March 2014 20:26 UTC

Return-Path: <adrian@olddog.co.uk>
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 792E61A02BF for <ccamp@ietfa.amsl.com>; Sun, 9 Mar 2014 13:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.202
X-Spam-Level:
X-Spam-Status: No, score=-96.202 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100, WEIRD_PORT=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 v8OIcniev7nu for <ccamp@ietfa.amsl.com>; Sun, 9 Mar 2014 13:26:28 -0700 (PDT)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5D31A02A9 for <ccamp@ietf.org>; Sun, 9 Mar 2014 13:26:27 -0700 (PDT)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s29KQ9sn028332; Sun, 9 Mar 2014 20:26:09 GMT
Received: from 950129200 (14.21.90.92.rev.sfr.net [92.90.21.14]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id s29KQ6xg028295 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 9 Mar 2014 20:26:07 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Rajan Rao'" <rrao@infinera.com>, "'Fatai Zhang'" <zhangfatai@huawei.com>, "'Dieter Beller'" <Dieter.Beller@alcatel-lucent.com>
References: <650AA355E323C34D9D4AAEED952E053D3FC6BBEA@SV-EXDB-PROD2.infinera.com> <F82A4B6D50F9464B8EBA55651F541CF85CAD5E4C@SZXEMA504-MBS.china.huawei.com> <650AA355E323C34D9D4AAEED952E053D3FC6D4AE@SV-EXDB-PROD2.infinera.com>
In-Reply-To: <650AA355E323C34D9D4AAEED952E053D3FC6D4AE@SV-EXDB-PROD2.infinera.com>
Date: Sun, 9 Mar 2014 20:26:08 -0000
Message-ID: <132301cf3bd5$cf0a8640$6d1f92c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_1324_01CF3BD5.CF11B230"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKw9VnQoF4V3YxjmEICO2ejjnzt1AEhTKUlAglrOgWY/GaaEA==
Content-language: en-gb
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/POcD69YyAMMHbSR2Sqc4PPgBNm8
Cc: 'CCAMP' <ccamp@ietf.org>
Subject: Re: [CCAMP] OVRLY - signaling extensions
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sun, 09 Mar 2014 20:26:30 -0000

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, J
 
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
https://www.ietf.org/mailman/listinfo/ccamp
 
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp