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

"Zafar Ali (zali)" <zali@cisco.com> Wed, 09 October 2013 07:54 UTC

Return-Path: <zali@cisco.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 25CB221E80D5 for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 00:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_HI=-8]
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 ynuOzozjsL7y for <ccamp@ietfa.amsl.com>; Wed, 9 Oct 2013 00:53:59 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 56B9721F9D17 for <ccamp@ietf.org>; Wed, 9 Oct 2013 00:53:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14742; q=dns/txt; s=iport; t=1381305239; x=1382514839; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7RWkPCoAMUiJPF0ikudXMeZd10cq/jPZHeNCsoVloHI=; b=Nld2c3YoIG62izoP+UPaNZPcr9Z36Wk/LZYYFXtkrMlhzOvt7knyoH4F IjApE+twRiNAWXy4W4rFAnGjjTXTIAw6F6FEp5JcSTUdx/AJNRBv275Hh ag1lNNvlBm9Xydv3lDt/BVWvOIvcgt8VXMUF64K3XFBbqQgw/JDMtrV8s s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAAAKVVKtJXHB/2dsb2JhbABagwc4UoMovgoXgQkWdIIlAQEBBAEBASAROgsMBgEGAhEDAQEBAwIGGQQDAgQlCxQBCAgCBAENBQgBEodrDIo5m1ySPIEpjWkCFhsHBoJkNYEEA5kykFKBZoE+gio
X-IronPort-AV: E=Sophos;i="4.90,1062,1371081600"; d="scan'208";a="269936377"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-4.cisco.com with ESMTP; 09 Oct 2013 07:53:36 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r997rZXd015323 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 9 Oct 2013 07:53:35 GMT
Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 9 Oct 2013 02:53:35 -0500
From: "Zafar Ali (zali)" <zali@cisco.com>
To: 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/mpvpLKMUWgFOTvGxqewIiE5jbQEWRmkQABjHHYAAEh8IgAAGSCKAAAmjooD//745AIAARJEA///HfwCAAEx3gP//xVaA
Date: Wed, 09 Oct 2013 07:53:34 +0000
Message-ID: <B6585D85A128FD47857D0FD58D8120D30F6553DC@xmb-rcd-x14.cisco.com>
In-Reply-To: <F82A4B6D50F9464B8EBA55651F541CF85CA784BD@SZXEMA504-MBS.china.huawei.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.247.60]
Content-Type: text/plain; charset="utf-8"
Content-ID: <C9AAC6B2D8792D4C968811B7D8FFB6A5@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 07:54:04 -0000

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-exclusion
>>>>>>-
>>>>>>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/?inclu
>>>>>>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-route
>>>>>>/
>>>>>>?
>>>>> >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
>>
>