Hi, Xian,

Thanks, please see my reply in-line.

Qilei Wang





"Zhangxian (Xian)" <zhang.x...@huawei.com> 
2013-09-16 15:45

收件人
"wang.qi...@zte.com.cn" <wang.qi...@zte.com.cn>, Ramon Casellas 
<ramon.casel...@cttc.es>, 
抄送
"pce@ietf.org" <pce@ietf.org>
主题
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: pce-boun...@ietf.org [mailto:pce-boun...@ietf.org] On Behalf Of 
wang.qi...@zte.com.cn
Sent: 2013年9月13日 15:27
To: Ramon Casellas
Cc: pce@ietf.org
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 <ramon.casel...@cttc.es> 
发件人:  pce-boun...@ietf.org 
2013-09-13 12:48 


收件人
pce@ietf.org, 
抄送

主题
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
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Reply via email to