Olufemi Komolafe | 2 Feb 22:36 2011
Picon

Re: New Version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures

Dan,

I recently read this draft and found it pretty interesting.

However, one main issue that struck me was that the approach in Section 7.2 for the core tree computation seemed very computational expensive.  Unless I'm missing something, It seems like the draft is suggesting computing the VSPTs for every leaf BN and then exhaustively working through all the potential combinations of paths to find the optimal combination for the core tree.  The number of evaluations needed struck me as potentially being very large and made me wonder whether there was a smarter way to try to compute the optimal core tree?    Is it possible to try to split up this computation somehow by distributing it judiciously between the PCEs?  For example perhaps by each PCE essentially computing the optimal core "sub-tree" from each ingress node for the domain to all the "downstream" BNs that are reached exclusively by it?   And then the source PCE has to combine these sub-trees optimally?  I'm not 100% sure that approach will work but nevertheless I think trying to avoid tediously iterating over all possible path combinations to compute the optimal core tree is  worthy of some more consideration.

Some minor typos:
Section 1. Introduction 
Incomplete sentence: "The ability to compute......"

Section 2. Terminology
"lead nodes" instead of "leaf nodes" for Destination

Section 5. Requirements
Points (5) to (8) do not really read like requirements.  Perhaps re-word?

Section 6. Objective Functions
Points (1) to (4) do not really read like objective functions. Perhaps re-word?

Section 7.1 Core Trees
Figure 3: Some of the labels on the right half of the diagram seem incorrect (i.e. should the two (XN3_1)s should be (XN1_2) and (XN3_2) respectively?)

Section 7.4.1 The Extension of RP Object
Errors in second sentence of text for C bit value of 1

Section 7.4.2 The PCE Sequence Object
Second sentence: "this objects"

Regards,
Femi

On 21 Jan 2011, at 22:30, Daniel King wrote:

Hi All,

 

We have created a new version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures (07).

 

 

This version was created to fix a number of minor edits, raise the issue of  manageability and help facilitate protection scenarios discussed during IETF 79 in Beijing. The draft update includes:

 

8. Protection Section

This section is used to highlight issues discussed in Beijing. Thanks to JP and all for your questions. We expect this topic to require more discussion and one scenario is that it should be addressed in separate document. The whole protection topic (not just for P2MP and multi-domain) will require a much more detailed analyses and we will follow-up on the various issues with a separate email/discussion.  

 

9.  Manageability Considerations

Obviously management of inter-domain P2MP path computations potentially raise a number issues and we have begun to document them. Each sub-areas will require further deliberation so please feel free to comment and make suggestions.

Finally, the authors would like to request working group adoption of this draft.

 

Thanks!                                                                                                                  

Quintin

_______________________________________________
Pce mailing list
Pce <at> ietf.org
https://www.ietf.org/mailman/listinfo/pce

<div>Dan,<div><br></div>
<div>I recently read this draft and found it pretty interesting.</div>
<div><br></div>
<div>However, one main issue that struck me was that the approach in Section 7.2 for the core tree computation seemed very computational expensive. &nbsp;Unless I'm missing something, It seems like the draft is suggesting computing the VSPTs for every leaf BN and then exhaustively working through all the potential combinations of paths to find the optimal combination for the core tree. &nbsp;The number of evaluations needed struck me as potentially being very large and made me wonder whether there was a smarter way to try to compute the optimal core tree? &nbsp; &nbsp;Is it possible to try to split up this computation somehow by distributing it judiciously between the PCEs? &nbsp;For example perhaps by each PCE essentially computing the optimal core "sub-tree" from each ingress node for the domain to all the "downstream" BNs that are reached exclusively by it? &nbsp; And then the source PCE has to combine these sub-trees optimally? &nbsp;I'm not 100% sure that approach will work but nevertheless I think trying to avoid tediously iterating over all possible path combinations to compute the optimal core tree is &nbsp;worthy of some more consideration.</div>
<div><br></div>
<div>Some minor typos:</div>
<div>Section 1. Introduction&nbsp;</div>
<div>Incomplete sentence: "The ability to compute......"</div>
<div><br></div>
<div>Section 2. Terminology</div>
<div>"lead nodes" instead of "leaf nodes" for Destination</div>
<div><br></div>
<div>Section 5. Requirements</div>
<div>Points (5) to (8) do not really read like requirements. &nbsp;Perhaps re-word?</div>
<div><br></div>
<div>Section 6. Objective Functions</div>
<div>Points (1) to (4) do not really read like objective functions. Perhaps re-word?</div>
<div><br></div>
<div>Section 7.1 Core Trees</div>
<div>Figure 3: Some of the labels on the right half of the diagram seem incorrect (i.e. should the two (XN3_1)s should be (XN1_2) and (XN3_2) respectively?)</div>
<div><br></div>
<div>Section 7.4.1 The Extension of RP Object</div>
<div>Errors in second sentence of text for C bit value of 1</div>
<div><br></div>
<div>Section 7.4.2 The PCE Sequence Object</div>
<div>Second sentence: "this objects"</div>
<div><br></div>
<div>Regards,</div>
<div>Femi</div>
<div>
<br><div>
<div>On 21 Jan 2011, at 22:30, Daniel King wrote:</div>
<br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span"><div lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<div>Hi All,<p></p>
</div>
<div><p>&nbsp;</p></div>
<div>We have created a new version of draft-zhao-pce-pcep-inter-domain-p2mp-procedures (07).<p></p>
</div>
<div><p>&nbsp;</p></div>
<div>
<a href="http://www.ietf.org/id/draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt">http://www.ietf.org/id/draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07.txt</a><p></p>
</div>
<div><p>&nbsp;</p></div>
<div>This version was created to fix a number of minor edits, raise the issue of&nbsp; manageability and help facilitate protection scenarios discussed during IETF 79 in Beijing. The draft update includes:<p></p>
</div>
<div><p>&nbsp;</p></div>
<div>8. Protection Section<p></p>
</div>
<div>This section is used to highlight issues discussed in Beijing. Thanks to JP and all for your questions. We expect this topic to require more discussion and one scenario is that it should be addressed in separate document. The whole protection topic (not just for P2MP and multi-domain) will require a much more detailed analyses and we will follow-up on the various issues with a separate email/discussion. &nbsp;<p></p>
</div>
<div><p>&nbsp;</p></div>
<div>9.&nbsp; Manageability Considerations<p></p>
</div>
<div>Obviously management of inter-domain P2MP path computations potentially raise a number issues and we have begun to document them. Each sub-areas will require further deliberation so please feel free to comment and make suggestions.<p></p>
</div>
<div><p></p></div>
<div>Finally, the authors would like to request working group adoption of this draft.<p></p>
</div>
<div><p>&nbsp;</p></div>
<div>Thanks!&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<p></p>
</div>
<div>Quintin<p></p>
</div>
</div>_______________________________________________<br>Pce mailing list<br><a href="mailto:Pce <at> ietf.org">Pce <at> ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/pce">https://www.ietf.org/mailman/listinfo/pce</a><br>
</div></span></blockquote>
</div>
<br>
</div>
</div>
rfc-editor | 3 Feb 05:04 2011

RFC 6123 on Inclusion of Manageability Sections in Path Computation Element (PCE) Working Group Drafts


A new Request for Comments is now available in online RFC libraries.

        
        RFC 6123

        Title:      Inclusion of Manageability Sections in 
                    Path Computation Element (PCE) Working Group 
                    Drafts 
        Author:     A. Farrel
        Status:     Historic
        Stream:     IETF
        Date:       February 2011
        Mailbox:    adrian <at> olddog.co.uk
        Pages:      13
        Characters: 28277
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-pce-manageability-requirements-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6123.txt

It has often been the case that manageability considerations have
been retrofitted to protocols after they have been specified,
standardized, implemented, or deployed.  This is sub-optimal.
Similarly, new protocols or protocol extensions are frequently
designed without due consideration of manageability requirements.

The Operations Area has developed "Guidelines for Considering
Operations and Management of New Protocols and Protocol Extensions"
(RFC 5706), and those guidelines have been adopted by the Path Computation
Element (PCE) Working Group.

Previously, the PCE Working Group used the recommendations contained
in this document to guide authors of Internet-Drafts on the contents
of "Manageability Considerations" sections in their work.  This
document is retained for historic reference.  This document 
defines a Historic Document for the Internet community.

This document is a product of the Path Computation Element Working Group of the IETF.

HISTORIC: This memo defines a Historic Document for the Internet
community.  It does not specify an Internet standard of any kind.
Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor <at> rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

Dhruv Dhody | 3 Feb 23:49 2011

Re: comments for draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

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:quintin.zhao <at> huawei.com]
Sent: Thursday, February 03, 2011 7:56 AM
To: dhruvd <at> huawei.com; pce <at> ietf.org
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:dhruvd <at> huawei.com

]
Sent: Monday, January 31, 2011 6:19 PM
To: qzhao <at> huawei.com
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!

 

<div>

<div class="Section1">

<p class="MsoNormal"><span>Dear Quintin, <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Thanks for your comments. <p></p></span></p>

<p class="MsoNormal"><span>I am working on a document about domain
sequence and will publish it before the next IETF meeting. <p></p></span></p>

<p class="MsoNormal"><span>I will take care to add a section
regarding the correlation between domain-seq and PCE-seq. <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Regards,<p></p></span></p>

<p class="MsoNormal"><span>Dhruv<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<div>

<p class="MsoNormal"><span>Dhruv Dhody</span><span><p></p></span></p>

<p class="MsoNormal"><span>Senior Technical Leader</span><span><p></p></span></p>

<p class="MsoNormal"><span>Huawei-Santa Clara, CA</span><span><p></p></span></p>

<p class="MsoNormal"><span>Work: (408) 330 4940</span><span><p></p></span></p>

<p class="MsoNormal"><span>Cell: (408) 667 8127</span><span><p></p></span></p>

<p><span lang="EN">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!</span><span lang="EN"><p></p></span></p>

</div>

<div>

<div class="MsoNormal" align="center"><span>

</span></div>

<p class="MsoNormal"><span>From:</span><span> Quintin Zhao
[mailto:quintin.zhao <at> huawei.com] <br><span>Sent:</span> Thursday, February 03, 2011
7:56 AM<br><span>To:</span> dhruvd <at> huawei.com;
pce <at> ietf.org<br><span>Subject:</span> FW: comments for
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07</span><p></p></p>

</div>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Dhruv,<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Thanks for your very detailed comments and suggestions! <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>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.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="msolistparagraph"><span><span>1)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span>Definition of Core-Tree: <p></p></span></p>

<p class="msolistparagraph"><span><p>&nbsp;</p></span></p>

<p class="msolistparagraph"><span>we will
update the definition of the core-tree to make it more clearer based on your
suggestion here.<p></p></span></p>

<p class="msolistparagraph"><span><p>&nbsp;</p></span></p>

<p class="msolistparagraph"><span><span>2)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><span>Domain sequence and PCE sequence: <p></p></span></p>

<p class="msolistparagraph"><span><p>&nbsp;</p></span></p>

<p class="msolistparagraph"><span>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.&nbsp; 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.<p></p></span></p>

<p class="msolistparagraph"><span>&nbsp;<p></p></span></p>

<span lang="EN"><span>3)<span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></span></span><span>SPT (shortest path tree) v/s MCT (minimum cost tree): </span><span lang="EN"><p></p></span><span lang="EN"><p>&nbsp;</p></span><span lang="EN">On</span><span>e way we can address this issue is that the transit PCE in the core-tree computation </span><span lang="EN">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. <p></p></span>

<p class="MsoNormal"><span lang="EN"><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span lang="EN">Quintin<p></p></span></p>

<p class="MsoNormal"><span lang="EN"><p>&nbsp;</p></span></p>

<p class="msolistparagraph"><span><p>&nbsp;</p></span></p>

<div>

<div>

<p class="MsoNormal"><span>From:</span><span> Dhruv Dhody [mailto:dhruvd <at> huawei.com</span><span><p></p></span></p>

<p class="MsoNormal"><span>] <br><span>Sent:</span> Monday, January 31, 2011
6:19 PM<br><span>To:</span> qzhao <at> huawei.com<br><span>Subject:</span> comments for
draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07<p></p></span></p>

</div>

</div>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Quintin, <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>I have following comments on the
&ldquo;draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07&rdquo;, any comments
on this are welcome from all. <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>1) Definition of Core-Tree: <p></p></span></p>

<p class="MsoNormal"><span>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. &nbsp;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. <p></p></span></p>

<p class="MsoNormal"><span>If confidentiality is a concern, path-key mechanism shall
be applied in those domains but the core-tree definition is not impacted. <p></p></span></p>

<p class="MsoNormal"><span>To summarize the issue here is the clear definition of
domain-tree, core-tree and final P2MP tree. <p></p></span></p>

<p class="MsoNormal"><span>Domain-Tree</span><span>: Should consist of
&nbsp;domain-sequence in form of a tree and has no information about BNs and
inter-AS TE links. <p></p></span></p>

<p class="MsoNormal"><span>Core-Tree: </span><span>&nbsp;&nbsp;A Core Tree is defined
as a tree which satisfies the following conditions:<p></p></span></p>

<p class="MsoNormal"><span>&nbsp;&nbsp; o&nbsp; The root of the core tree is the
ingress LSR in the root domain;<p></p></span></p>

<p class="MsoNormal"><span>&nbsp;&nbsp; o&nbsp; The leaves of the core tree are the
entry nodes in the leaf domains;<p></p></span></p>

<p class="MsoNormal"><span>&nbsp;&nbsp; o&nbsp; 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.<p></p></span></p>

<p class="MsoNormal"><span>Final Tree:</span><span> 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.<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>2) Domain-Seq V/s PCE-Seq<p></p></span></p>

<p class="MsoNormal"><span>RFC 5441 [BRPC] method uses IRO and sub-objects to
represent domain-sequence. In P2MP we should continue to use the similar
approach. <p></p></span></p>

<p class="MsoNormal"><span>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. <p></p></span></p>

<p class="MsoNormal"><span>Advantages<p></p></span></p>

<p class="MsoNormal"><span>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. <p></p></span></p>

<p class="MsoNormal"><span>b) There maybe multiple PCE in a domain, the selection of
PCE shouldn&rsquo;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. <p></p></span></p>

<p class="MsoNormal"><span>c) Domain sequence would be compatible to P2P inter-domain
BRPC method as described in RFC 5441. <p></p></span></p>

<p class="MsoNormal"><span>There is no need for PCE-Sequence and it doesn&rsquo;t
give any benefits over Domain Seq. &nbsp;<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>3) SPT (shortest path tree) v/s MCT (minimum cost tree)<p></p></span></p>

<p class="MsoNormal"><span>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.<p></p></span></p>

<p class="MsoNormal"><span>This is just for your information, so that an informed
decision can be taken based on this. <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Regards,<p></p></span></p>

<p class="MsoNormal"><span>Dhruv<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Dhruv Dhody</span><p></p></p>

<p class="MsoNormal"><span>Senior Technical Leader</span><p></p></p>

<p class="MsoNormal"><span>Huawei-Santa Clara, CA</span><p></p></p>

<p class="MsoNormal"><span>Work: (408) 330 4940</span><p></p></p>

<p class="MsoNormal"><span>Cell: (408) 667 8127</span><p></p></p>

<p><span lang="EN">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!</span><span lang="EN"><p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

</div>

</div>
Ramon Casellas | 4 Feb 09:52 2011
Picon

Re: comments for draft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

Dhruv, Quintin, all

See inline


On 03/02/2011 23:49, Dhruv Dhody wrote:
<!--a:link {mso-style-priority:99;} span.MSOHYPERLINK {mso-style-priority:99;} a:visited {mso-style-priority:99;} span.MSOHYPERLINKFOLLOWED {mso-style-priority:99;} p.MSOPLAINTEXT {mso-style-priority:99;} li.MSOPLAINTEXT {mso-style-priority:99;} div.MSOPLAINTEXT {mso-style-priority:99;} p {mso-style-priority:99;} pre {mso-style-priority:99;} p.MSOACETATE {mso-style-priority:99;} li.MSOACETATE {mso-style-priority:99;} div.MSOACETATE {mso-style-priority:99;} p.MSOLISTPARAGRAPH {mso-style-priority:34;} li.MSOLISTPARAGRAPH {mso-style-priority:34;} div.MSOLISTPARAGRAPH {mso-style-priority:34;} span.PLAINTEXTCHAR {mso-style-priority:99;} span.BALLOONTEXTCHAR {mso-style-priority:99;} span.HTMLPREFORMATTEDCHAR {mso-style-priority:99;} /* Font Definitions */ <at> font-face {font-family:SimSun; panose-1:2 1 6 0 3 1 1 1 1 1;} <at> font-face {font-family:Tahoma; panose-1:2 11 6 4 3 5 4 4 2 4;} <at> font-face {font-family:Candara; panose-1:2 14 5 2 3 3 3 2 2 4;} <at> font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} <at> font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} <at> font-face {font-family:"\ <at> SimSun";} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} p.MsoPlainText, li.MsoPlainText, div.MsoPlainText {margin:0in; margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier New";} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} pre {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:SimSun;} p.MsoAcetate, li.MsoAcetate, div.MsoAcetate {margin:0in; margin-bottom:.0001pt; font-size:8.0pt; font-family:Tahoma;} span.HTMLPreformattedChar {font-family:SimSun;} span.PlainTextChar {font-family:SimSun;} span.BalloonTextChar {font-family:Tahoma;} p.msolistparagraph, li.msolistparagraph, div.msolistparagraph {margin:0in; margin-bottom:.0001pt; text-indent:21.0pt; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle25 {mso-style-type:personal; font-family:Arial; color:windowtext;} span.EmailStyle26 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle27 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle28 {mso-style-type:personal; font-family:Calibri; color:#1F497D;} span.EmailStyle29 {mso-style-type:personal-reply; font-family:Arial; color:navy;} <at> page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} /* List Definitions */ <at> list l0 {mso-list-id:1406802115; mso-list-type:hybrid; mso-list-template-ids:-170870978 -1109869000 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;} <at> list l0:level1 {mso-level-text:"%1\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:.25in; text-indent:-.25in;} <at> list l0:level2 {mso-level-number-format:alpha-lower; mso-level-text:"%2\)"; mso-level-tab-stop:none; mso-level-number-position:left; margin-left:42.0pt; text-indent:-21.0pt;} <at> list l0:level3 {mso-level-tab-stop:1.5in; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level4 {mso-level-tab-stop:2.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level5 {mso-level-tab-stop:2.5in; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level6 {mso-level-tab-stop:3.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level7 {mso-level-tab-stop:3.5in; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level8 {mso-level-tab-stop:4.0in; mso-level-number-position:left; text-indent:-.25in;} <at> list l0:level9 {mso-level-tab-stop:4.5in; mso-level-number-position:left; text-indent:-.25in;} ol {margin-bottom:0in;} ul {margin-bottom:0in;} -->

 

From: Dhruv Dhody [mailto:dhruvd <at> huawei.com

 

Quintin,

 

 

1) Definition of Core-Tree:

   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.


 

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.



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?



 

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.

 

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.

<div>
    Dhruv, Quintin, all<br><br>
    See inline<br><br><br>
    On 03/02/2011 23:49, Dhruv Dhody wrote:
    <blockquote cite="mid:002d01cbc3f4$953a8cf0$9822c10a <at> china.huawei.com" type="cite">

&lt;!--a:link
	{mso-style-priority:99;}
span.MSOHYPERLINK
	{mso-style-priority:99;}
a:visited
	{mso-style-priority:99;}
span.MSOHYPERLINKFOLLOWED
	{mso-style-priority:99;}
p.MSOPLAINTEXT
	{mso-style-priority:99;}
li.MSOPLAINTEXT
	{mso-style-priority:99;}
div.MSOPLAINTEXT
	{mso-style-priority:99;}
p
	{mso-style-priority:99;}
pre
	{mso-style-priority:99;}
p.MSOACETATE
	{mso-style-priority:99;}
li.MSOACETATE
	{mso-style-priority:99;}
div.MSOACETATE
	{mso-style-priority:99;}
p.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
li.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
div.MSOLISTPARAGRAPH
	{mso-style-priority:34;}
span.PLAINTEXTCHAR
	{mso-style-priority:99;}
span.BALLOONTEXTCHAR
	{mso-style-priority:99;}
span.HTMLPREFORMATTEDCHAR
	{mso-style-priority:99;}

 /* Font Definitions */
  <at> font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 <at> font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 <at> font-face
	{font-family:Candara;
	panose-1:2 14 5 2 3 3 3 2 2 4;}
 <at> font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 <at> font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 <at> font-face
	{font-family:"\ <at> SimSun";}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
pre
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:SimSun;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:Tahoma;}
span.HTMLPreformattedChar
	{font-family:SimSun;}
span.PlainTextChar
	{font-family:SimSun;}
span.BalloonTextChar
	{font-family:Tahoma;}
p.msolistparagraph, li.msolistparagraph, div.msolistparagraph
	{margin:0in;
	margin-bottom:.0001pt;
	text-indent:21.0pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle25
	{mso-style-type:personal;
	font-family:Arial;
	color:windowtext;}
span.EmailStyle26
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle27
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle28
	{mso-style-type:personal;
	font-family:Calibri;
	color:#1F497D;}
span.EmailStyle29
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
 <at> page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
  <at> list l0
	{mso-list-id:1406802115;
	mso-list-type:hybrid;
	mso-list-template-ids:-170870978 -1109869000 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
 <at> list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:.25in;
	text-indent:-.25in;}
 <at> list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-text:"%2\)";
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	margin-left:42.0pt;
	text-indent:-21.0pt;}
 <at> list l0:level3
	{mso-level-tab-stop:1.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
 <at> list l0:level4
	{mso-level-tab-stop:2.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
 <at> list l0:level5
	{mso-level-tab-stop:2.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
 <at> list l0:level6
	{mso-level-tab-stop:3.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
 <at> list l0:level7
	{mso-level-tab-stop:3.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
 <at> list l0:level8
	{mso-level-tab-stop:4.0in;
	mso-level-number-position:left;
	text-indent:-.25in;}
 <at> list l0:level9
	{mso-level-tab-stop:4.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--&gt;
<div class="Section1">
<br><p class="msolistparagraph"><span><p>&nbsp; <br></p></span></p>
        <div>
          <div>
            <p class="MsoNormal"><span>From:</span><span> Dhruv Dhody
                  [<a class="moz-txt-link-freetext" href="mailto:dhruvd <at> huawei.com">mailto:dhruvd <at> huawei.com</a></span><span><p></p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
        <p class="MsoNormal"><span>Quintin, <p></p></span></p>
        <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
        <span><p>&nbsp;</p></span>
        <p class="MsoNormal"><span>1)
              Definition of Core-Tree: <p></p></span></p>
        <span><p></p></span>
        <p class="MsoNormal"><span>&nbsp;&nbsp; o&nbsp; 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.<p></p></span></p>
      </div>
    </blockquote>
    <br>
    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.<br><br><br><blockquote cite="mid:002d01cbc3f4$953a8cf0$9822c10a <at> china.huawei.com" type="cite">
      <div class="Section1">
<span><p>&nbsp;</p></span>
        <p class="MsoNormal"><span>2)
              Domain-Seq V/s PCE-Seq<p></p></span></p>
        <p class="MsoNormal"><span>RFC 5441
              [BRPC] method uses IRO and sub-objects to
              represent domain-sequence. In P2MP we should continue to
              use the similar
              approach. <p></p></span></p>
        <p class="MsoNormal"><span><br></span></p>
      </div>
    </blockquote>
    <br>
    Good point. <br><br>
    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. <br><br>
    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?)<br><br>
    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?
    <br><br><br><br><span><p></p></span>
    <blockquote cite="mid:002d01cbc3f4$953a8cf0$9822c10a <at> china.huawei.com" type="cite">
      <div class="Section1">
        <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
        <p class="MsoNormal"><span>3) SPT
              (shortest path tree) v/s MCT (minimum cost tree)<p></p></span></p>
        <p class="MsoNormal"><span>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.<p></p></span></p>
        <p class="MsoNormal"><span>This is
              just for your information, so that an informed
              decision can be taken based on this. <p></p></span></p>
        <p class="MsoNormal"><span><p>&nbsp;</p></span></p>
      </div>
    </blockquote>
    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.<br><br><br>
    Best regards,<br>
    R.<br><br>
</div>
Dhruv Dhody | 4 Feb 22:32 2011

Re: comments fordraft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

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

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: pce-bounces <at> ietf.org [mailto:pce-bounces <at> ietf.org] On Behalf Of Ramon Casellas
Sent: Friday, February 04, 2011 12:52 AM
To: pce <at> ietf.org
Subject: Re: [Pce] comments fordraft-zhao-pce-pcep-inter-domain-p2mp-procedures-07

 

Dhruv, Quintin, all

See inline


On 03/02/2011 23:49, Dhruv Dhody wrote:

 

 

From: Dhruv Dhody [mailto:dhruvd <at> huawei.com

 

Quintin,

 

 

1) Definition of Core-Tree:

   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.

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.   

 

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.

 


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.   


 

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.

 

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.

<div>

<div class="Section1">

<p class="MsoNormal"><span>Dear Ramon, <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Thanks for your comments, please find my reply
inline. <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Regards,<p></p></span></p>

<p class="MsoNormal"><span>Dhruv<p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<div>

<p class="MsoNormal"><span>Dhruv Dhody</span><p></p></p>

<p class="MsoNormal"><span>Senior Technical Leader</span><p></p></p>

<p class="MsoNormal"><span>Futurewei-Santa Clara, CA</span><p></p></p>

<p class="MsoNormal"><span>Work: (408) 330 4940</span><p></p></p>

<p class="MsoNormal"><span>Cell: (408) 667 8127</span><p></p></p>

<p><span lang="EN">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!</span><span lang="EN"><p></p></span></p>

</div>

<div>

<div class="MsoNormal" align="center"><span>

</span></div>

<p class="MsoNormal"><span>From:</span><span> pce-bounces <at> ietf.org [mailto:pce-bounces <at> ietf.org] <span>On Behalf Of </span>Ramon Casellas<br><span>Sent:</span> Friday, February 04, 2011
12:52 AM<br><span>To:</span> pce <at> ietf.org<br><span>Subject:</span> Re: [Pce] comments
fordraft-zhao-pce-pcep-inter-domain-p2mp-procedures-07</span><span><p></p></span></p>

</div>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Dhruv, Quintin, all<br><br>
See inline<br><br><br>
On 03/02/2011 23:49, Dhruv Dhody wrote: <p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="msolistparagraph"><span><p>&nbsp; <br><br></p></span><p></p></p>

<div>

<div>

<p class="MsoNormal"><span>From:</span><span> Dhruv
Dhody [<a href="mailto:dhruvd <at> huawei.com">mailto:dhruvd <at> huawei.com</a></span><p></p></p>

</div>

</div>

<p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span><p></p></p>

<p class="MsoNormal"><span>Quintin, <p></p></span><p></p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span><p></p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span> <p></p></p>

<p class="MsoNormal"><span>1) Definition of Core-Tree: <p></p></span><p></p></p>

<p class="MsoNormal"><span><p></p>&nbsp;&nbsp; o&nbsp;
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.<p></p></span><p></p></p>

<p class="MsoNormal"><span><br>
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.<br><br></span><span>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. &nbsp;&nbsp;</span><br><br><p></p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span> <p></p></p>

<p class="MsoNormal"><span>2) Domain-Seq V/s PCE-Seq<p></p></span><p></p></p>

<p class="MsoNormal"><span>RFC 5441 [BRPC] method uses IRO
and sub-objects to represent domain-sequence. In P2MP we should continue to use
the similar approach. <p></p></span><p></p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span><br>
Good point. <br><br>
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. <br><br>
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?)<br><br>
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? <br><br></span><span>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. <p></p></span></p>

<p class="MsoNormal"><span>In the domain-seq draft [which I am
preparing], I have added IANA considerations to introduce sub-object for IGP
Areas. I think it&rsquo;s very much needed. &nbsp;&nbsp;</span><br><br><br><p></p></p>

<p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span><p></p></p>

<p class="MsoNormal"><span>3) SPT (shortest path tree) v/s
MCT (minimum cost tree)<p></p></span><p></p></p>

<p class="MsoNormal"><span>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.<p></p></span><p></p></p>

<p class="MsoNormal"><span>This is just for your information,
so that an informed decision can be taken based on this. <p></p></span><p></p></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span><p></p></p>

<p class="MsoNormal"><span>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.</span><span><p></p></span></p>

<p class="MsoNormal"><span><p>&nbsp;</p></span></p>

<p class="MsoNormal"><span>Dhruv:
Okay!<p></p></span></p>

<p class="MsoNormal"><span><br><br><br>
Best regards,<br>
R.<p></p></span></p>

</div>

</div>
JP Vasseur | 6 Feb 20:18 2011
Picon

Fwd: Pce post from rfc-editor <at> rfc-editor.org requires approval



Begin forwarded message:

Date: February 5, 2011 10:54:38 PM GMT+01:00
Subject: Pce post from rfc-editor <at> rfc-editor.org requires approval

As list administrator, your authorization is requested for the
following mailing list posting:

    List:    Pce <at> ietf.org
    From:    rfc-editor <at> rfc-editor.org
    Subject: [Technical Errata Reported] RFC5521 (2705)
    Reason:  Too many recipients to the message

At your convenience, visit:

    https://www.ietf.org/mailman/admindb/pce
       
to approve or deny the request.


From: "RFC Errata System" <rfc-editor <at> rfc-editor.org>
Date: February 5, 2011 10:54:32 PM GMT+01:00
Subject: [Technical Errata Reported] RFC5521 (2705)



The following errata report has been submitted for RFC5521,
"Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5521&eid=2705

--------------------------------------
Type: Technical
Reported by: Ramon Casellas <ramon.casellas <at> cttc.es>

Section: 2.1.1

Original Text
-------------
 Unnumbered Interface ID Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 3   |     Length    |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TE Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TE Router ID and Interface ID fields are as defined in [RFC3477].






Oki, et al.                 Standards Track                     [Page 7]

RFC 5521        Extensions to PCEP for Route Exclusions       April 2009


   Autonomous System Number Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 4   |     Length    |      2-Octet AS Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that as in other PCEP objects [RFC5440] and RSVP-TE objects
   [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is
   provided.  It is anticipated that, as 4-octet AS Numbers become more
   common, both PCEP and RSVP-TE will be updated in a consistent way to
   add this support.

   SRLG Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 5   |     Length    |       SRLG Id (4 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SRLG Id (continued)      |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute SHOULD be set to two (2) and SHOULD be ignored on
   receipt.

Corrected Text
--------------
 Unnumbered Interface ID Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 4   |     Length    |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        TE Router ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Interface ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The TE Router ID and Interface ID fields are as defined in [RFC3477].






Oki, et al.                 Standards Track                     [Page 7]

RFC 5521        Extensions to PCEP for Route Exclusions       April 2009


   Autonomous System Number Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 32  |     Length    |      2-Octet AS Number        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Note that as in other PCEP objects [RFC5440] and RSVP-TE objects
   [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is
   provided.  It is anticipated that, as 4-octet AS Numbers become more
   common, both PCEP and RSVP-TE will be updated in a consistent way to
   add this support.

   SRLG Subobject

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |X|  Type = 34  |     Length    |       SRLG Id (4 bytes)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      SRLG Id (continued)      |    Reserved   |  Attribute    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute SHOULD be set to two (2) and SHOULD be ignored on
   receipt.

Notes
-----
Completes the existing errata, providing correct values for XRO sub-object types in object formats. The new values must be in line with RSVP-TE / CCAMP RFC4874 and  http://www.iana.org/assignments/pcep/pcep.xml#xro-flag-field

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5521 (draft-ietf-pce-pcep-xro-06)
--------------------------------------
Title               : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions
Publication Date    : April 2009
Author(s)           : E. Oki, T. Takeda, A. Farrel
Category            : PROPOSED STANDARD
Source              : Path Computation Element
Area                : Routing
Stream              : IETF
Verifying Party     : IESG




Date: February 5, 2011 10:55:30 PM GMT+01:00
Subject: confirm 9dbb9e6578241b532c303d8f9a8360e79be182ca


If you reply to this message, keeping the Subject: header intact,
Mailman will discard the held message.  Do this if the message is
spam.  If you reply to this message and include an Approved: header
with the list password in it, the message will be approved for posting
to the list.  The Approved: header can also appear in the first line
of the body of the reply.




<div>
<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>
<span>From: </span><span>&lt;<a href="mailto:pce-owner <at> ietf.org">pce-owner <at> ietf.org</a>&gt;<br></span>
</div>
<div>
<span>Date: </span><span>February 5, 2011 10:54:38 PM GMT+01:00<br></span>
</div>
<div>
<span>To: </span><span>&lt;<a href="mailto:pce-owner <at> ietf.org">pce-owner <at> ietf.org</a>&gt;<br></span>
</div>
<div>
<span>Subject: </span><span>Pce post from <a href="mailto:rfc-editor <at> rfc-editor.org">rfc-editor <at> rfc-editor.org</a> requires approval<br></span>
</div>
<br><div>
<p>As list administrator, your authorization is requested for the<br>
following mailing list posting:<br><br>
&nbsp;&nbsp;&nbsp; List:&nbsp;&nbsp;&nbsp; <a href="mailto:Pce <at> ietf.org">Pce <at> ietf.org</a><br>
&nbsp;&nbsp;&nbsp; From:&nbsp;&nbsp;&nbsp; <a href="mailto:rfc-editor <at> rfc-editor.org">rfc-editor <at> rfc-editor.org</a><br>
&nbsp;&nbsp;&nbsp; Subject: [Technical Errata Reported] RFC5521 (2705)<br>
&nbsp;&nbsp;&nbsp; Reason:&nbsp; Too many recipients to the message<br><br>
At your convenience, visit:<br><br>
&nbsp;&nbsp;&nbsp; <a href="https://www.ietf.org/mailman/admindb/pce">https://www.ietf.org/mailman/admindb/pce</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br>
to approve or deny the request.<br>
</p>

</div>
<br><div>
<span>From: </span><span>"RFC Errata System" &lt;<a href="mailto:rfc-editor <at> rfc-editor.org">rfc-editor <at> rfc-editor.org</a>&gt;<br></span>
</div>
<div>
<span>Date: </span><span>February 5, 2011 10:54:32 PM GMT+01:00<br></span>
</div>
<div>
<span>To: </span><span>&lt;<a href="mailto:oki <at> ice.uec.ac.jp">oki <at> ice.uec.ac.jp</a>&gt;, &lt;<a href="mailto:takeda.tomonori <at> lab.ntt.co.jp">takeda.tomonori <at> lab.ntt.co.jp</a>&gt;, &lt;<a href="mailto:adrian <at> olddog.co.uk">adrian <at> olddog.co.uk</a>&gt;, &lt;<a href="mailto:stbryant <at> cisco.com">stbryant <at> cisco.com</a>&gt;, &lt;<a href="mailto:adrian.farrel <at> huawei.com">adrian.farrel <at> huawei.com</a>&gt;, &lt;<a href="mailto:jpv <at> cisco.com">jpv <at> cisco.com</a>&gt;, &lt;<a href="mailto:julien.meuric <at> orange-ftgroup.com">julien.meuric <at> orange-ftgroup.com</a>&gt;<br></span>
</div>
<div>
<span>Cc: </span><span>&lt;<a href="mailto:ramon.casellas <at> cttc.es">ramon.casellas <at> cttc.es</a>&gt;, &lt;<a href="mailto:pce <at> ietf.org">pce <at> ietf.org</a>&gt;, &lt;<a href="mailto:rfc-editor <at> rfc-editor.org">rfc-editor <at> rfc-editor.org</a>&gt;<br></span>
</div>
<div>
<span>Subject: </span><span>[Technical Errata Reported] RFC5521 (2705)<br></span>
</div>
<br><br><div>

<br><p>The following errata report has been submitted for RFC5521,<br>
"Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions".<br><br>
--------------------------------------<br>
You may review the report below and at:<br><a href="http://www.rfc-editor.org/errata_search.php?rfc=5521&amp;eid=2705">http://www.rfc-editor.org/errata_search.php?rfc=5521&amp;eid=2705</a><br><br>
--------------------------------------<br>
Type: Technical<br>
Reported by: Ramon Casellas &lt;<a href="mailto:ramon.casellas <at> cttc.es">ramon.casellas <at> cttc.es</a>&gt;<br><br>
Section: 2.1.1<br><br>
Original Text<br>
-------------<br>
&nbsp;Unnumbered Interface ID Subobject<br><br>
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |X|&nbsp; Type = 3&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Reserved&nbsp;&nbsp; |&nbsp; Attribute&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TE Router ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
&nbsp;&nbsp; The TE Router ID and Interface ID fields are as defined in [RFC3477].<br><br><br><br><br><br><br>
Oki, et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 7]<br><br>
RFC 5521&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Extensions to PCEP for Route Exclusions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; April 2009<br><br><br>
&nbsp;&nbsp; Autonomous System Number Subobject<br><br>
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |X|&nbsp; Type = 4&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2-Octet AS Number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
&nbsp;&nbsp; Note that as in other PCEP objects [RFC5440] and RSVP-TE objects<br>
&nbsp;&nbsp; [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is<br>
&nbsp;&nbsp; provided.&nbsp; It is anticipated that, as 4-octet AS Numbers become more<br>
&nbsp;&nbsp; common, both PCEP and RSVP-TE will be updated in a consistent way to<br>
&nbsp;&nbsp; add this support.<br><br>
&nbsp;&nbsp; SRLG Subobject<br><br>
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |X|&nbsp; Type = 5&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SRLG Id (4 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SRLG Id (continued)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Reserved&nbsp;&nbsp; |&nbsp; Attribute&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
&nbsp;&nbsp; The Attribute SHOULD be set to two (2) and SHOULD be ignored on<br>
&nbsp;&nbsp; receipt.<br><br>
Corrected Text<br>
--------------<br>
&nbsp;Unnumbered Interface ID Subobject<br><br>
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |X|&nbsp; Type = 4&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Reserved&nbsp;&nbsp; |&nbsp; Attribute&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; TE Router ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interface ID&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
&nbsp;&nbsp; The TE Router ID and Interface ID fields are as defined in [RFC3477].<br><br><br><br><br><br><br>
Oki, et al.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Standards Track&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [Page 7]<br><br>
RFC 5521&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Extensions to PCEP for Route Exclusions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; April 2009<br><br><br>
&nbsp;&nbsp; Autonomous System Number Subobject<br><br>
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |X|&nbsp; Type = 32&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2-Octet AS Number&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
&nbsp;&nbsp; Note that as in other PCEP objects [RFC5440] and RSVP-TE objects<br>
&nbsp;&nbsp; [RFC3209], no support for 4-octet Autonomous System (AS) Numbers is<br>
&nbsp;&nbsp; provided.&nbsp; It is anticipated that, as 4-octet AS Numbers become more<br>
&nbsp;&nbsp; common, both PCEP and RSVP-TE will be updated in a consistent way to<br>
&nbsp;&nbsp; add this support.<br><br>
&nbsp;&nbsp; SRLG Subobject<br><br>
&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3<br>
&nbsp;&nbsp;&nbsp; 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<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |X|&nbsp; Type = 34&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SRLG Id (4 bytes)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br>
&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SRLG Id (continued)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; Reserved&nbsp;&nbsp; |&nbsp; Attribute&nbsp;&nbsp;&nbsp; |<br>
&nbsp;&nbsp; +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<br><br>
&nbsp;&nbsp; The Attribute SHOULD be set to two (2) and SHOULD be ignored on<br>
&nbsp;&nbsp; receipt.<br><br>
Notes<br>
-----<br>
Completes the existing errata, providing correct values for XRO sub-object types in object formats. The new values must be in line with RSVP-TE / CCAMP RFC4874 and&nbsp; <a href="http://www.iana.org/assignments/pcep/pcep.xml#xro-flag-field">http://www.iana.org/assignments/pcep/pcep.xml#xro-flag-field</a><br><br>
Instructions:<br>
-------------<br>
This errata is currently posted as "Reported". If necessary, please<br>
use "Reply All" to discuss whether it should be verified or<br>
rejected. When a decision is reached, the verifying party (IESG)<br>
can log in to change the status and edit the report, if necessary.<br><br>
--------------------------------------<br>
RFC5521 (draft-ietf-pce-pcep-xro-06)<br>
--------------------------------------<br>
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions<br>
Publication Date&nbsp;&nbsp;&nbsp; : April 2009<br>
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : E. Oki, T. Takeda, A. Farrel<br>
Category&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : PROPOSED STANDARD<br>
Source&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Path Computation Element<br>
Area&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Routing<br>
Stream&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : IETF<br>
Verifying Party&nbsp;&nbsp;&nbsp;&nbsp; : IESG<br>
</p>

</div>
<br><br><br><div>
<span>From: </span><span>&lt;<a href="mailto:pce-request <at> ietf.org">pce-request <at> ietf.org</a>&gt;<br></span>
</div>
<div>
<span>Date: </span><span>February 5, 2011 10:55:30 PM GMT+01:00<br></span>
</div>
<div>
<span>Subject: </span><span>confirm 9dbb9e6578241b532c303d8f9a8360e79be182ca<br></span>
</div>
<br><br><div>
<p>If you reply to this message, keeping the Subject: header intact,<br>
Mailman will discard the held message.&nbsp; Do this if the message is<br>
spam.&nbsp; If you reply to this message and include an Approved: header<br>
with the list password in it, the message will be approved for posting<br>
to the list.&nbsp; The Approved: header can also appear in the first line<br>
of the body of the reply.<br>
</p>

</div>
<br><br>
</blockquote>
</div>
<br>
</div>
Tomonori TAKEDA | 9 Feb 16:02 2011
Picon

iPOP2011 Call for Presentation

(Apologies if you received multiple copies of this message.)

Dear CCAMP, PCE, MPLS and MPLS-TP subscribers,

iPOP2011 Call for Presentation is now open as follows.
The deadline for submitting presentation proposal is February 25th.

Best Regards,
Tomonori Takeda

------------------------------------------------------------------------
                     Call for Presentation

7th  International Conference on IP + Optical Network (iPOP 2011)
                         June 2-3, 2010
               NEC Tamagawa Plant, Kanagawa, Japan
                  http://www.pilab.jp/ipop2011/

The conference is intended to share among the industry and the academia,
the knowledge, new findings, and experience on the state-of-the art of
IP and optical networking technologies. It features technical sessions
and planned exhibitions. The opportunity to participate is open to all.

Important Dates:
Submission deadline of one-page abstract: February 25, 2010 
Notification of acceptance: April 4, 2010
Submission deadline of final presentation slides: April 22, 2010

The Technical Program Committee for iPOP 2010 is soliciting presentation 
proposals for this conference. Protocol design, experiment, theory, 
implementation, and operational experiences are solicited.
The topics of the conference will include but not limited to the following:

* GMPLS/ASON technologies
* GMPLS Network management, OA&M
* Multi-layer network (MLN) / Multi-region network (MRN)
* Path Computation Element (PCE), Traffic engineering
* Inter-area/Inter-AS network
* L1VPN, Bandwidth on Demand, and Photonic Grid
* Wavelength Switched Optical Networks  (WSON), Routing wavelength
  assignment, Impairment management
* GMPLS-controlled Ethernet Label Switching  (GELS) and related Ethernet
  transport technologies
* Carrier Ethernet and MPLS-TP
* Photonic Network for NxGN and NwGN
* Application with high-bandwidth demand
* Testbed, field trial

If you wish to submit a topic for consideration, please send an Extended 
Abstracts of a 400 words and a maximum of 1 page, including figures and 
diagrams, speaker’s name, affiliation, and contact information 
to the Technical Program Committee at ipop2011-CFP <at> pilab.jp.
Please see http://www.pilab.jp/ipop2011/ for more details.
----------------------------------------------------------------------

Ramon Casellas | 15 Feb 09:55 2011
Picon

Question / issue PCEP port restriction - multiple PCEP adjacencies

Dear PCErs,

During some interoperability tests, we found an issue with the PCEP 
protocol and RFC5440 which manifests when using specific (although 
common) operating systems and we would appreciate your feedback to 
evaluate our options.

RFC5440 states (section 5)  that PCEP operates over TCP using a 
registered TCP port (4189) and all PCEP messages MUST be sent using the 
registered TCP port for the source and destination TCP port. Moreover, 
only one active connection between to given hosts/peers may be active at 
a time.
Although this is conceptually valid, I fail to see the reasoning behind 
the first restriction, and I see the second one as a direct consequence 
of the first.

The use case is as follows: assume a PCE host, with a PCEid address (in 
line with the "NodeID" "RouterID", or Loopback address, lo:0, defined as 
an IP address such that it is valid provided there is some connectivity, 
etc.)
The PCE creates a socket which is listening for TCP/PCEP connections 
("binding" to either the INADDR_ANY, 0.0.0.0 or restrict it to such 
PCEid address, but in any case to the port 4189).  At the same time it 
should also be able to have/initiate persistent TCP/PCEP connections to 
other peers (say, as a client), ideally keeping the same loopback 
address (NodeID) as the source IP address, while forcing the source port 
to what the RFC requires.

The main problem is that using that single PCEid address, it is not 
possible, or at least not possible in a portable way, to "bind" or 
associate several sockets to the same (local address, local port) pair. 
Of course,it should be theoretically possible, given that TCP 
connections would still be different considering the tuple (srcaddr, 
4189, dstaddr, 4189) but in practice it isn't:

After the first "listening" socket, the PCE would, for each persistent 
peer,
(i) create a socket SOCK_STREAM,
(ii) bind it to nodeid/4189 and
(iii) connect to remote peer/4189.

The first bind system call may fail depending on how the server is 
listening for connections (even worse, it some systems the bind system 
call may hijack the listening socket) or the second peer bind would fail 
since it would try to  bind to the same local address/port. For example, 
the GNU/Linux man page for bind is clear: ip(7) "Only one IP socket may 
be bound to any given local (address, port) pair". In technical terms, 
PCEP requires duplicate bindings at the socket level. Some systems may 
implement SO_REUSEPORT (1) socket option which could allow that, 
although it main use is to bind multicast addresses, or enable some sort 
of load sharing amongst TCP listeners in several threads. Unfortunately 
this is not implemented for example in GNU/Linux, although some 
non-official patches have been proposed (2). It is not clear whether it 
will be integrated or not.

Our workarounds seem to be either: allow clients to bind to port 0 
(ephemeral port) and use such allocated (dynamic) port (which is not 
compliant with RFC), or set IP aliases so each bind uses a different 
local address (we may need as many local addresses as peers, and some 
"mapping" to uniquely identify a PCE).

For what is worth, in my humble opinion the standard RFC is too strict 
requiring that all (client) sockets bind to port 4189

In summary we would appreciate your views on this:

a) what's the reasoning to force clients to bind on 4189 rather than say 
like in http? -- sometimes it is argued that this simplifies management 
such as firewall rules, etc. but I do not agree --

b) why limit to a single PCEP connection between two peers (other than a 
direct consequence of a) ), rather than allowing several parallel 
connections, provided that hosts use a single IP address and thus they 
can be identified?

c) As potential PCE implementers, have you encountered this issue, did 
you work around it? Are we missing something obvious?

Any feedback is appreciated

Best regards,

Ramon

(1) http://wiki.treck.com/Socket_Options

(1) http://marc.info/?l=linux-netdev&m=127165882728524&w=2 
<http://marc.info/?l=linux-netdev&m=127165882728524&w=2>

--

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01

Christian.Kaas-Petersen | 15 Feb 10:49 2011

Re: Question / issue PCEP port restriction - multiple PCEP adjacencies

Just my input (worth about 2 cents).

Although not explicitly stated in RFC 5440, the PCEP protocol has copied
a lot of features from BGP (OPEN, KEEPALIVE, and CLOSE messages
being the most obvious).  BGP uses TCP port 179, but only when 
listening; the BGP peer taking the initiative to connect to another BGP
peer may use any BGP port number.  I agree, there is no obvious
reason for forcing a PCEP client to use port 4189 as source port.

Christian 
________________________________________
From: pce-bounces <at> ietf.org [pce-bounces <at> ietf.org] On Behalf Of Ramon Casellas [ramon.casellas <at> cttc.es]
Sent: Tuesday, February 15, 2011 10:55 AM
To: pce <at> ietf.org; strongest-wp4 <at> ac.upc.edu
Subject: [Pce] Question / issue PCEP port restriction - multiple PCEP   adjacencies

Dear PCErs,

During some interoperability tests, we found an issue with the PCEP
protocol and RFC5440 which manifests when using specific (although
common) operating systems and we would appreciate your feedback to
evaluate our options.

RFC5440 states (section 5)  that PCEP operates over TCP using a
registered TCP port (4189) and all PCEP messages MUST be sent using the
registered TCP port for the source and destination TCP port. Moreover,
only one active connection between to given hosts/peers may be active at
a time.
Although this is conceptually valid, I fail to see the reasoning behind
the first restriction, and I see the second one as a direct consequence
of the first.

The use case is as follows: assume a PCE host, with a PCEid address (in
line with the "NodeID" "RouterID", or Loopback address, lo:0, defined as
an IP address such that it is valid provided there is some connectivity,
etc.)
The PCE creates a socket which is listening for TCP/PCEP connections
("binding" to either the INADDR_ANY, 0.0.0.0 or restrict it to such
PCEid address, but in any case to the port 4189).  At the same time it
should also be able to have/initiate persistent TCP/PCEP connections to
other peers (say, as a client), ideally keeping the same loopback
address (NodeID) as the source IP address, while forcing the source port
to what the RFC requires.

The main problem is that using that single PCEid address, it is not
possible, or at least not possible in a portable way, to "bind" or
associate several sockets to the same (local address, local port) pair.
Of course,it should be theoretically possible, given that TCP
connections would still be different considering the tuple (srcaddr,
4189, dstaddr, 4189) but in practice it isn't:

After the first "listening" socket, the PCE would, for each persistent
peer,
(i) create a socket SOCK_STREAM,
(ii) bind it to nodeid/4189 and
(iii) connect to remote peer/4189.

The first bind system call may fail depending on how the server is
listening for connections (even worse, it some systems the bind system
call may hijack the listening socket) or the second peer bind would fail
since it would try to  bind to the same local address/port. For example,
the GNU/Linux man page for bind is clear: ip(7) "Only one IP socket may
be bound to any given local (address, port) pair". In technical terms,
PCEP requires duplicate bindings at the socket level. Some systems may
implement SO_REUSEPORT (1) socket option which could allow that,
although it main use is to bind multicast addresses, or enable some sort
of load sharing amongst TCP listeners in several threads. Unfortunately
this is not implemented for example in GNU/Linux, although some
non-official patches have been proposed (2). It is not clear whether it
will be integrated or not.

Our workarounds seem to be either: allow clients to bind to port 0
(ephemeral port) and use such allocated (dynamic) port (which is not
compliant with RFC), or set IP aliases so each bind uses a different
local address (we may need as many local addresses as peers, and some
"mapping" to uniquely identify a PCE).

For what is worth, in my humble opinion the standard RFC is too strict
requiring that all (client) sockets bind to port 4189

In summary we would appreciate your views on this:

a) what's the reasoning to force clients to bind on 4189 rather than say
like in http? -- sometimes it is argued that this simplifies management
such as firewall rules, etc. but I do not agree --

b) why limit to a single PCEP connection between two peers (other than a
direct consequence of a) ), rather than allowing several parallel
connections, provided that hosts use a single IP address and thus they
can be identified?

c) As potential PCE implementers, have you encountered this issue, did
you work around it? Are we missing something obvious?

Any feedback is appreciated

Best regards,

Ramon

(1) http://wiki.treck.com/Socket_Options

(1) http://marc.info/?l=linux-netdev&m=127165882728524&w=2
<http://marc.info/?l=linux-netdev&m=127165882728524&w=2>

--
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area -- http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss 7 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 16 -- Fax. +34 93 645 29 01

_______________________________________________
Pce mailing list
Pce <at> ietf.org
https://www.ietf.org/mailman/listinfo/pce
Julien Meuric | 15 Feb 11:06 2011

Re: Question / issue PCEP port restriction - multiple PCEP adjacencies

Hi Ramon.

Thank you for sharing your implementation experience. This reminds me of 
an old thread on this list: 
http://www.ietf.org/mail-archive/web/pce/current/msg02096.html

That really looks like RFC 5440 is facing a lack in the implementation 
of the Linux OS. If compliance to the RFC requires to implement the 
patch you mention, as immediate solution I suggest to do so and to post 
any bug report/implementation feedback that may advocate including it 
for further system releases.

To all *implementers* of PCEP, a feedback on your own experience, 
associated to the OS you use, would be very appreciated. Experience over 
BSD and any Unix system would be much valuable. You may contact the 
chairs privately if you like.

Thanks,

Julien

Le 15/02/2011 09:55, Ramon Casellas a écrit :
> Dear PCErs,
>
> During some interoperability tests, we found an issue with the PCEP 
> protocol and RFC5440 which manifests when using specific (although 
> common) operating systems and we would appreciate your feedback to 
> evaluate our options.
>
> RFC5440 states (section 5)  that PCEP operates over TCP using a 
> registered TCP port (4189) and all PCEP messages MUST be sent using 
> the registered TCP port for the source and destination TCP port. 
> Moreover, only one active connection between to given hosts/peers may 
> be active at a time.
> Although this is conceptually valid, I fail to see the reasoning 
> behind the first restriction, and I see the second one as a direct 
> consequence of the first.
>
> The use case is as follows: assume a PCE host, with a PCEid address 
> (in line with the "NodeID" "RouterID", or Loopback address, lo:0, 
> defined as an IP address such that it is valid provided there is some 
> connectivity, etc.)
> The PCE creates a socket which is listening for TCP/PCEP connections 
> ("binding" to either the INADDR_ANY, 0.0.0.0 or restrict it to such 
> PCEid address, but in any case to the port 4189).  At the same time it 
> should also be able to have/initiate persistent TCP/PCEP connections 
> to other peers (say, as a client), ideally keeping the same loopback 
> address (NodeID) as the source IP address, while forcing the source 
> port to what the RFC requires.
>
> The main problem is that using that single PCEid address, it is not 
> possible, or at least not possible in a portable way, to "bind" or 
> associate several sockets to the same (local address, local port) 
> pair. Of course,it should be theoretically possible, given that TCP 
> connections would still be different considering the tuple (srcaddr, 
> 4189, dstaddr, 4189) but in practice it isn't:
>
> After the first "listening" socket, the PCE would, for each persistent 
> peer,
> (i) create a socket SOCK_STREAM,
> (ii) bind it to nodeid/4189 and
> (iii) connect to remote peer/4189.
>
> The first bind system call may fail depending on how the server is 
> listening for connections (even worse, it some systems the bind system 
> call may hijack the listening socket) or the second peer bind would 
> fail since it would try to  bind to the same local address/port. For 
> example, the GNU/Linux man page for bind is clear: ip(7) "Only one IP 
> socket may be bound to any given local (address, port) pair". In 
> technical terms, PCEP requires duplicate bindings at the socket level. 
> Some systems may implement SO_REUSEPORT (1) socket option which could 
> allow that, although it main use is to bind multicast addresses, or 
> enable some sort of load sharing amongst TCP listeners in several 
> threads. Unfortunately this is not implemented for example in 
> GNU/Linux, although some non-official patches have been proposed (2). 
> It is not clear whether it will be integrated or not.
>
> Our workarounds seem to be either: allow clients to bind to port 0 
> (ephemeral port) and use such allocated (dynamic) port (which is not 
> compliant with RFC), or set IP aliases so each bind uses a different 
> local address (we may need as many local addresses as peers, and some 
> "mapping" to uniquely identify a PCE).
>
> For what is worth, in my humble opinion the standard RFC is too strict 
> requiring that all (client) sockets bind to port 4189
>
>
> In summary we would appreciate your views on this:
>
> a) what's the reasoning to force clients to bind on 4189 rather than 
> say like in http? -- sometimes it is argued that this simplifies 
> management such as firewall rules, etc. but I do not agree --
>
> b) why limit to a single PCEP connection between two peers (other than 
> a direct consequence of a) ), rather than allowing several parallel 
> connections, provided that hosts use a single IP address and thus they 
> can be identified?
>
> c) As potential PCE implementers, have you encountered this issue, did 
> you work around it? Are we missing something obvious?
>
>
>
> Any feedback is appreciated
>
> Best regards,
>
> Ramon
>
>
> (1) http://wiki.treck.com/Socket_Options
>
> (1) http://marc.info/?l=linux-netdev&m=127165882728524&w=2 
> <http://marc.info/?l=linux-netdev&m=127165882728524&w=2>
>

Gmane