Subject: [Pce] Re: New draft related to BRPC

From: JP Vasseur <[email-masked]>
Date: Mon, 9 Jul 2007 16:05:02 -0400

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, ... ).

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.

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

Furthermore since you get several paths, would you try to signal two  
TE LSPs in which
case they may end up blocking each other ?

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.

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.

Thanks.

JP.

> Best regards,
> Dan Li & Hongmiao Xia

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

---

From: Dan Li <[email-masked]>
Date: Wed, 11 Jul 2007 19:57:22 +0800

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-masked] 
  Sent: Tuesday, July 10, 2007 4:05 AM
  Subject: Re: New draft related to BRPC

  Hi Dan,

    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. 

  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.

  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.

  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. 

  Thanks.

  JP.

    Best regards,

    Dan Li & Hongmiao Xia

---

From: JP Vasseur <[email-masked]>
Date: Wed, 11 Jul 2007 08:18:11 -0400

Hi Dan,

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

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

---

From: Dan Li <[email-masked]>
Date: Thu, 12 Jul 2007 19:33:59 +0800

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-masked] 
  Sent: Wednesday, July 11, 2007 8:18 PM
  Subject: Re: New draft related to BRPC

  Hi Dan,

    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-masked]
      Sent: Tuesday, July 10, 2007 4:05 AM
      Subject: Re: New draft related to BRPC

      Hi Dan,

        Â 
        Â 
        - If the WG would like to discuss this issue more, we wouldÂ be happy to present it in Chicago.
        Â 
        Â 

      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.

      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.

      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

---

From: JP Vasseur <[email-masked]>
Date: Thu, 12 Jul 2007 08:09:29 -0400

Hi Dan,

> It makes sence :-)

OK we're in sync, thanks.

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

Sure: more precisely, the aim of the ID is to explain why TE  
Aggregation in general
has been rejected by the IETF.

Thanks.

JP.

>> 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.Â
> 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).
>> the first one could not beÂ established successfully.
>> 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  
>> 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.Â
>>