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

["Zafar Ali (zali)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 20, 2014 3:49 PM
To: zali <[e-mail]<mailto:[e-mail]>>
Cc: "Zhangxian (Xian)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 20, 2014 3:11 PM
To: zali <[e-mail]<mailto:[e-mail]>>
Cc: "Zhangxian (Xian)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> wrote:

-----Original Message-----
From: "Zhangxian   (Xian)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 14, 2014 8:50 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/ccamp