Subject: Re: [Pce] comments for draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

From: Dhruv Dhody <[email-masked]>
Date: Thu, 03 Feb 2011 14:49:13 -0800

Dear Quintin, 

Thanks for your comments. 

I am working on a document about domain sequence and will publish it before
the next IETF meeting. 

I will take care to add a section regarding the correlation between
domain-seq and PCE-seq. 

Regards,

Dhruv

Dhruv Dhody

Senior Technical Leader

Huawei-Santa Clara, CA

Work: (408) 330 4940

Cell: (408) 667 8127

This email 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 here 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 email in error, please notify the sender by phone or email
immediately and delete it!

  _____  

From: Quintin Zhao [mailto:[email-masked]] 
Sent: Thursday, February 03, 2011 7:56 AM
To: [email-masked]; [email-masked]
Subject: FW: comments for
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

Dhruv,

Thanks for your very detailed comments and suggestions! 

Included here are my comments for your suggestions and at the same time, I
also forward our discussions to the list to get more ideas/inputs from
others.

1)      Definition of Core-Tree: 

we will update the definition of the core-tree to make it more clearer based
on your suggestion here.

2)      Domain sequence and PCE sequence: 

If we assume that the PCE sequence can be directly implied by the domain
sequence, I agree with what you suggested here to get rid of the
PCE-sequence object in the draft.  We need to specify the method for any PCE
to find out the PCE sequence based on the domain sequence either in this
draft or in a separate draft. Also in the inter-AS scenario, where one AS
also consists of multiple areas, the representation of the domain sequence
and the method to find out the PCE sequence also should be specified. Since
this is also true for the p2p computation, maybe it is better to have a
separate document to clearly specify the representation of domain sequence
and relationship between the domain sequence and PCE sequences.

3)                        SPT (shortest path tree) v/s MCT (minimum cost
tree): 
 
One way we can address this issue is that the transit PCE in the core-tree
computation can decide the number of paths sent upstream based on the
configuration and also based on if it is a shortest path tree or not. When
it is SPT, the number of the paths send upstream will be 1. 

Quintin

From: Dhruv Dhody [mailto:[email-masked]

] 
Sent: Monday, January 31, 2011 6:19 PM
To: [email-masked]
Subject: comments for draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

Quintin, 

I have following comments on the
"draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07", any comments on this
are welcome from all. 

1) Definition of Core-Tree: 

Core-Tree should be a P2MP tree with Root as the source node, leaves as the
entry boundary nodes of leaf domain. There is no need to include domain
nodes or inter-AS TE links or transit boundary nodes in its definition.
What I mean is once phase 1 is completed and PCE(1) has received all the
VSPT for all the entry boundary node of leaf domain, its objective is to
find an optimal tree meeting the OF, there is no need to specifically
suggest what should be the transit node and what should be the branch node
while computing the Core-Tree. 

If confidentiality is a concern, path-key mechanism shall be applied in
those domains but the core-tree definition is not impacted. 

To summarize the issue here is the clear definition of domain-tree,
core-tree and final P2MP tree. 

Domain-Tree: Should consist of  domain-sequence in form of a tree and has no
information about BNs and inter-AS TE links. 

Core-Tree:   A Core Tree is defined as a tree which satisfies the following
conditions:

   o  The root of the core tree is the ingress LSR in the root domain;

   o  The leaves of the core tree are the entry nodes in the leaf domains;

   o  The transit and branch nodes of the core tree MAY be from the entry
and exit nodes from the transit and branch domains. They can also be nodes
within the domains.

Final Tree: A set of LSRs and TE links that comprise the path of a P2MP TE
LSP from its ingress LSR to all of its egress LSRs.

2) Domain-Seq V/s PCE-Seq

RFC 5441 [BRPC] method uses IRO and sub-objects to represent
domain-sequence. In P2MP we should continue to use the similar approach. 

This concept of PCE-Sequence, where a sequence of PCE based on the domain
sequence should be decided and attached in the PCReq at the very beginning
of path computation. It is much simpler and advantageous to carry only
domain-sequence rather than PCE-Sequence. 

Advantages

a) All PCE must be aware of all other PCEs in all domain for PCE-Sequence.
There is no clear method for this. In domain-sequence PCE should be aware of
the domains and not all the PCEs serving the domain. PCE needs to be aware
of the neighboring PCEs as done by discovery protocols. 

b) There maybe multiple PCE in a domain, the selection of PCE shouldn't be
made at the PCC/PCE(1). This decision is made only at the neighboring PCE
which is completely aware of states of PCE via notification messages. 

c) Domain sequence would be compatible to P2P inter-domain BRPC method as
described in RFC 5441. 

There is no need for PCE-Sequence and it doesn't give any benefits over
Domain Seq.  

3) SPT (shortest path tree) v/s MCT (minimum cost tree)

In case of Shortest Path Tree, VSPT is enough for making the core-tree and
downstream PCE can continue to do pruning as done in P2P BRPC procedure. We
need to avoid pruning only in case of SPT and other objective function. Also
the core-tree procedure will guarantee to give optimal path with SPT if
core-tree is optimal and grafting is done. The same cannot be guaranteed for
MCT.

This is just for your information, so that an informed decision can be taken
based on this. 

Regards,

Dhruv

Dhruv Dhody

Senior Technical Leader

Huawei-Santa Clara, CA

Work: (408) 330 4940

Cell: (408) 667 8127

This email 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 here 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 email in error, please notify the sender by phone or email
immediately and delete it!

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 04 Feb 2011 09:52:17 +0100

Dhruv, Quintin, all

See inline

On 03/02/2011 23:49, Dhruv Dhody wrote:
>
>
> *From:*Dhruv Dhody [mailto:[email-masked]
>
> Quintin,
>
>    o  The transit and branch nodes of the core tree MAY be from the 
> entry and exit nodes from the transit and branch domains. They can 
> also be nodes within the domains.
>

I'm not sure I follow here: what's the use case for nodes within the 
domains being part of the core tree? probably I missed something.

> domain-sequence. In P2MP we should continue to use the similar approach.

Good point.

I believe as you mention that this has several advantages: it's easier 
to deduce/obtain domain sequences and domain trees and later (even if 
locally) map domains to one or more PCEs.

I still have doubts regarding the fact that, unless I am mistaken, the 
source PCE is assumed to have a PCEP adjacency to the other PCEs, (not 
necessarily from the adjacent domains) in order to expand the trees, 
right? (otherwise some kind of message routing would be needed?)

One nitpick: as far as I know, we lack an ERO subobject to convey 
IGP-area (there is an AS). We found this issue when implementing BRPC 
with the IRO as you mention, so we defaulted to online mapping of the 
"next PCE" based on the final destination and reachability info. The 
lack of an "IGP area" sub-object is also present in related work such as 
H-PCE. Would this be needed at the CCAMP level?

> In case of Shortest Path Tree, VSPT is enough for making the core-tree 
> and downstream PCE can continue to do pruning as done in P2P BRPC 
> procedure. We need to avoid pruning only in case of SPT and other 
> objective function. Also the core-tree procedure will guarantee to 
> give optimal path with SPT if core-tree is optimal and grafting is 
> done. The same cannot be guaranteed for MCT.
>
> This is just for your information, so that an informed decision can be 
> taken based on this.
>
This is worth noting in a next version of the draft. As Olefumi pointed 
out in a previous mail, this step is quite critical -- we added a 
paragraph discussing the potentially huge solution space -- and any 
procedures/heuristics that mitigate this controversial step are welcome.

Best regards,
R.

---

From: Dhruv Dhody <[email-masked]>
Date: Fri, 04 Feb 2011 13:32:16 -0800

Dear Ramon, 

Thanks for your comments, please find my reply inline. 

Regards,

Dhruv

Dhruv Dhody

Senior Technical Leader

Futurewei-Santa Clara, CA

Work: (408) 330 4940

Cell: (408) 667 8127

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ramon
Casellas
Sent: Friday, February 04, 2011 12:52 AM
To: [email-masked]
Subject: Re: [Pce] comments
fordraft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

Dhruv, Quintin, all

See inline

  

Quintin, 

I'm not sure I follow here: what's the use case for nodes within the domains
being part of the core tree? probably I missed something.

Dhruv: Core-tree should have the nodes inside the domains because an optimal
core-tree [based on the OF] can only be computed when we analyze the nodes
within the domains as well. The core-tree thus cannot be an abstract tree
with just the boundary nodes and domains; we must compute and select the
internal nodes and links as well. To support confidentiality the same nodes
and links can be hidden via a path-key but they must be computed and be a
part of core-tree. My comment is basically that an optimal core-tree cannot
be abstract; it must be absolute tree with all internal nodes and links
finalized.   

Good point. 

I believe as you mention that this has several advantages: it's easier to
deduce/obtain domain sequences and domain trees and later (even if locally)
map domains to one or more PCEs. 

I still have doubts regarding the fact that, unless I am mistaken, the
source PCE is assumed to have a PCEP adjacency to the other PCEs, (not
necessarily from the adjacent domains) in order to expand the trees, right?
(otherwise some kind of message routing would be needed?)

One nitpick: as far as I know, we lack an ERO subobject to convey IGP-area
(there is an AS). We found this issue when implementing BRPC with the IRO as
you mention, so we defaulted to online mapping of the "next PCE" based on
the final destination and reachability info. The lack of an "IGP area"
sub-object is also present in related work such as H-PCE. Would this be
needed at the CCAMP level? 

Dhruv: I think we must not assume that all PCE have a PCEP session to all
the other PCEs. This would be a big limitation and the system administrator
must do considerable configurations esp in case of inter-AS where IGP
discovery cannot be used. Some message routing similar to BRPC should be
implemented. The path taken by path-request and reply is same as each
domain-seq in the domain-tree. This is not very hard to implement. 

In the domain-seq draft [which I am preparing], I have added IANA
considerations to introduce sub-object for IGP Areas. I think it's very much
needed.   

This is worth noting in a next version of the draft. As Olefumi pointed out
in a previous mail, this step is quite critical -- we added a paragraph
discussing the potentially huge solution space -- and any
procedures/heuristics that mitigate this controversial step are welcome.

Dhruv: Okay!

Best regards,
R.