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

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

Hi Xian-

Yes this was triggered by the email. But there is also text in draft that suggest non-PCE scope for the draft. Please clarify the same in the next revision.

I have some other comments, but will send them separately (ASAP).

Thanks

Regards … Zafar

From: "Zhangxian (Xian)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 21, 2014 1:13 AM
To: zali <[e-mail]<mailto:[e-mail]>>, Cyril Margaria <[e-mail]<mailto:[e-mail]>>
Cc: "[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

Is there a particular statement in the draft  you would like to see a change?

Or if you meant my email sent to the list, I did not claim anything like “a standard based solution non-PCE solution where path key resolution is defined”, but rather a PCE is not mandated. However,  if a PCE is used (a solution supported by standards), it can be supported by existing PCEP without protocol extensions, plus additional considerations needed and explained in the latest draft. Does this clarify?

Regards,
Xian

From: Zafar Ali (zali) [mailto:[e-mail]]
Sent: 2014年2月21日 12:21
To: Zhangxian (Xian); Cyril Margaria
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi:

Please see in-line.

Thanks

Regards … Zafar

From: "Zhangxian (Xian)" <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 20, 2014 8:14 PM
To: Cyril Margaria <[e-mail]<mailto:[e-mail]>>, zali <[e-mail]<mailto:[e-mail]>>
Cc: "[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

Cyril has made it pretty clear. I just want to add that,  the function needed for draft-zhang-ccamp-route-exclusion-pathkey is to resolve path key.  So as long as mechanisms can fulfill this, it works.

Yes, if you have a proprietary solution, it will work for you. I asked pointers to a standard based solution non-PCE solution where path key resolution is defined – as this is what you are claiming. I am happy if you soften your claim.

Definitely using a PCE is a good and obvious example which is included in the draft, but it is NOT the only mechanism, as explained in the updated draft text quoted below.

Regards,
Xian

From: Cyril Margaria [mailto:[e-mail]]
Sent: 2014年2月21日 6:57
To: Zafar Ali (zali)
Cc: Zhangxian (Xian); [e-mail]<mailto:[e-mail]>
Subject: Re: [CCAMP] FW: New Version Notification for draft-zhang-ccamp-route-exclusion-pathkey-01.txt

Hi Zafar,
This is described in the section 2.2
"
If it cannot decode the PKS, the error handling procedure defined in Section 3.1 of [RFC5553]<http://tools.ietf.org/html/rfc5553#section-3.1> is not changed by this document.
This mechanism can work with all the PKS resolution mechanism, as detailed in [RFC5553] section 3.1<http://tools.ietf.org/html/rfc5553#section-3.1>.

Quoting relevant text from [RFC5553] section 3.1<http://tools.ietf.org/html/rfc5553#section-3.1>..


     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.

All these methods are pointing to a PCE based solution.


A PCE, co-located or not, may be used to resolve the PKS, but the node (i.e., a Label Switcher Router(LSR)) can also use the PKS information to index a Path Segment previously supplied to it by the entity that originated the PKS, for example the LSR that inserted the PKS in the RRO or a management system.

How this communication between LSR generating the Path key and LSR seeking Path info happens? If you are only referring to to co-located PCE, then scope comes back to a PCE based solution.


"

The document could also state :

PKS resolution MAY take any of the forms described in RFC5553 section 3.1. In addition the LSR



can also use the PKS information to index a Path Segment previously supplied to it by the entity
that originated the PKS. This can be, for example, the LSR that inserted the PKS in the RRO or a

   management system.

See above.




Would that answer your question?






On 20 February 2014 23:45, Zafar Ali (zali) <[e-mail]<mailto:[e-mail]>> wrote:

From: Cyril Margaria <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 20, 2014 4:43 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

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.

Can you please qualify this statement? Without PCE (PCEP) this solution does not work.

Thanks

Regards… Zafar