Hi Ramon,
From: ext Ramon Casellas [mailto:[email protected]] Sent: Tuesday, August 02, 2011 10:28 AM To: [email protected]; Margaria, Cyril (NSN - DE/Munich) Subject: Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 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. [Cyril] If one follow strictly the rfc, yes, but the text could be extended (via errata for example) 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. [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). 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. 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. 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 [email protected] https://www.ietf.org/mailman/listinfo/pce
