Salut Cyril, all
On 08/02/2011 09:55 AM, Margaria, Cyril (NSN - DE/Munich) wrote:
Hi,
If I understand correctly the problem PCE (i+1) has complete knowledge
the inter AS link (i+1) -> i but not the i->(i+1) link properties
(upstream).
Or seen the other way round, the PCE(i) does not have the TE link
ASBR(i+1) -> ASBR(i) -- I should say does not have it by OSPF-TE InterAS
extesions -- I nitpick since I humbly believe that, in the spirit of
BRPC, the role of PCE(i+1) should stop at entry ASBR. Reducing paths /
trimming and applying BRPC should be done by PCE(i) eventually in a two
step: interAS + own AS.
First I would tend to understand the following section of RFC5441 as :
PCE (i) can verify the link properties in the i->(i+1) direction
Yes, OSPF-InterAs [RFC5392] addresses this.
This should solve the problem mentioned except in the case the
algorithm require to know the link properties in both direction at the
same time, but the draft does not address this problem either.
Indeed, the problem is _bidirectional_ LSPs. The draft does address this
by "embedding" the upstream link in the BRPC response. For
unidirectional LSPs, the existing method works out of the box. In this
sense, if PCE(i) just constructs a generic graph parsing both opaque
types, it can just apply BRPC as in a multi-area, since its "TED" would
include the InterAs links anyway.
Please indicate if I missed something.
"
In the case of inter-AS TE LSP computation, this also requires adding
the inter-AS TE links that connect the domain(i) to the domain(i+1).
"
For bidirectional it would also need the InterAS TE links that connect
domain(i+1) to domain(i), e.g the TE link advertised by ASBR(i+1).
Hypothetically / theoretically, we have several solutions
* a proxy injects opaque 10 or 11 opaque type 6 advertised by ASBR(i+1)
within domain(i+1) into domain(i) [*]
* some adjacency is brought up between ASBRs which exchange both sides
of the TE link. RFC 5392 seems to exclude this.
* the TE links are included in the response within the PCRep when vspt=1
and some other flag
Thanks
Ramon
[*] RFC5392
4.1. Origin of Proxied TE Information
Section 4 describes how an ASBR advertises TE link information as a
proxy for its neighbor ASBR, but does not describe where this
information comes from.
(...)
to obtain some of the required configuration
information from BGP. Whether and how to utilize these possibilities
is an implementation matter.
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
