Hi Frederick, In the current operation of TE OSPF, the LSRs at each end of a TE link emit LSAs describing the link.The databases in the LSRs then have two entries (one locally generated, the other from the peer)that describe the different 'directions' of the link. For the inter-AS link, there is no IGP peering , so both of the two ASBRs connected by an inter-AS link only has TE link information in one direction(i.e.,the direction from local to remote ASBR).
RFC5392 has extended OSPF to get the basic information about the other direction(i.g., Remote AS Number and Remote ASBR ID). But for other TE properties,such as bandwith, the ASBR can not get the latest information in the reverse direction(i.e.,the direction from remote ASBR to local)timely.In order to solve the problem , RFC5392 has introduced a "proxy" as following: "In order for the CSPF route computation entity to include the link as a candidate path, we have to find a way to get LSAs describing its (bidirectional) TE properties into the TE database.This is achieved by the ASBR advertising, internally to its AS,information about both directions of the TE link to the next AS. The ASBR will normally generate an LSA describing its own side of a link; here we have it 'proxy' for the ASBR at the edge of the other AS and generate an additional LSA that describes that device's 'view' of the link." But how to realize the proxy is a probelm. A method intruduced in my draft has solved this problem simply by selecting the proper inter-AS links and carrying them in a PCRep to let neighbour PCE know which inter-AS link satisfy the required constraints. Thanks a lot. Xuerong Wang / Best Regards Frederick Robinson <frederick.bedf...@gmail.com> 2011-07-22 11:26 收件人 wang.xuer...@zte.com.cn 抄送 JP Vasseur <j...@cisco.com>, pce@ietf.org, pce-boun...@ietf.org 主题 Re: request timeslot for draft-wang-pce-inter-as-extentions-01 Hi Wang, I read the draft. It is interesting but one point isn't clear for me. Why couldn't we extend routing protocol to make border nodes get the bidirectional inter-AS links? Thanks, Frederick > > Hi JP and PCEers, > > Thank you for the promotion.We would like to trigger the > discussion, and greatly appreciate your comments and participatory. > > We add some scenarios to describe why we need to extend BRPC > procedure in the case of computing inter-AS bi-directional path. > > Suppose the inter-AS link fails in one direction(e.g., from C1 to B1). > As border node just have unidirectional inter-AS TE link properties, > for a bi-direction path computation from A to Z, PCE1 doesn't know > that the link from C1 to B1 can not be used. How PCEs select the > inter-AS links for the bidirectional path? > > Similarly,Suppose uni-direction LSP along A1-C-B-Z1 have already been setup. > After that we setup a bi-direction LSP from A to Z, neither PCE1 nor > PCE2 knows that whether the inter-AS link can > satisfy the constraints in both of the directions or not. > > For a bi-direction path computation from A to Z : > PCE2 computes bi-direction optimal paths(i.e.,VSPT): EGZ and FZ. > > Suppose the uni-direction inter-AS link from E to C doesn't satisfy > the constraints. Only inter-AS links C-F,D-E and D-Fcan > satisfy the constraints in bi-direction. But neither PCE1 nor PCE2 > knows that information, they don't know which inter-AS > links should be selected. > Actually the optimal paths between exit BN of AS1 and node Z are > shown in red color bellow, but PCE2 cannot compute > these bi-direction optimal paths by adding the inter-AS links . On > the other hand, PCE1 cannot compute the > bi-direction optimal paths by adding the inter-AS links either (i. > e.,PCE1 can not compute the bi-direction path from A to E and A to F). > > > > Thanks . > > Xuerong Wang / Best Regards -------------------------------------------------------- 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.
_______________________________________________ Pce mailing list Pce@ietf.org https://www.ietf.org/mailman/listinfo/pce
