Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt

From: JP Vasseur <[email-masked]>
Date: Tue, 9 May 2006 09:54:00 -0400

Hi Dean,

Many thanks for your comments. Replies/Discussion in line,

- No topology or resource information is distributed between domains
    (as mandated per [RFC4105] and [RFC4216]), which is critical to
    preserve IGP/BGP scalability and confidentiality in the case of TE
    LSPs spanning multiple domains.

DC2 - This is practically true but if not, the BRPC procedure can
       still be used.

JP>> Yes, but we want to clarify the fact BRPC does not require any  
topology or resource information distribution across domains. We'll  
reword to clarify.

- While certain constraints like bandwidth can be used across
    different domains, certain other TE constraints like resource
    affinity, color, metric, etc. as listed in [RFC2702] could be
    translated at domain boundaries.  If required, it is assumed  
that, at
    the domain boundary LSRs, there will exist some sort of local  
mapping
    based on offline policy agreement, in order to translate such
    constraints across domain boundaries during the inter-PCE
    communication process.

DC3 - This may also be relaxed as an assumption. These constraints
       may be globally or locally (thus may need mapping) defined,
       but in either case, the BRPC procedure may be applied.

JP>> Well at least not for the cost metric that must be consistent to  
compute the shortest inter-domain constrained path. You're right that  
other metrics apply to the general inter-domain case and are not  
specific to BRPC.

- Each AS can be made of several IGP areas.  The path computation
    procedure described in this document applies to the case of a single
    AS made of multiple IGP areas, multiples ASs made of a single IGP
    area or any combination of the above.  For the sake of simplicity,
    each AS will be considered to be comprised of a single area in this
    document.  The case of an Inter-AS TE LSP spanning multiple ASs  
where
    some of those ASs are themselves made of multiple IGP areas can be
    easily derived from this case by applying the BRPC procedure
    described in this document, recursively.

DC4 - The BRPC procedure in general can be applied to any network
       partitions in the context of (G-)MPLS networks, and so this
       paragraph could be moved to the Intruduction, and at least
       not a hard assumption.

JP>> Agree.

- The domain path (set of domains traversed to reach the destination
    domain) is either administratively pre-determined or discovered by
    some means (outside of the scope of this document).

DC5 - What does this mean ? Thought the domain path is calculated by
       the BRPC procedure.

JP>> nope, the BRPC computes the optimal (shortest) path between a  
source S in Domain A to destination D in Domain B, along a determined  
domain path (can be pre-determined or discovered during the BRPC  
procedure). But, BRPC does not attempt to discover all the domain- 
path, compute for each domain path the best path and return the  
absolute best path.

DC10 Thr BRPC procedure may return x number of path segments where x  
equals
      the number of equal cost paths (ECMP), where two parameters may be
      configurable based on carriers policy. The first is the max  
number for
      x, and the second is the approximates of these paths (costs are
      exactly the same or close enough).

JP> Do you see a strong reason for limiting x ?
The second requirement might indeed be interesting.
WG, any feed-back on this ?

DC11 - It could be reworded to say: After accommodating local policy
        that may be associated with domains that a LSP may traverse,
        if any, the BRPC would guarantee the optimality of inter-domain
        paths end-to-end.

JP> Not quite sure to see your point here ?

Thanks for your comments.

JP.

On May 8, 2006, at 5:57 PM, Dean Cheng ((dcheng)) wrote:

> Dear Authors,
>
> I've got some quick feedback please see the attached (lines inserted
> starting with DC).
>
> Cheers,
> Dean
>
> From: Jean Philippe Vasseur (jvasseur)
> Sent: Thursday, May 04, 2006 1:26 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt
>
> Dear WG,
>
> As agreed during our last WG meeting in Dallas (see the discussion  
> with Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG.  
> We took that opportunity to make several changes based on the  
> comments that we received so far. So new text has been added for  
> clarification, we reworded some sections and more importantly, we  
> removed the specification of the VSPT object and replaced it by a 1- 
> bit new flag in the RP object defined in PCEP.
>
> Comments very welcome.
>
> JP, Raymond, Nabil and Jean-Louis.
>
> Begin forwarded message:
>
>> From: [email-masked]
>> Date: May 4, 2006 3:50:01 PM EDT
>> To: [email-masked]
>> Subject: I-D ACTION:draft-vasseur-pce-brpc-00.txt
>> Reply-To: [email-masked]
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts  
>> directories.
>>
>>
>> Title : A Backward Recursive PCE-based Computation
>>                          (BRPC) procedure to compute shortest inter-
>>                           domain Traffic Engineering Label  
>> Switched Paths
>> Author(s) : J. Vasseur, et al.
>> Filename : draft-vasseur-pce-brpc-00.txt
>> Pages : 14
>> Date : 2006-5-4
>>
>>    This document specifies a Path Computation Element (PCE)-based
>>    procedure to compute inter-domain constrained shortest Traffic
>>    Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol  
>> Label
>>    Switching (MPLS) and Generalized MPLS (GMPLS) networks.  In this
>>    document a domain is referred to as a collection of network  
>> elements
>>    within a common sphere of address management or path computational
>>    responsibility such as IGP areas and Autonomous Systems.
>>
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-vasseur-pce-brpc-00.txt
>>
>> To remove yourself from the I-D Announcement list, send a message to
>> [email-masked] with the word unsubscribe in the  
>> body of the message.
>> You can also visit https://www1.ietf.org/mailman/listinfo/I-D- 
>> announce
>> to change your subscription settings.
>>
>>
>> Internet-Drafts are also available by anonymous FTP. Login with  
>> the username
>> "anonymous" and a password of your e-mail address. After logging in,
>> type "cd internet-drafts" and then
>> "get draft-vasseur-pce-brpc-00.txt".
>>
>> A list of Internet-Drafts directories can be found in
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> Internet-Drafts can also be obtained by e-mail.
>>
>> Send a message to:
>> [email-masked].
>> In the body type:
>> "FILE /internet-drafts/draft-vasseur-pce-brpc-00.txt".
>>
>> NOTE: The mail server at ietf.org can return the document in
>> MIME-encoded form by using the "mpack" utility.  To use this
>> feature, insert the command "ENCODING mime" before the "FILE"
>> command.  To decode the response(s), you will need "munpack" or
>> a MIME-compliant mail reader.  Different MIME-compliant mail readers
>> exhibit different behavior, especially when dealing with
>> "multipart" MIME messages (i.e. documents which have been split
>> up into multiple messages), so check your local documentation on
>> how to manipulate these messages.
>>
>>
>> Below is the data which will enable a MIME compliant mail reader
>> implementation to automatically retrieve the ASCII version of the
>> Internet-Draft.
>> Content-Type: text/plain
>> Content-ID: <[email-masked]>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>
> <draft-vasseur-pce-brpc-00DC.txt>

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

---

From: "Igor Bryskin" <[email-masked]>
Date: Tue, 9 May 2006 12:18:18 -0400

Hi JP,

I have a question for you. Correct me if I am wrong, but my understanding is that path segments for each of the domains are computed independently from each other. Hence the loops are possible. What is the protection against the loops?  Note that just excluding links of previous segments won't do, because the path computation  failure after the exclusions does not necessarily mean that end-to-end path does not exist: the loop might not occur if one or more previous segments would take different (albeit longer) paths,

Thanks,
Igor

  ----- Original Message ----- 
  From: JP Vasseur 
  To: Dean Cheng ((dcheng)) 
  Cc: [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Tuesday, May 09, 2006 9:54 AM
  Subject: Re: [Pce] Fwd: I-D ACTION:draft-vasseur-pce-brpc-00.txt 

  Hi Dean,

  JP>> Yes, but we want to clarify the fact BRPC does not require any topology or resource information distribution across domains. We'll reword to clarify.

  - While certain constraints like bandwidth can be used across
     different domains, certain other TE constraints like resource
     affinity, color, metric, etc. as listed in [RFC2702] could be
     translated at domain boundaries.  If required, it is assumed that, at
     the domain boundary LSRs, there will exist some sort of local mapping
     based on offline policy agreement, in order to translate such
     constraints across domain boundaries during the inter-PCE
     communication process.

  JP>> Well at least not for the cost metric that must be consistent to compute the shortest inter-domain constrained path. You're right that other metrics apply to the general inter-domain case and are not specific to BRPC.

     document.  The case of an Inter-AS TE LSP spanning multiple ASs where

  JP>> Agree.

  JP>> nope, the BRPC computes the optimal (shortest) path between a source S in Domain A to destination D in Domain B, along a determined domain path (can be pre-determined or discovered during the BRPC procedure). But, BRPC does not attempt to discover all the domain-path, compute for each domain path the best path and return the absolute best path.

  DC10 Thr BRPC procedure may return x number of path segments where x equals
       the number of equal cost paths (ECMP), where two parameters may be
       configurable based on carriers policy. The first is the max number for
       x, and the second is the approximates of these paths (costs are 
       exactly the same or close enough).

  JP.

    Dear Authors,

    Cheers,
    Dean

--------------------------------------------------------------------------

      Dear WG, 

      As agreed during our last WG meeting in Dallas (see the discussion with Adrian, acting as CCAMP co-chair), we moved that ID in PCE WG. We took that opportunity to make several changes based on the comments that we received so far. So new text has been added for clarification, we reworded some sections and more importantly, we removed the specification of the VSPT object and replaced it by a 1-bit new flag in the RP object defined in PCEP.

      Comments very welcome.

      Begin forwarded message:

        A New Internet-Draft is available from the on-line Internet-Drafts directories.

                                  domain Traffic Engineering Label Switched Paths

           This document specifies a Path Computation Element (PCE)-based
           procedure to compute inter-domain constrained shortest Traffic
           Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label
           Switching (MPLS) and Generalized MPLS (GMPLS) networks.  In this
           document a domain is referred to as a collection of network elements
           within a common sphere of address management or path computational
           responsibility such as IGP areas and Autonomous Systems.

        To remove yourself from the I-D Announcement list, send a message to 
        [email-masked] with the word unsubscribe in the body of the message.  
        You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
        to change your subscription settings.

        Internet-Drafts are also available by anonymous FTP. Login with the username
        "anonymous" and a password of your e-mail address. After logging in,
        type "cd internet-drafts" and then
        "get draft-vasseur-pce-brpc-00.txt".

        Send a message to:
        [email-masked].
        In the body type:

------------------------------------------------------------------------------

---

From: JP Vasseur <[email-masked]>
Date: Wed, 10 May 2006 09:22:08 -0400

Hi Igor,

On May 9, 2006, at 12:18 PM, Igor Bryskin wrote:

> Hi JP,
>
> I have a question for you. Correct me if I am wrong, but my  
> understanding is that path segments for each of the domains are  
> computed independently from each other. Hence the loops are  
> possible. What is the protection against the loops?  Note that just  
> excluding links of previous segments won't do, because the path  
> computation  failure after the exclusions does not necessarily mean  
> that end-to-end path does not exist: the loop might not occur if  
> one or more previous segments would take different (albeit longer)  
> paths,

As pointed out in the ID, the domain-path is not determined by the  
BRPC procedure: the aim of BRPC is to find the optimal (shortest)  
path across a determined set of domains. So in the case of Inter-AS  
(since in the vast majority of the cases for the IGP case, topology  
are tree-based), it is the responsibility of the domain path  
computation module to avoid loops. Two simple ways to implement this:  
(1) Manual configuration of the domain path on the head-end (in which  
case, the user should make sure of the absence of loop) (2) Rely on  
BGP to find your way to the destination AS. If you want to find all  
possible domain paths, use BRPC for each of them so as to compute to  
absolute best path, there are many ways to achieve this (out of the  
scope of this ID). Another important point here: we discussed the  
ability to record to set of traversed PCE and there will be a  
procedure defined to detect and break loops, should it happen.

Hope that this answers your question.

JP.

> JP>> Well at least not for the cost metric that must be consistent  
> to compute the shortest inter-domain constrained path. You're right  
> that other metrics apply to the general inter-domain case and are  
> not specific to BRPC.
>
> source S in Domain A to destination D in Domain B, along a  
> determined domain path (can be pre-determined or discovered during  
> the BRPC procedure). But, BRPC does not attempt to discover all the  
> domain-path, compute for each domain path the best path and return  
> the absolute best path.
>
>> with Adrian, acting as CCAMP co-chair), we moved that ID in PCE  
>> WG. We took that opportunity to make several changes based on the  
>> removed the specification of the VSPT object and replaced it by a  
>> 1-bit new flag in the RP object defined in PCEP.
>>
>> Comments very welcome.
>>