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
- [CCAMP] Resource ReserVation Protocol-Traffic Eng… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Daniele Ceccarelli
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zhangxian (Xian)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zhangxian (Xian)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Margaria, Cyril (Coriant - DE/Munich)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Fatai Zhang
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Daniele Ceccarelli
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… Zafar Ali (zali)
- Re: [CCAMP] Resource ReserVation Protocol-Traffic… John E Drake