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

[John E Drake <[e-mail]>]

Exactly.

Yours Irrespectively,

John

> -----Original Message-----
> From: Zhangxian (Xian) [mailto:[e-mail]]
> Sent: Tuesday, October 08, 2013 11:02 PM
> To: Zafar Ali (zali); CCAMP ([e-mail])
> Cc: John E Drake; Fatai Zhang
> 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-exclusio
> >> >n-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/?incl
> >> >ude _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