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.
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.
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.
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
_______________________________________________
Pce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/pce
