Hi, Qilei, Glad to see we at least share the understanding that not all requirements need to be met.
But what I meant in the previous email is we need to dig out more of the motivation to specify domain diversity. Is it just for path diversity? If so, RFC5440 supports already. Don’t you agree? Of course, there may be other reasons which I am not aware of. That’s what I would like to know more. Regards, Xian From: [email protected] [mailto:[email protected]] Sent: 2013年9月16日 16:26 To: Zhangxian (Xian); Ramon Casellas Cc: [email protected] Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions Hi, Xian, Thanks, please see my reply in-line. Qilei Wang "Zhangxian (Xian)" <[email protected]> 2013-09-16 15:45 收件人 "[email protected]" <[email protected]>, Ramon Casellas <[email protected]>, 抄送 "[email protected]" <[email protected]> 主题 RE: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions Hi, Qilei, Ramon and all, I think Ramon provides a straightforward solution to this requirement. But I would like to step back and ask: whether we should specify the domain diversity in PCEP for H-PCE or not? As we can see not all requirements specified in H-PCE RFC are accommodated in draft-ietf-pce-hierarchy-extensions (e.g., Setion 1.1.). [Qilei]: I can understand why the functions listed in section 1.1 are out of the scope of this draft, maybe because of BGP-TE and/or interior implementation. But I can't really know the reason why domain diversity does not fit in PCEP for H-PCE. Can you offer me more reasons here? Or maybe we can further discuss about this. According to Section 1.3.2 in RFC6805, domain diversity can facilitate path diversity. If this is the only reason, what currently defined in RFC5440 accommodates this need already, right? [Qilei]: How could the RFC5440 satisfy this need? If the source node only wants path diversity but specify domain diversity, it may end up with no path available, assume there is one transit domain all paths will have to go through from the source domain. On the other hand, if the source node only specifies path diversity, it may or may not get a domain-diversified path, which can be decided by the parent PCE. [Qilei]: I agree with your analysis. It may end up with no path available, but it is still the computation result of the PCE. Just from my opinion, we should firstly focus on the requirement whether we should specify the domain diversity in PCEP for H-PCE or not, as you addressed at the beginning. Any thoughts? Regards, Xian From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 2013年9月13日 15:27 To: Ramon Casellas Cc: [email protected] Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions Hi, Ramon, Thank you for pointing the RFC6007 to me. I almost forgot this draft. Yeah, you are right. This requirement can be satisfied by two approaches. One is the 2-step approach which can be addressed by IRO/XRO, and the other is the "D flag" in SVEC object in the H-PCE scenario according to your mail. Just from my opinion, the new flag indicating "domain diverse" in SVEC object is needed in PCEP protocol. Thanks Qilei Wang Ramon Casellas <[email protected]> 发件人: [email protected] 2013-09-13 12:48 收件人 [email protected], 抄送 主题 Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions Just from my understanding, maybe this requirement can be resolved by extending the PCEP object to indicate "domain-diverse" requirement when PCE computes a pair of dependent path at the same time. When PCC sends path request to child PCE, this requirement can be indicated in the path request message, and child PCE can forward this requirement indication to the parent PCE. Parent PCE has the topology information of domains, so it is able to compute two domain-diverse paths. Hi Qilei, all Would, for example, a new bit in the SVEC saying "domain diverse" fulfill such requirement? I was reading http://tools.ietf.org/html/rfc6007 sect 5.3 that discusses this. The two step can be addressed by IRO/XRO and the common H-PCE case could use a D flag. Domain sub-objects are not domain-specific 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |D|S|N|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number #1 | // // | Request-ID-number #M | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Thoughts? thanks, R. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
