Subject: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

From: [email-masked]
Date: Fri, 13 Sep 2013 11:36:55 +0800

Hi, authors,

Section 1.3.2.2 of RFC6805 describes a new requirement domain diversity in 
hierarchy PCE scenario. But the extension draft do not address any detail 
about this requirement currently. According to the definition in RFC6805, 
domain diversity is referred to as that a pair of paths do not transit any 
of the same domain. If this pair of paths only share common ingress and 
egress, they are also domain-diverse. 

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.

Thanks
Qilei Wang

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 13 Sep 2013 06:48:41 +0200

> 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.

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Sep 2013 07:22:58 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Ramon Casellas
Sent: Friday, September 13, 2013 12:49 PM
To: [email-masked]
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

Thoughts?
thanks, R.

---

From: [email-masked]
Date: Fri, 13 Sep 2013 15:26:38 +0800

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-masked]> 
发件人:  [email-masked]
2013-09-13 12:48

收件人
[email-masked], 
抄送

主题
Re: [Pce] A comment regarding domain diversity in 
draft-ietf-pce-hierarchy-extensions

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

Thoughts?
thanks, R.
_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Sep 2013 07:46:17 +0000

Hi, Qilei:
For domain diversity, when path computation traverses multiple domains including one ingress domain, multiple transit domains, one egress domain, there are several cases:

a.       Computation path share none of these domains.

b.      Computation path only shares both  ingress domain and egress domain but not share any transit domains.

c.       Computation path only shares ingress domain but not share any transit domain and egress domain.

d.      Computation path only shares egress domain but not share any transit domain and ingress domain.

I am wondering which case you are referred to ?

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 13, 2013 3:27 PM
To: Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Ramon,

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

2013-09-13 12:48

收件人

[email-masked],

抄送

主题

Re: [Pce] A comment regarding domain diversity in        draft-ietf-pce-hierarchy-extensions

   0                   1                   2                   3

Thoughts?
thanks, R.

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 13 Sep 2013 09:49:10 +0200

Qin,

Please see in-line tagged with Ramon>

El 13/09/2013 9:22, Qin Wu escribió:
>
> 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.
>
Ramon> there are several things to consider:

*) the D flag is generic, attached to the SVEC tuple, only to convey a 
group request constraint. This applies regardless of the actual method 
used in computation. We should discuss what are the implications, such 
as "are border nodes allowed (corner case)? Of course, a PCC can also 
play with inclusion and exclusion provided it has the information on the 
interconnection of domains, but I don't see this as a common case.

*) I understood the requirement was scoped to the H-PCE case, where it 
is the responsibility of the p-pce to ensure that they are 
domain-disjoint when selecting the domain sequence for both paths, and 
before segment expansion. How the parent does this I would say it is is 
implementation specific (k-shortest disjoint paths, iterative, etc.)

*) I would say that, without more information, a PCE or PCC cannot 
simply deduce whether two paths don't have any transit domains in 
common, unless this information is conveyed in the path ERO or 
attributes. I was thinking that the use of domain objects could be used
http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-03

if the EROs are "tagged" with domain information, it can be deduced 
whether both EROs are disjoint or not

> share ingress domain and egress domain.
Ramon> I guess we agree :o)

Thanks
R.

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Sep 2013 08:10:28 +0000

Very good points and clarifications. :-)
Regarding "are border nodes allowed", I think if inter-domain communication is required, the border node should allow, shouldn't it?

Also I am wondering whether this requirement is only applied to H-PCE case? H-PCE could be a typical use case. However I believe SVEC tuple is also applied to other use cases
Otherwise why RFC5440 specify it In more generic way.

Regards!
-Qin
From: Ramon Casellas [mailto:[email-masked]]
Sent: Friday, September 13, 2013 3:49 PM
To: Qin Wu
Cc: [email-masked]
Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Qin,

*) the D flag is generic, attached to the SVEC tuple, only to convey a group request constraint. This applies regardless of the actual method used in computation. We should discuss what are the implications, such as "are border nodes allowed (corner case)? Of course, a PCC can also play with inclusion and exclusion provided it has the information on the interconnection of domains, but I don't see this as a common case.

*) I understood the requirement was scoped to the H-PCE case, where it is the responsibility of the p-pce to ensure that they are domain-disjoint when selecting the domain sequence for both paths, and before segment expansion. How the parent does this I would say it is is implementation specific (k-shortest disjoint paths, iterative, etc.)

*) I would say that, without more information, a PCE or PCC cannot simply deduce whether two paths don't have any transit domains in common, unless this information is conveyed in the path ERO or attributes. I was thinking that the use of domain objects could be used
http://tools.ietf.org/html/draft-ietf-pce-pcep-domain-sequence-03

if the EROs are "tagged" with domain information, it can be deduced whether both EROs are disjoint or not

Thanks
R.

---

From: [email-masked]
Date: Fri, 13 Sep 2013 16:25:18 +0800

Hi, Qin:

I guess the sentences in section 1.3.2.2 of RFC6805 can answer you 
question, I cite them here,

"
A pair of paths are domain-diverse if they do not transit any of the
   same domains.  A pair of paths that share a common ingress and egress
   are domain-diverse if they only share the same domains at the ingress
   and egress (the ingress and egress domains).  Domain diversity may be
   maximized for a pair of paths by selecting paths that have the
   smallest number of shared domains.
"

Thanks
Qilei Wang

Qin Wu <[email-masked]> 
2013-09-13 15:46

收件人
"[email-masked]" <[email-masked]>, Ramon Casellas 
<[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>
主题
RE: [Pce] A comment regarding domain diversity in 
draft-ietf-pce-hierarchy-extensions

Hi, Qilei:
For domain diversity, when path computation traverses multiple domains 
including one ingress domain, multiple transit domains, one egress domain, 
there are several cases:
a.       Computation path share none of these domains.
b.      Computation path only shares both  ingress domain and egress 
domain but not share any transit domains.
c.       Computation path only shares ingress domain but not share any 
transit domain and egress domain.
d.      Computation path only shares egress domain but not share any 
transit domain and ingress domain.

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
[email-masked]
Sent: Friday, September 13, 2013 3:27 PM
To: Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] A comment regarding domain diversity in 
draft-ietf-pce-hierarchy-extensions
 
Hi, Ramon, 

Thanks 
Qilei Wang 

收件人
[email-masked], 
抄送

主题

   0                   1                   2                   3

Thoughts?
thanks, R.

---

From: Qin Wu <[email-masked]>
Date: Fri, 13 Sep 2013 09:34:30 +0000

Qilei:
I think (b) more makes sense. Maybe we further requires both egress node and ingress node belong to multiple domains.

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, September 13, 2013 4:25 PM
To: Qin Wu; Ramon Casellas
Cc: [email-masked]
Subject: RE: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Qin:

I guess the sentences in section 1.3.2.2 of RFC6805 can answer you question, I cite them here,

"

"

Thanks
Qilei Wang

2013-09-13 15:46

收件人

"[email-masked]" <[email-masked]>, Ramon Casellas <[email-masked]>,

抄送

主题

RE: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Qilei:

Regards!
-Qin

Hi, Ramon,

Thanks
Qilei Wang

2013-09-13 12:48

收件人

[email-masked],

抄送

主题

  0                   1                   2                   3

Thoughts?
thanks, R.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 16 Sep 2013 07:45:51 +0000

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.).

  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? 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.

Any thoughts?

Regards,
Xian

Sent: 2013年9月13日 15:27

Hi, Ramon,

Thanks
Qilei Wang

2013-09-13 12:48

收件人

[email-masked],

抄送

主题

   0                   1                   2                   3

Thoughts?
thanks, R.

---

From: [email-masked]
Date: Mon, 16 Sep 2013 16:25:31 +0800

Hi, Xian,

Thanks, please see my reply in-line.

Qilei Wang

"Zhangxian (Xian)" <[email-masked]> 
2013-09-16 15:45

收件人

     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

Hi, Ramon, 

Thanks 
Qilei Wang 

收件人
[email-masked], 
抄送

主题

   0                   1                   2                   3

Thoughts?
thanks, R.

---

From: "Zhangxian (Xian)" <[email-masked]>
Date: Mon, 16 Sep 2013 08:50:28 +0000

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-masked] [mailto:[email-masked]]
Sent: 2013年9月16日 16:26
To: Zhangxian (Xian); Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Xian,

Qilei Wang

2013-09-16 15:45

收件人

抄送

主题

[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?

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

Hi, Ramon,

Thanks
Qilei Wang

2013-09-13 12:48

收件人

[email-masked],

抄送

主题

  0                   1                   2                   3

Thoughts?
thanks, R.

---

From: [email-masked]
Date: Mon, 16 Sep 2013 17:42:49 +0800

Hi, Xian,

Do you mean the scenario that domain diversity can be used in?

I can understand domain diversity can facilitate path diversity, and I 
also agree RFC5440 supports path diversity, but I don't know how RFC5440 
could support domain diversity? That's what I am confused with.  I'm not 
sure if I have right understanding about your reply, can you explain more?

Thanks
Qilei Wang

2013-09-16 16:50

收件人
"[email-masked]" <[email-masked]>, 
抄送
"[email-masked]" <[email-masked]>, Ramon Casellas <[email-masked]>
主题
RE: [Pce] A comment regarding domain diversity in 
draft-ietf-pce-hierarchy-extensions

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

Hi, Xian, 

Qilei Wang 

收件人

  

  
Any thoughts? 
  
Regards, 
Xian 

Hi, Ramon, 

Thanks 
Qilei Wang 

收件人
[email-masked], 
抄送

主题

  0                   1                   2                   3

Thoughts?
thanks, R.

---

From: Dhruv Dhody <[email-masked]>
Date: Wed, 25 Sep 2013 05:04:12 +0000

Hi WG,

We have jotted down some thoughts regarding domain diversity in a draft [http://www.ietf.org/id/draft-dwpz-pce-domain-diverse-00.txt].
Welcome any comments / feedback?

Regards,
Dhruv (on behalf of co-authors/contributes)

---------------------------------------------------------------
Dhruv Dhody
System Architect,
Huawei Technologies India Pvt. Ltd.,
Banagalore
Mobile: +91-9845062422
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: 16 September 2013 15:13
To: Zhangxian (Xian); Ramon Casellas
Cc: [email-masked]
Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Xian,

I can understand domain diversity can facilitate path diversity, and I also agree RFC5440 supports path diversity, but I don't know how RFC5440 could support domain diversity? That's what I am confused with.  I'm not sure if I have right understanding about your reply, can you explain more?

Thanks
Qilei Wang

"Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>

2013-09-16 16:50

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ramon Casellas <[email-masked]<mailto:[email-masked]>>

主题

Hi, Qilei,

Regards,
Xian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: 2013年9月16日 16:26
To: Zhangxian (Xian); Ramon Casellas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Xian,

Qilei Wang

"Zhangxian (Xian)" <[email-masked]<mailto:[email-masked]>>

2013-09-16 15:45

收件人

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ramon Casellas <[email-masked]<mailto:[email-masked]>>,

抄送

"[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

主题

Any thoughts?

Regards,
Xian

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: 2013年9月13日 15:27
To: Ramon Casellas
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Pce] A comment regarding domain diversity in draft-ietf-pce-hierarchy-extensions

Hi, Ramon,

Thanks
Qilei Wang

Ramon Casellas <[email-masked]<mailto:[email-masked]>>
发件人:  [email-masked]<mailto:[email-masked]>

2013-09-13 12:48

收件人

[email-masked]<mailto:[email-masked]>,

抄送

主题

 0                   1                   2                   3

Thoughts?
thanks, R.
_______________________________________________
Pce mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pce