El 02/08/2011 10:46, Margaria, Cyril (NSN - DE/Munich) escribió:
Hi Ramon,
*From:*ext Ramon Casellas [mailto:[email protected]] **
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.
[Cyril] If one follow strictly the rfc, yes, but the text could be
extended (via errata for example)
[Cyril] : well, for bidirectional LSP you need to check the
properties in both direction, but both direction are not required to
be checked at the same time : PCE (i+1) check the inter-AS link in
direction i+1->i (one direction); PCE (i) check the inter-AS link in
direction i->(i+1).
[Ramon] Yes, good point. I was sticking/assuming BRPC as in current
RFC5441 (narrow minded :) ?) . As you stated BRPC would need to be
extended / clarified to allow this use case, and as far as I understood,
draft-wang covers this, where the TE links that have been
included/excluded by PCE(i+1) should be notifed to PCE(i) as the draft
proposes, shouldn't they?
In case the algorithm really need to consider both te-properties
(upstream and downstream) you would need the TE-properties to be
known by PCE(i). I Currently doubt that such requirement from an
algorithm exist, if there is a example of an algorithm that really
requires it (with BRPC and Dijkstra I think not), its welcomed.
[Ramon] Good point too. Even in intra-domain case, without extra
assumptions such as both TE metrics are equal in both directions, it is
not straightforward to compute the shortest bidirectional path. CSPF can
check both directions of the TE link at the same time to insure that
(asymmetric) unreserved bandwidth for that priority is enough when
considering a link for relaxation. In any case, since only single
InterAS links are to be considered, I agree such requirement is not clear.
The draft does include the inter-as link identifiers (which are known)
but not their TE-properties, so in this regard the draft is not
solving the problem.
So, to get the whole picture, let's try to summarize:
a) If a single entity (PCE(i)) is able to know TE atts for both
directions, current BRPC is ok. RFC5392 does not solve how, and other
routing extensions would be needed, or TE attributes manually provisioned
b) Otherwise, both directions of InterAS links should be checked
independently, but this requires extending RFC5441, PCE(i+1) notifying
of excluded / included links and draft-wang-pce-inter-as-extentions-01
addresses this.
I guess my point, probably not well explained in previous mails, is that
I would slightly prefer a) provided a good solution allows the upstream
InterAS links to be known although I would not object to b) since no
such good solution exists?.
Finally, I am a bit confused by your last statement. If b) is considered
(i.e. independent checking, and link exclusion) what problem is left to
solve? sorry for being dense.
Thanks
R.
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
