Dear Julien, PCErs
See inline tagged [Ramon]
On 08/07/2011 03:22 PM, Julien Meuric wrote:
I'm afraid I don't understand the question, sorry :) Just in case, I
did not mean that TE enabled bit was needed. For simplicity, assume
all ABRs are TE enabled.
I think JP was referring to the discussion in Quebec. (If you missed
it like me, audio archives may help to catch up.)
During the meeting, it seemed that "there was a need to know that a
router was TE-enabled to avoid a signaling failure". If it is not
known a priori, it is discovered at signaling time and crankback may
be used. Nonetheless, knowing that the ABR is TE-enabled is not
enough: the links to the destination may still not be TE-enabled, the
available bandwidth may not be enough, the SRLG/administrative groups
may not suit... Thus the extension would only save very few
crankbacks, and might not be worth the effort.
But I note that this is not the use case you have in mind.
[Ramon] thanks for the explanation :) indeed, I consider this two
different things
Second question is what can you do with the OSPF area ID ? I cannot
see any reason for knowing the area ID an ABR is connected to for
inter-area TE LSP computation ?
Being an ABR, R3 can only consider summary-LSAs from the backbone
when building the routing table (according to section 16.2 of
[RFC2328]), so it will not have any inter-area routes in its routing
table, but only intra-area routes from both Area 1 and Area 2.
Consequently, according to section 12.4.3, R3 will originate into
Areas 1 and 2 only summary-LSAs covering destinations in the directly
attached areas. At the same time, router R2, as an ABR connected to
the backbone, will inject into Area 2 summary-LSAs describing the
destinations in Area 0 (the backbone), Area 1 and other areas
reachable through the backbone. (...) This results in a situation
where internal router R4 (or PCE) calculates its routes to
destinations in the backbone and areas other than Area 1 via R2.
(Rcas: although this may be addressed with a virtual link, as RFC3509
mentions later on)
Thanks for providing this. If you believe this is an actual use case,
it may be relevant to the Wenhu's I-D. You also mentions 2 significant
things: it might be a corner case and existing solutions may already
be enough...
[Ramon] I am not sure how "corner" this case is :) but I would guess
that multi-homed areas, with one or more ABRs connected to area 0 and
one or more ABRs connected to "neighbor" areas it's quite common, and
may be improved? I understand that, being OSPF-TE and all areas having
to be attached to Area 0, the restriction simplifies a lot of things
with regard to arbitrary domain meshes. This is to me, as you may guess,
a main argument _against_ what is proposed.
For reference below, consider Figure 1
+-----------------------------+
| Area 0 (v) |
| |
+--A---B--+--C-----D---+--E---+
| | |
| Area 1 X Area 2 | Area 3
| | Z
| Y (u) |
| | |
+---------+------------+------+
So in our use case:
- R4 (or PCE) may want to compute an inter-area path towards some
endpoint at area1. It may also be requested to follow e.g. a domain
sequence within the IRO, listing areas 2 and 1. I would like a clean
way to consider R2 and R3 somehow differently. I believe here that
knowing the ABRs and the involved areas can be "a good thing" e.g. in
minimizing OF codes such as "minimum number of domains". of ocurse,
if there is no virtual link, I can deduce that R2 is attached to Area
0 since it is announcing summary LSAs for Area0 and areas other than
1 but I cannot rely on this.
It looks like there a lots of assumptions here. Per area-PCE function
out of ABRs? If so, why using PCE? The PCE architecture already
provides some solutions to that problem: PCE-capable ABR, virtual link
between PCE and remote areas... Before moving forward, I think the
context should be elaborated.
[Ramon] I would like to decouple the roles of ABR and PCE. Although
deploying PCEs in ABR has some advantages, it is not mandatory. We
consider one PCE per area, which may have several ABRs. I would not
exclude my case :) of "one area, one PCE in the middle" .
Moreover, if being area 2, we have the aforementioned one or more ABRs
towards area 0, one or more ABRs towards area 1 (left/west) and one or
more ABRs towards area 3 (right/east) wouldn't we need 2 or more PCEs
(without considering the PCEs that also should be in the neighboring
areas) ?
- If PCE within Area1 does not support BRPC/VPST,
This reads to me like "if the existing solution is not supported, let
us define a solution". :-) Both scenarios would require upgrade, so
what motives another one?
[Ramon] Agreed :) the fact that PCE with area 1 did not support BRPC was
to simplify the example, in order for the upstream PCE to request only
the "downstream segment".
PCE in Area2 could explicitly select P2P paths from R3, selecting
those ABRs that are directly attached to Area1. Knowing that R2 is
not directly attached to Area1 allows PCE within area 2 to not
request the R2 path.
So it seems that it would help in reducing the number of requests to
be sent. But what if, instead of R3, we have R3a and R3b? It would not
help here, while VSPT does.
[Ramon] Yes, multiple ABRs would almost imply BRPC for performance, yet
the mapping of ABRs to neighboring areas remains the same problem.
Although I do understand your points and current things can somehow be
made to work, allow me a further example. Consider that we want to
compute a Path from (u) to (v) and either we want to honor a domain
sequence (2, 1, 0), or PCE2 does not know of PCE0, or other potential
cases...
1.- PCE2 will select PCE1 (any discovery or assume PCED OSPF
extensions) and send the request.
2.- PCE2 will select PCE0.
3.- PCE0 will receive the request: RP(1, vspt=true) ENDPOINTS(u, v):
4.- It needs to apply BRPC so the upstream PCE will be able to
reduce/trim paths.
- It needs to obtain the entry nodes to the domain. Note that there are
three aspects: a) the domain sequence, the PCE sequence and the location
reachability of endpoints.
If it is only based on reachability, what prevents PCE0 from just
replying the paths { {C, v} {D, v} } ?
If it is based on reachability info plus PCE considerations it has
several choices:
{ A, B } ,
{ C, D } purely based on summaries,
{ A, B, C, D }
others?
Considering the example, it would make sense to restrict the VSPT to A
and B. To select a subset of ABRs (note that the "domain sequence" may
or may not be present):
a) It could use the PCE1 address, but this is mixing things, the entity
acting as a PCC could be located anywhere (e.g. a parent PCE or an NMS).
It should use the source endpoint to select the entry border nodes.
b) it could check the domain sequence (if present 2, 1, 0) identify the
upstream domain (1) or map the requester PCE to a domain (1) using
NEIGH_DOMAIN PCED extensions, but the previous point still applies
c) it could check the domain sequence (if present 2, 1, 0) identify the
upstream domain (1) and select from the border nodes those that are
attached to area 1 (A and B)
d) Other (existing? mechanisms) involve summary / external LSA,
hopefully with different metrics, etc. can we guarantee this?
My personal preference is c) Of course, any subset of entry border nodes
will "work" since PCE1 will end up filtering to its own exit nodes, but
some paths may be wasted?
- Knowing the area ids of the ABRs provides a simple mechanism to
somehow deduce a domain sequence and trigger the approporiate mechanism.
I like "simple". But adding a simple extension to address corner cases
is still introducing complexity somewhere... Currently, the question
is on the use cases for advertising area IDs: there might be some, but
they are not obvious to me yet.
[Ramon] The "cornicity" :) of the proposed use case is not clear yet,
and the simple extension does not change in any form what is currently
available. If you have the info, you may use it. If not, nothing changes.
Finally, somehow unrelated but in a wider scope, I am still wondering
whether "deducing" things directly from summary LSAs rather that from
dedicated opaque information that clearly decouples control and data
plane is the right thing to do. Ideally (augmented) TED info should
be self-contained in opaques :)
Opinions from others about this issue would be valuable.
[Ramon] I guess this last sentence somehow wraps and summarizes my
point. Feedback on this would be greatly appreciated, towards a
self-contained augmented TED with border nodes and reachability info.
Thanks for reading (longer than expected)
R.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
