[Pce] Re: New draft related to BRPC

Thu, 12 Jul 2007 04:53:20 -0700 

Dear JP,

It makes sence :-)

Now I am waitting for your new ID about Virtual Inter-AS TE Links.

Thanks,

Dan
 
  ----- Original Message ----- 
  From: JP Vasseur 
  To: Dan Li 
  Cc: JP Vasseur ; Raymond Zhang ; Nabil Bitar ; JL Le Roux ; Adrian Farrel ; 
[EMAIL PROTECTED] 
  Sent: Wednesday, July 11, 2007 8:18 PM
  Subject: Re: New draft related to BRPC


  Hi Dan,


  On Jul 11, 2007, at 7:57 AM, Dan Li wrote:


    Dear JP,
    Â 
    Thanks for your comments!
    Â 
    Sorry for the late response, please see inline words in Blue.
    Â 
    Best regards,
    Â 
    Dan
    Â 
      ----- Original Message -----
      From: JP Vasseur
      To: Dan Li
      Cc: JP Vasseur ; Raymond Zhang ; Nabil Bitar ; JL Le Roux ; Adrian Farrel 
; [EMAIL PROTECTED]
      Sent: Tuesday, July 10, 2007 4:05 AM
      Subject: Re: New draft related to BRPC


      Hi Dan,


      On Jul 7, 2007, at 6:29 AM, Dan Li wrote:


        Dear the authors of BRPC,
        Â 
        We just published a new draft which we think is worth to be reviewed by 
you:
        http://tools.ietf.org/wg/pce/draft-xia-pce-hybrid-network-00.txt
        Â 
        The purpose of the draft is:
        - This draft is primarily to explain a problem that we think is a real 
deployment scenario;
        - We believe that BRPC can be used to solve the problem;
        - If the WG is in agreement, we would like to propose a few paragraphs 
to be added to [brpc];
        - If the WG would like to discuss this issue more, we would be happy 
to present it in Chicago.
        Â 
        Please let us know what's your suggestion. We greatly appreciate your 
time to look at this new draft.
        Â 


      As you know the whole point of using a Multi-PCE approach with BRPC is to 
compute 
      the shortest inter-domain constrained path (in addition to diverse 
paths, ... ). 
      Â 
      Agree!

      The case you're looking at in this ID (called Hybrid network) can no 
longer guarantee that 
      you'll find the shortest path of course.
      Â 
      Agree!

      Referring to your first example, the most downstream PCE will only see 
the next hops
      to the downstream domain. So even if by using BRPC between the first set 
of domains 
      where you have cooperative PCEs you get the shortest path between the 
source and 
      the set of entry boundary nodes of the first non-PCE domain, this does 
not guarantee 
      you anything in term of path efficiency ... 
      Â 
      The purpose of this ID is try to look at the possible solution where the 
PCEs are not available in all the domains. By using BRPC, we can get the 
shortest inter-domain path. So even we could not get the shortest inter-domain 
path by applying BRPCÂ to all the domains, we still can get the less shortest 
inter-domain path by applying BRPCÂ to most domains. This is kind of best 
effort path computation. 

  But that does not help, since even in the case (PCE-domain)(PCE domain)(non 
PCE domain) you still do not know whether the best
  path up to the exit BR of the second domain is the one you should use. It 
might just be the worst possible path depending on the path
  from the entry BR to the destination in the last domain. This is clearly non 
deterministic. 


  And of course the (non PCE-domain)(PCE domain)(PCE domain) or 
(PCE-domain)(non PCE domain)(PCE domain) cases are even worse.


  Furthermore, in that case, you can also not compute diverse paths for the 
exact same reason (another motivation for using a Multi-PCE
  based approach).
      Furthermore since you get several paths, would you try to signal two TE 
LSPs in which 
      case they may end up blocking each other ?
      Â 
      Only one TE LSP is signalled in this case. Since there are several 
optional TE LSPs, one of the optional TE LSPs may be signalled if the first one 
could not be established successfully.

  OK so that does not give you any quantifiable gain.

      Note that this comment applies to the first two cases of section 2.2


      The case 3 of section 2.2 suggests to use Virtual Inter-AS TE Links: 
please refer to the 
      discussions on the list with regards to TE aggregation: this option has 
been examined 
      a number of times and has been rejected. Adrian and I still have in our 
plate to document this.
      Â 
      Sorry I was not aware of the history of the Virtual Inter-AS TE Links 
discussions. It will be very helpful if someone can give me more details on 
this issue, thanks.

  Stay tuned, we'll try to post an ID soon.

      And of course, if you start to alternate a number of PCE enabled and non 
PCE enabled 
      domains, the result gets not only extremely complex but more importantly 
highly unpredictable 
      in term of path quality.
      Â 
      Maybe the realistic world is not so horrible, the most possible scenario 
is that one of the PCEs is broken in multi-domain network. In this scenario, in 
order to get as much optimal inter-domain path as we can, I think we need try 
to use the BRPC in most domains where the PCEs are still available. Based on 
this understanding, we think it's necessary to clarify how to apply the 
BRPC to the scenarios described in this I-D. 


  See unless you can quantify the potential gain, which you cannot in this 
case, I prefer not to add another layer of complexity.


  Makes sense ?


  Thanks.


  JP.
      Thanks.


      JP.


        Best regards,
        Â 
        Dan Li & Hongmiao Xia








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

Reply via email to