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

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

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)" <[e-mail]>
Date: Wednesday, October 9, 2013 2:02 AM
To: zali <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Fatai Zhang
<[e-mail]>
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: [e-mail] [mailto:[e-mail]] On Behalf Of
>Zafar Ali (zali)
>Sent: 2013年10月9日 13:26
>To: John E Drake; Fatai Zhang; CCAMP ([e-mail])
>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: "[e-mail]" <[e-mail]>
>Date: Tuesday, October 8, 2013 6:26 PM
>To: zali <[e-mail]>, Fatai Zhang <[e-mail]>,
>"[e-mail]" <[e-mail]>
>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:[e-mail]]
>>> Sent: Tuesday, October 08, 2013 10:47 AM
>>> To: Fatai Zhang; John E Drake; CCAMP ([e-mail])
>>> 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 <[e-mail]>
>>> Date: Tuesday, October 8, 2013 3:01 AM
>>> To: "[e-mail]" <[e-mail]>, "[e-mail]"
>>> <[e-mail]>
>>> 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: [e-mail] [mailto:[e-mail]] On
>>> Behalf
>>> >Of John E Drake
>>> >Sent: Thursday, October 03, 2013 2:27 AM
>>> >To: CCAMP ([e-mail])
>>> >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/?include
>>> >_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
>>> >[e-mail]
>>> >https://www.ietf.org/mailman/listinfo/ccamp
>>> >_______________________________________________
>>> >CCAMP mailing list
>>> >[e-mail]
>>> >https://www.ietf.org/mailman/listinfo/ccamp
>>> 
>>> 
>>
>>
>
>_______________________________________________
>CCAMP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ccamp