Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi Zafar,

The IGP was merely an example.

The document does propose a simple set of extension that works (but are not
restricted to, nor require) with another standard IETF protocol, namely
PCEP.

In order to support LSP diversity, a mechanism to exchange the path used by
a LSP on another node is needed.
I recall that the point of the complain was that without specifying that
protocol the draft cannot be implemented without extra protocol work, and I
believe that draft-ietf-ccamp-lsp-diversity would require new proprietary
protocol to be specified for that purpose.

The approach used in draft-zhang-ccamp-route-exclusion-pathkey does not
require a new proprietary protocol, you may use a PCE and PCEP (colocated
in each PE). This can be implemented using IETF protocols, but its not
limited to them.
draft-zhang-ccamp-route-exclusion-pathkey allows for any other deployment,
with and without PCE.

The document address networks with PCE and without PCE.

Best regards,
Cyril

On 20 February 2014 22:13, Zafar Ali (zali) <zali@cisco.com> wrote:

>  Hi Cyrill-
>
>  This is funny - when we had an out-of-scope statement
> in draft-ietf-ccamp-lsp-diversity, authors and support
> of draft-zhang-ccamp-route-exclusion-pathkey starts complaining. Flying in
> similar statement is all of sudden fine? If you go with flooding PKS, what
> wrong with flooding RSVP-TE FEC?
>
>  Thanks
>
>  Regards ... Zafar
>
>   From: Cyril Margaria <cyril.margaria@gmail.com>
> Date: Thursday, February 20, 2014 3:49 PM
>
> To: zali <zali@cisco.com>
> Cc: "Zhangxian (Xian)" <zhang.xian@huawei.com>, "ccamp@ietf.org" <
> ccamp@ietf.org>
> Subject: Re: [CCAMP] FW: New Version Notification for
> draft-zhang-ccamp-route-exclusion-pathkey-01.txt
>
>     Hi Zafar:
>
>  The point is that to resolve the PKS you MAY use PCEP, or any other
> method you see fit.
>  On the last proposed implementation, you may also replace 'PCE' by 'Node
> generating the PKS',
>
>  If one see fit to flood the PKS in its IGP or have the management system
> configure the PKS information in each PE, it still falls in this statement.
>
>
>
>
> On 20 February 2014 21:25, Zafar Ali (zali) <zali@cisco.com> wrote:
>
>>  Hi Cyril-
>>
>>  RFC5553 mentions:
>>
>>  " Resolution of the PKS MAY take any of the following forms or use
>>      some other technique subject to local policy and network
>>      implementation.
>>
>>      o The LSR can use the PCE-ID contained in the PKS to contact the
>>        identified PCE using PCEP [RFC5440 <http://tools.ietf.org/html/rfc5440>] and request that the PKS be
>>        expanded.
>>
>>      o The LSR can contact any PCE using PCEP [RFC5440 <http://tools.ietf.org/html/rfc5440>] to request that
>>        the PKS be expanded, relying on cooperation between the PCEs.
>>
>>      o The LSR can use the information in the PKS to index a CPS
>>        previously supplied to it by the PCE that originated the PKS."
>>
>>
>>  How any of this justifies the following statement:
>>
>>  "1: Added a section describing how the Path Key resolution works, and
>> it demonstrates that the proposed method can work in both the scenario
>> with PCE, *as well as WITHOUT PCE.*"
>>
>>   Thanks
>>
>>  Regards ... Zafar
>>
>>   From: Cyril Margaria <cyril.margaria@gmail.com>
>> Date: Thursday, February 20, 2014 3:11 PM
>> To: zali <zali@cisco.com>
>> Cc: "Zhangxian (Xian)" <zhang.xian@huawei.com>, "ccamp@ietf.org" <
>> ccamp@ietf.org>
>> Subject: Re: [CCAMP] FW: New Version Notification for
>> draft-zhang-ccamp-route-exclusion-pathkey-01.txt
>>
>>     Hi Zafar,
>>
>>  The document follows the same procedure as RFC5553.
>> PKS resolution using PCE is one possible implementation, the processing
>> node may use other mechanism (section 3.1 of RFC5553 describes some of
>> them).
>>
>>  One possible implementation being "The LSR can use the information in
>> the PKS to index a CPS previously supplied to it by the PCE that originated
>> the PKS."
>>
>>  This can cover a number of mechanisms including configuration using
>> management system.
>>
>>  I hope this clarifies the statement.
>>
>>  Best Regards,
>>  Cyril.
>>
>>
>>
>> On 20 February 2014 18:29, Zafar Ali (zali) <zali@cisco.com> wrote:
>>
>>>
>>> -----Original Message-----
>>> From: "Zhangxian   (Xian)" <zhang.xian@huawei.com>
>>> Date: Friday, February 14, 2014 8:50 PM
>>> To: "ccamp@ietf.org" <ccamp@ietf.org>
>>> Subject: [CCAMP] FW: New Version Notification for
>>> draft-zhang-ccamp-route-exclusion-pathkey-01.txt
>>>
>>>  >1: Added a section describing how the Path Key resolution works, and
>>> it
>>> >demonstrates that the proposed method can work in both the scenario with
>>> >PCE, as well as WITHOUT PCE.
>>> >
>>>
>>>  Hi Xian:
>>>
>>> When an ERO expanding node hits exclude Path Key(EXRS), it still needs to
>>> lookup the path associated with the Path Key. So how do you achieve Path
>>> Key lookup WITHOUT PCE?
>>>
>>> More comments later,
>>>
>>> Thanks
>>>
>>> Regards...Zafar
>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> CCAMP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>
>>
>