Ramon Casellas <[email protected]> 发件人: [email protected] 2011-08-02 17:52
收件人 "Margaria, Cyril (NSN - DE/Munich)" <[email protected]> 抄送 [email protected] 主题 Re: [Pce] request timeslot for draft-wang-pce-inter-as-extentions-01 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). [Xuerong Wang]:If every ASBR only connect to one ASBR, PCE(i+1)and PCE(i) can check the inter-AS link seprately.But consider following scenario,there are two inter-AS bi-direction links connect to ASBR4(i.e.,link A and link B),PCE2 must let PCE1 know which of them satisfy the constraints in direction i+1->i. Similar situation is the inter-AS bi-direction links connect to ASBR5 (There are two inter-AS bi-direction links connect to ASBR5,i.e.,link C and link D). [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. [Xuerong Wang]:I think PCE(i+1) need not to include TE-properties of inter-AS links, because the selected inter-AS links already satisfy the required constraints,such as bandwith. Perhaps the only TE-property need to carry is TE metrics. But in the case of co-routed bidirectional LSP computation,maybe TE metrics need to be equeal in both directions? Or if there is indeed exist such requirement,the metric can carry in the PCRep too. 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 [Xuerong Wang]:At first,in the case of bidirectional LSP computation,there indeed exist some problem as discussed in the maillist.And RFC5392 also point out the problem.Secondly,inter-AS computation is the very important scenario of PCE application,so we need to solve the problem.RFC5392 introduces a method of IGP proxy,but how to do it is not clear. Proxy method should not be a local mechanism because it is related to the co-operate among different carrier.So at last,how to solve the prolem must be standalized. The method in draft-wang is very simple and valid. 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. [Xuerong Wang]:There are some cases that can not check the both directions of InterAS links independently. I'v described the scenario above in this mail. Thanks R. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
<<image/gif>>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
