Re: [CCAMP] OVRLY - signaling extensions

"Zafar Ali (zali)" <zali@cisco.com> Fri, 21 March 2014 23:31 UTC

Return-Path: <zali@cisco.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 994A11A0720 for <ccamp@ietfa.amsl.com>; Fri, 21 Mar 2014 16:31:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.146
X-Spam-Level:
X-Spam-Status: No, score=-14.146 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 3jZoneMxfA8M for <ccamp@ietfa.amsl.com>; Fri, 21 Mar 2014 16:31:04 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id EC8811A0444 for <ccamp@ietf.org>; Fri, 21 Mar 2014 16:31:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=187969; q=dns/txt; s=iport; t=1395444655; x=1396654255; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=cIo1zYQR5XxxaUzN6M5pWqHRsbQ68KyQ4IJq13Mi/Pw=; b=RqxrP/9mlG909pP4v9nC7fZ++KEEqC2tKzFCVEdanSQ2T0SkgE1Kqia8 cNJBqYEyGIJ4SMxZNc4oN1mCVg6ashcLuXyEEJeulE5JzGy6+LteSomx9 rDPR1riUMtuZhYA1mFKmOQDMaTYan+pylXVNr60BqM2N4H6fyB1ZugINS I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnYFAJHKLFOtJXHA/2dsb2JhbABQCYJCRDtXgwe2ZYE9hzoZgQEWdIIlAQEBBAEBARcBCAo7BgsMBgEGAhEBAgEBASEBBgMCBCULFAMGCAIEAQ0FGwSHWg2QU5wXolAXjX0LBwMHARkMBwkKDQQGAQIEgmmBSQSUXYNsgTKQf4MtgWkJFyI
X-IronPort-AV: E=Sophos; i="4.97,706,1389744000"; d="scan'208,217"; a="309035106"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 21 Mar 2014 23:30:53 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2LNUq6C002695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Mar 2014 23:30:52 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.171]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Fri, 21 Mar 2014 18:30:52 -0500
From: "Zafar Ali (zali)" <zali@cisco.com>
To: =?utf-8?B?UGF3ZcWCIEJyem96b3dza2k=?= <PBrzozowski@advaoptical.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, Gert Grammel <ggrammel@juniper.net>
Thread-Topic: [CCAMP] OVRLY - signaling extensions
Thread-Index: Ac85YJDrYXZOuOMaR1Gk+fcsuXhJCgBBUEbQAA/KqYAAVq5wAAAJzQ4AACk+9wAAKDZ4gAAAnTUAAIEkdoAAqOzPAAAC1RcAAABMlwAAWhmCAAAPwBuAAANXCIAAaGIaAP//2IAA
Date: Fri, 21 Mar 2014 23:30:51 +0000
Message-ID: <CF523707.A3CA3%zali@cisco.com>
In-Reply-To: <621d7a129eff4f0bb6c2533b5d4e24d0@MUC-SRV-MBX1.advaoptical.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.82.225.190]
Content-Type: multipart/alternative; boundary="_000_CF523707A3CA3zaliciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/T4Oxn6TfVAxu_kBW9jym3Dh_AEo
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, 21 Mar 2014 23:31:11 -0000

Pawel-

RFC4920 is not used at the UNI interface but within the core network. One other thing that there are use cases for sequential as well as concurrent path computations.

Thanks

Regards … Zafar

From: Paweł Brzozowski <PBrzozowski@advaoptical.com<mailto:PBrzozowski@advaoptical.com>>
Date: Friday, March 21, 2014 5:56 PM
To: zali <zali@cisco.com<mailto:zali@cisco.com>>, "Zhangxian (Xian)" <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>, Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: RE: [CCAMP] OVRLY - signaling extensions

Zafar,

I would really appreciate if you could answer the two questions below.

Let’s assume that signaling alone (supporting RFC4920) is used at the client-network boundary (to be very exact, there is no TE exchange, no PCEP at the boundary).
Assuming this, do you believe that for multi-homed clients, irrespective of network’s topology, it’s possible to request some number of diverse paths and:


a)      Come up with paths, which are most optimal every time.



b)      Fail to provide the paths, because of the sequence they were requested in.


Thanks,
Pawel

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, March 19, 2014 8:03 PM
To: Paweł Brzozowski; Zhangxian (Xian); Gert Grammel
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Powel-

Re: Multi-homed clients’ deficiencies via extensions to signaling: Please note that Multi-homed clients, in this case, are addressed via vanilla RFC4920 (Crankback Signaling).

Thanks

Regards … Zafar

From: Paweł Brzozowski <PBrzozowski@advaoptical.com<mailto:PBrzozowski@advaoptical.com>>
Date: Wednesday, March 19, 2014 2:31 PM
To: "Zhangxian (Xian)" <zhang.xian@huawei.com<mailto:zhang.xian@huawei.com>>, Gert Grammel <ggrammel@juniper.net<mailto:ggrammel@juniper.net>>
Cc: "ccamp@ietf.org<mailto:ccamp@ietf.org>" <ccamp@ietf.org<mailto:ccamp@ietf.org>>
Subject: Re: [CCAMP] OVRLY - signaling extensions

Gert, Xian,

I’m sorry to hear that the terminology I used confused you. Please find my e-mail with, hopefully less confusing terminology below.

On the side note, I believe that e-mail exchange on the group does not push us in any direction. It really does seem people are sending e-mails just for the sake of conversation. If you are interested in discussing the points I’ve raised, I’ll be happy to have a conference call with you. If not, no problem than, let’s just forego this topic.

Regards,
Pawel

“
I believe everybody agrees that there is a need in signaling for indication that “this service should be diverse from services/paths A-Z”, since it is a generic extension. It is needed regardless of the protocols used on the client-network boundary (signaling only/signaling+TE exchange/signaling+PCEP/signaling+TE exchange+PCEP), as it could be used by the network to maintain service diversity throughout the lifetime of the services (e.g. network would use this information when performing restoration).

Depending on the protocols used on the client-network boundary, there are different possibilities to achieve service diversity upon setups. Obviously, the more information is available through the interface, the better are the results. I believe that use of TE exchange (see "te-info-exchange" draft) and/or use of PCEP(see draft-zhang-ccamp-gmpls-uni-app) provides sufficient information to overcome limitations I listed in my previous e-mail. If PCEP is used on the boundary, network’s PCE should be sophisticated enough to handle inter-layer path computation if access and network links are in different layers. Having said that, I see the reasoning for trying to use signaling only to achieve some diversity functionality. I assume there are existing RFC4208 deployments, where adding additional protocols in the near future is simply a fairy tale. Those deployments would clearly benefit from clients being able to request diverse paths, even if in limited manner. It makes perfect sense to me, especially since I believe that the diversity signaling extension is needed anyway.

I agree with Adrian, from architectural perspective, there needs to be a line beyond which putting steroids into a protocol becomes a mess. E.g. I hope there will be no attempts to overcome multi-homed clients’ deficiencies via extensions to signaling.”

From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: Wednesday, March 19, 2014 7:01 AM
To: Paweł Brzozowski; Gert Grammel
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

I am surprised to see “UNI+PCEP” too. UNI is an interface while PCEP is a protocol, how they can be added together and in parallel with UNI/ENNI?

I cannot agree more with What Gert said: “Going forward, we shouldn’t mess up with the term and instead focus on solving the case.”  The intention of draft-zhang-ccamp-gmpls-uni-app is not trying to add confusion, but rather trying to explain existing mechanisms/protocols can help, on a case-by-case basis, within the context of RFC4208 without protocol extensions (Do not want to touch that sensitive term again, ☺).

Regards,
Xian

From: Paweł Brzozowski [mailto:PBrzozowski@advaoptical.com]
Sent: 2014年3月18日 0:01
To: Gert Grammel; Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Gert,

I was referring to draft-zhang-ccamp-gmpls-uni-app. UNI, PCE and PCEP terms are used all over the place ☺

Cheers,
Pawel

From: Gert Grammel [mailto:ggrammel@juniper.net]
Sent: Monday, March 17, 2014 11:52 AM
To: Paweł Brzozowski; Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi Pavel,

the term ‚UNI+PCEP‘ you’ve just used is again interesting. As terms like UNI, E-NNI and I-NNI are terms used in ITU-T documents, I did a quick check. Here what Rec. ITU-T G.8080/Y.1304 (02/2012) has to say about the case:

Route query interface: This interface accepts an unresolved route element and returns a route. An
RC may query another RC (or RCs) in parent or child routing areas to assist in resolving the route.
Examples of query results are:
1)  Return an egress SNPP on this subnet that is on a path to a given destination SNPP.
2)  Return  a  sequence  of  subnetworks  that  form  a  path  between  a  given  source/destination
SNPP pair.
3)  Return a sequence of subnetworks that form a path between two sets of SNPPs.
4)  Return  a  sequence  of  SNPPs  that  form  a path  between  a  given  source/destination  SNPP
pair.
5)  Return a sequence of SNPPs that form a path between a given source/destination SNPP pair
and includes one or more specific SNPPs.
6)  Return a sequence of SNPPs that form a path between a given source/destination SNPP pair
that is diverse from a given path.

And also this:
NOTE – The route query interface does not apply for the CC interface at the UNI reference point.

In other words the statement “UNI + PCEP == UNI” can only be true if “PCEP == NULL”.


So it would be better to distinguish between the use case (diversity) and the term UNI. Going forward, we shouldn’t mess up with the term and instead focus on solving the case.

Best

Gert

From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Pawel Brzozowski
Sent: 17 March 2014 15:31
To: Zhangxian (Xian); Vishnu Pavan Beeram
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Xian,

I believe everybody agrees that there is a need in signaling for indication that “this service should be diverse from services/paths A-Z”, since it is a generic extension. It is needed regardless of the client-network interface type (UNI/ENNI/UNI+PCEP), as it could be used by the network to maintain service diversity throughout the lifetime of the services (e.g. network would use this information when performing restoration).

Depending on the client-network interface type, there are different possibilities to achieve service diversity upon setups. Obviously, the more information is available through the interface, the better are the results. I believe that both ENNI and UNI+PCEP provide sufficient information to overcome limitations I listed before (which I believe should answer your questions). In UNI+PCEP case, network’s PCE should be sophisticated enough to handle inter-layer path computation if access and network links are in different layers. Having said that, I see the reasoning for trying to augment “blind UNI” (i.e. no PCEP/TE) with some diversity functionality. I assume there are existing GMPLS UNI deployments, where adding additional protocols in the near future is simply a fairy tale. Those deployments would clearly benefit from clients being able to request diverse paths, even if in limited manner. It makes perfect sense to me, especially since I believe that the diversity signaling extension is needed anyway.

I agree with Adrian, from architectural perspective, there needs to be a line beyond which putting steroids into a protocol becomes a mess. E.g. I hope there will be no attempts to overcome multi-homed UNI deficiencies via UNI-specific signaling extensions.

Regards,
Pawel

From: Zhangxian (Xian) [mailto:zhang.xian@huawei.com]
Sent: Friday, March 14, 2014 1:55 AM
To: Vishnu Pavan Beeram; Paweł Brzozowski
Cc: CCAMP
Subject: RE: [CCAMP] OVRLY - signaling extensions

Hi, Pavan, Pawel,

   I agree with the point Pavan added; it is yet another proposal that can solve connection request with diversity constraints. The difference(neither advantage nor disadvantage) lies in that it needs server layer provides necessary information and the computation action is performed by the client nodes.  While the rest lives with the constraint that only RSVP-TE message flow through UNI interface (as defined by RFC4208), and the computation is done separately if necessary or purely by the server layer.  The draft (draft-dios-ccamp-control-models-customer-provider<http://tools.ietf.org/id/draft-dios-ccamp-control-models-customer-provider-00.txt>) provides a very good summary of the control models, which cover both cases.

   I have some comments to the list of points Pawel made in his email,  starting with [Xian] inline:

  Note the key point I want to make here is NOT what is right or wrong, but THAT different assumptions flying around resulting in preference of different solutions, IMHO.


From: CCAMP [mailto:ccamp-bounces@ietf.org] On Behalf Of Vishnu Pavan Beeram
Sent: 2014年3月12日 0:17
To: Paweł Brzozowski
Cc: CCAMP
Subject: Re: [CCAMP] OVRLY - signaling extensions

Pawel, Hi!

You wrote:
"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. "

The underlined portion isn't totally true. Is it? The te-abstraction model discussed in Adrian's "te-info-exchange" draft (this model is currently under CCAMP's purview) does talk about advertising fate-sharing information along with the abstracted topological elements. And this would ensure that the diverse paths get computed concurrently by the CE node.

I couldn't agree more with the rest of your statements.

Regards,
-Pavan
On Tue, Mar 11, 2014 at 11:59 AM, Paweł Brzozowski <PBrzozowski@advaoptical.com<mailto:PBrzozowski@advaoptical.com>> wrote:
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.

 [Xian]: I think the point you are trying to make here is: computation together is superior than computation sequentially(with a high probability) under all situations, right? If so, I think it is necessarily true.

 I agree with the first point you made and it is based on the assumption that both connections are request as the same time. Under such assumption, it would make much better sense to computer together rather than sequentially. But it does not rule out the possibility that a node will initiate a new connection request, which requires to be diversified with a existing connection.  Again, for the second point, agreed but it really depends on the information availability to the node making the decision. If the client nodes is blind, then such claim does not hold true anymore.

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.

[Xian]: Well, the example you provide is true since there is limitation assumed here. What you explained is how exactly it works, ☺. Let me try to understand the point you are trying to make: do you imply that “”no TE visibility over UNI” is a bad thing, we should force every deployment to share information? What about the deployment already following RFC4208?

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.
[Xian]: Comments to Point 2 applies to these two points. Another point i would like to make, as mentioned in Section 4.1 of [UNI-APP], there is another possible solution (without leaking information fromt the server layer to the client layer), i.e. to use PCE.  This can be supported the work done in PCE WG (such as RFC5623, RFC6457 anddraft-ietf-pce-inter-layer-ext<http://tools.ietf.org/wg/pce/draft-ietf-pce-inter-layer-ext/>)/>).
Regards,
Xian

From: Adrian Farrel [mailto:adrian@olddog.co.uk<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>xt>.


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