Re: [CCAMP] OVRLY - signaling extensions
Dieter Beller <Dieter.Beller@alcatel-lucent.com> Tue, 11 March 2014 09:58 UTC
Return-Path: <Dieter.Beller@alcatel-lucent.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 E33E11A066C for <ccamp@ietfa.amsl.com>; Tue, 11 Mar 2014 02:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.175
X-Spam-Level:
X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, 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 GTYlnlwVP3QG for <ccamp@ietfa.amsl.com>; Tue, 11 Mar 2014 02:58:14 -0700 (PDT)
Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF211A068D for <ccamp@ietf.org>; Tue, 11 Mar 2014 02:58:14 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s2B9vx8C001180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 11 Mar 2014 04:58:01 -0500 (CDT)
Received: from destgsu0709.de.alcatel-lucent.com (slsv7at.de.alcatel-lucent.com [149.204.245.107]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s2B9vvQS024398 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Mar 2014 10:57:59 +0100
Received: from [149.204.107.17] (DESTGN0H466262.de.alcatel-lucent.com [149.204.107.17]) (authenticated bits=0) by destgsu0709.de.alcatel-lucent.com (8.14.3/8.13.8) with ESMTP id s2B9vsas016193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 11 Mar 2014 10:57:55 +0100 (CET)
Message-ID: <531EDE22.2010303@alcatel-lucent.com>
Date: Tue, 11 Mar 2014 10:57:54 +0100
From: Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: adrian@olddog.co.uk
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> <8f71d3e2fb1f47e7858721caf9f894a7@MUC-SRV-MBX1.advaoptical.com> <16a401cf3ca2$00152cf0$003f86d0$@olddog.co.uk>
In-Reply-To: <16a401cf3ca2$00152cf0$003f86d0$@olddog.co.uk>
Content-Type: multipart/related; boundary="------------050001010607040205050604"
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/zOtXny-2UupSakK65qBdnnqge0M
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: Tue, 11 Mar 2014 09:58:18 -0000
I agree with the assertion that you may find a pair of diverse LSPs if you request them together as opposed toHello Paweł,
OK draft-zhang-ccamp-gmpls-uni-app-05 Figure 1
Firstly, establishing a pair of mutually diverse paths by first setting up one and then trying to set up the other is at best a poor substitute for selecting two good paths.
requesting them sequentially. It is, however a matter of the network topology and network state (utilization)
that determines the likelihood that you may not find a pair of diverse paths if you request them sequentially.
Afaik, it is currently not possible to request a pair of diverse LSPs with two different ingress and egress nodes
based on the RSVP UNI signalling RFCs/drafts. The network would have to correlate somehow the two requests
for the 2 LSPs. Therefore, we are currently proposing a solution to the problem that is feasible with some minor
protocol extensions for the sequential case.
Thanks,
Dieter
But, let's assume you want to do it for some reason.
EN1 sets up an LSP EN1-CN1-CN2-CN3-EN3
EN2 wants an LSP to EN4 that is completely disjoint from the first LSP.
Of course, there has to be some (magic) exchange of information from EN1 to EN2, but let's also assume that this happens (although I believe the reason for doing it is suspect!)
Suppose EN1 reports the path as {EN1, CN1, keyX, EN3}
Suppose also that EN2 has no access to a PCE.
EN2 does the computation it can which is to choose CN1 or CN4. It will not choose CN1 as that is in the path it is trying to avoid.
So EN2 signals {EN2, CN4, looseEN4} with Not keyX
The Path message reaches CN4 and it looks for the next hop. It's loose so a path computation is needed.
CN4 sees the Not keyX and contacts the PCE for the core (or CN1) to expand the key.
The expansion shows {CN2, CN3}
So CN4 can now compute the path CN4-CN5-EN4 and signal as necessary.
[note: computations can be offloaded as desired]
Thus, yes, "avoid all links from EN2 to CN1". But I prefer "avoid all nodes CN1" because that is really what you are doing.
A
From: Paweł Brzozowski [mailto:PBrzozowski@advaoptical.com]
Sent: 10 March 2014 01:07
To: adrian@olddog.co.uk; 'Rajan Rao'; 'Fatai Zhang'; 'Dieter Beller'
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions
Adrian,
If EN1 can ask PCE – I agree, there is no need for crankback. Do you think that using pathkey as exclusion when there is no PCEP/TE visibility on the UNI boundary is worth considering? If so, could you walk me through such a case? Let’s take figure 1 from the document as an example.
1. EN1 sets up a service A to EN3 via CN1.
2. EN2 wants to set up a service B to EN4, which is both node and link-disjoint from path of service A. It will use pathkey exclusion for this purpose.
If I understand “Path key is used in conjunction with the identity of the domain entry point, not in isolation” statement correctly, in order to avoid choosing wrong path for service B, EN2 should add TWO exclusions:
CN1 (or all links from EN2 to CN1) AND pathkey from service A. Is this correct?
Thanks,
Pawel
From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Sunday, March 09, 2014 4: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 http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-uni-app-05.txt" rel="nofollow">draft-zhang-ccamp-gmpls-uni-app.
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" rel="nofollow">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" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp" rel="nofollow">https://www.ietf.org/mailman/listinfo/ccamp
PROJECT MANAGER ASON/GMPLS CONTROL PLANE
IP ROUTING AND TRANSPORT BL
IP TRANSPORT BU
Lorenzstrasse 10
70435 Stuttgart, Germany
Phone: +49 711 821 43125
Mobil: +49 175 7266874
Domicile of the Company: Stuttgart · Local Court Stuttgart HRB 4026
Chairman of the Supervisory Board: Michael Oppenhoff
Board of Management: Wilhelm Dresselhaus (Chairman) · Hans-Jörg Daub · Andreas Gehe
This e-mail and its attachments, if any, may contain confidential information.
If you have received this e-mail in error, please notify us and delete or destroy the e-mail and its attachments, if any, immediately.
If you have received this e-mail in error, you must not forward or make use of the e-mail and its attachments, if any.
- [CCAMP] OVRLY - signaling extensions Rajan Rao
- [CCAMP] 答复: OVRLY - signaling extensions Fatai Zhang
- Re: [CCAMP] OVRLY - signaling extensions Rajan Rao
- Re: [CCAMP] OVRLY - signaling extensions Adrian Farrel
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions Adrian Farrel
- Re: [CCAMP] OVRLY - signaling extensions Rajan Rao
- Re: [CCAMP] OVRLY - signaling extensions Fatai Zhang
- Re: [CCAMP] OVRLY - signaling extensions Fatai Zhang
- Re: [CCAMP] OVRLY - signaling extensions Rajan Rao
- Re: [CCAMP] OVRLY - signaling extensions Fatai Zhang
- Re: [CCAMP] OVRLY - signaling extensions Dieter Beller
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions Vishnu Pavan Beeram
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Rajan Rao
- Re: [CCAMP] OVRLY - signaling extensions Igor Bryskin
- Re: [CCAMP] OVRLY - signaling extensions Gert Grammel
- Re: [CCAMP] OVRLY - signaling extensions Dieter Beller
- Re: [CCAMP] OVRLY - signaling extensions Igor Bryskin
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Igor Bryskin
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Adrian Farrel
- Re: [CCAMP] OVRLY - signaling extensions Zhangxian (Xian)
- Re: [CCAMP] OVRLY - signaling extensions Zhangxian (Xian)
- Re: [CCAMP] OVRLY - signaling extensions Zhangxian (Xian)
- Re: [CCAMP] OVRLY - signaling extensions Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] OVRLY - signaling extensions Adrian Farrel
- Re: [CCAMP] OVRLY - signaling extensions Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] OVRLY - signaling extensions Adrian Farrel
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Gabriele Maria Galimberti (ggalimbe)
- Re: [CCAMP] OVRLY - signaling extensions Dieter Beller
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Zafar Ali (zali)
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Gert Grammel
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions John E Drake
- Re: [CCAMP] OVRLY - signaling extensions Gert Grammel
- Re: [CCAMP] OVRLY - signaling extensions Rajan Rao
- Re: [CCAMP] OVRLY - signaling extensions Rajan Rao
- Re: [CCAMP] OVRLY - signaling extensions Zhangxian (Xian)
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions Adrian Farrel
- Re: [CCAMP] OVRLY - signaling extensions Gert Grammel
- Re: [CCAMP] OVRLY - signaling extensions Zafar Ali (zali)
- Re: [CCAMP] OVRLY - signaling extensions Igor Bryskin
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions Paweł Brzozowski
- Re: [CCAMP] OVRLY - signaling extensions Zafar Ali (zali)