Discussion list for Path Computation Element (PCE) - based architecture for computation of paths in MPLS and GMPLS

headers JP Vasseur | 9 Aug 2007 20:02

Hi,

The draft minutes have been posted: http://www3.ietf.org/proceedings/ 
07jul/minutes/pce.txt

Please comments your comments if any by August 24.

JP.

<div>
<blockquote type="cite">Please "send" your comments if any by August 24.</blockquote>
<br><div>
<br><div>Begin forwarded message:</div>
<br class="Apple-interchange-newline"><blockquote type="cite">
<div>From: JP Vasseur &lt;<a href="mailto:jvasseur <at> cisco.com">jvasseur <at> cisco.com</a>&gt;</div>
<div>Date: August 9, 2007 2:02:59 PM EDT</div>
<div>To: <a href="mailto:pce <at> ietf.org">pce <at> ietf.org</a>
</div>
<div>Subject: [Pce] Draft minutes PCE WG Meeting IETF-69</div>
<div><br></div> <div>Hi,</div>
<div><br></div>
<div>The draft minutes have been posted: <a href="http://www3.ietf.org/proceedings/07jul/minutes/pce.txt">http://www3.ietf.org/proceedings/07jul/minutes/pce.txt</a>
</div>
<div><br></div>
<div>Please comments your comments if any by August 24.</div>
<div><br></div>
<div>JP.</div>
<div><br></div>
<div><br></div>
<div>_______________________________________________</div>
<div>Pce mailing list</div>
<div><a href="mailto:Pce <at> lists.ietf.org">Pce <at> lists.ietf.org</a></div>
<div><a href="https://www1.ietf.org/mailman/listinfo/pce">https://www1.ietf.org/mailman/listinfo/pce</a></div> </blockquote>
</div>
<br>
</div>

<div>

<div class="Section1">

<div>

<div>

<p class="MsoNormal"><span lang="EN-GB">Hello all,<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">I have a little comment/suggestion
on PCEP regarding the request Id.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">In section 7.3.1 states
that<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">&ldquo;The
Request-ID-number value combined with the source IP address of the PCC and the
PCE address uniquely <p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">identify the path
computation request context&rdquo;.<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">I agree with that,
however there may be 2 requests with same request Id exchanged on the same
session in <p></p></span></p>

the case of session
between 2 PCEs.

<p class="MsoNormal"><span lang="EN-GB">One Path Request being
sent by PCE#1 to PCE#2 and the other one by PCE#2 to PCE#1.<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">I don&rsquo;t think there
is any problem with that but I am a little concerned about potential
misinterpretation especially<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">in PCErr and PCNotif
message.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">If a PCNtf/PCErr message
contains an RP object, nothing indicates if it is related to the Request from
PCE#1 to PCE#2<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">or the one from PCE#2 to
PCE#1, except the notification/error type and value.<p></p></span></p>

I guess this is why for
instance for the &ldquo;Pending Request cancelled&rdquo; notification there are
2 values. One for PCC and

<p class="MsoNormal"><span lang="EN-GB">one for the PCE.<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">One of the problem, from
an implementation perspective, is that we must first ready the Notification
type/value in order to retrieve<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">the correct PathRequest.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Another problem is if an implementation
does not recognize a given Error type/value, then it can&rsquo;t tell for sure
which PathRequest it<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">is related to.<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">So it seems to me it
would be more consistent to add a bit in the RP object (in the flag field) to
indicate the<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">&ldquo;direction&rdquo;
of the PathRequest.<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">For instance if the bit
is set the Message that carry the RP object is related to the request sent by
the destination of the message.<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">Hence, an RP object would
actually uniquely indentifies a PathRequest.<p></p></span></p>

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

<p class="MsoNormal"><span lang="EN-GB">Regards<p></p></span></p>

<p class="MsoNormal"><span lang="EN-GB">Fabien Verhaeghe</span><span lang="EN-GB"><p></p></span></p>

</div>

</div>

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

</div>

</div>

Hi,

In June this year, the ITU-T Study Group 15 sent us a revised copy of their 
work plan for Optical Transport Network topics. You can see their liaison 
and the work plan at 
https://datatracker.ietf.org/documents/LIAISON/file451.doc. You can cut 
straight to the work plan at 
http://www.itu.int/dms_pub/itu-t/oth/09/01/T09010000010001MSWE.doc.

It is interesting to look through this plan to check for any overlap or 
conflict.

Table 7-1-2 is a long list of IETF drafts and RFCs that are related to the 
work being done by SG15. In addition to periodic emails to notify SG15 of 
new RFCs, we also comment on the content of this table from time to time.

At the moment I can see nothing in the work plan that requires immediate 
comment, but please check for yourselves if you are interested or concerned.

Otherwise, I will send the following simple liaison on 18th August.

Thanks,
Adrian

===

To: ITU-T Q3/15
From: IETF CCAMP and PCE working groups
In response
Subject: Your OTNT Work Plan

Thank you for continuing to share your OTNT work plan through your liaison 
from your June plenary in Geneva. I have made the IETF's CCAMP and PCE 
working groups aware of the work plan, and at this time we do not have any 
issues or concerns to raise resulting from the content of the plan.

Please note that the publication of new RFCs related to the optical control 
plane are notified to SG15 through separate liaisons from time to time, and 
you may wish to update table 7-1-2 accordingly. Please keep us informed as 
your work plan evolves.

Best regards,
Adrian Farrel
IETF Liaison to the ITU-T SG15 on Optical Control Plane 

Hi,

The meeting in Chicago was broadly in support of adopting two I-Ds as 
working group drafts:

- Encoding of Objective Functions in Path Computation Element (PCE)
  communication and discovery protocols
  draft-leroux-pce-of-01.txt

- Diff-Serv Aware Class Type Object for Path Computation Element
  Communication Protocol draft-sivabalan-pce-dste-01.txt

Can you please indicate your opinion.

Now that the inter-AS requirements work is stable, the authors of two I-Ds 
related to the use of PCE for P2MP path computations (Adrian is one of the 
authors) have asked us to look at adopting this work. We think that a little 
more discussion is needed first, and have asked them to present the I-Ds in 
Vancouver so that we can make a decision immediately afterwards. Please have 
a look at the I-Ds and send your comments to the mailing list.

- PCC-PCE Communication Requirements for Point to Multipoint
  Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
  draft-yasukawa-pce-p2mp-req-02.txt

- Applicability of the Path Computation Element (PCE) to
   Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
   and Generalized MPLS (GMPLS) Traffic Engineering (TE)
   draft-yasukawa-pce-p2mp-app-00.txt

Thanks,
JP and Adrian 

Yes for the adoption of these two IDs 

> -----Message d'origine-----
> De : Adrian Farrel [mailto:adrian <at> olddog.co.uk] 
> Envoyé : dimanche 12 août 2007 17:32
> À : pce <at> ietf.org
> Objet : [Pce] New PCE working group I-Ds
> 
> Hi,
> 
> The meeting in Chicago was broadly in support of adopting two 
> I-Ds as working group drafts:
> 
> - Encoding of Objective Functions in Path Computation Element (PCE)
>   communication and discovery protocols
>   draft-leroux-pce-of-01.txt
> 
> - Diff-Serv Aware Class Type Object for Path Computation Element
>   Communication Protocol draft-sivabalan-pce-dste-01.txt
> 
> Can you please indicate your opinion.
> 
> 
> Now that the inter-AS requirements work is stable, the 
> authors of two I-Ds related to the use of PCE for P2MP path 
> computations (Adrian is one of the
> authors) have asked us to look at adopting this work. We 
> think that a little more discussion is needed first, and have 
> asked them to present the I-Ds in Vancouver so that we can 
> make a decision immediately afterwards. Please have a look at 
> the I-Ds and send your comments to the mailing list.
> 
> - PCC-PCE Communication Requirements for Point to Multipoint
>   Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
>   draft-yasukawa-pce-p2mp-req-02.txt
> 
> - Applicability of the Path Computation Element (PCE) to
>    Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
>    and Generalized MPLS (GMPLS) Traffic Engineering (TE)
>    draft-yasukawa-pce-p2mp-app-00.txt
> 
> Thanks,
> JP and Adrian 
> 
> 
> 
> 
> _______________________________________________
> Pce mailing list
> Pce <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
> 

Hi,

> - Encoding of Objective Functions in Path Computation Element (PCE)
>   communication and discovery protocols
>   draft-leroux-pce-of-01.txt
> 
Yes, I support this work. 
One question:
There are 6 OFs are mandatory, so PCE may not need to advertise these 6 OFs to PCC, and PCC can assume that PCE
should support these 6 OFs. If PCE does not, then the error message should be sent to PCC. Is this implied in
this draft?

> - Diff-Serv Aware Class Type Object for Path Computation Element
>   Communication Protocol draft-sivabalan-pce-dste-01.txt
> 
Yse, I support this work.

Regards,

Dan

----- Original Message ----- 
From: "Adrian Farrel" <adrian <at> olddog.co.uk>
To: <pce <at> ietf.org>
Sent: Sunday, August 12, 2007 11:31 PM
Subject: [Pce] New PCE working group I-Ds

> Hi,
> 
> The meeting in Chicago was broadly in support of adopting two I-Ds as 
> working group drafts:
> 
> - Encoding of Objective Functions in Path Computation Element (PCE)
>   communication and discovery protocols
>   draft-leroux-pce-of-01.txt
> 
> - Diff-Serv Aware Class Type Object for Path Computation Element
>   Communication Protocol draft-sivabalan-pce-dste-01.txt
> 
> Can you please indicate your opinion.
> 
> 
> Now that the inter-AS requirements work is stable, the authors of two I-Ds 
> related to the use of PCE for P2MP path computations (Adrian is one of the 
> authors) have asked us to look at adopting this work. We think that a little 
> more discussion is needed first, and have asked them to present the I-Ds in 
> Vancouver so that we can make a decision immediately afterwards. Please have 
> a look at the I-Ds and send your comments to the mailing list.
> 
> - PCC-PCE Communication Requirements for Point to Multipoint
>   Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
>   draft-yasukawa-pce-p2mp-req-02.txt
> 
> - Applicability of the Path Computation Element (PCE) to
>    Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
>    and Generalized MPLS (GMPLS) Traffic Engineering (TE)
>    draft-yasukawa-pce-p2mp-app-00.txt
> 
> Thanks,
> JP and Adrian 
> 
> 
> 
> 
> _______________________________________________
> Pce mailing list
> Pce <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
> 

Hi Dan, 

Thanks for your support.

Please see inline,

> -----Message d'origine-----
> De : Dan Li [mailto:danli <at> huawei.com] 
> Envoyé : lundi 13 août 2007 12:21
> À : pce <at> ietf.org
> Objet : Re: [Pce] New PCE working group I-Ds
> 
> Hi,
> 
> > - Encoding of Objective Functions in Path Computation Element (PCE)
> >   communication and discovery protocols
> >   draft-leroux-pce-of-01.txt
> > 
> Yes, I support this work. 
> One question:
> There are 6 OFs are mandatory, so PCE may not need to 
> advertise these 6 OFs to PCC, and PCC can assume that PCE 
> should support these 6 OFs. If PCE does not, then the error 
> message should be sent to PCC. Is this implied in this draft?

Actually no. What is mandatory is the capability to encode these six OF, and not the support of these six OF on
the PCE.

Also have a look at section 8.1: 

"Also note that it is not mandatory for an implementation to support 
all objective functions defined in section 5."

Hope this clarifies.

Regards,

JL

> 
> > - Diff-Serv Aware Class Type Object for Path Computation Element
> >   Communication Protocol draft-sivabalan-pce-dste-01.txt
> > 
> Yse, I support this work.
> 
> Regards,
> 
> Dan
> 
> ----- Original Message -----
> From: "Adrian Farrel" <adrian <at> olddog.co.uk>
> To: <pce <at> ietf.org>
> Sent: Sunday, August 12, 2007 11:31 PM
> Subject: [Pce] New PCE working group I-Ds
> 
> 
> > Hi,
> > 
> > The meeting in Chicago was broadly in support of adopting 
> two I-Ds as 
> > working group drafts:
> > 
> > - Encoding of Objective Functions in Path Computation Element (PCE)
> >   communication and discovery protocols
> >   draft-leroux-pce-of-01.txt
> > 
> > - Diff-Serv Aware Class Type Object for Path Computation Element
> >   Communication Protocol draft-sivabalan-pce-dste-01.txt
> > 
> > Can you please indicate your opinion.
> > 
> > 
> > Now that the inter-AS requirements work is stable, the 
> authors of two I-Ds 
> > related to the use of PCE for P2MP path computations 
> (Adrian is one of the 
> > authors) have asked us to look at adopting this work. We 
> think that a little 
> > more discussion is needed first, and have asked them to 
> present the I-Ds in 
> > Vancouver so that we can make a decision immediately 
> afterwards. Please have 
> > a look at the I-Ds and send your comments to the mailing list.
> > 
> > - PCC-PCE Communication Requirements for Point to Multipoint
> >   Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
> >   draft-yasukawa-pce-p2mp-req-02.txt
> > 
> > - Applicability of the Path Computation Element (PCE) to
> >    Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
> >    and Generalized MPLS (GMPLS) Traffic Engineering (TE)
> >    draft-yasukawa-pce-p2mp-app-00.txt
> > 
> > Thanks,
> > JP and Adrian 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > Pce mailing list
> > Pce <at> lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/pce
> > 
> 
> 
> _______________________________________________
> Pce mailing list
> Pce <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
> 

Yes to both.

On Aug 12, 2007, at 11:31 AM, Adrian Farrel wrote:

> Hi,
>
> The meeting in Chicago was broadly in support of adopting two I-Ds  
> as working group drafts:
>
> - Encoding of Objective Functions in Path Computation Element (PCE)
>  communication and discovery protocols
>  draft-leroux-pce-of-01.txt
>
> - Diff-Serv Aware Class Type Object for Path Computation Element
>  Communication Protocol draft-sivabalan-pce-dste-01.txt
>
> Can you please indicate your opinion.
>
>
> Now that the inter-AS requirements work is stable, the authors of  
> two I-Ds related to the use of PCE for P2MP path computations  
> (Adrian is one of the authors) have asked us to look at adopting  
> this work. We think that a little more discussion is needed first,  
> and have asked them to present the I-Ds in Vancouver so that we can  
> make a decision immediately afterwards. Please have a look at the I- 
> Ds and send your comments to the mailing list.
>
> - PCC-PCE Communication Requirements for Point to Multipoint
>  Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
>  draft-yasukawa-pce-p2mp-req-02.txt
>
> - Applicability of the Path Computation Element (PCE) to
>   Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
>   and Generalized MPLS (GMPLS) Traffic Engineering (TE)
>   draft-yasukawa-pce-p2mp-app-00.txt
>
> Thanks,
> JP and Adrian
>
>
>
> _______________________________________________
> Pce mailing list
> Pce <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce

Yes to both. 

Thanks

Regards.. Zafar  

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian <at> olddog.co.uk] 
> Sent: Sunday, August 12, 2007 11:32 AM
> To: pce <at> ietf.org
> Subject: [Pce] New PCE working group I-Ds
> 
> Hi,
> 
> The meeting in Chicago was broadly in support of adopting two 
> I-Ds as working group drafts:
> 
> - Encoding of Objective Functions in Path Computation Element (PCE)
>   communication and discovery protocols
>   draft-leroux-pce-of-01.txt
> 
> - Diff-Serv Aware Class Type Object for Path Computation Element
>   Communication Protocol draft-sivabalan-pce-dste-01.txt
> 
> Can you please indicate your opinion.
> 
> 
> Now that the inter-AS requirements work is stable, the 
> authors of two I-Ds related to the use of PCE for P2MP path 
> computations (Adrian is one of the
> authors) have asked us to look at adopting this work. We 
> think that a little more discussion is needed first, and have 
> asked them to present the I-Ds in Vancouver so that we can 
> make a decision immediately afterwards. Please have a look at 
> the I-Ds and send your comments to the mailing list.
> 
> - PCC-PCE Communication Requirements for Point to Multipoint
>   Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
>   draft-yasukawa-pce-p2mp-req-02.txt
> 
> - Applicability of the Path Computation Element (PCE) to
>    Point-to-Multipoint (P2MP) Multiprotocol Label Switching (MPLS)
>    and Generalized MPLS (GMPLS) Traffic Engineering (TE)
>    draft-yasukawa-pce-p2mp-app-00.txt
> 
> Thanks,
> JP and Adrian 
> 
> 
> 
> 
> _______________________________________________
> Pce mailing list
> Pce <at> lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/pce
> 

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

37	May 2013
29	April 2013
73	March 2013
26	February 2013
15	January 2013
8	December 2012
33	November 2012
28	October 2012
5	August 2012
27	July 2012
19	June 2012
8	May 2012
17	April 2012
36	March 2012
33	February 2012
8	January 2012
6	December 2011
25	November 2011
39	October 2011
35	September 2011
41	August 2011
50	July 2011
3	June 2011
15	May 2011
6	April 2011
30	March 2011
26	February 2011
9	January 2011
9	December 2010
8	November 2010
20	October 2010
27	September 2010
18	August 2010
29	July 2010
15	June 2010
5	May 2010
11	April 2010
32	March 2010
16	February 2010
29	January 2010
33	December 2009
8	November 2009
19	October 2009
42	September 2009
13	August 2009
11	July 2009
7	June 2009
18	May 2009
35	April 2009
51	March 2009
17	February 2009
34	January 2009
21	December 2008
52	November 2008
19	October 2008
40	September 2008
45	August 2008
33	July 2008
24	June 2008
16	May 2008
43	April 2008
53	March 2008
59	February 2008
6	January 2008
3	December 2007
21	November 2007
30	October 2007
53	September 2007
37	August 2007
39	July 2007
39	June 2007
32	May 2007
19	April 2007
77	March 2007
49	February 2007
52	January 2007
24	December 2006
24	November 2006
32	October 2006
9	September 2006
15	August 2006
63	July 2006
71	June 2006
63	May 2006
30	April 2006
28	March 2006
30	February 2006
66	January 2006
7	December 2005
36	November 2005
75	October 2005
26	September 2005
77	August 2005
106	July 2005
12	June 2005

Draft minutes PCE WG Meeting IETF-69

Fwd: Draft minutes PCE WG Meeting IETF-69

PCEP Request ID

Draft liaison #5 - ITU-T Optical Transport Networks Work Plan

New PCE working group I-Ds

RE: New PCE working group I-Ds

Re: New PCE working group I-Ds

RE: New PCE working group I-Ds

Re: New PCE working group I-Ds

RE: New PCE working group I-Ds