Subject: Re: [Pce] I-D Action:draft-king-pce-inter-area-as-applicability-00.txt

From: "Daniel King" <[email-masked]>
Date: Sun, 7 Mar 2010 14:45:19 -0000

Resend. Strangely the original email never made it to the list. 

-----Original Message-----
From: Daniel King [mailto:[email-masked]] 
Sent: 06 March 2010 14:15
To: [email-masked]
Subject: I-D Action:draft-king-pce-inter-area-as-applicability-00.txt

Howdy all, 

I recently submitted a new draft:

Applicability of the Path Computation Element to Inter-Area and Inter-AS
MPLS and GMPLS Traffic Engineering:

http://www.ietf.org/internet-drafts/draft-king-pce-inter-area-as-applicabi
lity-00.txt

The document examines the applicability of the PCE architecture, protocols,
and protocol extensions for computing multi-area and multi-AS paths in MPLS
and GMPLS networks. I plan to present the work in Anaheim (IETF77). As
always I would appreciate any comments or feedback via the list. 

Thanks,
Dan

---

From: Meral Shirazipour <[email-masked]>
Date: Sun, 07 Mar 2010 10:50:44 -0500

Hi Daniel,
  Here are 1-2 quick comments on the draft:

Section 5:
I would add a section 5.5 for Loop Avoidance in the inter-domain case.
Would it be just to say that we count on the peering agreements or the 
H-PCE for loop avoidance.(Then does that mean we don?t need a mechanism 
to detect loops specifically for inter-AS scenarios? What would be the 
definition of a loop here?)

5.2 Inter-AS Bandwidth Guarantees
I think here and in general it would be great to mention some PCE 
inter-layer work. One way to guarantee BW would then be to provision a 
new lower layer connection. (Nested LSP...).

Regards,
Meral

Daniel King <[email-masked]> a Ã©critÂ :

> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: "Daniel King" <[email-masked]>
Date: Wed, 10 Mar 2010 21:34:34 -0000

Hi Meral, 

Thanks for your quick review and response. 

AS looping? I thought if a BGP speaker would see its own AS in the AS_PATH
of a route, it would reject it. ;-) I conceded that loop avoidance is still
a possibility for inter-AS networks, however we need to be careful and limit
the scope and try not to solve the Internet. Mechanisms like AS-path
customization and aggregation perhaps increase the probability of routing
loops, although this can be mitigated by applying local BGP policies, and/or
various path attributes. Although as you point out, we did envisage that
H-PCE is applicable to inter-AS environments as well. Either way the topic
needs discussing in the draft.

The inter-layer aspects are something I never really considered for this
draft, at least not so far. The potential for using PCE to assist in
inter-layer traffic engineering is well known [RFC5623]. The scenario you
mentioned is a good example. Although it would widen this discussion yet
further and also raise the issue of PCE deployment models, perhaps single
PCE with multi-layer visibility, co-operative PCEs or PCEs with VNTM
co-operation, et al. 
	
Br, Dan.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Meral
Shirazipour
Sent: 07 March 2010 15:51
To: Daniel King
Cc: [email-masked]
Subject: Re: [Pce] I-D
Action:draft-king-pce-inter-area-as-applicability-00.txt

Hi Daniel,

Section 5:

Regards,
Meral

---

From: Meral Shirazipour <[email-masked]>
Date: Wed, 10 Mar 2010 17:19:28 -0500

Hi Daniel,
    About the looping issue, I agree with you. However, my concern is 
not about loops in the final path found by the PCEs, but about loops or 
duplicates in the PCEP (PCReq) messages.  In RFC4927 (2007) it is 
mentioned:

4.9.  Loop Avoidance

   In case of multiple-PCE inter-area path computation, there may be
   risks of PCECP request loops.  A mechanism MUST be defined to detect
   and correct PCECP request message loops.  This may rely, for
   instance, on the recording, in the request message, of the set of
   traversed PCEs.

   Also, the returned path in a response message MUST be loop free.

I think a ?PCReq loop? must first be defined. It is not enough to 
compare it to a routing loop, because a PCReq for the same initial 
request might arrive at an intermediate PCE from different adjacent 
PCEs. At what point can the intermediate PCE decide to reject one of 
the PCReq messages because it considers it a loop ? Maybe I am digging 
too much into it?

Cheers,
Meral

Ps: and for loops in the returned path, there are some other more 
original proposals  like MPLS Loop Prevention Mechanism of RFC3063 
(2001) :)

Daniel King <[email-masked]> a écrit :

> Daniel King <[email-masked]> a écrit :
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 11 Mar 2010 16:38:54 -0000

Hi Meral and Dan,

This looks like a reasonable point to cover. There are techniques already in 
place (for example, listing the PCEs to visit in order) to prevent this, 
mechanisms that can be used to detect it, and futures (e.g., hierarchical 
PCE) that mean the problem doesn't arise in some deployments.

Cheers,
Adrian
----- Original Message ----- 
From: "Meral Shirazipour" <[email-masked]>
To: "Daniel King" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, March 10, 2010 10:19 PM
Subject: Re: [Pce]I-D 

Hi Daniel,

4.9.  Loop Avoidance

Cheers,
Meral