Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes

Daniele Ceccarelli <daniele.ceccarelli@ericsson.com> Wed, 09 October 2013 15:14 UTC

Return-Path: <daniele.ceccarelli@ericsson.com>
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B82DF21E8096 for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 08:14:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.032
X-Spam-Level:
X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.216, BAYES_00=-2.599, HELO_EQ_SE=0.35, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKfGBVbGCZDK for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 08:13:58 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB45521E8138 for <ccamp@ietf.org>; Wed, 9 Oct 2013 08:13:53 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-b0-525572b02ec3
Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 32.62.16099.0B275525; Wed, 9 Oct 2013 17:13:52 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.119]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.02.0328.009; Wed, 9 Oct 2013 17:13:52 +0200
From: Daniele Ceccarelli <daniele.ceccarelli@ericsson.com>
To: "Zafar Ali (zali)" <zali@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>, "CCAMP (ccamp@ietf.org)" <ccamp@ietf.org>
Thread-Topic: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes
Thread-Index: Ac6/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAA3PwgAAOqg0AAAFBt4AAACltgAAAL9UAAAFRz4AAAS0BgAABDKsAABLiYRA=
Date: Wed, 09 Oct 2013 15:13:51 +0000
Message-ID: <4A1562797D64E44993C5CBF38CF1BE481627D6@ESESSMB301.ericsson.se>
References: <F82A4B6D50F9464B8EBA55651F541CF85CA784BD@SZXEMA504-MBS.china.huawei.com> <B6585D85A128FD47857D0FD58D8120D30F6553DC@xmb-rcd-x14.cisco.com>
In-Reply-To: <B6585D85A128FD47857D0FD58D8120D30F6553DC@xmb-rcd-x14.cisco.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvre6GotAgg4u7TS2ezLnBYvF6x1d2 i8XbOlks+prPszqweEz5vZHVo+XIW1aPJUt+MgUwR3HZpKTmZJalFunbJXBlfHl2ialgQh9j xZZDx5gbGPd0MXYxcnJICJhI3D37E8oWk7hwbz0biC0kcJhRom2LRBcjF5C9mFFi5vyXQEUc HGwCVhJPDvmAxEUEljNKLP95iR2kQVigTOLR6qtgzSIC5RIzfm9jhLDLJL7df8ICYrMIqEi0 nG8As3kFvCUWLD3JDLFgBqPE1MmHwZo5BXwlfv1tBmtmFJCVmLB7EZjNLCAucevJfCaISwUk luw5zwxhi0q8fPyPFcJWlPj4ah/YocwCmhLrd+lDtCpKTOl+yA6xV1Di5MwnLBMYRWchmToL oWMWko5ZSDoWMLKsYmTPTczMSS833MQIjJWDW37r7mA8dU7kEKM0B4uSOO+Ht85BQgLpiSWp 2ampBalF8UWlOanFhxiZODilGhi1zj0NbZeTPv3N/tDuzEiLGyddHVVePeOvv69xjzczSPGf yTLz5Nhw77+Mk6LX6VTX1WpVJid8ShBLvFUhaSq+r9v78wSjANZpH4QdC7fdfXTm5UVnaXaB e5WPHSvPrEvwuvD37vriRGuGpksc08svn/i9/tdUs09/befpln6+spih9cWZjRFKLMUZiYZa zEXFiQB142LOYwIAAA==
Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Routes
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 09 Oct 2013 15:14:03 -0000

Hi Zafar,

That's one of the reasons why I prefer the path key approach with the path stateful PCE (or whatever we call it, I don't care).
In this example, where R are the routers and O the optical nodes how does the LSP diversity mechanisms work?

                   UNI                                  UNI
R1 --- R2 -------O1----O2----O3-----R4----R5
      \                       |          |           |                  /
        \ R3 -------O4-----O5----O6-----R6 /
                  UNI                                   UNI

In the case of LSP diversity the only way i understand things can work is.
1. I setup a working path R1-R2-O1-O2-O3-R4-R5. 
2. R1 somehow collects the 5ple of LSP O1-O2-O3
3. R1 wants to setup a protection path in diversity and asks R3 to ask O4 for a path in diversity re the 5ple of O1-02-03
4. how can O4 resolve that the nodes/link corresponding to the 5ple are O1-O2-O3? It is not possible. The only way is a hop by hop check with cranckback if the signaling generated from O4 goes through a node among O1-O2-O3.

If there are no RSVP states in the nodes, how can it work? The path key should work in that case.

Please correct any mistake in the procedure I wrote above (btw a procedure, even in example or appendix, in your draft could be helpful)

Thanks
Daniele


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Zafar Ali (zali)
> Sent: mercoledì 9 ottobre 2013 09:54
> To: Fatai Zhang; Zhangxian (Xian); CCAMP (ccamp@ietf.org)
> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> (RSVP-TE) Path Diversity using Exclude Routes
> 
> Fatai and John:
> 
> In most of the cases, when the UNI-N node computing the path is also
> hosting the RSVP-TE FEC against which exclusion is required, it knows the
> path take by the other LSP. For the other cases, please note that just
> because optical network is running GMPLS UNI for client interface does not
> mean that it is running RSVP-TE for the optical trail management. E.g., optical
> trail management can still using an already deployed proprietary mechanisms
> or an NMS based scheme. The draft is addressing schemes that are capable
> of this functionality.
> 
> Fatai:
> 
> Need for the path keys in XRO scheme requiring PCE to remember the (path
> key, path info) "states" for "indefinite" time and scaling restriction of the
> solution I mentioned in my email is not a matter of terminology or
> philosophy. You are introducing new permanent states at PCE.
> 
> Thanks
> 
> Regards … Zafar
> 
> 
> -----Original Message-----
> From: Fatai Zhang <zhangfatai@huawei.com>
> Date: Wednesday, October 9, 2013 3:23 AM
> To: zali <zali@cisco.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>,
> "ccamp@ietf.org" <ccamp@ietf.org>
> Cc: "jdrake@juniper.net" <jdrake@juniper.net>
> Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> (RSVP-TE) Path Diversity using Exclude Routes
> 
> >Hi Zafar,
> >
> >This is operator's policy, and timer can help as what RFC5520 and RFC
> >5553 defined.
> >
> >I really don't want to spend my time on discussing the terminology or
> >philosophy (on what is stateful PCE), but I more care about how your
> >draft can work.
> >
> >Could you clarify John's question below (it is also my question)?
> >How does your draft work in the real implementation? Who can interpret
> >the *LSP identifier* (5ple) defined in your draft?
> >
> >=========================================================
> ==============
> >=== ====================================================
> >>>"The means by which the node calculating or expanding the route of
> >>>the signaled LSP discovers the route of the path(s) from which the
> >>>signaled LSP requires diversity are beyond the scope of this
> >>>document. "
> >
> >>>Doesn't this disclaimer effectively render this draft useless? The
> >>>draft also does not define how the node that initially signaled the
> >>>LSP finds the 'node calculating or expanding the route'
> >>>nor how it delivers the signaled LSP request to that node.
> >
> >
> >
> >Best Regards
> >
> >Fatai
> >
> >
> >-----Original Message-----
> >From: Zafar Ali (zali) [mailto:zali@cisco.com]
> >Sent: Wednesday, October 09, 2013 2:50 PM
> >To: Fatai Zhang; Zhangxian (Xian); CCAMP (ccamp@ietf.org)
> >Cc: John E Drake
> >Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> >(RSVP-TE) Path Diversity using Exclude Routes
> >
> >Fatai-
> >
> >In RFC 5520 and RFC5553, PCE is only expected to keep the (path key,
> >Path
> >info) state for only a short amount of time. Time that is required to
> >signal an LSP provides an upper bound on the time the (path key, Path
> >info) state needs to be stored by the PCE. The RFC5520 specifically
> >talks about path key expiration and is purged. 16 bit path keys are
> >used as reuse of the path key is assumed.
> >
> >In your draft the PCE needs to remember the (path key, path info) "states"
> >for "indefinite" time. If you like we call such PCE "path-stateful PCE"
> >but it is stateful. Also, the solution is not scalable as a PCE can
> >only hold 64K of (path key, path info) states.
> >
> >Thanks
> >
> >Regards … Zafar
> >
> >
> >-----Original Message-----
> >From: Fatai Zhang <zhangfatai@huawei.com>
> >Date: Wednesday, October 9, 2013 2:12 AM
> >To: zali <zali@cisco.com>, "Zhangxian (Xian)" <zhang.xian@huawei.com>,
> >"ccamp@ietf.org" <ccamp@ietf.org>
> >Cc: "jdrake@juniper.net" <jdrake@juniper.net>
> >Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> >(RSVP-TE) Path Diversity using Exclude Routes
> >
> >>Hi Zafar,
> >>
> >>Really interesting for your assertion.
> >>
> >>Did you mean that RFC 5520 is specific for stateful PCE?
> >>
> >>In additon, please look at "Control of Function through Configuration
> >>and Policy" of RFC 5520 and RFC5553.
> >>
> >>
> >>Best Regards
> >>
> >>Fatai
> >>
> >>
> >>-----Original Message-----
> >>From: Zafar Ali (zali) [mailto:zali@cisco.com]
> >>Sent: Wednesday, October 09, 2013 2:07 PM
> >>To: Zhangxian (Xian); CCAMP (ccamp@ietf.org)
> >>Cc: John E Drake; Fatai Zhang
> >>Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> >>(RSVP-TE) Path Diversity using Exclude Routes
> >>
> >>Hi Zhangxian:
> >>
> >>State does not always means RSVP TE states in the network. PCE (sever)
> >>needs to remember path information (possibly with other path
> >>attributes) it computed for indefinite time. These are states that PCE
> >>needs to remember. Hence, stateful PCE.
> >>
> >>Thanks
> >>
> >>Regards … Zafar
> >>
> >>
> >>-----Original Message-----
> >>From: "Zhangxian   (Xian)" <zhang.xian@huawei.com>
> >>Date: Wednesday, October 9, 2013 2:02 AM
> >>To: zali <zali@cisco.com>, "ccamp@ietf.org" <ccamp@ietf.org>
> >>Cc: "jdrake@juniper.net" <jdrake@juniper.net>, Fatai Zhang
> >><zhangfatai@huawei.com>
> >>Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic Engineering
> >>(RSVP-TE) Path Diversity using Exclude Routes
> >>
> >>>Hi, Zafar,
> >>>
> >>>    Thank you for sharing the thoughts. But I cannot agree with what
> >>>you said below.
> >>>
> >>>    Path key solution does not necessarily need the presence of a
> >>>stateful PCE. Similarly with RFC5553, the path key owner needs to
> >>>retain this information so that I can interpret when used at a later time.
> >>>Retaining such information does not equal to a stateful PCE which
> >>>needs to know the LSP states of the whole network it serves.
> >>>
> >>>Regards,
> >>>Xian
> >>>
> >>>-----Original Message-----
> >>>From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> >>>Behalf Of Zafar Ali (zali)
> >>>Sent: 2013年10月9日 13:26
> >>>To: John E Drake; Fatai Zhang; CCAMP (ccamp@ietf.org)
> >>>Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic
> >>>Engineering
> >>>(RSVP-TE) Path Diversity using Exclude Routes
> >>>
> >>>Hi John:
> >>>
> >>>No, RFC 5520/ RFC5533 are fine. The issue is that solution proposed
> >>>by draft-zhang-ccamp-route-exclusion-pathkey-00.txt forces customers
> >>>to deploy a stateful PCE where PCE need to remember path it has
> >>>served for indefinite time.
> >>>
> >>>Thanks
> >>>
> >>>Regards ... Zafar
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: "jdrake@juniper.net" <jdrake@juniper.net>
> >>>Date: Tuesday, October 8, 2013 6:26 PM
> >>>To: zali <zali@cisco.com>, Fatai Zhang <zhangfatai@huawei.com>,
> >>>"ccamp@ietf.org" <ccamp@ietf.org>
> >>>Subject: RE: [CCAMP] Resource ReserVation Protocol-Traffic
> >>>Engineering
> >>>(RSVP-TE) Path Diversity using Exclude Routes
> >>>
> >>>>Zafar,
> >>>>
> >>>>So, is your assertion that RFC5553 is broken?
> >>>>
> >>>>Yours Irrespectively,
> >>>>
> >>>>John
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Zafar Ali (zali) [mailto:zali@cisco.com]
> >>>>> Sent: Tuesday, October 08, 2013 10:47 AM
> >>>>> To: Fatai Zhang; John E Drake; CCAMP (ccamp@ietf.org)
> >>>>> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic
> >>>>>Engineering
> >>>>> (RSVP-TE) Path Diversity using Exclude Routes
> >>>>>
> >>>>> Fatai and all-
> >>>>>
> >>>>> In a stateless PCE, Path Keys are transient and they expire. For
> >>>>>this solution  to work you need a PCE that can keep Paths
> >>>>>associated with a Path Key  around (a stateful PCE where states are
> >>>>>path computed by the PCE).
> >>>>>
> >>>>> Thanks
> >>>>>
> >>>>> Regards Š Zafar
> >>>>>
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: Fatai Zhang <zhangfatai@huawei.com>
> >>>>> Date: Tuesday, October 8, 2013 3:01 AM
> >>>>> To: "jdrake@juniper.net" <jdrake@juniper.net>, "ccamp@ietf.org"
> >>>>> <ccamp@ietf.org>
> >>>>> Subject: Re: [CCAMP] Resource ReserVation Protocol-Traffic
> >>>>>Engineering
> >>>>> (RSVP-TE) Path Diversity using Exclude Routes
> >>>>>
> >>>>> >Hi John,
> >>>>> >
> >>>>> >Totally agree with you, I already found these two drafts are much
> >>>>> >*useless*.
> >>>>> >
> >>>>> >This is why we made a new draft (very simple and useful) and put
> >>>>> >our feet on the ground.
> >>>>> >
> >>>>>
> >>>>>>http://www.ietf.org/internet-drafts/draft-zhang-ccamp-route-
> exclus
> >>>>>>ion
> >>>>>>-
> >>>>>>p
> >>>>> >ath
> >>>>> >key-00.txt
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >
> >>>>> >Best Regards
> >>>>> >
> >>>>> >Fatai
> >>>>> >
> >>>>> >
> >>>>> >-----Original Message-----
> >>>>> >From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
> On
> >>>>> Behalf
> >>>>> >Of John E Drake
> >>>>> >Sent: Thursday, October 03, 2013 2:27 AM
> >>>>> >To: CCAMP (ccamp@ietf.org)
> >>>>> >Subject: [CCAMP] Resource ReserVation Protocol-Traffic
> >>>>> >Engineering
> >>>>> >(RSVP-TE) Path Diversity using Exclude Routes
> >>>>> >
> >>>>> >HI,
> >>>>> >
> >>>>> >I was reading:
> >>>>>
> >>>>>>http://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity/?in
> >>>>>>clu
> >>>>>>d
> >>>>>>e
> >>>>> >_te xt=1, and I happened to notice the following paragraph:
> >>>>> >
> >>>>> >"The means by which the node calculating or expanding the route
> >>>>> >of
> >>>>>the
> >>>>> >signaled LSP discovers the route of the path(s) from which the
> >>>>>signaled
> >>>>> >LSP  requires diversity are beyond the scope of this document. "
> >>>>> >
> >>>>> >Doesn't this disclaimer effectively render this draft useless?
> >>>>> >The draft also does not define how the node that initially
> >>>>> >signaled the
> >>>>>LSP
> >>>>> >finds the 'node calculating or expanding the route'  nor how it
> >>>>> >delivers the signaled LSP request to that node.
> >>>>> >
> >>>>> >As an aside, the draft:
> >>>>>
> >>>>>>http://datatracker.ietf.org/doc/draft-ali-ccamp-rsvp-te-include-ro
> >>>>>>ute
> >>>>>>/
> >>>>>>?
> >>>>> >inc
> >>>>> >lude_text=1 would be subject to the same criticism except that
> >>>>> >the above quoted paragraph is replaced with:
> >>>>> >
> >>>>> >"The above-mentioned use cases require relevant path inclusion
> >>>>> >requirements to be communicated to the route expanding nodes.
> >>>>> >This document addresses  these requirements and defines
> >>>>> >procedures to address them."
> >>>>> >
> >>>>> >Even though this is helpful, the draft doesn't actually define
> >>>>> >these procedures.
> >>>>> >
> >>>>> >Yours Irrespectively,
> >>>>> >
> >>>>> >John
> >>>>> >
> >>>>> >
> >>>>> >_______________________________________________
> >>>>> >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
> >>
> >
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp