Subject: [Pce] path key and brpc

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 14 Jul 2006 14:10:59 +0200

the draft speaks about inter-as comp methods in introduction e.g brpc 
but how the latter can be used in conjunction with pks ?

the draft mentions it may result into two documents (one in ccamp and 
the other in pce wg) -> good idea because path key technique can be used 
independently of the presence of a initial pcc-/pce- pce exchange

the latter would result in the possibility to make use of pks with pd pc

<http://www.ietf.org/internet-drafts/draft-bradford-pce-path-key-00.txt>

   Networking Working Group                        Rich Bradford (Ed) 
   IETF Internet Draft                                    JP Vasseur 
                                                  Cisco Systems, Inc. 
                                                        Adrian Farrel 
                                                   Old Dog Consulting 

   Proposed Status: Standard 
   Expires: December 2006                                                
                                                           June 2006 

                  draft-bradford-pce-path-key-00.txt 

   Preserving Topology Confidentiality in Inter-Domain Path 
   Computation and Signaling 
    
Status of this Memo 
    
   By submitting this Internet-Draft, each author represents that 
   any applicable patent or other IPR claims of which he or she is 
   aware have been or will be disclosed, and any of which he or she 
   becomes aware will be disclosed, in accordance with Section 6 of 
   BCP 79. 
    
   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 
    
   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other 
   documents at any time.  It is inappropriate to use Internet-Drafts 
   as reference material or to cite them other than as "work in 
   progress." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/ietf/1id-abstracts.txt. 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html. 

Bradford, Vasseur and Farrel                                         1 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   Abstract 
    
   Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 
   Label Switched Paths (LSPs) may be computed by Path Computation 
   Elements (PCEs). Where the TE LSP crosses multiple domains, such 
   as Autonomous Systems (ASs), the path may be computed by multiple 
   PCEs that cooperate, with each responsible for computing a segment 
   of the path. 
    
   However, in some cases such as when ASs are administered by 
   separate Service Providers, it would break confidentiality rules 
   for a PCE to supply a path segment to a PCE in another domain, 
   thus disclosing internal topology information. This issue may be 
   circumvented by returning a loose hop and by invoking a new path 
   computation from the domain boundary LSR during TE LSP setup as 
   the LSP enters the second domain, but this technique has several 
   issues including the problem of maintaining path diversity. 
    
   This document defines a mechanism to hide the contents of a 
   segment of a path, called the Confidential Path Segment (CPS). The 
   CPS may be replaced by a path key that can be conveyed in the PCE 
   Communication Protocol (PCEP) and signaled within in a Resource 
   Reservation Protocol (RSVP) explicit route object. 

   Table of contents 
   To be Added 
    
   Conventions used in this document 
    
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
   "OPTIONAL" in this document are to be interpreted as described in 
   RFC-2119 [RFC2119]. 
 
1.      Note 
    
   It must be noted that this document proposes RSVP-TE and PCEP 
   protocol extensions and may eventually result in two separate 
   documents to be discussed in the CCAMP and PCE Working Groups 
   respectively. 
    
2.      Terminology 
     
   ASBR Routers: border routers used to connect to another AS of a 
   different or the same Service Provider via one or more links 
   inter-connecting between ASs. 

Bradford, Vasseur, and Farrel                                        2 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   CPS: Confidential Path Segment. A segment of a path that contains 
   nodes and links that the AS policy requires to not be disclosed 
   outside the AS. 
    
   Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 
    
   LSR: Label Switching Router. 
    
   LSP: Label Switched Path. 
    
   PCC: Path Computation Client: any client application requesting a 
   path computation to be performed by a Path Computation Element.  
     
   PCE: Path Computation Element: an entity (component, application 
   or 
   network node) that is capable of computing a network path or route 
   based on a network graph and applying computational constraints. 
    
   TE LSP: Traffic Engineering Label Switched Path 
    
3.      Introduction 
    
   Path computation techniques using the Path Computation Element 
   (PCE) have been described in [PCE-ARCH] and allow for path 
   computation of inter-domain Multiprotocol Label Switching (MPLS) 
   traffic engineering (TE) Label Switched Paths (LSPs).  
    
   An important element of inter-domain TE is that TE information is 
   not usually shared between domains for scalability and 
   confidentiality reasons ([RFC4105] and [RFC4216]). Therefore, a 
   single PCE is unlikely to be able to compute a full inter-domain 
   path. 
    
   Two routing scenarios can be used for inter-domain TE LSPs: one 
   using per-domain path computation (defined in [PD-PATH-COMP]), and 
   the other using a PCE-based path computation technique with 
   cooperation between PCEs (as described in [PCE-ARCH]). In this 
   second case, paths for inter-domain LSPs are computed by 
   cooperation between PCEs each of which computes a segment of the 
   path across one domain. Such a path computation procedure is 
   described in [BRPC]. 
    
   If confidentiality is required between domains (such as would very 
   likely be the case between ASs belonging to different service 
   providers) then cooperating PCEs cannot exchange path segments or 
   else the receiving PCE and the Path Computation Client (PCC) will 
   be able to see the individual hops through another domain. We 
   define the part of the path which we wish to keep confidential as 
   the Confidential Path Segment (CPS). 
 
Bradford, Vasseur, and Farrel                                        3 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 

   One mechanism for preserving the confidentiality of the CPS is for 
   the PCE to return a path containing a loose hop for the segment 
   internal to a domain that must be kept confidential. The concept 
   of loose hops for the route of an LSP is described in [RFC3209]. 
   The Path Computation Element Communication Protocol (PCEP) 
   supports the use of paths with loose hops, and it is a local 
   policy decision at a PCE whether it returns a full explicit path 
   or uses loose hops. 
    
   If loose hops are used, the TE LSPs are signaled as normal 
   ([RFC3209]), and when a loose hop is encountered in the explicit 
   route it is resolved by performing a secondary path computation. 
   Given the nature of the cooperation between PCEs in computing the 
   original path, this secondary computation occurs at a Label 
   Switching Router (LSR) at a domain boundary and the route is 
   expanded as described in [PD-PATH-COMP]. 
    
   The PCE-based computation model is particularly useful for 
   determining mutually disjoint inter-domain paths such as might be 
   required for service protection. A single path computation request 
   is used. However, if loose hops are returned, the path of each LSP 
   must be recomputed at the domain boundaries as the LSPs are 
   signaled, and since the LSP signaling proceeds independently for 
   each LSP, disjoint paths cannot be guaranteed since the LSRs in 
   charge of expanding the EROs are not synchronized. 
    
   Therefore, using the loose hop technique, path segment 
   confidentiality and path diversity are mutually incompatible 
   requirements. 
 
   This document defines the notion of a Path Key that is a token 
   that replaces a path segment in an explicit route. The Path Key 
   can be encoded as a Path Key Sub-object (PKS) which can be 
   exchanged in PCEP [PCEP] for PCE path computation results and 
   subsequent computation requests, and in RSVP-TE [RFC3209] for 
   signaling of explicit paths. The PKS may also, optionally, be used 
   in recorded routes in RSVP-TE. 
    
   The next section provides the details for this solution. 
    
4.      Path-Key Solution 
    
   The Path-Key solution may be applied in the PCE-based path 
   computation context as follows. A PCE computes a path segment and 
   replaces it in the path reported to the PCC (or another PCE) by 
   one or more sub-objects referred to as the PKS. The entry and 
   boundary LSR of each CPS SHOULD be specified as hops in the 

Bradford, Vasseur, and Farrel                                        4 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   returned path immediately preceding the PKS, but where two PKSs 
   are supplied in sequence the entry node to the second MAY be 
   encoded within the first. The exit node of a CPS MAY be present as 
   a strict hop immediately following the PKS, but MAY also be hidden 
   as part of the PKS and through the use of a subsequent loose hop. 
    
   The PKS, itself, MAY be supplied as a loose hop, but is 
   RECOMMENDED to be used as a strict hop immediately following the 
   hop that indicates the boundary LSR. 
  
4.1.   Mode of Operation 
 
   During path computation, when local policy dictates that 
   confidentiality must be preserved for all or part of the path 
   segment being computed, the PCE associates a path-key with the 
   computed path for the CPS, places its own identifier (its PCE-ID) 
   along with the path-key in a PKS, and inserts the PKS in the path 
   returned to the PCC or the collaborating PCE immediately after the 
   sub-object that identifies the LSR that will expand the PKS into a 
   explicit path hops. This will usually be the LSR that is the start 
   point of the CPS. The PCE that generates a PKS MUST store the 
   computed path segment and the path-key for later retrieval. A 
   local policy SHOULD be used to determine for how long to retain 
   such stored information, and whether to discard the information 
   after it has been queried using the procedures described below. 
   TBD: Need to define the scope of the PKS and spell out the 
   restrictions on Path Key re-use. 
 
   A head-end LSR that is a PCC converts the path returned by a PCE 
   into an explicit route object (ERO) that it includes in the 
   Resource Reservation Protocol (RSVP) Path message. If the path 
   returned by the PCE contains PKSs these are included in the ERO. 
   Like any other sub-objects, the PKS is passed transparently from 
   hop to hop, until it becomes the first sub-object in the ERO. This 
   will occur at the start of the CPS which will usually be the 
   domain boundary. The PKS MUST be preceded by an ERO sub-object 
   that identifies the LSR that must expand the PKS, so the PKS will 
   not be encountered in ERO processing until the LSR that can 
   process it. 
 
   An LSR that encounters a PKS when trying to identify the next-hop 
   retrieves the PCE-ID from the PKS and sends the path-key to the 
   PCE in a PCEP query the details of which will be described in a 
   further revision of this document. 
    
   Upon receiving the path query, the PCE identifies the computed 
   path segment using the supplied path-key, and returns the 
   previously computed path segment in the form of explicit hops to 
 
Bradford, Vasseur, and Farrel                                        5 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   the requesting node. The requesting node inserts the explicit hops 
   into the ERO and continues to process the LSP setup as per 
   [RFC3209]. 
    
   Note that if a PCE fails to expand a PKS, the requesting LSR MUST 
   fail the LSP setup and SHOULD use the procedures associated with 
   loose hop expansion failure [RFC3209]. 
    
5.      PCEP/RSVP-TE Path Key Sub-object 

   The Path Key sub-object (PKS) may be carried in the Explicit Route 
   Object (ERO) of a PCEP PCRep message [PCEP] or an  RSVP-TE Path 
   message [RFC3209]. The PKS is a fixed-length sub-object containing 
   a Path-Key and a PCE-ID. The Path Key is an identifier, or token 
   used to represent the CPS within the context of the PCE identified 
   by the PCE-ID. The PCE-ID identifies the PCE that can decode the 
   Path Key using a reachable IPv4 or IPv6 address of the PCE. 
   Because of the IPv4 and IPv6 variants, two subobjects are defined 
   as follows. 
    
     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |L|    Type     |     Length    |           Path Key            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                    IPv4 address (4 bytes)                     | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
         L 
    
         The L bit SHOULD NOT be set, so that the sub-object 
   represents a strict hop in the explicit route. 
    
         Type 
    
         TBD  Path Key with IPv4 address 
    
         Length 
    
         The Length contains the total length of the subobject in 
   bytes, including the Type and Length fields.  The Length is always 
   8. 
    
         IPv4 address 
    
         An IPv4 address of the PCE that can decode this key. The 
   address used SHOULD be an address of the PCE that is always 

Bradford, Vasseur, and Farrel                                        6 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   reachable, and MAY be an address that is restricted to the domain 
   in which the LSR that is called upon to expand the CPS lies. 
    
     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 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |L|    Type     |     Length    |           Path Key            | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    |                    IPv6 address (16 bytes)                    | 
    |                                                               | 
    |                                                               | 
    |                                                               | 
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
       L 
    
           As above. 
    
       Type 
    
          TBD  Path Key with IPv6 address 
    
       Length 
    
          The Length contains the total length of the subobject in 
   bytes, including the Type and Length fields.  The Length is always 
   20. 
    
       IPv6 address 
    
          An IPv6 address of the PCE that can decode this key. The 
   address used SHOULD be an address of the PCE that is always 
   reachable, but MAY be an address that is restricted to the domain 
   in which the LSR that is called upon to expand the CPS lies. 

6.      Security Considerations 
    
   This document proposes tunneling secure topology information 
   across an untrusted AS, so the security considerations are many 
   and apply to PCEP and RSVP-TE. 
   Issues include: 
  - Security of the CPS (can other network elements probe for 
     expansion of path-keys, possibly at random?). 
  - Authenticity of the path-key (resilience to alteration by 
     intermediaries, resilience to fake expansion of path-keys). 
  - Resilience from DNS attacks (insertion of spurious path-keys; 
     flooding of bogus path-key expansion requests). 

Bradford, Vasseur, and Farrel                                        7 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
7.      Manageability Considerations 
    
   TBD 
    
8.      IANA considerations 
    
   The IANA section will be detailed in further revision of this 
   document. 
    
   For RSVP, it will include code point requests for the three new 
   ERO sub-objects, and a new ErrorSpec Error Code. 
    
   For PCEP, it will include code point requests for the three new 
   computed path sub-objects. 

9.      Intellectual Property Considerations 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology 
   described in this document or the extent to which any license 
   under such rights might or might not be available; nor does it 
   represent that it has made any independent effort to identify any 
   such rights. Information on the procedures with respect to rights 
   in RFC documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
   The IETF invites any interested party to bring to its attention 
   any copyrights, patents or patent applications, or other 
   proprietary rights that may cover technology that may be required 
   to implement this standard. Please address the information to the 
   IETF at [email-masked]. 
    
10.     References 
    
10.1.  Normative References 
    
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate  
   Requirement Levels", BCP 14, RFC 2119, March 1997.  

Bradford, Vasseur, and Farrel                                        8 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 
   and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 
   3209, December 2001. 
    
   [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 
   Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element  
   (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, 
   work in progress.  
      
10.2.  Informational References 
     
   [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation  
   Element (PCE) Architecture", draft-ietf-pce-architecture, work in  
   progress.  
    
   [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation 
   method for establishing Inter-domain Traffic  Engineering (TE) 
   Label 
   Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-
   comp, work in progress. 
    
   [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based 
   Computation 
   (BRPC) procedure to compute shortest inter-domain Traffic 
   Engineering Label Switched Path", draft-vasseur-pce-brpc, work in 
   progress. 
    
   [RFC4105]    Le Roux, J., Vasseur, JP, Boyle, J., "Requirements 
   for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", 
   RFC 4105, June 2005. 
    
   [RFC4216]    Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS 
   Traffic Engineering requirements", RFC 4216, November 2005. 

11.                              Authors' Addresses: 
    
   Rich Bradford (Editor) 
   Cisco Systems, Inc. 
   1414 Massachusetts Avenue 
   Boxborough , MA - 01719 
   USA 
   Email: [email-masked] 
    
   J.-P Vasseur 
   Cisco Systems, Inc. 
   1414 Massachusetts Avenue 
   Boxborough , MA - 01719 
 
Bradford, Vasseur, and Farrel                                        9 
 
 
draft-bradford-pce-path-key-00.txt                        June 2006 
 
   USA 
   Email: [email-masked] 
    
   Adrian Farrel 
   Old Dog Consulting 
   EMail:  [email-masked] 

    

    
    
   Full Copyright Statement  
          
   Copyright (C) The Internet Society (2006). 
    
    This document is subject to the rights, licenses and restrictions 
    contained in BCP 78, and except as set forth therein, the authors 
    retain all their rights. 
       
   This document and the information contained herein are provided 
   on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 
   THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 
   ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 
   PARTICULAR PURPOSE.  

Bradford, Vasseur, and Farrel                                       10 
 


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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 14 Jul 2006 09:13:22 -0400

Hi Dimitri,

On Jul 14, 2006, at 8:10 AM, dimitri papadimitriou wrote:

> the draft speaks about inter-as comp methods in introduction e.g  
> brpc but how the latter can be used in conjunction with pks ?
>

BRPC can be used in conjunction with PKS since the set of returned  
paths by a downstream PCE can be made of loose hops. Path-Keys are  
then accumulate along the computed path.

> the draft mentions it may result into two documents (one in ccamp  
> and the other in pce wg) -> good idea because path key technique  
> can be used independently of the presence of a initial pcc-/pce-  
> pce exchange
>

Indeed.

Thanks.

JP.

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 14 Jul 2006 15:26:27 +0200

hi jp

JP Vasseur wrote:

> paths by a downstream PCE can be made of loose hops. Path-Keys are  then 
> accumulate along the computed path.

as far as my understanding goes on brpc, it says

    Step 2: PCE(n) computes VSPT(n) made of the list of shortest
    constrained path(s) between every BR-en(j,n) and the TE LSP
    destination using a suitable path computation algorithm (e.g.  CSPF)
    and returns the computed VSPT(n) to PCE(n-1).

=> do you mean that you are going to send back a list of asbr's that are 
the head-end of these constraint sp's ?  please detail in your draft

add also the overhead increase in maintaining a set of keys that the 
enitity as to potentially maintain and how long -

thx,
-d.

>> the other in pce wg) -> good idea because path key technique  can be 
>> used independently of the presence of a initial pcc-/pce-  pce exchange
>>
>> <http://www.ietf.org/internet-drafts/draft-bradford-pce-path- key-00.txt>
>>
>>
>>
> .

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 14 Jul 2006 21:03:08 +0200

hi j-p

JP Vasseur wrote:

> Hi Dimitri,
> 
> On Jul 14, 2006, at 9:26 AM, dimitri papadimitriou wrote:
> 
>> hi jp
>>
>> JP Vasseur wrote:
>>
>>> Hi Dimitri,
>> => do you mean that you are going to send back a list of asbr's  that 
>> are the head-end of these constraint sp's ?  please detail in  your draft
>>
> 
> This is already explicitly mentioned in the ID:
> 
>    Each branch of the VSPT tree (path) may be returned in the form  of an
>    explicit path (in which case all the hops along the path segment are
>    listed) or a loose path (in which case only the BR is specified) so
>    as to preserve confidentiality along with the respective cost.

but there is a specific point here if you refer to that section - what 
"loose path" means when stating only the "BR" is listed i.e. it is not 
only a list including the set of BR's facing the upstream domain but 
also the BR's of the downstream domain otherwise i don't see how the 
"complete" loose path can be returned to the head-end LSR

> I'll add a short section pointing to the Path-key ID (after the split  
> of the Path-key ID).
> 
> Yes as pointed out by Adrian yesterday this will be discussed in a  
> further revision of the Path-key ID.

ok -

thanks,
- dimitri.

>>>>    documents at any time.  It is inappropriate to use Internet- Drafts
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
>>>>
>>>>          L
>>>>
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
>>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+
>>>>
>>>>        L
>>>>
>>>>            As above.
>>>>
>>>>        Type
>>>>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 14 Jul 2006 09:31:40 -0400

Hi Dimitri,

On Jul 14, 2006, at 9:26 AM, dimitri papadimitriou wrote:

>> BRPC can be used in conjunction with PKS since the set of  
>> returned  paths by a downstream PCE can be made of loose hops.  
>> Path-Keys are  then accumulate along the computed path.
>
> => do you mean that you are going to send back a list of asbr's  
> that are the head-end of these constraint sp's ?  please detail in  
> your draft
>

    Each branch of the VSPT tree (path) may be returned in the form  
of an
    explicit path (in which case all the hops along the path segment are
    listed) or a loose path (in which case only the BR is specified) so
    as to preserve confidentiality along with the respective cost.

> add also the overhead increase in maintaining a set of keys that  
> the enitity as to potentially maintain and how long -
>

Thanks.

JP.

> thx,
> -d.
>
>>> the draft mentions it may result into two documents (one in  
>>> ccamp  and the other in pce wg) -> good idea because path key  
>>> technique  can be used independently of the presence of a initial  
>>> pcc-/pce-  pce exchange
>>>
>>>                                                   Cisco Systems,  
>>> Inc.
>>>                                                         Adrian  
>>> Farrel
>>>                                                    Old Dog  
>>> Consulting