Re: [CCAMP] OVRLY - signaling extensions

Vishnu Pavan Beeram <vishnupavan@gmail.com> Tue, 11 March 2014 16:16 UTC

Return-Path: <vishnupavan@gmail.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 8A40B1A0473 for <ccamp@ietfa.amsl.com>; Tue, 11 Mar 2014 09:16:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, 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 G_Sezlf5564D for <ccamp@ietfa.amsl.com>; Tue, 11 Mar 2014 09:16:54 -0700 (PDT)
Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8B01A077F for <ccamp@ietf.org>; Tue, 11 Mar 2014 09:16:53 -0700 (PDT)
Received: by mail-wi0-f180.google.com with SMTP id hm4so1137134wib.1 for <ccamp@ietf.org>; Tue, 11 Mar 2014 09:16:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lu0+MM55rj+kFb3BEr904llR6KeHcrOpNGv1EZiK+Ew=; b=FI3xe8KFiD4D6yU7QEbHTAWP4z8dQcDoeVCA7bJ8Kevr0mBaas3FF/MOj8xyhGCQzL q4goZU7OoFlvUnTan7hnmIQmQgo7R+mZ7hqm20oWFE4+CzggzMXKucs3s0ViToHwhlOM 7eFeqmDYN0RnNdMLPU9PMBgRX1uYofskm3CaGow3B0aSEE8++KNT+cQiKrHzzOVNmIG2 fYyrmtQHelQyi2N08udpLy/j+pfNxDUy9DOuqM6QjuhNc2IjUIxmsmKKi5rZo950HuCM /Pu2Yf8YmuITU3l/u6FtoGBZungfaEjQXziZq776dyFsUgo5fEc6ueNacJqH9w1Du4eC Ny7Q==
MIME-Version: 1.0
X-Received: by 10.194.62.206 with SMTP id a14mr38364771wjs.26.1394554606998; Tue, 11 Mar 2014 09:16:46 -0700 (PDT)
Received: by 10.194.79.170 with HTTP; Tue, 11 Mar 2014 09:16:46 -0700 (PDT)
In-Reply-To: <7d1ddc68ad6b4e2d9c5acf3dc2ea1e39@MUC-SRV-MBX1.advaoptical.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> <8f71d3e2fb1f47e7858721caf9f894a7@MUC-SRV-MBX1.advaoptical.com> <16a401cf3ca2$00152cf0$003f86d0$@olddog.co.uk> <7d1ddc68ad6b4e2d9c5acf3dc2ea1e39@MUC-SRV-MBX1.advaoptical.com>
Date: Tue, 11 Mar 2014 12:16:46 -0400
Message-ID: <CA+YzgTty-DyVZeAAHg-HJ=zNXSgUhn-kNx3SMOP5fj4JGrbSpQ@mail.gmail.com>
From: Vishnu Pavan Beeram <vishnupavan@gmail.com>
To: =?ISO-8859-2?Q?Pawe=B3_Brzozowski?= <PBrzozowski@advaoptical.com>
Content-Type: multipart/alternative; boundary=047d7b66f8e1f85c6f04f4570bd7
Archived-At: http://mailarchive.ietf.org/arch/msg/ccamp/I-Eu1NrZbyQxntX7M9GYkzRsuwI
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 16:16:59 -0000

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