Subject: [Pce] New PCE working group I-Ds

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 12 Aug 2007 16:31:59 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 13 Aug 2007 11:43:14 +0200

Yes for the adoption of these two IDs 

> -----Message d'origine-----
> De : Adrian Farrel [mailto:[email-masked]] 
> Envoyé : dimanche 12 août 2007 17:32
> À : [email-masked]
> 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:
> 
> 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.
>

---

From: Dan Li <[email-masked]>
Date: Mon, 13 Aug 2007 18:20:57 +0800

Hi,

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

>   Communication Protocol draft-sivabalan-pce-dste-01.txt
Yse, I support this work.

Regards,

Dan

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Mon, 13 Aug 2007 12:34:08 +0200

Hi Dan, 

Thanks for your support.

Please see inline,

> De : Dan Li [mailto:[email-masked]] 
> Envoyé : lundi 13 août 2007 12:21
> À : [email-masked]
> Objet : Re: [Pce] New PCE working group I-Ds
> 
> Hi,
> 
> 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

> authors of two I-Ds 
> think that a little

---

From: Jaudelice Cavalcante de Oliveira <[email-masked]>
Date: Mon, 13 Aug 2007 07:41:38 -0400

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

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Mon, 13 Aug 2007 10:01:57 -0400

Yes to both. 

Thanks

Regards.. Zafar  

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Sunday, August 12, 2007 11:32 AM
> To: [email-masked]

---

From: "Dean Cheng \(dcheng\)" <[email-masked]>
Date: Mon, 13 Aug 2007 10:20:15 -0700

Yes to both. 

Dean
> Sent: Sunday, August 12, 2007 8:32 AM
> To: [email-masked]

---

From: Mach Chen <[email-masked]>
Date: Tue, 14 Aug 2007 09:32:00 +0800

Hi,
Yes to both.

Best regards,
Mach

> -----邮件原件-----
> 发件人: Adrian Farrel [mailto:[email-masked]]
> 发送时间: 2007年8月12日 23:32
> 收件人: [email-masked]
> 主题: [Pce] New PCE working group I-Ds
> 
> Hi,
>

---

From: Meral Shirazipour <[email-masked]>
Date: Tue, 14 Aug 2007 00:50:51 -0400

Hi,
  in favor of both I-Ds.

Regards,
Meral

---

From: "fabien.verhaeghe" <[email-masked]>
Date: Tue, 14 Aug 2007 08:38:28 +0200

Hi,

I support both I-Ds.

Regards
Fabien

-----Message d'origine-----

Hi,

Thanks,
JP and Adrian

---

From: "Lucy Yong" <[email-masked]>
Date: Tue, 14 Aug 2007 09:20:54 -0500

Yes to both. 
Cheers,
Lucy

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Sunday, August 12, 2007 10:32 AM
To: [email-masked]
Subject: [Pce] New PCE working group I-Ds

Hi,

Thanks,
JP and Adrian

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Tue, 14 Aug 2007 21:03:31 +0200

> Sent: Sunday, August 12, 2007 5:32 PM
> To: [email-masked]

ok, three comments though: 

- units B-R is from def. speed(bps)-res.capacity(b) -> ? please check
- still unclear to me whether isis pce disc. will or not use a
  separate inst. (cf. gen-app discussion at isis working group)
- question about oscillation effects resulting from opposed obj.
  adv. from diff. pce's

>   Communication Protocol draft-sivabalan-pce-dste-01.txt

architectural impact to be clarified before moving forward i think
that the important disc. point is whether such info obtained from 
TED or via other means

also from <http://www3.ietf.org/proceedings/07mar/minutes/pce.txt>

* 13) Diff-Serv Aware Class Type Object for Path Computation Element 
* Communication Protocol 
* draft-sivabalan-pce-dste-00.txt (Jon Parker - 5mn) [95] 
*
* Pce does not know class pool.
* Dimitri: in interprovider context, how do you assure global
significance?
* Jon: this is an issue not tackled here.
* Adrian: how PCE has knowledge class pool ? You would suggest to build
this knowledge based on IGP 
* flooded information ?
* JP: please respin the draft tackling issue raised by Dimitri
* Not many people red the draft

-> draft still does not seem to address that issue.

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Wed, 15 Aug 2007 14:08:52 +0200

Hi Dimitri,

Thanks for these comments.

Please see inline,

> De : PAPADIMITRIOU Dimitri 
> [mailto:[email-masked]] 
> Envoyé : mardi 14 août 2007 21:04
> À : [email-masked]; [email-masked]
> Objet : RE: [Pce] New PCE working group I-Ds
> 
>  
> 

B is in bps and R is in bps. 
B-R is the actual bandwidth consumption on the link, in bps.
We will clarify the units in next revision.

>   separate inst. (cf. gen-app discussion at isis working group)

ISIS pce disc relies on procedures defined in 4971. 
This is a deployment issue to use same or separate instances.

> - question about oscillation effects resulting from opposed obj.

Would you please clarify and provide an example?

Regards,

JL

> architectural impact to be clarified before moving forward i 
> think that the important disc. point is whether such info 
> obtained from TED or via other means
> 
> * Adrian: how PCE has knowledge class pool ? You would 
> suggest to build this knowledge based on IGP
> * flooded information ?
> authors of two 
> > I-Ds related to the use of PCE for P2MP path computations 
> (Adrian is 
> > one of the
> 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.
> >

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Wed, 15 Aug 2007 22:22:49 +0200

hi j-l 

> From: LE ROUX Jean-Louis RD-CORE-LAN 
> [mailto:[email-masked]] 
> Sent: Wednesday, August 15, 2007 2:09 PM
> To: PAPADIMITRIOU Dimitri; [email-masked]; [email-masked]
> Subject: RE: [Pce] New PCE working group I-Ds
> 
> Hi Dimitri,
> 

i thought that capacity/residual bandwidth was expressed in b
and you were using the term speed for bps - pls check

> This is a deployment issue to use same or separate instances.

do you assume that you would leave such choice possible ? i 
was left with the impression after last isis mtg discussion
that there is a real incentive for making this a recommended
behavior

> Would you please clarify and provide an example?

PCE_1 advertizing OF_1 attracts all demands in normal
conditions while PCE_2 advertizing OF_2 attracts demands
after failure/re-routing or other rare event

hence, you would then be balancing between both PCEs 
after failure and when reverting and back again if the 
failure occur once more (e.g. flapping)

i am not saying this will happen but heterogeneity in
OF advertized may lead to unbalanced request between
PCEs

thanks,
-d.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 15 Aug 2007 18:49:19 -0400

Hi,

Chair hat off

> that there is a real incentive for making this a recommended

Just to avoid confusion: the PCED is being carried within the ISIS
Router Capability TLV, the processing of which is defined in RFC4971.

> OF advertized may lead to unbalanced request between

Which might precisely be a deployment objective.

Thanks.

JP.

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 16 Aug 2007 09:17:13 +0200

hi

> Router Capability TLV, the processing of which is defined in RFC4971.

indeed, i am not referring to 4971 at such, i am referring to the
fact that if exchanging non-routing info w/ is-is result in recommending 
separated instance then the ISIS PCE disc. w-g doc becomes a prime 
candidate for such recommendation. just a matter of consistency.

> Which might precisely be a deployment objective.

then how do you ensure that prevent the oscillation effect ?

thanks,
-d.
> .

---

From: LE ROUX Jean-Louis RD-CORE-LAN <[email-masked]>
Date: Thu, 16 Aug 2007 11:09:55 +0200

>then how do you ensure that prevent the oscillation effect ?

The failure example you provide is solved by fixing flapping with a dampening mechanism, this is not a PCE issue by the way...

Would you please provide a practical example where heterogeneity leads to oscillations?

Regards,

JL

De: dimitri papadimitriou
Date: jeu. 16/08/2007 09:17
À: JP Vasseur
Cc: [email-masked]
Objet : Re: [Pce] New PCE working group I-Ds

hi

thanks,
-d.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 16 Aug 2007 10:30:32 +0100

> candidate for such recommendation. just a matter of consistency.

My understanding of the discussion in the ISIS working group is that:
- They are tending towards believing that there should be a separation 
between
   flooding of IP link-state information and *all* other information
- They think that such a separation might reasonably be handled by using
   multiple (greater than one) instances of ISIS
- They have not yet reached a conclusion as to whether existing extensions
   fall into this category, but there was building opinion that TE 
advertisements
   might be strong candidates for off-loading to a second instance
- The Router Capability TLV would also be up for consideration

No slides for this topic from the ISIS working group in Chicago seem to have 
been posted yet.

The most recent version of the relevant I-D appears to be 
http://www.ietf.org/internet-drafts/draft-ginsberg-isis-genapp-01.txt 
although I know Les was planning some updates as a result of the Chicago 
meeting.

It seems to me that:
1. The ISIS working group is not going to reach a conclusion on this
   in a hurry.
2. When they do reach a conclusion we MUST fall in with it.
3. In the mean time, just as TE and Router Caps are currently
   carried in a single instance, the PCE discovery will be so
   carried.
4. You should all contribute to this discussion on the ISIS mailing list.

Cheers,
Adrian

---

From: JP Vasseur <[email-masked]>
Date: Thu, 16 Aug 2007 08:29:20 -0400

Hi,

On Aug 16, 2007, at 3:17 AM, dimitri papadimitriou wrote:

> fact that if exchanging non-routing info w/ is-is result in  
> recommending separated instance then the ISIS PCE disc. w-g doc  
> becomes a prime candidate for such recommendation. just a matter of  
> consistency.

If the ISIS group leads to the conclusion of using multiple ISIS  
instances
TE related info may be carried within a separate instance, which is  
fine.
As far as the PCED is concerned, the mode of operation is for now
compliant to RFC4971. This may also apply to OSPF at some point
by the way (at least this has been briefly discussed). Anyway, this is
not a PCE related discussion. As far as this ID is concerned, this
won't impact its contents since it is carried within the ISIS Router  
capability.

> then how do you ensure that prevent the oscillation effect ?

You're mixing two issues: the fact that the PCEs announce different
OF does not by itself lead to oscillation. What you describe above
is an example of different use case in normal and failure scenarios
which is perfectly fine if the PCE has been configured for doing so.

JP.

---

From: David Ward <[email-masked]>
Date: Thu, 16 Aug 2007 09:45:23 -0500

Adrian -

At this point, the summary and conclusion you have below is the only path
forward. 

-DWard

---

From: Kenji Kumaki <[email-masked]>
Date: Mon, 20 Aug 2007 17:20:09 +0900

I support these two documents.

Thanks,
Kenji