Sounds reasonable, I am wondering whether it is sufficient for just defining one new 'D' flag in the SVEC object? Why 'D' flag was not defined when RFC5440 was documented. How do I know computed paths don't have any transit domains in common. Domain diversity is more complicated when computed paths don't even share ingress domain and egress domain.
Regards! -Qin From: [email protected] [mailto:[email protected]] On Behalf Of Ramon Casellas Sent: Friday, September 13, 2013 12:49 PM To: [email protected] Subject: 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
