Re: [CCAMP] OVRLY - signaling extensions

John E Drake <jdrake@juniper.net> Mon, 17 March 2014 15:27 UTC

Return-Path: <jdrake@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 ED0EF1A042E for <ccamp@ietfa.amsl.com>; Mon, 17 Mar 2014 08:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 r19zRmOCkJHA for <ccamp@ietfa.amsl.com>; Mon, 17 Mar 2014 08:27:31 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 131031A042C for <ccamp@ietf.org>; Mon, 17 Mar 2014 08:27:30 -0700 (PDT)
Received: from mail108-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Mon, 17 Mar 2014 15:27:21 +0000
Received: from mail108-am1 (localhost [127.0.0.1]) by mail108-am1-R.bigfish.com (Postfix) with ESMTP id AFAAE1001AC; Mon, 17 Mar 2014 15:27:21 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -18
X-BigFish: VPS-18(zz98dI9371Ic89bh542Ic857h4015I1447Idb82h9a6kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1d7338h1de098h1033IL1b1984h17326ah8275bh1bc7b9h8275dh18c673h1de097h186068h18602eh1d68deh19bc52i19bc50iz2fh109h2a8h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1a24h1a82h1ad9h1b0ah1bceh224fh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1fe8h1ff5h20f0h2216h22d0h2336h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h9a9j1155h)
Received-SPF: pass (mail108-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=jdrake@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(10009001)(428001)(164054003)(199002)(189002)(377454003)(13464003)(24454002)(51914003)(46102001)(19300405004)(87936001)(2656002)(15202345003)(19273905006)(87266001)(561944002)(19580395003)(83322001)(19580405001)(80976001)(76576001)(76796001)(76786001)(85306002)(16236675002)(47976001)(50986001)(74366001)(54356001)(92566001)(81342001)(95416001)(18206015023)(74316001)(94946001)(97336001)(97186001)(53806001)(81542001)(79102001)(86362001)(81816001)(4396001)(95666003)(69226001)(17760045001)(63696002)(81686001)(54316002)(20776003)(76482001)(80022001)(33646001)(66066001)(74706001)(93136001)(74502001)(74662001)(56776001)(47446002)(59766001)(90146001)(74876001)(56816005)(15975445006)(83072002)(31966008)(65816001)(85852003)(93516002)(77982001)(49866001)(47736001)(94316002)(24704002)(24736002)(16866105001)(579004)(559001);DIR:OUT;SFP:1101;SCL:1;SRVR:BLUPR05MB561;H:BLUPR05MB562.namprd05.prod.outlook.com;FPR:245FFFF5.ACFAA38D.71D1734A.82246880.20AB1;MLV:sfv;PTR:InfoNoRecords;A:1; MX:1; LANG:en;
Received: from mail108-am1 (localhost.localdomain [127.0.0.1]) by mail108-am1 (MessageSwitch) id 1395070038274927_22344; Mon, 17 Mar 2014 15:27:18 +0000 (UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.254]) by mail108-am1.bigfish.com (Postfix) with ESMTP id 3CB6C60116; Mon, 17 Mar 2014 15:27:18 +0000 (UTC)
Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 17 Mar 2014 15:27:14 +0000
Received: from BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 17 Mar 2014 15:27:09 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB561.namprd05.prod.outlook.com (10.141.202.139) with Microsoft SMTP Server (TLS) id 15.0.898.11; Mon, 17 Mar 2014 15:27:06 +0000
Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.00.0898.005; Mon, 17 Mar 2014 15:27:06 +0000
From: John E Drake <jdrake@juniper.net>
To: Dieter Beller <Dieter.Beller@alcatel-lucent.com>
Thread-Topic: [CCAMP] OVRLY - signaling extensions
Thread-Index: Ac85YJDrYXZOuOMaR1Gk+fcsuXhJCgBBUEbQAA/KqYAATDQ6AAAJzQ8AACk+9gAAKDZ4gAABiQ5QARrLi4AABh0RAAAC8WcAAABBkQAABXJIIAAAtHkAAADLrbA=
Date: Mon, 17 Mar 2014 15:27:06 +0000
Message-ID: <161c47fa95e54e73907e8e21e789ba38@BLUPR05MB562.namprd05.prod.outlook.com>
References: <279301cf41d8$65564e10$3002ea30$@olddog.co.uk> <CF4CA2DB.5AE5B%ggalimbe@cisco.com> <b8f25887593743cc979fa6b734e28485@BLUPR05MB562.namprd05.prod.outlook.com> <53270EB2.3020706@alcatel-lucent.com>
In-Reply-To: <53270EB2.3020706@alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.13]
x-forefront-prvs: 0153A8321A
Content-Type: multipart/related; boundary="_004_161c47fa95e54e73907e8e21e789ba38BLUPR05MB562namprd05pro_"; type="multipart/alternative"
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/iZedtqo1wWE-70-7sMR7-NBr0io
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: Mon, 17 Mar 2014 15:27:38 -0000

Dieter,

Please see my email to Gabriele on this topic.  I hope it’s clear but if not, please let me know.

Yours Irrespectively,

John

From: Dieter Beller [mailto:Dieter.Beller@alcatel-lucent.com]
Sent: Monday, March 17, 2014 8:03 AM
To: John E Drake
Cc: Gabriele Maria Galimberti (ggalimbe); adrian@olddog.co.uk; 'Zhangxian (Xian)'; 'Paweł Brzozowski'; 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi John,

there are more GMPLS implementations deployed in the field - the proposed extensions are addressing use cases
that network operators are requesting and can as such be considered as added value for GMPLS. IMHO, these fall
into the pragmatics category.


Thanks,
Dieter

On 17.03.2014 15:44, John E Drake wrote:
Gabriele,

Why should we standardize something simply because you have shipped it, particularly when you don’t even use GMPLS within your server network?

Yours Irrespectively,

John

From: Gabriele Maria Galimberti (ggalimbe) [mailto:ggalimbe@cisco.com]
Sent: Monday, March 17, 2014 5:07 AM
To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>; 'Zhangxian (Xian)'; John E Drake; 'Paweł Brzozowski'
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

I agree Adrian !

We need to look ahead and use the best for the future   … and We'll DO that !
But, I'd also say, let me keep my bended solution already working in field.

Regards,

Gabriele
[http://www.cisco.com/swa/i/logo.gif]


Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

ggalimbe@cisco.com<mailto:ggalimbe@cisco.com>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049












From: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Reply-To: "adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>" <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Date: Monday, March 17, 2014 12:59 PM
To: Gabriele Galimberti <ggalimbe@cisco.com<mailto:ggalimbe@cisco.com>>, Xian Zhang <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>, John Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>, 'Paweł Brzozowski' <PBrzozowski@advaoptical.com<mailto:PBrzozowski@advaoptical.com>>
Cc: 'CCAMP' <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] OVRLY - signaling extensions

Forgive me, but I hear "What if I don't want to use an aeroplane? Can't I just strap rockets on my pig?"  :-) [RFC1925]

As engineers, of course we should keep making things do what people want to do with them.
As architects we should use the best tools for the job.

This is the dichotomy I was trying to comment on before.
Of course we need to "bend" what is in the field to add function. That is not a crime.
But we should also take the long view because we also know what happens to metal if you keep bending it.

A

From: Gabriele Maria Galimberti (ggalimbe) [mailto:ggalimbe@cisco.com]
Sent: 17 March 2014 10:36
To: Zhangxian (Xian); John E Drake; Paweł Brzozowski; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Correct Xian,

But You are using a different technology (centralised vs. distributed).
What if I don't want to used the PCE and I want to rely on GMPLS also for the Restoration ?

Regards,

Gabriele
[http://www.cisco.com/swa/i/logo.gif]


Gabriele Galimberti
Technical Leader
Cisco Photonics Srl

Via Philips, 12
20900 - Monza (MI)
Italy
www.cisco.com/global/IT/<http://www.cisco.com/global/IT/>

ggalimbe@cisco.com<mailto:ggalimbe@cisco.com>
Phone :+39 039 2091462
Mobile :+39 335 7481947
Fax :+39 039 2092049












From: Xian Zhang <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>
Date: Monday, March 17, 2014 8:40 AM
To: John Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>, Paweł Brzozowski <PBrzozowski@advaoptical.com<mailto:PBrzozowski@advaoptical.com>>, "adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>" <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Cc: 'CCAMP' <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] OVRLY - signaling extensions

Hi, John,

Just one comment to what you describe below. To meet the functionality you mentioned below, have you ever thought of using PCE/PCEP?

To be more specific, A CE (or EN in UNI context), which wishes to set up N diversified LSPs, sends a path request to PCE asking for diversified path (where is the PCE is not the key point here, but if you think it matters, we can discuss). Once it gets reply (each including ingress and egress PEs info, with/without path-key), it then starting the signaling procedure separately for each LSP setup.

Regards,
Xian

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of John E Drake
Sent: 2014年3月12日 1:35
To: Paweł Brzozowski; adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Pawel,

I’m not sure if people understood what I was proposing in my original note on Suurballe:

“If we want to get N node disjoint paths across, I think we need to define a new service in which the ingress CE sends the ingress PE a request containing a destination (egress) CE, the number of disjoint paths N, and a list of its attachment circuits to be considered in the request.  What it receives in exchange is a list of [attachment circuit, path keys] which it then can include in a set of Path messages that it sends to the provider network.”

I.e., the procedures between ingress CE and ingress PE for the new service would *precede* the sending of any Path message across any UNI.  Also, the attachment circuits may be between the ingress CE and two or more ingress PEs; they are *not* just between the ingress CE and the ingress PE to which it send its request for disjoint paths.  Further, when the ingress CE sends the Path message for a particular [attachment circuit, path keys] tuple, it sends it across the UNI to the ingress PE at the other end of the specified attachment circuit.  (It is assumed that as part of these new service procedures the egress CE is also queried for a list of its attachment circuits.  This was one of the uses for which RFC 4974 was designed.)

Yours Irrespectively,

John

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Pawel Brzozowski
Sent: Tuesday, March 11, 2014 8:59 AM
To: adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>
Cc: 'CCAMP'
Subject: Re: [CCAMP] OVRLY - signaling extensions

Adrian,

Thanks for the throughout explanation. Appreciate it. You wrote:

“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.”

I couldn’t agree more. The reason I asked is because CCAMP is recently having a plethora of proposals for achieving LSP diversity, none of which talks about PCEP/TE visibility on the UNI boundary. As many have noticed, these proposals are fundamentally flawed. While I understand there is room for them, especially in the legacy deployments, it seems rather scary that these are the only diversity proposals pursued by CCAMP at the moment. What makes it even scarier is that authors of these proposals seem to belittle the implications of foregoing use of PCEP/TE visibility for achieving diversity. I allowed myself to summarize them below.

Cheers,
Pawel


1.       As John has noticed, since algorithms are greedy, it is possible to find a pair of diverse paths if they are computed together as opposed to computed sequentially. Also when computing paths simultaneously it is likely to come with a lower combined cost of paths.



2.       As Rajan and Fatai have noticed, since there is no TE visibility over UNI, multi-homed UNI-Cs have really no way of telling which UNI-N to go. Hence they have to try them one-by-one until they get a working path, which implies crankback architecture.

Example – draft-zhang-ccamp-gmpls-uni-app-05 Figure 1

EN1 sets up an LSP1 EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP2 to EN4 that is link-disjoint from the first LSP.



In the figure there are two link-disjoint paths from path of LSP1:
EN2-CN1-CN4-CN5-EN4  and EN2-CN4-CN5-EN4. Sadly, since EN2 has no knowledge of network’s topology, it has to choose one of ENXes’ it’s connected to and wish for the best. Depending on the network topology and resource usage, ENX can either deliver a link-disjoint path or not. If it does not, we have a crankback.



3.       Even if UNI-N chosen by UNI-C delivers disjoint path, there is no guarantee, that this path is the optimal to be found. It could be that if UNI-C chose other UNI-N, path would have been more optimal.

Example – draft-zhang-ccamp-gmpls-uni-app-05 Figure 1



EN1 sets up an LSP1 EN1-CN1-CN2-CN3-EN3

EN2 wants an LSP2 to EN4 that is link-disjoint from the first LSP.

                Using some tiebreakerEN2 decides to signal setup to CN1 and not to CN4, following path is set up:  EN2-CN1-CN4-CN5-EN4 . If CN4 was asked, more optimal path would have been used: EN2-CN4-CN5-EN4.


4.       Likelihood of crankbacks increases when there are multiple links between UNI-C and UNI-N and UNI-N is a blocking switch.

Example:
                There are 3 access links between UNI-C and UNI-N: link1, link2 and link3. Since there are switching constraints on UNI-N, diverse path can only be supplied via link2. If UNI-C chooses link1 in signalling, we have a crankback.

From: Adrian Farrel [mailto:adrian@olddog.co.uk]
Sent: Monday, March 10, 2014 4:48 PM
To: Paweł Brzozowski
Cc: 'CCAMP'
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hello 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.

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<mailto: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 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




_______________________________________________

CCAMP mailing list

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

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